August 2023 - openSUSE Factory - openSUSE Mailing Lists

Changes to dbus packaging (Some Attention maybe required).
by Simon Lees 04 Oct '23

04 Oct '23

Hi All, For Tumbleweed and ALP we plan to follow Red Hat / Fedora / Debian and move from dbus-daemon to dbus-broker as it has a number of advantages and is what upstream is now focusing on. While one of the goals here is to provide the same user experience there will be a couple of changes that will likely require adjustments in a few packages. 1. tools such as dbus-send and dbus-uuid will no longer be installed by default on all systems (we have many use cases that will simply no longer need them and this follows other distro's). Currently the package dbus-1-tools exists and is required by dbus-1 but that will change maybe to a recommends so if you know your package needs one of these tools you can add the Requires there now, otherwise I plan to go through and look at debian and fedora to try and find any packages that need this requires before it becomes optional for dbus. 2. The symlink from /etc/machine-id to /var/lib/dbus/machine-id will no longer be present on all machines and software should be adapted to use /etc/machine-id from systemd rather then the dbus copy. Again this has already happened for Debian and Fedora so hopefully many upstreams have already adapted to this. I'll outline the plan / timeline below. 1. Currently - dbus-broker has been in the distro for quite some time and the dbus-1 package has already been split up and we are at the point of asking people nicely to start testing (instructions below), myself and at least several other people have already been testing this without issues. 2. In 2-3 weeks if I don't hear of any issues we will update the systemd presets to enable dbus-broker rather then dbus-daemon. 3. Unless someone indicates they really want to keep maintaining dbus-daemon and have good reasons for doing so I will make dbus-daemon uninstallable. 4. Once we have done the work to ensure that as many packages that use dbus-send and other tools require the tools package we will drop the requires for dbus-tools from the dbus package. Instead it will probably move to being a Recommends in one of the patterns so it still ends up on most users machines. Switching to dbus-broker: Run the following as root zypper in dbus-broker systemctl disable dbus systemctl enable dbus-broker systemctl --global disable dbus systemctl --global enable dbus-broker https://www.mail-archive.com/debian-policy@lists.debian.org/msg35437.html https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementa… -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

4 6

Off topic: Can't log in to Bugzilla
by Mark Rubin 23 Sep '23

23 Sep '23

I believe I have a login at https://bugzilla.opensuse.org/ with the same username and password that I use here and at https://forums.opensuse.org/. It works at both those sites, and used to work at Bugzilla although the last time I used it there was several years ago. Bugzilla seems to know me, but when I try to log in using "openSUSE_IDP Log In" (the only choice) it rejects me, before asking for username/password/etc, with "There is already an account with the login name <my email address>". I did a password reset, and got a token in my email which it accepted back along with a new password, which then brought me to a page ending with my info and "Your profile is up to date". But I can't continue to the site from there, and trying to log in again restarts the same "already an account" loop. If anyone has any suggestions, or a way to contact the Bugzilla administrators to plead my case, I'd appreciate it. I have some new information to post there regarding my thread here, plus another new/verifiable bug to report. It's very frustrating to be trying to contribute (in some small way) to openSUSE only to get blocked by things like this.

7 16

RFC: turn off ppc32 and ppc64 big endian builds on openSUSE:Factory:PowerPC
by Dirk Müller 14 Sep '23

14 Sep '23

Hi all, recently I was made aware that openSUSE:Factory:PowerPC is quite a large distribution as it is building for ppc 32bit, ppc64 big endian and ppc64 little endian. in OpenQA as far as I know we are only testing the ppc64 little endian builds. Given the upcoming data center move and the lack of testing, are there any concerns about turning off the builds for ppc 32bit and ppc64 big endian? It would reduce build power needs as well as disk storage /publishing bandwidth which is shared with other distributions and architectures and becomes a problem because of PowerPC being exceptionally large. Thanks a lot in advance for any insight you can provide, Greetings, Dirk

10 26

Thunderbird 115
by Joe Salmeri 07 Sep '23

07 Sep '23

Is there a reason that Thunderbird 115 is being held back ? Version 115.0.1 was released on 07/20/2023 which was almost a month ago Version 115.1.0 was released on 08/01/2023 Version 115.1.1 was released on 08/15/2023 If I look at openSUSE build the builds are disabled https://build.opensuse.org/package/show/mozilla/thunderbird115 Is there an ETA as to when it will be published ? Thanks -- Regards, Joe

13 27

[RFC] Switching to drop-in files (systemd)
by Franck Bui 04 Sep '23

04 Sep '23

Hi, The way the systemd daemons (such as PID1, logind) parse their configuration file is specified in systemd-system.conf(5) man page (section CONFIGURATION DIRECTORIES AND PRECEDENCE). Basically the daemons parse first their "main" configuration file (e.g /etc/systemd/system.conf for PID1) and then read and apply the optional drop-in files located in the following directories: /usr/lib/systemd/*.conf.d/ /usr/local/lib/systemd/*.conf.d/ /run/systemd/*.conf.d/ /etc/systemd/*.conf.d/ It's important to note that drop-in files have higher precedence than the main configuration file. Hence if a package customizes an option by shipping a drop-in file in /usr/lib/systemd/*.conf.d/, it might override the value already set by the user if the same option was customized by the sysadmin in the main configuration. There were various discussions [1] about addressing this concern but at the end upstream preferred keeping the existing logic. This implies that using the main configuration files is not 100% safe (even if it's been documented since a long time) especially since openSUSE distros relies on drop-in files to tune a few upstream defaults, see systemd-default-settings package to get the list. To avoid inconvenient divergences with upstream, we'll follow the existing logic but this implies that: - use of main config files, such as /etc/systemd/{system.conf,logind.conf}, should be avoided and instead customization should be done via drop-in files, such as /etc/systemd/system.conf.d/50-local.conf. - Some drop-in priority ranges should be defined to make sure that drop-in created by users have always higher precedence over the ones shipped by packages. The priority ranges reserved for users and downstream will be defined and documented in the relevant wiki page. - at installation, systemd packages will stop installing (empty/template) main configuration files and instead users will find the templates in drop-in directories (such as /etc/systemd/*.conf.d/50-{local,main,xxx}.conf, exact filename to be defined). - optionally, the packaging stuff will take care of converting existing main configuration files into drop-in files during package update. If there's no objection with the above, this change will be probably take place during the upgrade to systemd v254 or quickly after. Thanks. [1] https://github.com/systemd/systemd/pull/17161

13 37

new pkg pipewire-module-xrdp
by Jason Craig 04 Sep '23

04 Sep '23

I have created a new package to facilitate sound with xrdp when using pipewire. At least one user has tested it and I have submitted it to X11:RemoteDesktop[1]. This request has stalled without response for a bit, if anyone can help with that. I intend to submit this to Factory after it is accepted into the devel project. thanks /Jason Craig [1] https://build.opensuse.org/request/show/1105159

2 2

Maintenance of library packages in topical teams?
by Dominik George 01 Sep '23

01 Sep '23

Heisan, this topic came up during my submission of python-mmllib to the Python devel project [1]. But, in fact, it seems to be a quite general discussion, so I am raising it here to get a general picture. As a side note, my current endeavour is exploring the maintenance, especially team maintenance and mentoring approaches, of packages in openSUSE, in comparison to how it is handled in Debian. I am a Debian Developer and therefore quite used to the workflows and basic approaches over there. The general question I'd like to discuss is where libraries for development in various languages should be maintained. There are development teams for all major languages, and these seem, to some extent, to maintain development libraries as well. Then, looking at MMLlib as an example, this package can be seen in two ways: * it is a library that can be used for various kinds of programs written in Python, among which are games, educational toys, and multimedia applications * it is not _really_ generic, as it is somewhat specialized in not only, but probably mostly the fields mentioned above So, in *theory*, MMLlib is a generic library that can be used by whoever thinks they need it in their program, but in practice, it will be mostly useful for the mentioned fields. Matej therefore proposed it be moved to another team, with the Education devel project in mind (because education is the field where I, also being the upstream maintainer, developed it). I, i ncontrast, are still in favour of having all sorts of Python libraries maintained in a language team. Let me summarize what I think are the arguments for the two approaches: a) Maintaining all development libraries in a single language project - high maintenance load for a single team - large collection of packages in a single, probably not too well namespaced bunch + simplified auto-maintenance and batch changes + better control over adherence to library packaging guidelines b) Maintaining specialised libraries in topical projects - less control over adherence to library packaging guidelines - not clear which topic fits the best (see example above) sometimes + less maintenance burden for a single team Closely related to this question is the question whether development libraries should go into the distribution at all. More recently, I found the stance of the Go language team on that [2]. In conclusion, this is "we do not want a large collection of development packages in the distribution, only those needed to build and run leaf binaries". Taht implies that developers who use openSUSE for their work are told to use non-openSUSE sources instead, and install development libraries from the repositories provided by their language ecosystem, and that we make a clear distinction: * packages in openSUSE are for end users * developers use their language ecosystem tools Generally, I am in favour of providing all tools, including libraries, for everyone in a distribution, but that's a very "Debian" view of things. In practice, it shows that for Python development, virtual environments managed with poetry or whtever, and installing packages from PyPI, is far better suited. So I am somewhat moving into that direction. But then again, I find it questionnable that the Go language team should be responsible for maintaining any binary leaf packages. Why is teh Go devel project responsible for maintaining, say, hugo [3], and not a devel project tailored at website topics? All in all, I think my favourite pattern would be somethign like this: * maintain binary leaf packages in a topical team * maintain libraries in a language team, independent of topic * do not accept libraries that are not dependencies of leaf packages I am aware that there is no "one size fits all" solution, but hopefully, others can contribute valuable views on that topic ☺. Ha det bra, Nik [1] https://build.opensuse.org/request/show/1103110?notification_id=42200225 [2] https://en.opensuse.org/openSUSE:Packaging_Go#Not_all_packages_will_be_acce… [3] https://build.opensuse.org/package/show/openSUSE:Factory/hugo

4 4

Heads up regarding future log spamming by memfd_create()
by Larry Finger 31 Aug '23

31 Aug '23

In kernel 6.3, memfd_create() was modified to issue a pr_warn_once() when called with neither MFD_EXEC nor MFD_NOEXEC_SEAL was set in the flags associated with the request. The warning was intended to get to user-space maintainers to fix their code. That attempt failed as the first such event happened during boot, and no one ever saw the warning. In kernel 6.6, the log statement has been changed to pr_info_ratelimited(), thus the event is logged regularly. Most of these will need to be fixed upstream, but I am announcing the ones I see on my system in case we will need to fix them in TW. My system has logged 1250 of these events in less than 17 hours of up time. The different user-space programs triggering this event on my system are as follows: akonadi_followu akonadi_indexin chrome IPDL Background kmozillahelper ksplashqml kwin_x11 plasmashell pulseaudio qemu-system-x86 Renderer (sd-executor) systemd TaskCon~ller #0 TaskCon~ller #1 TaskCon~ller #2 TaskCon~ller #3 thunderbird-bin Xorg.bin If you are the openSUSE maintainer of any of these, please push a fix. Thanks, Larry

2 2

openSUSE Tumbleweed download URL changed?
by Andrei Borzenkov 31 Aug '23

31 Aug '23

The https://build.opensuse.org/repositories/openSUSE:Tumbleweed shows downloadcontent.opensuse.org (instead of download.opensuse.org) which gives 403 for all links.

3 2

Re: Thunderbird 115
by Eric Schwarzenbach 31 Aug '23

31 Aug '23

On 8/31/23 08:32, Richard Biener wrote: > On Thu, 31 Aug 2023, Rainer Klier wrote: > >> hi, >> >> Am 31.08.23 um 14:05 schrieb Wolfgang Rosenauer: >>> I've submitted Thunderbird 115.2.0 today for inclusion in Tumbleweed. >>> >>> ... and I'm waiting for the first thread to complain about the changes ;-) >> do we have to somehow "convert" or upgrade all the settings, when we first >> start the new version? >> >> or is this done automatically on the fly? > On the fly didn't work for me (on Leap, from an even older Thunderbird > profile), I've successfully copied away the old profile and used > import profile from the new TB to "convert". > > "successfully" in the sense that it works, GPG stuff required quite > some fiddling. And my - the new UI sucks, maybe I'll get used to it. I seem to recall Thunderbird assuring us, when they touted the upcoming changes, that there would be setting to change any of them back to way they were in the old UI. Is that not the case?

2 1