- Zypp Development

[zypp-devel] feedback/questions about zypp-evaporate
by Mauro Morales 29 Feb '16

29 Feb '16

Hi , Just wanted to give some feedback/make some questions about zypp-evaporate. When machinery runs an inspection on a system we extract different scopes of information. 1. The list of packages `rpm -qa --qf ...` so we get the name, version, release, architecture, vendor and checksum of the package. 2. The list of repos `zypper --xmlout repos --details` so we get the alias, name, type, url, enabled, autorefresh, gpgcheck and priority. 3. The list of patterns `zypper patterns -i` so we capture name, version and release. Now if I compare this information in my system I go from having around 2445 packages to 266 solvables, which I find very cool btw. A use case for us would be the ability to * give zypper/zypp-evaportate from the command line a list of packages, repos and patterns from an inspected machine * optionally pass some flags to tell how to resolve in case of different scenarios and expected output format With this functionality we can improve the output of our kiwi export by making the config.xml file more concise (like in my case 10 fold shorter) Would this be possible? Thanks!

2 1

[zypp-devel] 'zypper ps' pending changes
by Michael Andres 24 Sep '15

24 Sep '15

zypper-1.12.16 ============== 'zypper ps' got 2 new options: --short & --print ------------------------------------------------------------------- ps [options] List running processes which might still use files and libraries deleted by recent upgrades. Command options: -s, --short Create a short table not showing the deleted files. Given twice, show only processes which are associated with a system service. Given three times, list the associated system service names only. --print <format> For each associated system service print <format> on the standard output, followed by a newline. Any '%s' directive in <format> is replaced by the the system service name. ------------------------------------------------------------------- To see only those processes associated with a system service: ------------------------------------------------------------------- $ zypper ps -ss The following running processes use deleted files: PID || User | Command | Service -----++------------+----------------------------+----------------- 329 || root | systemd-journald (deleted) | systemd-journald 439 || root | libvirtd | libvirtd 893 || avahi | avahi-daemon | avahi-daemon 894 || root | gdbus | ModemManager 895 || root | rpcbind | rpcbind ------------------------------------------------------------------- To get the plain list of affected system service names only: ------------------------------------------------------------------- $ zypper ps -sss ModemManager avahi-daemon dbus icecream libvirtd lvm2-lvmetad polkit postfix ------------------------------------------------------------------- ------------------------------------------------------------------- $ zypper ps --print 'systemctl status %s' systemctl status ModemManager systemctl status avahi-daemon systemctl status dbus systemctl status icecream systemctl status libvirtd systemctl status lvm2-lvmetad systemctl status polkit systemctl status postfix ------------------------------------------------------------------- zypper-1.12.17 ============== In reports like (bsc#945169) systems suffer from slow running 'lsof' calls. We added a new section and option commit/psCheckAccessDeleted to turn off the calls if necessary: ------------------------------------------------------------------- [commit] ## Post commit check for processes/services using old/deleted files ## ## Like 'zypper ps', the post commit check for processes/services using ## old/deleted files calls 'lsof'. On some systems 'lsof' seems to perform ## very slow, and the check takes up to several minutes. Due to this it's ## possible to disable the automatic check after each commit. Explicit calls ## to 'zypper ps' are not affected by this option. ## ## Valid values: boolean ## Default value: yes ## # psCheckAccessDeleted = yes ------------------------------------------------------------------- -- 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

Re: [zypp-devel] zypp file conflicts multilib
by Michael Andres 07 Jul '15

07 Jul '15

On Tuesday 07 July 2015 09:49:03 Damian Ivanov wrote: > When installed in parallel, multilib RPM packages may contain files that > live in common paths. When this happens, RPM uses the following algorithm: > > - If the file in both packages is identical, installation is allowed > and the file is written > - If the file in both packages is an ELF binary, the file used is the > file in the package for the primary architecture > - If the file in both packages is not an ELF binary a RPM conflict is > raised > > > So my suggestion here would be zypper also not to warn about a file > conflict if you're installing a package for a secondary architecture that > contains an elf file that conflicts with an elf file for your primary > architecture. > RPM heuristics will anyway not overwrite the elf file for you primary > architecture, > so zypper warning about that happening makes no sense (as it won't happen). File conflicts are detected and reported by libzypp/libsov; zypper just visualizes them. On Fedora it's important that libsolv was built passing "-DFEDORA=1" to cmake. This will set the solver option 'implicitobsoleteusescolors=1', which enables support for installing multilib RPM package in parallel. (you can grep for implicitobsoleteusescolors in /var/log/zypper.log to check it's value). If the reported conflicts are nevertheless wrong, you should file an issue at https://github.com/openSUSE/libsolv/issues. (Somehow related to https://github.com/openSUSE/libzypp/issues/46; zypper is not familiar with Fedoras way of installing multilib RPM package in parallel.) > You open to patches? :) Of course. Preferred via github. (https://github.com/openSUSE/{libsolv,libzypp,zypeper}) -- 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, Dilip Upmanyu 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

2 5

[zypp-devel] zypp file conflicts multilib
by Damian Ivanov 07 Jul '15

07 Jul '15

Hello all, As a fun test I compiled libsolv+libzypp+zypper for Fedora 22 https://build.opensuse.org/project/show/home:damianator:fedora:zypper On a vanilla Fedora 22 install I installed libsolv+libzypp+zypper and did zypper remove yum* dnf* Actually Fedora is completely usually with only zypper, impressive! (the only real problem would be the anaconda installer) I encountered one more issue though. On Fedora the 32-bit lib packages are the 'normal' i686 packages of the lib copied to the x86-64 repos. So when you install a lib like alsa-lib.i686 it contains the same files (the .so files reside in their respective /usr/lib or /usr/lib64 folders) the x86-64 version does. For non binary files (which on both architectures are the same) no conflict is there. But alsa-lib (and other packages) contains also binaries like 'aserver' which differs for both architectures and zypper warns about a file conflict and if I continue the /usr/bin/aserver file from the x86-64 will be replaced with the one from the i686 package, zypper says. I was wondering why zypper warns about that and yum/dnf doesn't and just installs the alsa-lib package. Turns out even with zypper the file won't be replaced with the one from the i686 package! Explanation here: https://lists.fedoraproject.org/pipermail/devel/2010-January/129725.html When installed in parallel, multilib RPM packages may contain files that live in common paths. When this happens, RPM uses the following algorithm: - If the file in both packages is identical, installation is allowed and the file is written - If the file in both packages is an ELF binary, the file used is the file in the package for the primary architecture - If the file in both packages is not an ELF binary a RPM conflict is raised So my suggestion here would be zypper also not to warn about a file conflict if you're installing a package for a secondary architecture that contains an elf file that conflicts with an elf file for your primary architecture. RPM heuristics will anyway not overwrite the elf file for you primary architecture, so zypper warning about that happening makes no sense (as it won't happen). You open to patches? :) Best regards, Damian -- 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] BuildRequires: graphviz-gnome
by Damian Ivanov 07 Jul '15

07 Jul '15

Hello all, I am interested in zypper/libzypp and found that it BuildRequires: graphviz-gnome I found: https://github.com/openSUSE/libzypp/pull/25 but not actually anything using graphviz-gnome is that still required? (grep for graphviz shows only the buildrequire and cmake looking for it) Thanks in advance! -- 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] [zypper-1.12.5] git like subcommands for zypper
by Michael Andres 19 Jun '15

19 Jun '15

JFYI: zypper-1.12.5 provides simple git-like subcommand support. (Backported to SLE12/openSUSE13.2 in zypper-1-11-33) [zypper(8)] SUBCOMMANDS Zypper subcommands are inspired by git(1). Subcommands are standalone executables that live in the zypper_execdir (/usr/lib/zypper/commands). For subcommands zypper provides a wrapper that knows where the subcommands live, and runs them by passing command options and arguments to them. If a subcommand is not found in the zypper_execdir, the wrapper will look in the rest of your $PATH for it. Thus, it’s possible to write local zypper extensions that don’t live in system space. This is how to add your own subcommand zypper mytask: · The executable must be named zypper-mytask. · The executable must be located your $PATH. · A manpage for zypper-mytask should be provided and explaining the commands options and return values. It will be shown when calling zypper help mytask. · Zypper built-in commands take precedence over subcommands with the same name. · It’s fine to call zypper or use libzypp from within your subcommand. You can use the built-in zypper subcommand command to get a list of all subcommands in zypper_execdir and from elsewhere on your $PATH. Using zypper global-options together with subcommands, as well as executing subcommands in zypper shell is currently not supported. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX GmbH, Development, ma(a)suse.de Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu 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] New Rpm-ecosystem Mailing List
by Florian Festi 11 May '15

11 May '15

Hi! tl;td: Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem if your interested in any part of the rpm ecosystem. While there are quite some mailing lists already that deal with the different tools around and including rpm we realized that there is no good place to discuss issues that involve multiple parts of (our own) package handling stack even less so to stay in contact with other rpm based solutions. To solve this we create a new mailing list: rpm-ecosystem(a)lists.rpm.org Normal user questions and development talk is supposed to stay on the per project mailing lists. The new list is for questions like: * How do other implementations handle specific problems? * Is this new feature interesting for downstream distributions? * How do the different packaging guidelines treat a special topic? * Anyone there to support our demand for this new rpm feature? And it is for topics like: * Packaging guide lines * RPM features * Build systems and compose tools * Dependency solvers, installers and updaters * RPM based image creation / non rpm based updates for rpm based distributions In short: It is meant to bind the rpm universe together. Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem Please forward this mail to anyone that might be interested - especially to rpm related sub projects and groups. Thanks! Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -- 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] detecting an install media based on directory layout
by Olaf Hering 07 May '15

07 May '15

What is the easiest way to decide if a given directory tree from a block device is an install media? In grub2 for Xen PV guests a grub script has to decide if a menu has to be presented or not. The current approach is to do something like r=some_disk if test -e $r/content && test -e $r/boot/x86_64/vmlinuz-xen && test -e $r/boot/x86_64/initrd-xen then show install menu show boot menu else show boot menu fi I wonder if that is robust enough to decide if a given block device is an installation DVD or not. Should the script stat something else, or some additional files to be sure, like /media.1/directory.yast or /media.1/media? Olaf -- 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] zypp.conf multiversion kernel config -- different retention for different kernels?
by lyndat3＠your-mail.com 27 Apr '15

27 Apr '15

I have a server I use as a Xen host. On occassion, I need to boot into !Xen, kernel-default. I want to keep multiple kernel-xen versions installed, but only one (eventually 2), kernel-default. Following Chapter 12. Installing Multiple Kernel Versions https://activedoc.opensuse.org/book/opensuse-system-analysis-and-tuning-gui… I've edited zypp.conf multiversion = kernel-xen multiversion.kernels = latest,latest-1,running,3.16.7-7,3.19.4-1.g74c332b and rebooted. With that config, I'd expected that I'd end up with ONE kernel-default, and several kernel-xen. Instead, I find rpm -qa | grep -i ^kernel kernel-default-4.0.0-1.1.g49e42b3.x86_64 kernel-default-3.19.4-1.1.g74c332b.x86_64 kernel-default-3.16.7-7.1.x86_64 kernel-xen-4.0.0-1.1.g49e42b3.x86_64 kernel-xen-3.19.4-1.1.g74c332b.x86_64 kernel-firmware-20150209git-36.1.noarch I.e., multiple kernel-default, and kernel-xen-3.16.7-7.1.x86_64 which existed before the edit/reboot, is now gone. What's the right multiversion config to do what I need? LT -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: zypp-devel+owner(a)opensuse.org

2 3

[zypp-devel] Retailer Statement for 63291
by user 23 Mar '15

23 Mar '15

HI, document as an attachment Dale Becker Kerber, Eck & Braeckel LLP 1000 Myers Building Springfield, IL 62701 Phone: 217-789-0960 Fax: 217-789-2822 http://www.kebcpa.com Kerber, Eck & Braeckel, LLP CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email to sender at KEB and promptly delete this message and its attachments from your computer system.

1 0