September 2008 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] New solver call : resolveQueue
by Stefan Schubert 11 Mar '09

11 Mar '09

Hi, apart from the solver call "resolvePool" ( collect all transactions from the pool, solving this transactions and writing the result back to pool) the solver can work off a given request queue too: /** * Resolve package dependencies: * * The solver works off the given queue and writes back the solution * to pool. * * Returns "true" on success (i.e., if there were no problems that * need user interaction) and "false" if there were problems. In * the latter case, use problems() and later applySolutions() * below. **/ bool resolveQueue (solver::detail::SolverQueueItemList & queue); The queue can have elements which are described in the following classes: base class: SolverQueueItem.h SolverQueueItemDelete.h SolverQueueItemInstall.h SolverQueueItemLock.h SolverQueueItemInstallOneOf.h SolverQueueItemUpdate.h Known problems: - The update and InstallOneOf request does not work correctly. - The error messages are too abstract now for the user. (Jano, you can start implementation now :-) ) 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 12

[zypp-devel] MediaAria2c merged
by Duncan Mac-Vicar P. 27 Oct '08

27 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MediaAria2c is now official part of libzypp. MediaAria2c és ara part oficial de libzypp! Author: dmacvicar Date: Tue Sep 30 00:04:58 2008 New Revision: 11212 URL: http://svn.opensuse.org/viewcvs/zypp?rev=11212&view=rev Log: - - Merge aria2c Media handler code from Google SOC 2008 (Gerard Farras) - - Only activated by making env var ZYPP_ARIA=1 - - various changes on merge: - - moved exist function to the Aria specific class - - close programs - - use arrays of commands instead of building strings - - some reformatting - - cleanup will come later TODO: Move the exceptions also in the aria class. NOTE: the default handler is still the curl one. We merge the code so people can enable it and test it. But it can't be enabled without setting the env variable. Modified: trunk/libzypp/package/libzypp.changes trunk/libzypp/zypp/CMakeLists.txt trunk/libzypp/zypp/media/MediaAccess.cc trunk/libzypp/zypp/media/MediaAccess.h trunk/libzypp/zypp/media/MediaException.cc trunk/libzypp/zypp/media/MediaException.h -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkjhUyIACgkQzR62qWZ+QtHY3gCeKGehBJ7CsU17s0xGQ/rIAn9B UkMAoJlvl0G3Meu8yGzL26pXpfyBWl0L =DUlK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 8

[zypp-devel] Enabled distupgrade of the SAT solver
by Stefan Schubert 07 Oct '08

07 Oct '08

Hi, I have enabled the distupgrade of the SAT solver. In order to use the old distupgrade you can set the environment variable ZYPP_NO_SAT_UPDATE. But this should be used as fallback only :-) This variable will can be used until the old distupgrade mechanism will be removed from libzypp. I will send an EMAIL when this happens. 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

4 6

[zypp-devel] show accessed mirror
by Peter Poeml 01 Oct '08

01 Oct '08

Hi, would it be possible to show the mirror which is accessed when downloading a package? (Technically, the download client is following redirects and the actualy URL needs to be shown, not just the first URL that was contacted but that redirected to another URL) It is a long-standing problem that this information is lacking and it makes debugging and optimizing much harder than necessary, because this information is only available deeply buried in some logfile. We need this information for two reasons: 1) Debugging - to see which URL was accessed when something goes wrong, like a mirror timing out. For example, Whenever a mirror returns garbage, it takes a lot of additional time to find out which one, because all reports are lacking the critical detail, and it is usually hard to find it out later. 2) Optimizing the load sharing between different mirrors - to distinguish slow mirrors from fast ones. For example, I am very much in need of information about the situation in the US, but even though people in the US run installations for me and are willing to send me logs, I can't get this information. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

2 3

[zypp-devel] Upgrade Assistant Service
by Jano Kupec 30 Sep '08

30 Sep '08

Hi, Benji Weber wrote: > Greetings, > > I noticed that you created the > http://en.opensuse.org/Standards/Repository_Index_Service page. > > Another use case I don't see mentioned is for assisting with upgrades. > Client could provide the repositories it is currently using, and the > service could suggest replacements for use in the upgrade. Nice idea. I would view this as an extension to current RIS, or even a new type of service (UAS), since it needs to feed something up to the service (so far zypp only gets info from repos, does not feed any data, except authentication, up to the repos/services). # add service as usually $ zypper as [-t uas] URI alias # - probe the service type, see its a UAS # - send URIs of defined non-service repos + maybe some other info (product) # - read response (may be repoindex.xml, maybe something different). $ zypper refs alias > Also yet another reason to be able to identify repository duplicates. > ( https://bugzilla.novell.com/377568 ) Of course. -- cheers, jano -- 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] Beware: libzypp-5.13.0 - WhatProvides::empty retruns invers result.
by Michael Andres 29 Sep '08

29 Sep '08

Hi! In libzypp-5.13.0 zypp::sat::WhatProvides::empty retruns the inverse result. That's the reason why e.g zypper in -C 'capability' fails. Just WhatProvides::empty is affected, size and iterator behave as expected. libzypp-5.13.0 is on beta2, so remember this in case of strange error reports. Fixed in 5.13.1 -- 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] zypper-0.12.7 update/list-updates now defaults to --type package
by Jano Kupec 29 Sep '08

29 Sep '08

To anyone who uses 'zypper update' or 'zypper list-updates' without explicitly specifying the --type option: the default has been changed from 'patch' to 'package' since zypper 0.12.7 For more info see https://bugzilla.novell.com/show_bug.cgi?id=395480 cheers, jano -- 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] New feature (usability): Report progress in resolving dependency
by Arthur Rodrigo Sawazachi Valadares 24 Sep '08

24 Sep '08

Hi, I looked for this issue on the code and the wiki and didn't find anything, but if I missed something and this topic has already been discussed or implemented, please tell me =/ I haven't read all the documentation concerning zypp, right now I just wanted to know if what I'm thinking makes sense and would be useful. I think it would be interesting for ZYpp to report it's progress while resolving packages. On YaST, when it calls zypp to resolve, it is only able to pop up a window that says "Solving" and hide it after it's done. This can be an issue if the system freezes on that moment, if you are on text mode remotely you don't have a way to check if the machine is frozen or really solving. I do know this usually takes a small amount of time, but can we can document a maximum wait time or could it actually take very long? An idea to solve this would be to modify the function resolvePool() to accept a callback function pointer as a parameter. It would then call this function passed to it in a regular basis (probably inside resolveDependencies()). This way you could make your own progress bar, animation, etc, function on any graphical toolkit you want. Sorry for the long e-mail, any comments, suggestions and pointers would be nice. Meanwhile I'll keep reading on the ZYpp docs/code and see if I missed something else. Thank you, -- 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] ZYpp History Log
by Jan Kupec 24 Sep '08

24 Sep '08

Hi! I'm about to commit the first version of new history logging for libzypp, which will be described at http://en.opensuse.org/Libzypp/Package_History This will replace the old /var/log/YaST/y2logRPM; the new log will be written to /var/log/zypp/history by default, configurable in zypp.conf. As per discussion with a few people, there should not be much to do to adapt to this change (it seems that libzypp was the only one writing to this file). You should just be prepared to request the file from bug reporters, if needed, because you won't get the file in the /var/log/YaST dir tarball. Also bug reporting wiki howtos can be adapted. We also can consider making a backup of the old log and leaving a note with the new location (yast2-core package could do this perhaps?). -- cheers, jano -- 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] r11120 - /trunk/sat-solver/tools/repo_repomdxml.c
by Michael Schroeder 22 Sep '08

22 Sep '08

On Mon, Sep 22, 2008 at 12:24:29PM -0000, dmacvicar(a)svn.opensuse.org wrote: > + /* save the timestamp in the non solvable number 1 */ > + if ( pd->timestamp > 0 ) > + repo_set_num(pd->repo, -1, REPOSITORY_TIMESTAMP, pd->timestamp); > + break; Eek, this really is too ugly. Why "non-solvable -1"? Please don't do such a bad design. 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

1 0

[zypp-devel] ZyppHacker: Please use the correct/reasonable insert iterator!
by Michael Andres 22 Sep '08

22 Sep '08

Hi! std::vector<RepoInfo> toModify; getRepositoriesInService(oldAlias, std::insert_iterator<std::vector<RepoInfo> >( toModify, toModify.begin() )); Reading such a line you know why some people complain about templates. a) It's not readable. b) It's not reasonable. Usually there are also convenience methods that build the right object for you. For the purpose here STL provides: std::back_inserter(container&) std::front_inserter(container&) Now the above can be written as: std::vector<RepoInfo> toModify; getRepositoriesInService( oldAlias, std::front_inserter(toModify) ); The benefit is IMO obvious. And now as we can read the code, we may recognize that we don't want to use a front_inserter with a vector. We don't want to shift the whole array to the right on each insert. We want this: getRepositoriesInService( oldAlias, std::back_inserter(toModify) ); or getRepositoriesInService(oldAlias, std::insert_iterator<std::vector<RepoInfo> >( toModify, toModify.end() )); Whenever you have to write such a beast, you should ask yourself whether it's not worth writing a short convenience method. You already wrote the body: insert_iterator<std::vector<RepoInfo> >( toModify, toModify.end() ) Just put it into a function with a resonable name: template<class Container> inline insert_iterator<Container> back_inserter( Container & c ) { return insert_iterator<Container>( c, c.end() ); } -- 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

Re: [zypp-devel] CredentialManager to get data for authentication
by Jan Kupec 18 Sep '08

18 Sep '08

Gerard Farràs i Ballabriga wrote: > 2008/9/8 Jan Kupec <jkupec(a)suse.cz <mailto:jkupec@suse.cz>> > > Three things to do yet (in the order of importance): > > > Hi! > > And also, I will try to use this new class in MediaAria2c handler, which is > in development in home/gfarrasb branch, within build service (see [1]). great, i hope i'll find some time to try this out! JFYI, the CredentialManager API (and file format) has changed a bit now, and it probably will even more during the next week, so be prepared :O) > MediaAria2c uses "aria2c" as external program (not uses libcurl) to > retrieve > files and it could use "--http-user" and "--http-passwd" options to > authenticate. > > Gerard > > [1] > https://build.opensuse.org/project/show?project=home%3Agfarrasb%3Abranches%… > -- cheers, jano -- 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] CredentialManager to get data for authentication
by Jan Kupec 18 Sep '08

18 Sep '08

Hi, i just committed an initial version of zypp::media::CredentialManager (CM) class (http://lists.opensuse.org/zypp-commit/2008-09/msg00057.html) which serves for manipulation of global and user's credential files. These are by default /etc/zypp/credentials (world readable, or group readable?) and ~/.zypp/credentials). CM is used by the media backend (currently only MediaCurl) to retrieve username/password in case it needs to authenticate to the target URL. If CM fails to find the credentials, MediaCurl will ask user via callback to provide it. It will also ask the user whether and where (global/user's) to save them and will use CM to save them after successful authentication. Current solution uses simple text files containing one URL per line, _containing_ also 'username:password@'. These URLs are then fed to the zypp::Url constructor which parses them into an object from which you can get the username and password, as well as compare with other URLs using different zypp::url::ViewOption, etc... This solution satisfies our current needs, but it could be extended in the future if needed. zypp::media::CredentialFileReader takes care of returning one AuthData_Ptr per valid line of the input file, so if you don't like the 'URL' solution, we just need to change the reader/writer. Three things to do yet (in the order of importance): - for services, propagate the credentials down to its repos when refreshing the service, or use the service's credentials when refreshing the repos. I don't know how to do this yet. - write CredentialFileWriter to be used by CredentialManager::save*() methods + a callback asking the user to decide whether he wants to save the credentials in the global file or user's own. - need a way to pass CredManagerOptions into MediaCurl (where the CredentialManager is currently used). Currently i'm just able to prefix the Target::root() to the default credential files paths. Later we can add an interface to zypper to manage these data, list, remove, add records, etc. Comments/suggestions are welcome. cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 7

Re: [zypp-devel] CredentialManager to get data for authentication
by Dominique Leuenberger 16 Sep '08

16 Sep '08

On Tue, 2008-09-16 at 12:11 +0200, Michael Andres wrote: > On Tue, Sep 16, Jan Kupec wrote: > > > look at the file provided as ?credentials=/absolute/path/credfile > > > > - the URL has to be saved with this parameter > > - Q: isn't revealing of the location of the credentials file > > a security issue? > > I don't think so. Everybody knows that passwords are stored in > /etc/passwd. This does not make it less secure. Not completely true... in case of /etc/passwd (or /etc/shadow actually nowadays), the algo does not nescessarly need to be reversible to check the password hash (take MD5.. it's not reversible by mathematics). This works as the program (login) never actually needs to get the clear text password from the hash. In 'our' case, zypper / libzypp will have to decrypt the passwords (in case they are encrypted) to be able to use them for login. The entire infrastructure to decrypt it is provided in the source files, so the security is not really granted in this case. But 'revealing the location' is probably the smallest issue here... everybody knows they would be found in /etc/zypp/credentials.d The only way to prevent password stealing is not having the file world readable. A Deamon accessing it, probably controlled via PolicyKit would be the solution IMHO. Dominique -- 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] problem building libsatsolver 0.10.11
by Jan-Simon Möller 15 Sep '08

15 Sep '08

Hi ! I've as qestion about building libsatsolver 0.10.11. with swig and cmake updated to factory, i see this: make[2]: Entering directory `/usr/src/packages/BUILD/satsolver-0.10.11' /usr/bin/cmake -E cmake_progress_report /usr/src/packages/BUILD/satsolver-0.10.11/CMakeFiles 80 [ 95%] Building C object bindings/python/CMakeFiles/satsolver_python.dir/satsolver_python.o cd /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python && /usr/bin/gcc -D_FILE_OFFSET_BITS=64 -Dsatsolver_python_EXPORTS -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -Werror -Wall -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -Werror -Wall -g -O3 -fPIC -I/usr/src/packages/BUILD/satsolver-0.10.11 -I/usr/src/packages/BUILD/satsolver-0.10.11/src -I/usr/include/python2.5 -I/usr/src/packages/BUILD/satsolver-0.10.11/applayer -I/usr/src/packages/BUILD/satsolver-0.10.11/tools -DVERSION=\"0.10.11\" -o CMakeFiles/satsolver_python.dir/satsolver_python.o -c /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c cc1: warnings being treated as errors /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c: In function 'xsolvable_each_attr_callback': /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c:3132: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c: In function 'xsolvable_attr_lookup_callback': /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c:3217: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c: In function 'xsolvable_attr_exists_callback': /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c:3292: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c: In function 'XSolvable_attr_exists': /usr/src/packages/BUILD/satsolver-0.10.11/bindings/python/satsolver_python.c:3389: warning: dereferencing type-punned pointer will break strict-aliasing rules make[2]: *** [bindings/python/CMakeFiles/satsolver_python.dir/satsolver_python.o] Error 1 make[2]: Leaving directory `/usr/src/packages/BUILD/satsolver-0.10.11' make[1]: *** [bindings/python/CMakeFiles/satsolver_python.dir/all] Error 2 make[1]: Leaving directory `/usr/src/packages/BUILD/satsolver-0.10.11' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.91538 (%build) e.g. line 3132, 3217 3292 are all assignements value = Swig_True; or *result = Swig_True: Any idea ? best regards, Jan-simon -- 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] Delta management for local patches also?
by Axel C. Frinke 15 Sep '08

15 Sep '08

Hello, since I still connect to the internet by a 56K modem, I developed my own way to perform online updates: I have the openSuSE patches locally stored on my hard disk, and from time to time I connect with rsync to an openSuSE mirror (using option --dry-run) to generate a list of files to retrieve by chance. Once I have fast access (in the CIP pool of the university or at friends), I download these files onto a USB flashdisk (using command wget --mirror -i download.lst) and store them later on my hard disk. So far, so good. However, in order to save disk space, I prefer to retrieve delta patches. And here comes my problem: regardless of the value of 'download.use_deltarpm' in file /etc/zypp/zypp.conf, libzypp always wants to retrieve 'full' patch rpms rather than delta rpms. Actually, I go for that. Until now I helped myself from that situation by using vsftpd, so I made yast2 and zypper believe it would download from a remote ftp server, but in any case I would prefer a way to apply delta rpms even if the source is a local directory. At meanwhile, I wrote some stuff to implement this functionality, it works very well for me. My solution is relatively simple: in /etc/zypp/zypp.conf, I just implemented an additional boolean variable 'use_deltarpm_always' (I do not insist on this name). If its value is set to true, delta rpms will be used even if the repository is a local path. I am aware that this feature is of limited interest in most cases, thus I would appreciate it very much if it could be overtaken. Thanks to a good friend I have a modified specfile and a patch file to be applied on sources 4.27.1 of libzypp. If you are interested, please tell me where I can mail it to. Thanks in advance! Best regards, Axel. P.S.: if you reply by private email, you are of course welcome to write in German! ;-) -- 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 up/up -t package change
by Michael Schroeder 15 Sep '08

15 Sep '08

Hi, what's the status of the "make zypper up" default to "zypper up -t package" change? If we agree to do it, SLES11 should already contain the chage. Thanks, 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

2 1

Re: [zypp-devel] Zypper up/up -t package change
by Dominique Leuenberger 15 Sep '08

15 Sep '08

On Mon, 2008-09-15 at 13:26 +0200, Michael Schroeder wrote: > Hi, > > what's the status of the "make zypper up" default to "zypper up > -t package" change? If we agree to do it, SLES11 should already > contain the chage. What will be the alternative to what we have now? zypper up -t patch sounds a bit to long for me. Maybe a zypper patch? Dominique -- 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] libzypp-bindings: some iterators required
by Nikolay Derkach 13 Sep '08

13 Sep '08

Hi, Some suggestions for zypp bindings: - I think it would be really nice to have Capabilities objects iterable, e.g. to list provides, requires and such - Please add byIdentIterator to ResPool.i PS: is it ok to report these small issues on the list or should I probably file bug reports to keep track about bugs? -- Regards, Nikolay Derkach -- 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] python: ZConfig is missing in bindings
by Nikolay Derkach 13 Sep '08

13 Sep '08

Hi, Please add yet another %include for ZConfig.h -- Regards, Nikolay Derkach -- 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] repository 'path'
by Jan Kupec 11 Sep '08

11 Sep '08

Hi Hackers, the support for *path* in repositories (the piece appended to baseurl) is still not perfect in libzypp. I am about to fix it, but first i've got a few questions. - DO WE NEED THIS AT ALL? :O) AFAICT, we needed this for multi-product media (like patch-CDs probably). I'm not sure why, though, can't we just go about it with two different URLs? If some 'conent' file references the other repo with a relative path, it should be no problem for libzypp to just use the baseurl+this_path, no need to treat them separately(?). Is the 'path' part of YUM's definition? If your answer to these is 'NO,YES,NO', i'll be happy to remove all the path stuff from libzypp now instead of fixing it for no good reason :O) (maybe with some backward compatibility, reading the path, and appending it to baseurls). And forget the next question then. - our repository definition allows multiple baseurls to be defined, as well as mirrors (these are ignored currently IIRC). What to do with this: [foorepo] baseurl = http://url1.org/repos baseurl = http://url2.org/whatever path = foorepo/openSUSE/11.1 not to mention mirrors. Should we just use the path for all of the baseurls? cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 3

[zypp-devel] zypper's XML being also libzypp's?
by Jan Kupec 11 Sep '08

11 Sep '08

Hi, i want to extend zypper's --xmlout somewhat. For example the output of product-info and products commands will need some <product .../> tag with product's attributes. The code producing this from a zypp::Product object could be probably better placed in libzypp than zypper. In fact i already put ServiceInfo's and RepoInfo's XML representation into libzypp (dumpAsXMLOn(ostream)). I just wanted to ask whether you would like this approach, where/how to document it. Currently there is only http://en.opensuse.org/Standards/Zypper_Xml which references http://svn.opensuse.org/svn/zypp/trunk/zypper/src/output/xmlout.rnc , but as soon as we start putting some of the XML methods to libzypp, this will not be sufficient (even some of the existing stuff can be moved from zypper to libzypp). I suggest to put the .rnc files to libzypp, like we do for parsers (some of them can even be reused). Wiki docs can reference those .rnc files then, as well as other (higher-level) .rnc can include them. cheers, jano -- 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] Next step for zypper output
by Peter Poeml 10 Sep '08

10 Sep '08

Hi, please compare yourself. zypper output: The following packages are going to be upgraded: libtiff3-3.8.2-108.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) libtdb1-3.2.3-0.1.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) libsmbclient0-3.2.3-0.1.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) libtalloc1-3.2.3-0.1.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) cifs-mount-3.2.3-0.1.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) libwbclient0-3.2.3-0.1.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) perl-doc-5.10.0-37.4.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) perl-5.10.0-37.4.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) perl-base-5.10.0-37.4.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) libneon27-0.28.2-17.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) neon-0.28.2-17.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) release-notes-openSUSE-11.0.7-0.1.noarch (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) nfs-client-1.1.2-9.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) python-2.5.2-26.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) python-xml-2.5.2-26.2.i586 (Main Update Repository, SUSE LINUX Products GmbH, Nuernberg, Germany) [...] yum output: ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kernel-default i586 2.6.25.11-0.1 11.0-updates 22 M Updating: ConsoleKit i586 0.2.10-14.2 11.0-updates 67 k ConsoleKit-x11 i586 0.2.10-14.2 11.0-updates 16 k MozillaFirefox i586 3.0.1-0.1 11.0-updates 875 k SuSEfirewall2 noarch 3.6_SVNr195-9.2 11.0-updates 67 k acl i586 2.2.47-6.1 11.0-updates 64 k acpid i586 1.0.6-63.2 11.0-updates 34 k acroread i586 8.1.2_SU1-0.1 11.0-updates 37 M asclock i586 2.0.12-255.1 11.0 91 k [...] Can you spot the difference? - alphabetically sorted - easily visible that a kernel update is due - kernel is installed (!) not updated - etc etc Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

3 3

[zypp-devel] libzypp: about 11.1 product handling and beloved zypp::ResTraits
by Michael Andres 09 Sep '08

09 Sep '08

The major change in 11.0 product handling (from the zypp POV) is the fact that products are again 'installed'. Good by repo refreshing and solver running just to figure out if a product is installed. Short details: The 'database' of installed products will be located in /etc/products.d. Release packages will put the products metadata there, when they are installed, and the data are removed again if the package gets removed. So within libzypp the relase Package and the Product are sort of different views to the same object. One can't be without the other. This tight connection is expressed by the fact, that both objects share the same ResStatus. I started to review zypper, pkg-bindings and the UIs, and adapt all code that refers to satisfied/broken/needed when dealing with Products. They are again, like Packages, installed. But I'd like you to forget this immediately ;) If a distinction has to be drawn between installed items (package, product) and verified items (pattern, patch), we'll provide this info as a property of ResKind. This leads to the 2nd topic: zypp::ResTraits I want to remove them at least outside libzypp. All that is used and needed outside libzyzypp is the kind of a resolvable: The Type is: class ResKind aka ResObject::Kind aka ResTraits<ResObject>::KindType And the kind strings are available as ResKind constants: zypp::ResKind::package zypp::ResKind::patch zypp::ResKind::pattern zypp::ResKind::product zypp::ResKind::srcpackage I think this is nicer to read and write than the traits way: zypp::ResTraits<zypp::Package>::kind zypp::ResTraits<zypp::Patch>::kind zypp::ResTraits<zypp::Pattern>::kind zypp::ResTraits<zypp::Product>::kind zypp::ResTraits<zypp::SrcPackage>::kind -- 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 5

Re: [zypp-devel] python: ResPool object is unsubscriptable
by Nikolay Derkach 09 Sep '08

09 Sep '08

On Sun, Sep 7, 2008 at 10:13 PM, Jano Kupec <jkupec(a)suse.cz> wrote: > Nikolay Derkach wrote: >> >> Hi, >> >> I would be nice if ResPool objects would be subscriptable >> (dictionaries). For example it'd be very convenient to have an access >> to pool items like this: >> >> Z = zypp.ZYppFactory_instance().getZYpp() >> >> ... >> >> p = Z.pool() >> print p[package_name].isInstalled() >> >> where package_name is a key name (pool item name). > > But there can be multiple PoolItems with the same name (different versions, > different kinds)... Such an interface could be provided, but it would still > not point to a single PoolItem, but rather a set. Yes, in general case it may be a list. >> Right now the only way I could find to do this is: >> >> for item in Z.pool(): >> if item.name() == pkg_name: >> print item.status().isInstalled() >> >> which makes code a bit bloated. > > Better use the byName or byIdent iterators, they use indices. Hm, it seems that Z.pool().byKindIterator() is gone, so I have to use something like this: for item in range(Z.pool().byIdentBegin(zypp.KindOfPackage(), pkgname), Z.pool().byIdentEnd(zypp.KindOfPackage(), pkgname)): Another problem is that KindOfResolvable() (needed for KindOfPackage() and such) is also not available anymore, while it's still used in ResTraits.i -- 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] python: ResPool object is unsubscriptable
by Nikolay Derkach 08 Sep '08

08 Sep '08

Hi, I would be nice if ResPool objects would be subscriptable (dictionaries). For example it'd be very convenient to have an access to pool items like this: Z = zypp.ZYppFactory_instance().getZYpp() ... p = Z.pool() print p[package_name].isInstalled() where package_name is a key name (pool item name). Right now the only way I could find to do this is: for item in Z.pool(): if item.name() == pkg_name: print item.status().isInstalled() which makes code a bit bloated. -- Regards, Nikolay Derkach -- 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] Uniqueness of a repository
by Nikolay Derkach 07 Sep '08

07 Sep '08

Hi, How can I figure out that a repository belongs e.g. to official ones (oss, non-oss, debug)? The only way which comes to mind is to check packages' GPG keys, but maybe there an easier way? What are the unique characteristics? -- Regards, Nikolay Derkach -- 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] jippie - my pool gets listed! Q: nicer output ?
by Jan-Simon Möller 05 Sep '08

05 Sep '08

Moin moin! >>> for item in pool: ... print item.string() ... U__s_(2)ConsoleKit-x11-0.2.10-12.3.i586(software) [...] U__s_(546)hicolor-icon-theme-0.10-63.5.noarch(software) Jippie - it works with zypp from svn. So just one more question: can i somehow only query * packagename * version * repoalias or do i need to extract this. I mean e.g. for item in pool: item.name() item.version() item.repoalias() Best regards Jan-Simon -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 5

[zypp-devel] Comments/ideas for libzypp-bindings-python
by Jan-Simon Möller 05 Sep '08

05 Sep '08

Moin moin! Just some observations/ideas and random stuff. RepoManager: * I miss iterators like knownRepos() and knownServices() returning the respective RepoInfo ** Reason: I can easily add repositories, but its hard to find the already known repos from RepoManager to query/refresh/whatever * If I use the nice feature addService("alias", URL("pathtorepofile")) i'm stuck refreshing the repos as >>> myrepomanager.refreshServices() fails with RuntimeError: Parse error * I've no chance to iterate and/or get repoinfos for handling. * i've an url and an alias, but no serviceinfo up to now, but TypeError: in method 'RepoManager_refreshService', argument 2 of type 'zypp::ServiceInfo const &' requires a ServiceInfo :/ * ok, getService(alias) works ... but syntax is bad imho... myrepomanager.refreshService(myrepomanager.getService("alias")) or ? If i can addService("alias", URL) why not refreshService("alias") ** btw refreshService fails here with "RuntimeError: Parse error" (same repos work done with repoinfo) best regards Jan-Simon -- 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] RepoInfo API cleanup
by Jano Kupec 04 Sep '08

04 Sep '08

JFYI: - {Repo,Service}Info::dumpAsXMLOn(ostream) added - RepoInfo::dumpRepoOn() deprecated in favor of dumpAsIniOn() - RepoInfo{,Base} setters made void (see also http://jniq.blogspot.com/2008/09/convenient-setters-in-c.html) cheers, jano -- 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] Killer feature request for zypper output
by Peter Poeml 04 Sep '08

04 Sep '08

Hi, a small screen log to give you an idea, what I *really* want. Extra points for showing the changes in colour. # yum --changelog update libgcc Loading "changelog" plugin Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package libgcc.i586 0:4.1.2_20070115-0.22 set to be updated --> Running transaction check Changes in packages about to be updated: libgcc - 4.1.2_20070115-0.22.i586 * Wed Jul 23 14:00:00 2008 - matz(a)suse.de - Fix using of uninitialized registers in reload, breaking structure assignment. [bnc #354405] * Mon May 26 14:00:00 2008 - matz(a)suse.de - Fix a problem with xor instructions on s390x. [bnc #394409] * Wed Apr 23 14:00:00 2008 - matz(a)suse.de - Fix unwind compatiblity issues. [bnc #376357] Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: libgcc i586 4.1.2_20070115-0.22 sles10-post-sp2 51 k Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 51 k Is this ok [y/N]: Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

2 1

[zypp-devel] libzypp-bindings (python) - zypp.RepoInfo no longer generated ...
by Jan-Simon Möller 04 Sep '08

04 Sep '08

I updated to HEAD (big mistake ;)) and now i can't access RepoInfo any longer. >>> myrepoinfo = zypp.RepoInfo() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'RepoInfo' I also tried to downgrade again (r10787) but no luck. Also tried a parallel install of latest swig. Any clue why this happened ? Or a "usable" revision ? best regards Jan-Simon -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 9

[zypp-devel] libzypp client special behaviour for Factory?
by Peter Poeml 04 Sep '08

04 Sep '08

Hi, I hear that factory installs force no-cache pragma, which destroys any cacheability. Is that (still) so? Or is that outdated information? If yes, this should be regarded as workaround of the past and removed. Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

4 6

[zypp-devel] libzypp-bindings (python) memory leak of type 'zypp::ResPool *'
by Jan-Simon Möller 04 Sep '08

04 Sep '08

Hi Klaus, hi list ! >>> mypool = zy.pool() swig/python detected a memory leak of type 'zypp::ResPool *', no destructor found. I got it working but next stop is to query the pool, which fails. best regards Jan-Simon -- 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] [Patch] building libzypp-bindings with prefix != /usr
by Jan-Simon Möller 03 Sep '08

03 Sep '08

Here's a patch to be able to define the cmake Paths and my Makefile.cvs. Could we integrate this ? Best regards Jan-Simon

1 0

[zypp-devel] building libzypp with prefix != /usr
by Jan-Simon Möller 03 Sep '08

03 Sep '08

Here's what i use for that ... autodetections seems broken here. best regards Jan-Simon

1 0

[zypp-devel] [patch] build satsolver as user with prefix != /usr
by Jan-Simon Möller 03 Sep '08

03 Sep '08

Hi ! Here are some hacks I use to build satsolver locally without touching the installed system / build in separate prefix. Could we add these or such a solution to the repo ? best regards Jan-Simon

1 0

[zypp-devel] Yet another bindings issue
by Nikolay Derkach 03 Sep '08

03 Sep '08

Hi, I tried to hack python zypp bindings. With this code I want to list available resolvables in a specified repo: import zypp Z = zypp.ZYppFactory_instance().getZYpp() pool = Z.pool() repoManager = zypp.RepoManager() # find a repository with an alias r = pool.reposFind("qt") assert r print "ss: ", r.solvablesSize() print r.solvablesEmpty() print r.alias() repo = r.info() assert repo kp = repo.keepPackages() print kp repoManager.refreshMetadata(repo) if not repoManager.isCached( repo ): repoManager.buildCache( repo ) repoManager.loadFromCache( repo ); print "Available items: %d" % ( pool.size() ) for item in pool: print item.resolvable().description() The ouput is: ss: <Swig Object of type 'zypp::Repository::size_type *' at 0x8357b0>swig/python detected a memory leak of type 'zypp::Repository::size_type *', no destructor found. True Traceback (most recent call last): File "list_available_resolvables.py", line 23, in <module> kp = repo.keepPackages() AttributeError: 'PySwigObject' object has no attribute 'keepPackages' swig/python detected a memory leak of type 'RepoInfo *', no destructor found. swig/python detected a memory leak of type 'zypp::ResPool *', no destructor found. Note that it shows that there are no solvable in the repo. Any ideas what I'm doing wrong? Thanks. -- Regards, Nikolay Derkach -- 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] Trying to try out MediaAria2c handler...
by Peter Poeml 03 Sep '08

03 Sep '08

Hi, I'd like to try out Gerards work, which he has built in the build service, branched from the zypp-devel project: home:gfarrasb:branches:zypp:svn/libzypp It builds on openSUSE 11.0. However, trying to install it I run into a number of dependency problems: Error: Missing Dependency: satsolver-tools = 0.10.4 is needed by package libzypp-5.7.0-3.1.i586 (home_gfarrasb_branches_zypp_svn) Error: Missing Dependency: libzypp.so.424 is needed by package yast2-pkg-bindings-2.16.40-0.2.i586 (installed) Error: Missing Dependency: libzypp.so.424 is needed by package yast2-gtk-2.16.14-1.2.i586 (installed) I would be able to deinstall the yast stuff, but I can't find a newer sat solver for 11.0. In fact, I can't find any satsolver-tools package in the build service: % osc search --package satsolver-tools No matches found for 'satsolver-tools' in packages So I thought you guys could shed some light on what could be done? What's the recommended procedure to use newer libzypp builds on 11.0? Thanks, Peter -- Contact: admin(a)opensuse.org (a.k.a. ftpadmin(a)suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development

7 33

[zypp-devel] Re: [zypp-commit] r10919 - /trunk/libzypp/zypp/parser/RepoindexFileReader.cc
by Michael Matz 03 Sep '08

03 Sep '08

Hi Jano, [sorry you get this twice] On Wed, 3 Sep 2008, jkupec(a)svn.opensuse.org wrote: > Log: > - skip repositories with non-matching target distro when reading repoindex > > @@ -98,6 +103,19 @@ > if ( reader_r->name() == "repo" ) > { > XmlString s; > + > + // skip repositories with unknown or not matching target distribution > + s = reader_r->getAttribute("distro_target"); > + if (!s.get() || _target_distro != s.asString()) > + { > + MIL > + << "Skipping repository meant for '" > + << (s.get() ? s.asString() : "(not specified)") > + << "' distribution (current distro is '" << _target_distro << "')." > + << endl; > + return true; > + } > + If I understand the code correctly I don't think this is a good idea. If the repofile doesn't have any entry for "distro_target" it will be skipped. I rather would think that this is supposed to mean "don't care". Even _if_ it has a target-distro set (that's a new concept anyway, right?) why should we reject to use it? E.g. if it's completely self-contained (in the sense of only having external dependencies on, say, libc), like I would expect with some vendor repos, I can and want to use it on all distros. Also, how is the name matched? Above it's a string comparison. But 11.1 and SLES11 will be roughly the same, for instance. To me it sounds more a feature needlessly annoying users. What's the purpose of this? Ciao, Michael. -- 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] libzypp-binding-python: gpgCheck(False) has no effect ?
by Jan-Simon Möller 03 Sep '08

03 Sep '08

Hi and moin moin ! I'm playing again with libzypp/python. See the test1.py (lots of comments, but i need to remember later :D). I've a local obs instance mirrored at http://localhost/. The repo is at http://localhost/software_from_lire/base_factory/ [DIR] Parent Directory - [DIR] i586/ 03-Jul-2008 13:57 - [DIR] noarch/ 03-Jul-2008 13:30 - [DIR] nosrc/ 03-Jul-2008 13:26 - [DIR] repodata/ 03-Jul-2008 13:57 - [ ] software_from_lire.repo 03-Jul-2008 13:57 220 [DIR] src/ In the repoinfo I set gpgCheck to False. If I add this repoinfo it works, but then: >>> myrepomanager.refreshMetadata(myrepoinfo) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/dl9pf/pfx/lib64/python/site-packages/zypp.py", line 1609, in refreshMetadata def refreshMetadata(*args): return _zypp.RepoManager_refreshMetadata(*args) RuntimeError: History: - Signature verification failed for repomd.xml Valid metadata not found at specified URL(s) >>> Any idea ? What did I miss ? Best regards, Jan-Simon

2 2

[zypp-devel] using libzypp as user and also in /$MYROOT (libzypp-bindings / libzypp)
by Jan-Simon Möller 03 Sep '08

03 Sep '08

Hi ! I'm using libzypp / libzypp-bindings-python to query packages available in an http-rpmmd-repo. I started with initializeTarget(zypp.Pathname("/tmp/a")) created my repoinfo, but then mymanager.addRepository(myrepoinfo) fails because it wants to write to /etc/zypp. How can I change this behaviour ? AFAIK /etc/zypp is stored in configPath. But found no "setConfigPath". Did I miss something? Or is this not possible with libzypp ? Best regards Jan-Simon -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 5

[zypp-devel] vendor
by Martin Vidner 03 Sep '08

03 Sep '08

Hi, I have tried to update oS 11.0 to SLES 11 Alpha2 using zypper dup. The proposed transaction only contained a dozen of packages, and it turned out that zypp thinks the SLES packages have no vendor specified. Is that a known bug? (Or a "feature"?) Consequently the solver thought that I would be changing the vendor of all packages and did not allow to update them. So I thought never mind, there I see a mention of "vendors.d" in the log file where I should be able to say that the empty vendor is equivalent to "SUSE LINUX Products GmbH, Nuernberg, Germany". But there is no documentation :( (And after reading the code I suspect that it is unusable because it assumes the vendor name does not contain a comma.) Is this supposed to work at all? -- Martin Vidner, YaST developer http://www.google.com/images?q=argh Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 6