August 2023 - openSUSE Factory - openSUSE Mailing Lists

Leap not more useful for WebServer with php
by Walddys Emmanuel Dorrejo Céspedes 09 Oct '23

09 Oct '23

Leap is stuck with PHP 8.0 version, when most devs and project have move to php8.1/8.2, i was hoping that php8.1 at least this version reach leap 15.5, but didn't reached the main repo. sad.

6 6

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 … [View More]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 [View Less]

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&… [View More]

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 … [View More]

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 … [View More]

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. … [View More]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 [View Less]

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 … [View More]

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