- Zypp Development

[zypp-devel] Testmail
by Benjamin Zeller 23 Oct '19

23 Oct '19

Testing if zypp-devel works properly. -- Benjamin Zeller <bzeller(a)suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] NEW: zypper-1.14.31 (libzypp-17.15.0) - Resolver focus modes
by Michael Andres 22 Oct '19

22 Oct '19

NEW: zypper-1.14.31 (libzypp-17.15.0) --solver-focus MODE [/etc/zypp/zypp.conf:solver.focus] If you do not request a specific version of a package the solver will pick a reasonable one. The solvers general attitude when resolving a job is to focus on installing the best version of the requested package and to add or update dependencies as they are needed. Aside from this 'Focus on Job', which is the default, two other focus modes are available: In 'Focus on Installed' mode the solver focuses on applying as little changes to the installed packages as needed. Choosing an older version of a requested package is valid if it’s dependencies require less changes to the system. The solver will try to avoid updating already installed packages. In 'Focus on Update' mode the solver focuses on updating the requested package and all its dependencies as much as possible. Beware, installing a single package in this mode may easily lead to a mini system update. For a single command the focus mode can be set using the '--solver-focus MODE' switch. Valid modes are Job, Installed or Update. If you want to change the default mode for your system, set [/etc/zypp/zypp.conf:solver.focus] to the desired value. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres, R&D, ma(a)suse.com, Phone: ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] Re: Question regarding error codes and `/var/run/reboot-needed`
by Michael Andres 12 Jun '19

12 Jun '19

On Wednesday 12 June 2019 12:16:04 Rafael Fernández López wrote: > I see that `zypper needs-rebooting` right now only checks for the > existence of said file, but we might be safer in the future if zypper > behavior changes if using `zypper needs-rebooting`. IMO right. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE Linux GmbH, Development, ma(a)suse.com Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] 'zyyper remove' grabbing additional packages for removal
by Brian Reichert 04 Jun '19

04 Jun '19

I hope this is the correct forum for this question; I'm open to suggestions for something more appropriate. I'm using zypper 1.13.28 (zypper-1.13.28-20.2.x86_64) under SLES 12.3. I'm invoking zypper as such: zypper -v -v --userdata "$zyp_tid" --no-remote remove -D -y --details --no-clean-deps $uninstall_rpms For some reason, zypper is going out of it's way to grab additional packages. I don't want it so do so, but I don't know how to prevent it. Here's an example run; I've altered the names of the packages, as this is our proprietary code. Note that it correctly lists the packages in the lines written as 'Selecting ...', but if you review the final list: The following 15 packages are going to be REMOVED It grabbed two more: foo-iptables foo-restage # zypper -v -v --no-remote remove -D -y --details --no-clean-deps foo-agents foo-chroot foo-chroot1 foo-httpd foo-ipm foo-kerberos_bar foo-libs_bar foo-oracle_bar foo-osc foo-radius_bar foo-tomcat_bar foo-ui foo_bar Verbosity: 2 Remote repositories disabled. Entering non-interactive mode. Non-option program arguments: 'foo-agents' 'foo-chroot' 'foo-chroot1' 'foo-httpd' 'foo-ipm' 'foo-kerberos_bar' 'foo-libs_bar' 'foo-oracle_bar' 'foo-osc' 'foo-radius_bar' 'foo-tomcat_bar' 'foo-ui' 'foo_bar' Initializing Target Loading repository data... Reading installed packages... Force resolution: Yes Selecting 'foo-osc-16.4-99.x86_64' for removal. Selecting 'foo-oracle_bar-16.4-99.x86_64' for removal. Selecting 'foo-chroot-16.4-99.x86_64' for removal. Selecting 'foo-httpd-16.4-99.x86_64' for removal. Selecting 'foo-tomcat_bar-16.4-99.x86_64' for removal. Selecting 'foo-ui-16.4-99.x86_64' for removal. Selecting 'foo-ipm-16.4-99.x86_64' for removal. Selecting 'foo-kerberos_bar-16.4-99.x86_64' for removal. Selecting 'foo-libs_bar-16.4-99.x86_64' for removal. Selecting 'foo_bar-6.4-99.x86_64' for removal. Selecting 'foo-agents-16.4-99.x86_64' for removal. Selecting 'foo-chroot1-16.4-99.x86_64' for removal. Selecting 'foo-radius_bar-16.4-99.x86_64' for removal. Resolving package dependencies... Force resolution: Yes The following 15 packages are going to be REMOVED: foo-agents 16.4-99 x86_64 Company, Inc. foo-chroot 16.4-99 x86_64 Company, Inc. foo-chroot1 16.4-99 x86_64 Company, Inc. foo-httpd 16.4-99 x86_64 Company, Inc. foo-ipm 16.4-99 x86_64 Company, Inc. foo-iptables 16.4-99 x86_64 Company, Inc. foo-kerberos_bar 16.4-99 x86_64 Company, Inc. foo-libs_bar 16.4-99 x86_64 Company, Inc. foo-oracle_bar 16.4-99 x86_64 Company, Inc. foo-osc 16.4-99 x86_64 Company, Inc. foo-radius_bar 16.4-99 x86_64 Company, Inc. foo-restage 6.4-99 x86_64 Company, Inc. foo-tomcat_bar 16.4-99 x86_64 Company, Inc. foo-ui 16.4-99 x86_64 Company, Inc. foo_bar 6.4-99 x86_64 Company, Inc. 15 packages to remove. After the operation, 353.0 MiB will be freed. Continue? [y/n/...? shows all options] (y): y committing (dry run) CommitResult (total 15, done 0, error 0, skipped 15, updateMessages 0) -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 1

[zypp-devel] Locale management support in zypper
by Benjamin Zeller 01 Feb '19

01 Feb '19

Just a short heads up about a new feature in zypper version: 1.14.23 We have added new commands for locale management: zypper locales zypper addlocale zypper removelocale Those commands make it possible to inspect and manipulate the systems `requested locales`, aka. the languages software packages should try support by installing translations, dictionaries and tools, as far as they are available. -- Benjamin Zeller <bzeller(a)suse.de> Systems Programmer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] JFYI: libzypp-17.10.2 / zypper-1.14.18 and --no-recommends
by Michael Andres 18 Dec '18

18 Dec '18

JFYI: libzypp-17.10.2 / zypper-1.14.18 and --no-recommends Due to the trend to have really small systems more and more systems are installed with --no-recommends (or `solver.onlyRequires = true` in /etc/zypp/zypp.conf). Unfortunately this option also prevented the autoselection of appropriate driver or language supporting packages. This flaw should be fixed with libzypp-17.10.2 / zypper-1.14.18. - The use of --no-recommends should no longer affect the selection of driver and language supporting packages. - `zypper inr --no-recommends` should just add missing driver and language supporting packages to the system. Omitting all the 'ordinary' recommends. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX GmbH, Development, ma(a)suse.com Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] gpgkey ignored for rpm-md repositories?
by Joe Damato 04 Apr '18

04 Apr '18

Greetings: My rpm-md style repository contains *both* repository metadata GPG signatures (i.e. repomd.xml.asc) and RPM packages which have GPG signatures, created via rpm --addsign. On a YUM-based system (e.g., CentOS 7), I simply need to list all the necessary URLs for both repository GPG and package signing public keys with gpgkey=. When I update the metadata (via yum makecache) all listed keys are automatically imported to the correct place; package signing keys into rpm db and the repository signing key into the YUM keyring. On OpenSUSE 42.3 with zypper 1.13.40 and libzypp 16.17.10, I have noticed that none of the URLs specified with gpgkey= seem to be imported even after I run zypper --gpg-auto-import-keys refresh reponame. I have verified this by running rpm -qa | grep gpg-pubkey and saw that the keys specified in the repository configuration file were not imported to RPM DB. It seems that the only way to import a package signing key on OpenSUSE 42.3 for an rpm-md style repository is to run rpm --import file.key. Is this a known issue? Perhaps I am doing something wrong; maybe there is another command I should run to get zypper to import the keys listed with gpgkey other than "refresh" ? If my observation is correct that gpgkeys are not currently being imported by zypper, there might be a relatively straightforward solution: it appears that gpgkey URLs are being parsed from the repo config, they just aren't being used. Perhaps in RepoManager::Impl::refreshMetadata in addition to downloading the raw repository metadata and repository signing key into the cache directory, libzypp could also iterate across gpgKeyUrls() (via the RepoInfo object reference which is passed in), download the keys, and import them into rpm DB (if they have not already been imported). Thanks, Joe -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

2 1

[zypp-devel] libzypp/zypper branched for Code12 maintenance
by Michael Andres 24 Oct '17

24 Oct '17

JFYI: Maintenance for Code12 (libzypp-16.x zypper-1.13.x) has been moved to SuSE-SLE-12-SP2-Branch. Master is now open for Code15 (libzypp 17.x zypper 1.14.x) -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX GmbH, Development, ma(a)suse.com Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

1 0

[zypp-devel] "Checking for file conflicts" - slower than it used to be?
by Adam Spiers 24 Apr '17

24 Apr '17

Is it just me or does the "Checking for file conflicts" stage of a zypper install sometimes take a lot longer than it used to? My memory is that it always used to be extremely fast, whereas now it can take tens of seconds in some cases, or even minutes. It seems very strange to me that it would ever need to take more than a fraction of a second. Is there a good reason for this? -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

3 5

[zypp-devel] Using python zypp in a daemon without locking zypper forever
by Bernhard Suttner 15 Mar '17

15 Mar '17

Hi, I'm trying to integrate libzypp to a daemon which is written in python. I'm using SLES12 with the following components: zypper- 1.12.45 -31.2.x86_64 libzypp- 15.23.1-30.1 .x86_64 python-zypp-0.7.3-1.6.x86_64 It's working pretty good but unfortunately, it does block zypper from being used as the daemon will keep the "lock" even if the zypp object is destroyed. I have attached 3 examples which illustrates the issue: - testZ.py will just initate the zypp library and then sleep forever in a while loop. - testThread.py will do the same but will initate the zypp library in a separate thread - testProcess.py will use a new process instead of a thread Just start the test application and then try to use zypper in a second shell e.g. zypper search which will then show the following message: System management is locked by the application with pid 18852 (python). Close this application before trying again. The same happpens for testThread.py. testProcess.py does work as the process in which zypp was initiated will be terminated and everything is free'd. Does someone know how to get the testZ.py example running? I don't want to start a process (or thread) for doing the zypp stuff within the daemon. Would be great if there is a better solution. Thank you in advance. Best regards, Bernhard Suttner ______________________________________________________ ATIX - The Linux & Open Source Company

3 3