October 2023 - openSUSE Factory - openSUSE Mailing Lists

[TESTERS WANTED] Using git to maintain packages on OBS - test run
by Dan Čermák 08 Dec '23

08 Dec '23

Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work". FAQ: - Where can I report issues or provide feedback? https://github.com/openSUSE/scm-staging/issues (for bugs) or https://github.com/openSUSE/scm-staging/discussions (for general feedback) - Is this how the future of packaging in openSUSE is going to look like? Maybe, maybe not. This is currently just a test drive and its outcome will influence the way forward. - Will submitrequests to my develpackage still work? Sadly no, branching a git maintained package on OBS does not work. Please indicate in the description of your package that users should contribute on src.opensuse.org instead. - Which tools do I need? Just git, git-lfs and osc (at least version 1.2.0 is recommended for service runs to work) Looking forward to your feedback! Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

23 66

Migrate from update-alternatives to libalternatives
by Martin Schreiner 05 Dec '23

05 Dec '23

Hello folks, As some of you may know, there are some limitations regarding update-alternatives that prevent it from working perfectly when using transactional updates. Basically, /var isn't part of the snapshot's data. This means that all files created/manipulated during package installation in /var/lib/alternatives won't be taken into consideration when snapshots are rolled back. More information is available here: https://kubic.opensuse.org/documentation/transactional-update-guide/tu-setu… This fact could lead to broken symlinks: Suppose I install "go1.20"(snapshot A) and "go1.21" (snapshot B). I then boot from snapshot A, but "/var/lib/alternatives/go" still tells "update-alternatives" that "go1.21" would be a valid choice, since this information lives outside of the snapshot's directories, in "/var". If "update-alternatives" were to accept that choice, then "/etc/alternatives/go" would become a broken link, our last line of defence here being how carefully maintained "update-alternatives" is. So that's not a system-level design solution, but rather very application-specific. What we're planning: Replace update-alternatives with libalternatives: https://github.com/openSUSE/libalternatives This change should be done gradually on Factory, and ideally it would require no manual intervention from the users. We plan on releasing this change in batches: i.e.: all Go versions we provide on Factory would be migrated to libalternatives in a single-pass. Then another set of closely-related packages, such as the OpenJDK. Then another, so on and so forth. What we need: The goal of this thread is to establish a line of discussion around this change, which should be a gradual one on Factory. All opinions, comments, ideas and criticism are valid, and will be taken into consideration. Status: There are currently 14909 spec files on openSUSE:Factory. 964 (6.46%) of these depend on update-alternatives. Currently 52 packages use libalternatives, such as vim and nodejs-common. Basically, the cores of both MicroOS and SLE Micro are already using libalternatives. Things that seem to be clear in this particular context: 1 - libalternatives should work really well with transactional updates: As the state of alternatives kept by libalternatives is maintained in /usr/share/libalternatives/<binary>/<pref>.conf, this means that packages only need to provide a single file to provide their alternative. This file will be part of the package's regular files (declared in %files), and no state is modified by any hooks (preun, postun, prerm, postrm) during the updates. Rolling back a snapshot will revert back to a state where that alternative didn't exist (as it wasn't installed). 2 - libalternatives does not manipulate symlinks: /usr/bin/alts (the main binary for libalternatives) executes binaries directly (by calling exec()). The actually binary (for example, /usr/bin/vi) is a symlink to /usr/bin/alts, which then reads its configuration files and determines which binary to execute, based on the highest priority. 3 - libalternatives supports user overrides: non-root users can override the alternatives by creating their own local preference file in $HOME/.config/libalternatives.conf. This may be done by invoking "alts" directly, as it serves both purposes. 4 - Even if it doesn't manipulate symlinks, groups and manpages are still supported: libalternatives has a "group" directive for manipulating groups of binaries together, and it has some verifications to ensure the binaries in these groups are indeed declared in tandem with one another, essentially managing them as a collection. It also has a "man" directive for man pages, so even if it's not doing symlink manipulation, look up man pages still works. In fact, our "man" package was patched to work with libalternatives support: https://build.opensuse.org/package/view_file/Base:System/man/man-db-2.9.4-a… 5 - No RPM macros are required: This is really cool. We're basically just adding a file to %files, to use libalternatives. So no RPM macros are even required here. But we could create an RPM macro that automatically writes the preference file, so we could easily manipulate its contents inside the RPM spec. 6 - How libalternatives can actually be used So there are actually at least TWO ways to use libalternatives: we either create a symlink to /usr/bin/alts, or use libalternatives as a shared object and write a tiny wrapper program, such as this one: https://build.opensuse.org/package/view_file/devel:languages:nodejs/nodejs-… The advantage of the first method is that we don't need a special – albeit short – C program to act as a dispatcher for libalternatives's magic sauce. The advantage of the second method is that we don't need packages to depend on the "alts" package (which contains /usr/bin/alts), but only on "libalternatives1" instead (which provides /usr/lib64/libalternatives.so.1). I appreciate if you can provide any insights here, they're more than welcome. Thank you.

16 45

Sudo announcement - upcoming changes
by Otto Hollmann 27 Nov '23

27 Nov '23

Hi all, I'm happy to inform you about upcoming changes in our openSUSE implementation of sudo. The first change is splitting configuration files between /etc and /usr/etc. More information about why we are introducing this change can be found here [1]. Sudo will read configuration files in the following order: /etc/sudoers, /usr/etc/sudoers. Our distribution file will be installed in /usr/etc/sudoers. If there is no /etc/sudoers file, the command visudo will open /usr/etc/sudoers and save the result as /etc/sudoers. If /etc/sudoers file already exists, there is no change in visudo behavior - it will open and edit /etc/sudoers. Big thanks to sudo upstream and Jason Sikes for this change. The second change relates to the configuration "Defaults targetpw" SUSE traditionally ships sudo with "Defaults targetpw". That allows any user in the system to use sudo without configuration by authenticating as the target user (usually root). An alternative authentication scheme used by some Linux distributions allows users who are members of a specific group to authenticate as root by typing their own password. So far, this model required manual configuration. To make this approach easier, we are now introducing the following optional packages: * sudo-policy-wheel-auth-self * sudo-policy-sudo-auth-self * system-group-sudo If installed, users in the wheel group (first package) or sudo group (second package) will be asked for their password instead of the password of the target account when executing the sudo command. There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users. So updating sudo is safe in any case. The third package (which will be installed as a dependency for the package sudo-policy- sudo-auth-self) creates a configuration file for systemd-sysusers, ensuring that the system group "sudo" will be created. *Please note the meaning of the wheel group is not well defined, so adding users to that group may have effects outside the scope of sudo.* In addition, those packages also install polkit policies so applications using polkit will be also allowed to authenticate in the same way. [1] https://en.opensuse.org/openSUSE:Packaging_UsrEtc Regards, Otto Hollmann

9 23

Remove dependency on /usr/bin/python3
by Daniel Garcia 22 Nov '23

22 Nov '23

Hello, As part of a Python team maintenance task we are trying to remove the dependency on /usr/bin/python3 from as many packages as possible to reduce the problems of changing the system python in the future [1]. Right now /usr/bin/python3 is a link provided by the current system python package that today is python311, in Factory. Any package that provides a python script with the shebang #!/usr/bin/python3 will have the requirement on /usr/bin/python3. There's a macro in the python-rpm-macros to fix the shebang on python scripts automatically, that can be used in the install phase, just before the fdupes call, and point to the real binary and not the link: %python3_fix_shebang This macro expands to: for f in /home/abuild/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}- %{RELEASE}.x86_64/usr/bin/*; do [ -f $f ] && sed -i "1s@#!.*python.*@#!$(realpath /usr/bin/python3)@" $f done And indeed will replace the shebang to point to #!/usr/bin/python3.11. This will make the script to work correctly, even if the system python changes in the distribution, avoiding the problem of running with a different python and not finding the deps that are in /usr/lib/python3.11/site- packages. In some cases it could be okay to have the shebang #!/usr/bin/python3, if there are no external dependencies and it's something that will work with different python versions, but when possible, and as a general rule, it'll be better to fix the shebangs. If you maintain a package that provides some python script, please, consider to add this macro call. [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1212476 -- Daniel García Moreno Python Packager

8 13

Announcing Agama 5
by Imobach Gonzalez Sosa 22 Nov '23

22 Nov '23

Hi all, We have just released Agama 5 which, among other things, includes: * A translated web user interface. By now, it is available in Dutch, English, Japanese, Spanish, Swedish. * A prototype of a software patterns selection. However, the important part is the discussion in the openSUSE Factory mailing list[1]. * Agama does not reuse pre-existing swap partitions. * Support to boot via PXE. As usual, you can find the full announcement in our blog[2]. Regards, Imo [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… [2] https://yast.opensuse.org/blog/2023-10-25/agama5 -- Imobach González Sosa SUSE Linux LLC

2 1

What Tumbleweed patterns do we want to offer during Agama installation
by Ancor Gonzalez Sosa 21 Nov '23

21 Nov '23

We need to talk. ;-) As you may know, the YaST Team is developing an alternative installer called Agama (formerly D-Installer). https://github.com/openSUSE/agama We want the workflow in Agama to be simpler than with YaST. Even without any selection of packages to install. But quite some people expressed their desire of being able to customize the software selection while installing the operating system itself. Since we don't want to bring back complex and specific concepts like the installation roles, we decided to expose the current list of patterns so the users can decide which ones to install... knowing that would expose some organizational problems we have with patterns. Take a look at https://yast.opensuse.org/assets/images/patterns-demo.gif That's a first implementation that shows we have WAY too many patterns that are WAY too arbitrarily organized. If we want to use patterns as the main concept to allow software customization... What can we do? Organize the patterns better? Introduce some kind of flag to distinguish the patterns that make sense to offer during installation? Fix something in the way we categorize the patterns? We feel this is not an UI problem, but an structural one. We are looking forward for realistic suggestions. Meanwhile, you can play with the current list by downloading the staging version of Agama. Ie. any image called agama-live-xxx-openSUSE-yyy.iso from https://download.opensuse.org/repositories/systemsmanagement:/Agama:/Stagin… Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

12 23

SCSI device identification and SCSI symlink generation in sg3_utils 1.48
by Martin Wilck 09 Nov '23

09 Nov '23

With the forthcoming update of sg3_utils to v1.48 (currently in Base:System, to be submitted to Factory soon), SCSI device identification and SCSI symlink generation by udev will change. TL;DR: unreliable device identifiers will not be used by default any more, and /dev/disk/by-id symlinks for such identifiers will not be created by default, either. The policy can be changed by editing the udev rules in 00-scsi-sg3_config.rules. Please file bugs and / or notify me if you have trouble with this new identification scheme. Of course, while this is still in Base:System, we can also discuss the general approach for Factory, and the defaults to be applied. Long version: It is well known that referring to disk devices by their device node (like /dev/sda) is unreliable. In most situations, it is recommended to refer to devices by their content, i.e. using file system UUIDs or labels. Sometimes, however, the devices must be referred to by hardware properties. For this purpose, udev maintains various symlinks under /dev/disk/by-id. This post is specifically about SCSI symlinks, which have the format /dev/disk/by-id/scsi-XYZ. If you don't use dm-multipath, and don't use hardware IDs to refer to any disks or partitions anywhere, you can stop reading here. SCSI devices can be identified in different ways by the contents of SCSI VPD (Vital Product Data) pages. In PVD 83 (device identification), the following identifiers may occur (see SCSI spec SPC-6 §7.7.6 for details): a) NAA registered extended: 36... (+ 31 hex digits) b) NAA registered: 35... (+ 15 hex digits) c) NAA extended: 32... (+ 15 hex digits) d) EUI-64: 2... (+ 16 hex digits) e) SCSI name string: 8... (+ utf-8 string) f) NAA local ("L"): 33... (+ 15 hex digits) g) T10 vendor-ID ("T): 1... (+ string) h) vendor-specific ("V") 0... (+ string) Furthermore, we have i) serial number ("S"): S... (+ vendor/product/serial string) The list above is sorted roughly top-down by the reliability (uniqueness) of these identifiers. The udev rules select the most reliable available identifier from the above list to set the ID_SERIAL udev property, which is used e.g. by dm-multipath to identify SCSI devices which represent different paths to the same physical volume. Furthermore, the udev rules create /dev/disk/by-id/scsi-$ID symlinks for all identifiers from the above list that are defined for a given device. This makes sure that whatever identifier a user has chosen for referring to her disks will be available as symlink under /dev/disk/by-id. However, this has also severe disadvantages. The identifiers f)-i) are not reliable; IOW there can be multiple devices in the same system that use the same identifier, although they don't represent the same physical disk. This applies to i) in particular: Some large storage arrays use the same serial number for all LUNs they expose. Using such identifiers for multipath can cause fatal data corruption. Moreover, the creation of these symlinks during boot can slow down booting a lot, because thousands of devices may be contending for the same symlink. Lastly, not creating useless symlinks will tidy up /dev/disk/by-id and make it easier to read. Therefore sg3_utils 1.48 changes the policy for SCSI device identification. The policy can be customized in the udev rule "00-scsi- sg3_config.rules" (to change the policy, copy this file from /usr/lib/udev/rules.d to /etc/udev/rules.d first). For determining ID_SERIAL, only a)-e) above are tried. If users need to use additional identifiers from the list above, they can set the udev property .SCSI_ID_SERIAL_SRC (leading "." is intentional) to any combination of the capital letters in quotes in the list above. E.g. "ST" would mean to take g) and i) into account. To restore the previous behavior, set ENV{.SCSI_ID_SERIAL_SRC}="LTVS". The current upstream default is "T", so that g) above is still enabled. To disable all "unreliable" IDs, set it to the empty string. If udev encounters a device for which ID_SERIAL can't be assigned, it prints a warning to the journal. Symlink generation is controlled by the variable .SCSI_SYMLINK_SRC. It can also be set to any combination of "LTVS", with the same meaning of the letters as above, and controls which scsi-... symlinks udev will create under /dev/disk/by-id/, *in addition* to the symlink /dev/disk/by-id/scsi-$ID_SERIAL, which will always be created if ID_SERIAL could be determined. Again, to restore the previous behavior of the udev rules, set ENV{.SCSI_SYMLINK_SRC}="LTVS". The default is the empty string. Note 1: The symlink generation applies to both disks and partitions. Partition symlinks have a "-part$P" string appended to the name of the symlink of their parent disk. Note 2: Modern SCSI devices usually support one or more of the "reliable" identifiers a)-e) above. I expect that only very few old devices really need one of f)-i). Inform me if you find counter- examples. Note 3: ATA and USB devices have additional identifiers generated by the transport (/dev/disk/by-id/ata-* and /dev/disk/by-id/usb-*) which are unaffected by this change. These devices often don't expose proper SCSI IDs, but they actually don't need them because the ATA or USB identifiers are unique. Regards, Martin

7 27

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 31 Oct '23

31 Oct '23

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have had problems for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - sonic-pi: Fails to build Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

1 0

[Announcement] support for systemd soft-reboot
by Thorsten Kukuk 31 Oct '23

31 Oct '23

Hi, systemd v254 introduced "soft-reboot" (https://manpages.opensuse.org/systemctl),which reboots the userland, but not the kernel or hardware. This allows a quick reboot after updates of e.g. dbus, glibc or openssl. With the latest snapshot, rebootmgr and os-update support this now, too. Means, if you use os-update for automatic updating your server and an update requires a reboot, but there is no new kernel or bootloader, the reboot will be done much quicker now. transactional-upate will get support for this next. The "zypp-boot-plugin" (https://manpages.opensuse.org/zypp-boot-plugin) looks at the packages which got installed or updated and decides according a config file, if: - a hard reboot is required (e.g. after update of the bootloader - kexec is enough (if only the kernel is updated) - a soft-reboot is sufficient - no reboot is necessary at all It's in the responsibility of the application triggering the reboot which of the method it used, zypp-boot-plugin only gives a hint. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

1 0

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 30 Oct '23

30 Oct '23

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have had problems for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - weblate: Fails to build - yuzu: Fails to build Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

1 0