February 2008 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] Configurability of 'keep downloaded packages'
by Stanislav Visnovsky 22 Mar '08

22 Mar '08

Hi! I'm working on the functionality to keep the downloaded packages on disk, not removing them. This needs to be configurable, of course. I'd like to get your views on how much configurability we need. I see at least the following options: 1) global enable/disable 2) per-repository enable/disable 3) per-access protocol enable/disable (CD, HTTP, FTP, NFS, ...) Any opinions? Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

9 24

[zypp-devel] We're going to loose resolvables of kind 'Language'.
by Michael Andres 18 Mar '08

18 Mar '08

We're going to loose resolvables of kind 'Language'. The sat solver allows to handle language supporting packages the way as e.g. hardware supporting packages, via namespaces. So there is no more need to create those dummy language-resolvables. That's nice because the satpool does not allow to have solvables without a repository. So we don't have to create a dummy repository just to maintain those dummy resolvables. The zypp interface will basically stay the same: void setRequestedLocales( const LocaleSet & locales_r ); LocaleSet getRequestedLocales() const; LocaleSet getAvailableLocales() const; May be we add some convenience methods. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 4

[zypp-devel] Verify system feature dropped?
by Katarina Machalkova 07 Mar '08

07 Mar '08

Hi, zypp hackers, while working on ncurses package selector redesign I have found out that yet another thing has been dropped (deprecated/obsoleted/temporarily unavailable) from zypp silently, without communicating this fact to those who are using the feature. In this case, maintainers of package selectors. Facts: FaTE #301178 "Offer 'verify installed package dependencies' functionality in YaST" mandatory/important for SLE10 SP1 important for openSUSE 10.3 Requested by: kkaempf(a)novell.com Project Manager: visnov(a)novell.com (adding those to Cc:) After selecting 'Verify system' entry from package selector menu, solver run should check package dependencies and take appropriate action to restore the consistency of the system (e.g. mark missing packages for installation) However, this never happens, I'm getting false-positive result that all dependencies are correct (which is obviously not true) and this message in the log: Resolver.cc (verifySystem): Will currently not be supported by the SAT-solver Maybe I'm not having the most recent version of SAT-solver and this issue would be already settled if I made fresh svn checkout. In that case you may disregard this e-mail. Anyway, as this feature was mandatory, I believe it should not be dropped without adequate substitute. Moreover, it has been requested for zypper, too (FaTE #301918 - adding jkupec to Cc:). As this is not the first thing dropped/made obsolete from zypp more or less silently, I'd really appreciate if (in the future) we would be informed about such changes and about adequate replacement functionality (if any). Better late, than never at all (finding this out sheerly by accident). Zypp is a library that is used by other applications (package selectors, zypper,...) and without them, it's just dead kilo-lines of code in subversion. frozenB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

3 4

[zypp-devel] collect pending AIs thread
by Duncan Mac-Vicar P. 06 Mar '08

06 Mar '08

Hi guys, I would like to collect in this thread all details that we need to address in the next weeks. You can incrementally reply to this thread and I will put them all together. I start with: - patch and delta rpm creation - fix attributes to take care of translations - integrate patch & pattern concepts (wrap APIs, etc) - fix UIs to support this patches and patterns (including the applet) - enhance downloader to download .solv files - take care of media.1 for media verification (either download it when downloading solv files only, or store it in solv file) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

9 19

[zypp-devel] Selectables and 'candidate'
by Jan Kupec 01 Mar '08

01 Mar '08

Let's agree on what a candidate is (installation candidate, right?). Is it one of the resolvables (or pool items) of a Selectable considered to be the most suitable to be selected for installation based on current setup of policies? Is it just a hint for the solver about what should be installed in case the user doesn't specifically choose another version? Is the 'candidate' tied to a particular Selectable or is it rather a candidate of multiple Selectables (the whole pool perhaps)? Klaus suggested the term 'candidate' is misleading. Why? If the candidate is for some reason not installable (which will be determined by solving), is there a problem with still calling it a candidate? Candidate != to-be-installed, right? If the answers are positive, the Selectable::candidate() should return the candidate based on current policies and should be used by the UIs to mark it for installation (if user clicked to install the selectable (no specific version)) and by the solver to mark it for installation to satisfy some dependencies. And that's just about it. If not, please correct me. Anything else? I hope i'm not messing things up :O) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

12 24

[zypp-devel] XML output for zypper
by Jan Kupec 29 Feb '08

29 Feb '08

Hi there! zypper -x (--xmlout) is almost done. The main features (currently in svn, to be in zypper-0.10.2) include: * all output in XML: info, warning, error messages, progress/download progress, prompts, * uniquely identified user dialogs (prompts) * enumerated possible dialog answers (comming soon: prompt help) * query command results as xml data - list-updates (obsoletes the xu command) uses the established update info xml structure from zypp-check-patches/zypper xu - repos - search (TODO) - patches (TODO) - info (TODO) * other special information as xml data - install summary * common types of output (messages, progress) are written using classes derived from Out class (OutNormal, OutXML) so this type of output can easily be changed/extended, new class can be added (e.g. OutColored). Output examples attached. I have left the <update-status> subtree compatible with zypp-check-patches, but i've changed the rest of the xml written by 'zypper --terse xu' [2] (used by the updater applets) a bit as i believe it is only used by the applets so far, which we can adapt. There is an RNC scheme at [0], which will get installed to /usr/share/zypper/$somewhere/xmlout.rnc. I will also update [2] http://en.opensuse.org/Standards/Zypper_Xml after the code freeze. Also there is prompt.h header file at [1] with an enum of the prompt IDs and their description (TODO) which i plan to get installed into /usr/include/zypper/prompt.h. As for zypper commands and options: - I would like to drop the xu command in favor of 'zypper -x lu -t package -t patch'. - Also, i'd like to use the --terse option for other type of machine-readable output (like zypper repos printing the table without header and decoration). For 11.0 it should be just ignored (provided only for rug-compatibility). IMO we can afford dropping these, as they were only used by the updater applets so far (probably :O). XML input is not implemented yet, but eventually will be. So go ahead and play with it, feedback is welcome! Cheers, jano [0] http://svn.opensuse.org/svn/zypp/trunk/zypper/src/output/xmlout.rnc [1] http://svn.opensuse.org/svn/zypp/trunk/zypper/src/output/prompt.h [2] http://en.opensuse.org/Standards/Zypper_Xml

1 0

[zypp-devel] zypper dup shortcoming
by Michael Andres 27 Feb '08

27 Feb '08

As people are encouraged to use 'zypper dup', we get some reports which describe problems arising from the fact that we update the update stack in the running system. After installing the new libzypp, zypper continues the transaction and is still using the old lib. While the new libzypp converts and removes obsoltete locations (like the cache store or the obsolete sql databases) in it's post install script, the zypper running still tries to access these locations. Maybe zypper should check whether the update stack needs an update, and handle this specially. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 5

[zypp-devel] Re: [CruiseControl] zypp-trunk build 8907 failed
by Michael Matz 25 Feb '08

25 Feb '08

Hi, On Mon, 25 Feb 2008, zypp-devel(a)opensuse.org wrote: > The build failed. > > See http://gabbai.suse.de:3333/builds/zypp-trunk/8907 for details. > (only SUSE-internal) > > /usr/include/zypp/ByteCount.h:80: Warning(503): Can't wrap 'operator size_type' unless renamed to a valid identifier. > /usr/include/zypp/repo/RepoType.h:62: Error: '__eq__' is multiply defined in the generated module. > /usr/include/zypp/Pathname.h:154: Error: Previous declaration of '__eq__' Can someone who feels responsible for python PLEASE fix those bloody bindings, which fail to compile since weeks?! Or remove them, or something. It makes no sense to have an automatic compile checker if noone looks at them or fixes bugs exposed there. >From the looks of it it rather seems that SWIG is broken as it thinks that namespace zypp { namespace filesystem { bool operator==( const Pathname & l, const Pathname & r ); }} and namespace zypp { namespace repo { bool operator==(const RepoType & obj1, const RepoType & obj2); }} are the same, which clearly they aren't. I have no idea about SWIG. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] rpmlib dependencies
by Stefan Schubert 25 Feb '08

25 Feb '08

Hi, while generating testcases I recognized that the pool has rpmlib dependencies. These dependencies will be added to the testcases. Former libzypp parsers (helix paser) have dropped this kind of dependency. How will be managed this in the SAT solver-pool ? P.S.: This code will never be touched by rpmlib dependencies: function : pool_addrelproviders /* make our system solvable provide all unknown rpmlib() stuff */ if (plist.count == 0 && !strncmp(id2str(pool, name), "rpmlib(", 7)) { queue_push(&plist, SYSTEMSOLVABLE); } Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Re: [zypp-commit] r8851 - /trunk/libzypp/zypp/sat/Solvable.cc
by Michael Matz 22 Feb '08

22 Feb '08

Hi Duncan (and others), On Thu, 21 Feb 2008, matz(a)svn.opensuse.org wrote: > Author: matz > Date: Thu Feb 21 16:39:05 2008 > New Revision: 8851 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8851&view=rev > Log: > We need to add mediadir also in the non-trivial case. This and the last commit to satsolver/tools/repo_rpmmd.c fix a bug in parsing of susetags repos which look like our full trees (i.e. no revisions in the rpm filename), unfortunately it necessarily breaks handling of the media file with already generated SOLV files from yum repos. You need to update those, once this libsatsolv and libzypp is submitted, or already now if you use SVN. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 4

[zypp-devel] Deleting unmaintained packages
by Stefan Schubert 22 Feb '08

22 Feb '08

Hi, While updating the system we have a flag "delete unmaintained packages" which has the default setting "off" (I assume :-) ) but can be changed to "on" by the user. That means that packages for which no update is available and their vendor begin with "suse" will be deleted. Meanwhile (we can have more than one product on a system) this behaviour is wrong. E.G. if you have installed opensuse and a SLES product on your system and update the SLES product, all packages of opensuse will be deleted which are not updated by the SLES product. Ma ( We have too many Michaels in the team, so I take the login name :-) ) has suggested to delete not supported packages if they have unfulfilled dependencies only (Not regarding the vendors anymore). This list should be shown to the user who can decide how to go on. Any other opinions ? Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 11

Re: [zypp-devel] zypper-devel rpm on buildservice (zypp:svn) missing libraries (Selection.h and Language.h)?
by gryffus＠hkfree.org 21 Feb '08

21 Feb '08

Stephan Kulow napsal(a): > Am Donnerstag 21 Februar 2008 schrieb Stanislav Visnovsky: >> I've seen Coolo fixing these problems in SVN. Try to use YaST SVN trunk. > > Yeah, Gryffus stayed up all night till someone woke up and fixed it :) > > Greetings, Stephan > And imagine that sweet sleep with the feeling, that i can compile YaST gtk lol :-)) Thx again - C0010 iz teh r0xx0rz :-))) Gfs -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] [patch] Keep downloaded packages
by Stanislav Visnovsky 21 Feb '08

21 Feb '08

Hi! Could you, please, review the attached patch for libzypp? It implements the feature to keep the downloaded packages on disk cache and it's able to reuse existing cached files. The patch applies cleanly against trunk, almost applies against jump_sat ;-) The downloaded packages are stored (by default at) /var/cache/zypp/packages/<alias>/<arch>/<package>.rpm Keep packages behavior is enabled/disabled by repository. Add 'keeppackages=1' to .repo file. The configuration: zypp.conf ========= Added 'packagesdir' option to zypp.conf to re-define a prefix to keep the downloaded packages. Default is '/var/cache/zypp/packages' a.repo ===== Added 'keeppackages' option to .repo parser. Set to 1 to keep the packages. Stano

3 4

[zypp-devel] "resume downloads" feature
by Cristian Rodríguez 21 Feb '08

21 Feb '08

Hi all: now that zypp has the ability to save downloaded packages seems natural to implement a "resume" functionality so packages that were partially downloaded because of user interruption and/or network errors can be finished without having to download the whole complete package. This feature may be specially useful for slower links in combination with big packages like openoffice and may help saving signficant bandwidth, enhacing user experience. Is there any plan to implement this ? ( Curl already has built-in support for this btw..) Thanks for yoru attention.. -- "Morality is merely an interpretation of certain phenomena — more precisely, a misinterpretation." - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] zypper-devel rpm on buildservice (zypp:svn) missing libraries (Selection.h and Language.h)?
by Gryffus 21 Feb '08

21 Feb '08

Hello hackers! I try to compile yast2, but i have stucked at compiling gtk module.... The error says: make all-recursive make[1]: Entering directory `/home/gryffus/yast-svn/trunk/gtk' Making all in src make[2]: Entering directory `/home/gryffus/yast-svn/trunk/gtk/src' CXX yzyppwrapper.lo In file included from /usr/include/c++/4.3/ext/hash_map:64, from /usr/include/YaST2/ycp/YCode.h:228, from /usr/include/YaST2/ycp/YStatement.h:28, from /usr/include/YaST2/ycp/ExecutionEnvironment.h:22, from /usr/include/YaST2/ycp/y2log.h:16, from yzyppwrapper.cc:12: /usr/include/c++/4.3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. yzyppwrapper.cc:18:28: error: zypp/Selection.h: No such file or directory yzyppwrapper.cc:21:27: error: zypp/Language.h: No such file or directory yzyppwrapper.cc:40: error: 'zypp::Language' has not been declared yzyppwrapper.cc:40: error: expected initializer before 'ZyppLanguage' yzyppwrapper.cc:47: error: 'ZyppLanguage' does not name a type yzyppwrapper.cc: In member function 'std::string Ypp::Package::provides()': yzyppwrapper.cc:406: error: expected initializer before '&' token yzyppwrapper.cc:407: error: 'zypp::CapSet' has not been declared yzyppwrapper.cc:407: error: expected `;' before 'it' yzyppwrapper.cc:408: error: 'it' was not declared in this scope yzyppwrapper.cc:408: error: 'capSet' was not declared in this scope yzyppwrapper.cc: In member function 'std::string Ypp::Package::requires()': yzyppwrapper.cc:420: error: expected initializer before '&' token yzyppwrapper.cc:421: error: 'zypp::CapSet' has not been declared yzyppwrapper.cc:421: error: expected `;' before 'it' yzyppwrapper.cc:422: error: 'it' was not declared in this scope yzyppwrapper.cc:422: error: 'capSet' was not declared in this scope yzyppwrapper.cc: In member function 'bool Ypp::Package::fromCollection(Ypp::Package*)': yzyppwrapper.cc:444: warning: 'std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > zypp::Pattern::install_packages(const zypp::Locale&) const' is deprecated (declared at /usr/include/zypp/Pattern.h:53) yzyppwrapper.cc:456: error: 'ZyppLanguage' was not declared in this scope yzyppwrapper.cc:456: error: expected `;' before 'language' yzyppwrapper.cc:459: error: expected initializer before '&' token yzyppwrapper.cc:460: error: 'zypp::CapSet' has not been declared yzyppwrapper.cc:460: error: expected `;' before 'it' yzyppwrapper.cc:461: error: 'it' was not declared in this scope yzyppwrapper.cc:461: error: 'capSet' was not declared in this scope yzyppwrapper.cc:462: error: 'language' was not declared in this scope yzyppwrapper.cc: In function 'Ypp::Package::Version* constructVersion(ZyppObject)': yzyppwrapper.cc:666: warning: 'zypp::Repository zypp::ResObject::repository() const' is deprecated (declared at /usr/include/zypp/ResObject.h:126) yzyppwrapper.cc: In member function 'GSList* Ypp::Impl::getPackages(Ypp::Package::Type)': yzyppwrapper.cc:1324: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1324: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1324: error: no matching function for call to 'zypp::ResPoolProxy::byKindBegin()' yzyppwrapper.cc:1325: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1325: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1325: error: no matching function for call to 'zypp::ResPoolProxy::byKindEnd()' yzyppwrapper.cc: In constructor 'Ypp::Ypp()': yzyppwrapper.cc:1391: error: 'Selection' is not a member of 'zypp' yzyppwrapper.cc:1391: error: 'Selection' is not a member of 'zypp' yzyppwrapper.cc:1391: error: no matching function for call to 'zypp::ResPoolProxy::saveState()' yzyppwrapper.cc:1392: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1392: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1392: error: no matching function for call to 'zypp::ResPoolProxy::saveState()' yzyppwrapper.cc: In member function 'bool Ypp::isModified()': yzyppwrapper.cc:1414: error: 'Selection' is not a member of 'zypp' yzyppwrapper.cc:1414: error: 'Selection' is not a member of 'zypp' yzyppwrapper.cc:1414: error: no matching function for call to 'zypp::ResPoolProxy::diffState()' yzyppwrapper.cc:1415: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1415: error: 'Language' is not a member of 'zypp' yzyppwrapper.cc:1415: error: no matching function for call to 'zypp::ResPoolProxy::diffState()' make[2]: *** [yzyppwrapper.lo] Error 1 make[2]: Leaving directory `/home/gryffus/yast-svn/trunk/gtk/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gryffus/yast-svn/trunk/gtk' make: *** [all] Error 2 I have searched for the 2 libraries (Selection.h and Language.h) and found them in some older rpms (i.e. dipe repository), but not in the one on zypp:svn repository... It is a yast error, or zypper error? Thanx Gryffus -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2

[zypp-devel] Fetcher and hardlinking
by Duncan Mac-Vicar P. 18 Feb '08

18 Feb '08

Right now Fetcher copies identical files from the configured caches to the destination path. When downloading metadata, Fetcher uses a tmp directory to download all metadata, and it gets identical files from the repos raw metadata directories. Normally, the raw metadata dir of the same repo we are downloading is the best candidate to have the identical files. Then the original repo dir is renamed to something tmp too, and the tmp dir is renamed to the repo raw metadata dir (this allows to keep always consistant raw metadata copies). I have experimented locally so when a identical file is found in a previous cache, I hardlink instead of copy, at the end I don't care which directory is deleted first, because hard links are "refcounted". My refresh is much faster now. But Fetcher is also used in other places appart of repository metadata download, and there, I have no idea if the cache dirs are in different filesystem than the destination directory. I tested and ln will fail. Can I do hardlink by default, and fallback to copy? Is there anything else I could be missing? If not, I will commit this :-) Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 4

[zypp-devel] zypp contribution
by Rémy Marquis 17 Feb '08

17 Feb '08

"If you are an openSUSE contributor, we do need help with testing, and there are lot of “mechanical” jobs to do which don’t require much experience with the platform (but compiling). If you want to see this in 11.0 and can contribute, please contact us ." Hello all, I'm following discreetly zypp development since a few months, the next zypp look very promising :) I'm currently using the factory version (in fact, the 10.3 with the last yast packages), so I test libzypp/zypper each days and sometime I report some bugs. I just d/l the last trunk svn version of zypp, and gcc is ready to work. I don't really have lot of time, but if you have some "boring" job that I can do to help, I'll be happy to do it, just show me the way :) Regards, Rémy -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 13

[zypp-devel] repomanager doing unwanted refresh?
by Michael Andres 17 Feb '08

17 Feb '08

JFYI: <4> -------------------------------------- <4> - alias : full 10.3 <4> - url : dir:///dist/10.3-i386 <4> - path : <4> - type : yast2 <4> - enabled : 1 <4> - autorefresh : 0 autorefresh is off <4> - gpgcheck : 0 <4> - gpgkey : <4> - keeppackages : 0 <4> <4> refreshMetadata <1> calvin(8888) [zypp] RepoManager.cc(checkIfToRefreshMetadata):406 Going to try to check whether refresh is needed for dir:///dist/10.3-i386 but RepoManager checks, and <1> chmod /Local/ROOT/raw_cache/full 10.3RuVsrX 040755 <1> initializing.. <0> Rewriting url dir:///dist/10.3-i386 <1> Trying scheme 'dir' <1> MediaDIR::MediaDIR(dir:///dist/10.3-i386) <1> Opened: dir(dir:///dist/10.3-i386 not attached; localRoot "") <0> Opened new media access using id 1 to dir:///dist/10.3-i386 <0> Going to try to provide file /content from media number 1 <0> attach(id=1) <5> MediaDIR.cc(attachTo):88 THROW: MediaDIR.cc(attachTo):88: Specified path '/dist/10.3-i386' is not allowed as media source: dir:///dist/10.3-i386 <0> MediaHandler - checking if to remove attach point <5> MediaHandler.cc(attach):651 RETHROW: MediaDIR.cc(attachTo):88: Specified path '/dist/10.3-i386' is not allowed as media source: dir:///dist/10.3-i386 <5> MediaSetAccess.cc(provideFileInternal):223 CAUGHT: MediaHandler.cc(attach):651: Specified path '/dist/10.3-i386' is not allowed as media source: dir:///dist/10.3-i386 <0> Media couldn't provide file /content , releasing. <0> release(id=1) <0> Request to release media - not attached; eject 0 <0> ProvideFile exception caught, callback answer: 0 <0> Aborting fails (that's why it was turned off) Someone able to reproduce this as well? Note that I'm relocating the caches via zypp.conf to /Local/ROOT/raw_cache/. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Re: [zypp-commit] r8690 - in /trunk/sat-solver/src: repo.c repo.h
by Michael Schroeder 16 Feb '08

16 Feb '08

On Thu, Feb 14, 2008 at 04:09:58PM -0000, kkaempf(a)svn.opensuse.org wrote: > Author: kkaempf > Date: Thu Feb 14 17:09:57 2008 > New Revision: 8690 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8690&view=rev > Log: > add a generic attribute lookup function 'repo_lookup' IMHO makes no sense, you should be using repo_search. Cheers, Michael. -- Michael Schroeder mls(a)suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] zypper dup
by Stephan Kulow 15 Feb '08

15 Feb '08

Hi, Matz fixed the crash, but now I have the following (after a lot of time :) coolo@desdemona#build>sudo ./src/zypper dup Reading installed packages... 1184 Probleme: Problem: yast2-pkg-bindings-2.16.12-15.3.x86_64 is not installable Problem: libzypp-4.2.1-2.2.x86_64 is not installable Problem: zypper-0.9.6-5.9.x86_64 is not installable ..... Not suprisingly x86_64 is not installable here Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 16

[zypp-devel] Re: [zypp-commit] r8702 - in /trunk/sat-solver/tools: repo2solv.sh repo_susetags.c repo_susetags.h susetags2solv.c
by Klaus Kaempf 15 Feb '08

15 Feb '08

* matz(a)svn.opensuse.org <matz(a)svn.opensuse.org> [Feb 15. 2008 10:58]: > Author: matz > Date: Fri Feb 15 10:58:43 2008 > New Revision: 8702 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8702&view=rev > Log: > susetags2solv always constructs attributes now, by default into the main > SOLV file. Agreed, always constructing attributes makes sense. However, with this change it seems as if attributes aren't stored in a separate .attr file. Is this right ? Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 4

[zypp-devel] weired problems during commit
by Stephan Kulow 15 Feb '08

15 Feb '08

Hi, I dared to update to zypp:svn and then tried to zypper in and then I get a weired problem, it downloads media.1/media first and then again /inst-source/ and wonders that it can't write a dir as a file. Any idea? Greetings, Stephan Herunterladen von Paket yast2-users-2.16.8-9.x86_64, 0 B (0 B installiert) Lade herunter: media * Downloading [100%] Lade herunter: inst-source * Downloading [100%] Problem beim Laden von Daten von: Cannot write file /var/adm/mount/AP_0x00000005 and this how zypper log looks like: MediaHandler.cc(createAttachPoint):393 Trying to create attach point in /var/adm/mount PathInfo.cc(_Log_Result):295 mkdir /var/adm/mount/AP_0x00000005 00755 MediaHandler.cc(createAttachPoint):370 Created default attach point /var/adm/mount/AP_0x00000005 Sysconfig.cc(read):31 Load '/etc/sysconfig/proxy' Sysconfig.cc(read):71 done reading '/etc/sysconfig/proxy' MediaCurl.cc(attachTo):547 Proxy: -none- MediaHandler.cc(attach):653 Attached: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ attached; localRoot "/var/adm/mount/AP_0x00000005" MediaCurl.cc(doGetFileCopy):1024 /media.1/media MediaCurl.cc(doGetFileCopy):1058 URL: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/media.… MediaCurl.cc(doGetFileCopy):1119 dest: /var/adm/mount/AP_0x00000005/media.1/media MediaCurl.cc(doGetFileCopy):1120 temp: /var/adm/mount/AP_0x00000005/media.1/media.new.zypp.WJZjti MediaCurl.cc(doGetFileCopy):1303 HTTP response: 200 PathInfo.cc(_Log_Result):295 mkdir /var/adm/mount/AP_0x00000005/media.1 00755rename /var/adm/mount/AP_0x00000005/media.1/media.new.zypp.WJZjti -> /var/adm/mount/AP_0x00000005/media.1/media MediaCurl.cc(doGetFileCopy):1332 done: /var/adm/mount/AP_0x00000005/media.1/media{- 0644 0/0 size 42} MediaHandler.cc(provideFile):1010 provideFile(/media.1/media) MediaManager.cc(checkDesired):113 checkDesired(1): desired (report by N4zypp4repo17SUSEMediaVerifierE) MediaManager.cc(checkDesired):116 checkDesired(1): desired (cached) MediaCurl.cc(doGetFileCopy):1024 MediaCurl.cc(doGetFileCopy):1058 URL: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ MediaCurl.cc(doGetFileCopy):1119 dest: /var/adm/mount/AP_0x00000005 MediaCurl.cc(doGetFileCopy):1120 temp: /var/adm/mount/AP_0x00000005.new.zypp.GyKRq1 MediaCurl.cc(doGetFileCopy):1303 HTTP response: 200 PathInfo.cc(_Log_Result):295 rename /var/adm/mount/AP_0x00000005.new.zypp.GyKRq1 -> /var/adm/mount/AP_0x00000005 PathInfo.cc(_Log_Result):297 FAILED: errno 21 MediaCurl.cc(doGetFileCopy):1321 Rename failed -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 3

[zypp-devel] Warning: I moved libzypp
by Stephan Kulow 15 Feb '08

15 Feb '08

Hi, /trunk/libzypp is now what was yesterday jump_sat branch, so don't update unless you want to :) The current plan is to port the UIs today and then submit to Factory. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] Re: [zypp-commit] r8671 - /branches/tmp/ma/jump_sat/libzypp/zypp/ResObject.cc
by Michael Matz 14 Feb '08

14 Feb '08

Hi, On Thu, 14 Feb 2008, mlandres(a)svn.opensuse.org wrote: > ByteCount ResObject::size() const > - { return 1024 * lookupNumAttribute( sat::SolvAttr::size ); } > + { return ByteCount( lookupNumAttribute( sat::SolvAttr::size ), ByteCount::K ); } Meh. Talk about overdesign :-) int n1 = 12, n2 = 3, n3; Number number1(n1), number2(n2), number3; number3 = math::Number::Natural::Operation::Commutative::Multiplicative::Multiply (number1, number2); n3 = number3.toInt(); Crazy. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] progress
by Stephan Kulow 13 Feb '08

13 Feb '08

Hi! As you can see in my zypper.log, it takes 44 seconds for rpmdb2solv to finish, but still my zypper stays silent on what is going on. Only after the process finished, it will say "Reading installed packages", but that step takes exactly no second, so it's pointless to have progress for that one ;( Please move the progress kickoff to before rpmdb2solv is started. Greetings, Stephan 2008-02-13 14:43:03 <0> desdemona(17411) [zypp] ExternalProgram.cc(start_program):172 Executing '/bin/sh' '-c' 'rpmdb2solv > "/var/cache/zypp/_rpm.solv"' 2008-02-13 14:43:03 <0> desdemona(17411) [zypp] ExternalProgram.cc(start_program):283 pid 17490 launched 2008-02-13 14:43:47 <0> desdemona(17411) [zypp] ExternalProgram.cc(checkStatus):336 pid 17490 successfully completed 2008-02-13 14:43:47 <0> desdemona(17411) [zypp::satpool] PoolImpl.cc(setDirty):125 _createRepo @System 2008-02-13 14:43:47 <0> desdemona(17411) [zypp::satpool] PoolImpl.cc(setDirty):125 _addSolv @System 2008-02-13 14:43:47 <1> desdemona(17411) [zypp] TargetImpl.cc(load):347 adding /var/cache/zypp/_rpm.solv to pool(@System)Target loaded: 1427 resolvables -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2

[zypp-devel] New preferred way to iterate the pool by name and kind.
by Michael Andres 12 Feb '08

12 Feb '08

JFYI URL: http://svn.opensuse.org/svn/zypp/branches/tmp/ma/jump_sat/libzypp/zypp Revision: 8625 I tagged the byName iterator as deprecated, so the compiler tells you where it is used. Please review the code and check whether byIdent is an appropriate replacement. -- The 'old' zypp pool internally maintained a byName index, so it was a fast way to iterate the pool by name and filter by kind to visit e.g. all packages named foo: invokeOnEach( pool.byNameBegin( name ), pool.byNameEnd( name ), resfilter::ByKind( kind ), action() ); for_( it, pool.byNameBegin( name ), pool.byNameEnd( name ) ) { if ( (*it)->kind() == kind ) { ... } } This is no longer true. In contrary, byName now is a 'quite expensive' iteration. It's faster to rewrite these loops using byIdent (and no filter): invokeOnEach( pool.byIdentBegin( kind, name ), pool.byIdentEnd( kind, name ), action() ); for_( it, pool.byIdentBegin( kind, name ), pool.byNameEnd( kind, name ) ) { ... } How to construct the byIdent iterator: ResPool::byIdentBegin( poolItem ) // using this poolItems kind and name ResPool::byIdentBegin( kind, name ) // explicit kind and name ResPool::byIdentBegin<Package>( name ) // or templated kind -- If you prefer using iterator in a for' loop, but dislike to figure out the exact type of the iterator, you may find the 'for_' macro convenient: #include "zypp/base/Easy.h" for_( it, pool.byIdentBegin( kind, name ), pool.byIdentEnd( kind, name ) ) { PoolItem copy = *it; } instead of: for ( ResPool::byIdent_iterator it = pool.byIdentBegin( kind, name ), end = pool.byIdentEnd( kind, name ); it != end, ++it ) { PoolItem copy = *it; } -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] SAT: speedup zypper lu
by Michael Matz 11 Feb '08

11 Feb '08

Hi, the same problem as with dist upgrade also hits with zypper lu, it does a linear walk over all poolitems, for each calling the ByName iterator, which in turn also walks over the entire pool. Not So Clever, except if you want to test how the machine behaves with O(N^2) algorithms :) This of course could be fixed in libzypp by building a name->poolitem index itself and use it in the ByName iterator. But in the old libzypp a considerable amount of space and time was used for just building several dozen indices, and ideally we don't repeat this again. For one or two ByName filters (e.g. when done in reaction to a user action) such index is not necessary. In this case of course it is. The question is, if we want to support such use case in libzypp nicely, and if yes in which way. We could add an ByNameFast filter which builds an index, or just rely on the callers being fixed (like I do here). What the SAT library can provide without much overhead is an index for a ByKindName filter (doesn't exist yet), so _that_ one could be made fast without taking many resources. Interestingly that happens to be the usecase of zypper too. Anyway, for the time being for people testing zypper of the sat branch, this patch makes one usecase (which happens to be my primary performance testcase) fast. Ciao, Michael. Index: zypper-misc.cc =================================================================== --- zypper-misc.cc (revision 8599) +++ zypper-misc.cc (working copy) @@ -1,6 +1,7 @@ #include <fstream> #include <sstream> #include <ctype.h> +#include <tr1/unordered_map> #include <boost/format.hpp> #include <boost/logic/tribool.hpp> #include <boost/logic/tribool_io.hpp> @@ -33,6 +34,7 @@ //using namespace zypp::detail; using namespace std; +using namespace std::tr1; using namespace zypp; using namespace boost; @@ -1231,6 +1233,7 @@ findArchUpdateItem( const ResPool & pool // ---------------------------------------------------------------------------- typedef set<PoolItem> Candidates; +typedef unordered_multimap<string, PoolItem> Name2Item; static void find_updates( const ResObject::Kind &kind, Candidates &candidates ) @@ -1240,6 +1243,42 @@ find_updates( const ResObject::Kind &kin it = pool.byKindBegin (kind), e = pool.byKindEnd (kind); cerr_vv << "Finding update candidates" << endl; +#if 1 + Name2Item name2item; + for (; it != e; ++it) + name2item.insert(std::make_pair((*it)->name(), *it)); + + it = pool.byKindBegin (kind); + for (; it != e; ++it) + { + if (it->status().isUninstalled()) + continue; + PoolItem item = *it; + LookForArchUpdate info; + std::pair<Name2Item::iterator, Name2Item::iterator> it2 + = name2item.equal_range(item->name()); + invokeOnEach( make_transform_iterator(it2.first, _Select2nd<Name2Item::value_type>()), + make_transform_iterator(it2.second, _Select2nd<Name2Item::value_type>()), + // get uninstalled, equal kind and arch, better edition + functor::chain ( + functor::chain ( + functor::chain ( + resfilter::ByUninstalled (), + resfilter::ByKind( item->kind() ) ), + resfilter::byArch<CompareByEQ<Arch> >( item->arch() ) ), + resfilter::byEdition<CompareByGT<Edition> >( item->edition() )), + functor::functorRef<bool,PoolItem> (info) ); + + _XDEBUG("findArchUpdateItem(" << item << ") => " << info.best); + PoolItem candidate = info.best; + if (!candidate.resolvable()) + continue; + + cerr_vv << "item " << *it << endl; + cerr_vv << "cand " << candidate << endl; + candidates.insert (candidate); + } +#else for (; it != e; ++it) { if (it->status().isUninstalled()) @@ -1253,6 +1292,7 @@ find_updates( const ResObject::Kind &kin cerr_vv << "cand " << candidate << endl; candidates.insert (candidate); } +#endif } // ---------------------------------------------------------------------------- -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 4

[zypp-devel] yast2-qt
by Stephan Kulow 11 Feb '08

11 Feb '08

Hi! With the advice from Michael I ported yast2-qt (basically removing Selection support and commenting out Language support for now). It starts, but works weired and crashes when I play too much. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] adding Supplements for USB devices to packages
by Stanislav Brabec 11 Feb '08

11 Feb '08

Hallo. I am maintaining several packages with drivers for specialized USB hardware - Smart Card readers, UPSes. Is it a good idea to add Supplements to spec files to allow automatic picking of driver packages during the package selection? If yes, what exactly should I add there? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Re: [zypp-commit] r8586 - /trunk/sat-solver/tools/repo_rpmmd.c
by Michael Matz 11 Feb '08

11 Feb '08

Hi, On Sun, 10 Feb 2008, dmacvicar(a)svn.opensuse.org wrote: > Author: dmacvicar > Date: Sun Feb 10 23:24:05 2008 > New Revision: 8586 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8586&view=rev > Log: > - store location, dunno why it does not work yet Your lastsolvableid handling missed some cases where the solvable also is changed to the next one. In fact in the rpm-md case it's easier to calculate the solvable Id when we need it, from the (certainly correct) pd->solvable. Works now. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] Re: [zypp-commit] r8586 - /trunk/sat-solver/tools/repo_rpmmd.c
by Michael Matz 10 Feb '08

10 Feb '08

Hi Duncan, On Sun, 10 Feb 2008, dmacvicar(a)svn.opensuse.org wrote: > @@ -451,18 +463,18 @@ > { > case STATE_METADATA: > for (; *atts; atts += 2) > - { > - if (!strcmp(*atts, "packages")) > - { > - pd->numpacks = atoi(atts[1]); > - if (pd->numpacks < 0) > - pd->numpacks = 0; > + { > + if (!strcmp(*atts, "packages")) > + { > + pd->numpacks = atoi(atts[1]); > + if (pd->numpacks < 0) > + pd->numpacks = 0; Please leave the sat-solver files in GNU indentation style. See http://www.gnu.org/prep/standards/standards.html.gz#Formatting . mls doesn't like the space before open-parentheses in function calls (boo, hiss!) but apart from that the style is fairly homogenous right now. It should stay that way. Thanks, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] Re: [zypp-commit] r8592 - in /branches/tmp/ma/jump_sat/libzypp/zypp: Package.cc sat/Solvable.cc
by Michael Matz 10 Feb '08

10 Feb '08

Hi, On Sun, 10 Feb 2008, dmacvicar(a)svn.opensuse.org wrote: > Author: dmacvicar > Date: Sun Feb 10 23:34:15 2008 > New Revision: 8592 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8592&view=rev > Log: > - this is wrong, suse/ dir is a datadir told in the content file so this uggly append is > not valid for yum repos. > > so for now, as the optimization of mediafile only happens in susetags repos > append suse/ only for this case. As I said, someone needs to store the datadir into Repoinfo (for rpm-md it's for instance usually "repodata"). Then we can use it to form full rpm filepaths. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] testing jump_sat zypper
by Stephan Kulow 08 Feb '08

08 Feb '08

Hi, I found two problems: 1. "zypper dup" takes _FOREVER_ (and creates again MBs of zypper.log) 2. "zypper search gnome" crashes in ResolvableQuery.cc ==12994== Invalid read of size 4 ==12994== at 0x8076E48: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::all ocator<char> >(char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.tcc:675) ==12994== by 0x4113764: _ZN4zypp5cache15ResolvableQuery4Impl43iterateResolvablesByKindsAndStringsAndReposERKSt6vectorINS_7ResKindESaIS4_EERKS3_ISsSa ISsEEiSA_N5boost8functionIFbRKNS_15DefaultIntegralIxLxn1EEENSD_13intrusive_ptrINS_4data9ResObjectEEEESaIvEEE (ResolvableQuery.cc:209) ==12994== by 0x41127DA: _ZN4zypp5cache15ResolvableQuery43iterateResolvablesByKindsAndStringsAndReposERKSt6vectorINS_7ResKindESaIS3_EERKS2_ISsSaISsEE iSB_N5boost8functionIFbRKNS_15DefaultIntegralIxLxn1EEENSC_13intrusive_ptrINS_4data9ResObjectEEEESaIvEEE (ResolvableQuery.cc:525) ==12994== by 0x80D031B: int ZyppSearch::invokeOnEachSearched<Match, zypp::functor::FunctorRef<InstalledCache, bool, zypp::PoolItem const&, zypp::fun ctor::functor_detail::nil>, zypp::functor::FunctorRef<InstalledCache, bool, zypp::DefaultIntegral<long long, (long long)-1> const&, boost::intrusive_pt r<zypp::data::ResObject> > >(Match, zypp::functor::FunctorRef<InstalledCache, bool, zypp::PoolItem const&, zypp::functor::functor_detail::nil>, zypp::f unctor::FunctorRef<InstalledCache, bool, zypp::DefaultIntegral<long long, (long long)-1> const&, boost::intrusive_ptr<zypp::data::ResObject> >) (zypper -search.cc:211) ==12994== by 0x80CA359: ZyppSearch::cacheInstalled() (zypper-search.cc:243) ==12994== by 0x80CC49F: ZyppSearch::ZyppSearch(boost::intrusive_ptr<zypp::ZYpp>&, ZyppSearchOptions const&, std::vector<std::string, std::allocator< std::string> >) (zypper-search.cc:95) ==12994== by 0x806DDA3: Zypper::doCommand() (zypper.cc:1930) ==12994== by 0x80712A3: Zypper::safeDoCommand() (zypper.cc:601) ==12994== by 0x8075F9E: Zypper::main(int, char**) (zypper.cc:113) ==12994== by 0x80872B7: main (zypper-main.cc:43) ==12994== Address 0x8 is not stack'd, malloc'd or (recently) free'd -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 9

[zypp-devel] RFC: ZYpp application layer comments
by Duncan Mac-Vicar P. 08 Feb '08

08 Feb '08

I would like others (especially Michael) to review it. I am quoting the blocks of texts from the Wiki, which I would like to focus the discussion on. >Communication between the YCP application and the C++ package selector widgets is very limited (almost nonexistent). In particular, the YCP application cannot create a pool and pass a handle to that pool to the C++ package selector or vice versa. >Thus, for all important objects like pool or similar, there must be a singleton object for each that can easily be accessed from both the YCP code (via package bindings) and from the package selectors. Those singleton objects should live in the app layer. >Selectables have a higher level status that is the result of the useful permutations of the status flags of their resolvables and the fact whether or not one resolvable from this selectable (one instance of that package) is already installed: >Matching Selectable and Resolvable Status and Candidate Handling >The package selectors use the selectable status. They never store any selectable's status; they always retrieve the status when it is needed. When the user changes a selectable's status, they set new status and retrieve it for display so the display and the selectable status are always in sync. >Since selectable don't exist in the libzypp layer, matching a selectable status to the individual resolvable status flags is done by the app layer and vice versa. The app layer also keeps track of the candidate. This is important when the selectable status is used since some operations (install, update) implicitly operate on the candidate. I think this is one of the central parts of the problem we need to solve. >As long as the user did not explicitly choose a specific candidate, the app layer automatically chooses one from the available resolvables. That automatic choice takes matching architectures and most recent version number into account. This is not trivial. Right now the UIs do this choices in some random code somewhere in the UI, or using the selectable candidate function, which is now incomplete. This kind of decision is the same as the solver local policy. So we have to connect them trough the API somehow. Imagine this something like: bestCandidate( list_of_candidates, task ) Of course this has to be in Selectable, but it has to be connected to the local policy, and it depends on the task you want to execute. Otherwise the UIs will continue breaking things like vendor (the UIs iterate over a package list and select the higher version instead of the best candidate according to the system policies ). >Patterns (collections of packages to fulfil a certain task) This is where the UI <-> library problems starts. What the wiki describes there is the description of a Selection. >Technically, none of those higher level objects has a package content: They all just have dependencies that typically (but not necessarily) are satisfied by packages. Exactly. >From a user's point of view, however, those higher level objects are nothing else than containers for packages. Though this is a somewhat simplistic view, users typically want to see what is behind a pattern, a patch, or a language resolvable. This is why each of them should have a mechanism to enumerate the packages that belong to them. This is true, but only if you can live with the true: the mechanism to enumerate the list of packages is just an algorithm, not a list. It can be false information. That is why I tried to start using the term "related packages" instead of "content". >Enumerate all packages that belong to an RPM group (not just for leaf RPM groups, also those that belong to a higher level like "Productivity") I think the best way to solve this problems is to introduce categories for all resolvabes (tags), in the case of packages it can be implemented using rpm groups, and implement iterators to match full tag, part of it, a collection of them, etc. >Changing the status of a pattern, patch, or language typically affects the status of other resolvables, most notably the packages that belong to this pattern, patch, or language. Those changes should be propagated immediately to those packages so the user can instantly see the effect. >In the past there were calls to just propagate those changes, which worked in most cases, but not in certain pathological ones. But those calls were quick, so for the user there was an instant response. >Recent changes rely on a full solver run to propagate the changes, which gives the correct result in all cases, but which on the other hand is much slower. As some users disable the automatic dependency check because of this, some of them get confused because no change is propagated. There have been bug reports with lively discussions about that. I read this as, we need to do a solver run without doing a solver run? This is a technical limitation, which could be solved of we could for example cheap-ly clone a pool , do something and see the changes, without making the main one dirty. I have no idea yet if that undocumented dirpool has something to do with that ;-) >The user can select any one of those search modes: > > * Contains > * Begins with > * Exact match > * Use wildcards (*, ?) > * Use regular expression > >Case sensitivity in all searches can be switched on or off. > >A query engine to replace this functionality in the UI should enumerate >(return an iterator to) the selectables that match the given criteria. > Update Problems Filter View >This filter view enumerates those packages that for one reason or the other >could not automatically be updated during a system update. Adding packages >to this list is done by the system update application layer. And what is the criteria for searching those? >Libzypp/Application Layer/API Proposal >enum Type { > PACKAGE, > PATTERN, > PATCH, > LANGUAGE > } Why resolvable kind can't be used here? Why the need to duplicate it? > * Create pool iterator (based on the above query as a parameter) > > Pool pool = new Pool (q); So this is like a pool proxy based on a query? Why not the iterator taking the query as a parameter (Michael could comment more?) I have one concern with the design of the pool based on queries. It means we have to load the pool data, this will not be bad with the sat solver, but this is not the same zypper does, as zypper only gets the resolvable data to be displayed on the screen, without any pool. Appart of that the query api seems fine. Other API that could be part of the zypp layer is a command oriented api. If you look what API smart offers to the UIs is a much simpler API, and it is the same the command line tool offers, and this is quite similar to all zypper code. It defines a Command class (install, search, etc) it defines a abstract interface for callbacks (confirm dialogs, progress, questions, etc) The UI simply creates a command and executes it. This is a much simpler approach, but I think it is needed in addition to the layer our selector need. Both packagekit and any app wanting to install a package could benefit from this. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 9

[zypp-devel] status
by Duncan Mac-Vicar Prett 07 Feb '08

07 Feb '08

- pkg-bndings are ported and they are in build service, it is a _link against 10.3 one plus a patch, the patch does not apply, if anyone knows how to fix this please do it. I am not expert in these OBS features. - TODO: mergesolv and yum attributes (at least package path) - libzypp, zypper submited to obs, libzypp does not build (can't understand the error) - pool now is fast (ma fixed it ;-) ) - zypper in foo is really fast... - added coolo and Klaus to OBS zypp:svn project so only having the attribute medafile in the solv file while commit, is what we need to install a package (unless other minor bug appears) Cheers! Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 4

[zypp-devel] missing stuff
by Duncan Mac-Vicar P. 06 Feb '08

06 Feb '08

We are close guys, but still things don't work together. After Michael connected the pool with the sat pool, zypper now works just before commit, it now marks the packages to install and they get solved as expected. Commit fails then because resolvables have no repo information. URGENT STUFF (for "tomorrows" deadline) - repo2solv.sh was not using -a by default, and ignoring the packages translations, I added packages.en for now. but later, it uses mergesolv, which makes the attributes to dissapear, so it works if I manually cat packages.en and packages and use susetags2solv -a, but not with repo2solv.sh which uses mergesolv. Can we fix this? libzypp forks repo2solv.sh - I tried to implement something similar like repo_lookup_str which does not require a callback, but for nums, and it did not work :-( Can aynone check it? - Commit fails because Resolvables created by the pool iterator have a dummy Repository class. We need a way to associate the sat::Repo (which can be constructed just by using an id), this should be easy, but it is tricky, before all resolvables were created when creating a repository object, and this was constructed from the info, so every resolvable had a link to it. I think the right place to do it is when calling RepoManager::loadFromCache, we get the repoinfo and we should store in some place, where? no idea, as the Repository class has no sense anymore. - pkg-bindings are not ported yet :-( but from zypper porting this should be straightforward OTHER STUFF - zypper iterates the pool to show a summary of installation, also to mark a candidate for install. This is really slow with the current (non-optimized) pool adaptor. Is there another way we can speed up this? This also slows commit calculation which also heavily relies on pool iterations. For now it looks like all time moved from reading the cache is now here ;-) Appart of that things look promising. Speed and memory usage is nice. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 5

[zypp-devel] Re: [zypp-commit] r8486 - /trunk/sat-solver/tools/repo_rpmdb.c
by Michael Matz 06 Feb '08

06 Feb '08

Hi Duncan, On Wed, 6 Feb 2008, dmacvicar(a)svn.opensuse.org wrote: > Author: dmacvicar > Date: Wed Feb 6 03:08:04 2008 > New Revision: 8486 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8486&view=rev > Log: > avoid segfault. FIXME please Can't reproduce with current trunk. There was a segfault before in stringpool_str2id (from calling strlen on NULL), but that was fixed by ma some time ago. Are you sure you had current src/stringpool.c ? (I'm commenting this in again, if you still experience segfault, please tell me where I can take a look). Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] Preliminary zypper port
by Duncan Mac-Vicar P. 05 Feb '08

05 Feb '08

Hi! I have merged zypper changes from trunk into the sat branch, and then ported zypper to compile with libzypp. I had some porting steps in wiki Libzypp/SAT_Porting but a nvidia crash sent it to hell before I could save it :-( Some notes: - I submited the packages to zypp:svn project. llibzypp does not build because a weird error after rpm checks for unpackaged files: |RPM build errors: cannot open Pubkeys index using db3 - No such file or directory (2) File not found: /var/tmp/libzypp-4.1.6-build/usr/lib/zypp (anyone knows about this) - the first try, zypper hangs and eats all ram just after loading proxy settings. I unittested the parser and it was OK. So the codepath that comes next, which is something curl proxy related might be causing problems. Renaming sysconfig/proxy away solved this issue. - zypper loads the repos fine, reads rpm database, very fast (9.5 seconds for 18 repos _cold_ time including rpm, that is 10x faster, if I am not lying myself reading the logs in a wrong way), but it can't find the object to install in the pool because the pool iterator is not connected to the SAT pool, this is something Michael is working on. - Right now there is no store for saving patterns and patches. This will be tricky: current store: store --> rpmmd2solv (xml convertor) --> /var/lib/zypp/store.solv -> zypp repo (pool) rpm db ---> rpmdb2solv -----> /var/cache/zypp/_rpm.solv -> zypp repo (pool) The first step of converting the store from xml happens only once, and from rpm every time the rpm db changes. Now, when target reads, we have to load both solvs in the same repo, because sat solver takes only one "installed repo", but later we need to dump the patterns and patches to one solv, while the packages are not dumped (because the primary source is the rpm database ). This requires 2 AIs - integrating repo_write_solv into the library - allowing to save by kind or better: some generic filter) so a solv. This part is _very important_ |- zypper search has to be redone, basically using sat-solver/Repodata search, perhaps we can keep the same interface for now. This is not urgent for the first submit though. | Cheers Duncan | -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

6 12

[zypp-devel] Re: [zypp-commit] r8464 - in /branches/tmp/ma/jump_sat/libzypp/zypp: ./ cache/ parser/ parser/xmlstore/ parser/xmlstore/schema/ solver/detail/ target/ target/store/
by Stanislav Visnovsky 05 Feb '08

05 Feb '08

Dňa Monday 04 February 2008 22:58:14 dmacvicar(a)svn.opensuse.org ste napísal: > Author: dmacvicar > Date: Mon Feb 4 22:58:14 2008 > New Revision: 8464 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=8464&view=rev > Log: > - remove xml store > > snif, this is emotional for me, it was the first piece of c++ code I wrote > when joining SUSE. > > But the replacement is... nothing! what can be better than removing code by > simplifying the concept. Where is the concept documented when you started to implement it already? Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] zypp::ResolverProblemsList->details()
by Katarina Machalkova 04 Feb '08

04 Feb '08

Hi guys, does anyone know what happened to $subject? While testing package selector, I found out that details describing current solver problem (messages such as "A conflict over foo-1.2.3 requires removal of bar-3.2.1 which is scheduled to be kept etc. etc.") have suddenly disappeared. In other words, zypp::ResolverProblemsList->details() keeps returning empty strings. Or, at least I've been unable to find some case where it would actually return something (but maybe I have obsoleted zypp headers). Are these problem details gone for good with the new sat solver? Whether they are or not, I would probably consider adjusting UI (nc) not to display them at all, it has always been overly long string, hardly fitting the screen and confusing user more than bringing some actual useful info. Afaik, Qt package manager does not display solver problem details either (in the new Qt4 port). What do you think? B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

2 2

[zypp-devel] ZYpp/sat target loads from solv now
by Duncan Mac-Vicar P. 02 Feb '08

02 Feb '08

Hi! Target to loads the rpm resolvables from a solv file now. initializeTarget() does as usual, creates the target object and imports gpg keys (this is an area where we could gain speed too) Target::resolvables() was removed. Target::load() was added. load() creates the .solv file from the rpm database and stores it in /var/cache/zypp/_rpm.solv A cookie file is also saved to know if the cache corresponds to the current rpm state. If it is the solv file is not regenerated. load() also loads the solv file in the pool. Now we have to focus on RepoManager and the Repository class. Right now, RepoManager is ported to use solv files, but the API introduced in 10.3 is very granular. Repository object is still obtained via createFromCache, and the Repository object still has a resolvables() interface (which is a hack for now). We have to figure an API for Repository that is consistent with the one in Target. An iterator over Resolvables could be an option, this iterator would use the sat::Repo solvable iterator underneaths. When to load the .solv? right now the call to resolvables() to it. But target has load(), it is becoming inconsistent across classes. Other option is to move the solvables code from Target to RepoManager, and have these resolvables accesible via createFromSystem() there. That would allow to access the target repositories with the same API as the other repositories, and we leave the Target only for commit. It would be more consistent with the sat concept (where installed resolvables _are_ a repo after all) What do you think? TODO for those who are helping with this important project ;-) AI: Pool, top priority -> WIP by Michael AI: satsolver rpmdb2solv segfaults when setting the vendor to the solvable. Nobody noticed it? I commented the vendor assignment locally to be able to run it. AI: attributes for yum files (required for updates) AI: right now, rpmdb2solv seems to also not contain any attributes in the solv file, we need this for the UIs. I have uploaded tonights svn to buildservice zypp:svn, where we will integrate all pieces. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0