July 2024 - openSUSE Factory - openSUSE Mailing Lists

Why has slowroll gone back to older kernel?
by Larry Len Rainey 02 Jul '24

02 Jul '24

1 0

dmesg new T column
by JA McInnes 02 Jul '24

02 Jul '24

A recent Tumbleweed update has brought a new column to dmesg..? T followed by a number like: [ T158] usb 5-2: new low-speed USB device number 9 using xhci_hcd What is this? -JohnM.

3 2

Re: drkonqi service
by Eric Schwarzenbach 02 Jul '24

02 Jul '24

It's not some random page, it's the KDE drkonqi github README. Of course this doesn't mean they can't wrong or misguided. If so, the output from these commands is certainly misleading: ❯ systemctl is-enableddrkonqi-coredump-processor@.service disabled   ~/stuff/work/code/wrycan/xms-8.0-branch ❯ sudo systemctl enabledrkonqi-coredump-processor@.service Created symlink /etc/systemd/system/systemd-coredump@.service.wants/drkonqi-coredump-processor@.service → /usr/lib/systemd/system/drkonqi-coredump-processor@.service. ❯ systemctl is-enableddrkonqi-coredump-processor@.service enabled ❯ sudo systemctl is-enableddrkonqi-coredump-processor@.service enabled On 7/2/24 11:33 AM, Andrei Borzenkov wrote: > On 02.07.2024 18:06, Eric Schwarzenbach wrote: >> Thanks, Andreas, that clears up that side confusion. >> >> The command suggested by https://github.com/KDE/drkonqi, >> >> |systemctl is-enabled drkonqi-coredump-processor@.service| >> >> does work, and shows it to be disable|d|, despite that page suggesting >> it should be enabled. >> > > You cannot enable template unit. Period. Whatever is written on some > random page in Internet. > > You can have DefaultInstance=xxx property in template unit which will > get enabled when you try to enable template itself. This property is > not present in drkonqi-coredump-processor@.service. > >> I could of course just enable it, > > You cannot. > >> but I'm trying to understand whether >> it being disabled is some intentional openSUSE decision that I might > > It is not. The drkonqi-coredump-processor@.service is even explicitly > enabled in presets shipped by openSUSE. It just cannot work with the > current unit definition. > >> want to go along with, especially in light of messages during my >> update and >> Lassi's journalctl that suggest either that it may have previously been >> enabled, or doesn't need to be enabled to be activated during a crash or >> some such. I hope someone can clear that up. >> >> Cheers, >> Eric >> >> >> On 7/2/24 4:07 AM, Andreas Schwab wrote: >>> On Jun 30 2024, Eric Schwarzenbach wrote: >>> >>>> Failed to stopdrkonqi-coredump-processor@.service: Unit name >>>> drkonqi-coredump-processor@.service is missing the instance name. >>> This is a limitation of the systemd-update-helper script, it cannot >>> cope >>> properly with parameterized units. >>> > > Well, as mentioned template@.service can provide default instance > which then can be implicitly enabled through "systemctl enable > template@.service". May be it was there is the past but got lost. I > have no idea what is expected as an instance here. > >>>> systemctl status drkonqi-coredump-processor.service >>>> >>>> gives >>>> >>>> Unit drkonqi-coredump-processor.service could not be found. >>>> >>>> nor do I find it with list-units. Web searches don't give me any sense >>>> that KDE has moved away from using it...has openSUSE for some reason? >>> See systemd.unit(5): >>> >>> Unit names can be parameterized by a single argument called >>> the >>> "instance name". The unit is then constructed based on a >>> "template file" >>> which serves as the definition of multiple services or >>> other units. A >>> template unit must have a single "@" at the end of the unit >>> name prefix >>> (right before the type suffix). The name of the full unit >>> is formed by >>> inserting the instance name between "@" and the unit type >>> suffix. In the >>> unit file itself, the instance parameter may be referred to >>> using "%i" >>> and other specifiers, see below. >>> >>

1 0

Mesa 3D packages are not available for openSUSE Leap from X11:XOrg repository
by Nikolai Nikolaevskii 02 Jul '24

02 Jul '24

Since 2024-06-17 (see boo#1226445 https://bugzilla.opensuse.org/show_bug.cgi?id=1226445) new Mesa 3D is not available for openSUSE Leap. That means newer GPUs (including iGPUs in new CPUs) cannot work with Leap. Previously it was possible to use new hardware with openSUSE Leap by getting Mesa 3D packages from X11:XOrg repo and new kernel from kernel:stable repo. Mesa 3D packages: https://software.opensuse.org/package/Mesa Will Mesa 3D packages be available from X11:XOrg repository for Leap?

2 1

Re: drkonqi service
by Eric Schwarzenbach 02 Jul '24

02 Jul '24

Thanks, Andreas, that clears up that side confusion. The command suggested by https://github.com/KDE/drkonqi, |systemctl is-enabled drkonqi-coredump-processor@.service| does work, and shows it to be disable|d|, despite that page suggesting it should be enabled. I could of course just enable it, but I'm trying to understand whether it being disabled is some intentional openSUSE decision that I might want to go along with, especially in light of messages during my update and Lassi's journalctl that suggest either that it may have previously been enabled, or doesn't need to be enabled to be activated during a crash or some such. I hope someone can clear that up. Cheers, Eric On 7/2/24 4:07 AM, Andreas Schwab wrote: > On Jun 30 2024, Eric Schwarzenbach wrote: > >> Failed to stopdrkonqi-coredump-processor@.service: Unit name >> drkonqi-coredump-processor@.service is missing the instance name. > This is a limitation of the systemd-update-helper script, it cannot cope > properly with parameterized units. > >> systemctl status drkonqi-coredump-processor.service >> >> gives >> >> Unit drkonqi-coredump-processor.service could not be found. >> >> nor do I find it with list-units. Web searches don't give me any sense >> that KDE has moved away from using it...has openSUSE for some reason? > See systemd.unit(5): > > Unit names can be parameterized by a single argument called the > "instance name". The unit is then constructed based on a "template file" > which serves as the definition of multiple services or other units. A > template unit must have a single "@" at the end of the unit name prefix > (right before the type suffix). The name of the full unit is formed by > inserting the instance name between "@" and the unit type suffix. In the > unit file itself, the instance parameter may be referred to using "%i" > and other specifiers, see below. >

2 1

RegreSSHion: Remote Code Execution Vulnerability In OpenSSH Server (CVE-2024-6387)
by Nikolai Nikolaevskii 02 Jul '24

02 Jul '24

https://www.suse.com/security/cve/CVE-2024-6387.html https://www.qualys.com/regresshion-cve-2024-6387/ The regreSSHion Bug An Unauthenticated Remote Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems. What is regreSShion? regreSSHion, CVE-2024-6387, is an unauthenticated remote code execution in OpenSSH’s server (sshd) that grants full root access. It affects the default configuration and does not require user interaction. It poses a significant exploit risk. https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regressh… The Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. CVE assigned to this vulnerability is CVE-2024-6387. https://nvd.nist.gov/vuln/detail/CVE-2024-6387 CVE-2024-6387 Detail Awaiting Analysis This vulnerability is currently awaiting analysis. Description A signal handler race condition was found in OpenSSH's server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6387 https://access.redhat.com/security/cve/cve-2024-6387 https://security-tracker.debian.org/tracker/CVE-2024-6387 https://www.kaspersky.com/blog/openssh-vulnerability-mitigation-cve-2024-63… https://vulcan.io/blog/cve-2024-6387-how-to-fix-regresshion-vulnerability/ https://www.phoronix.com/news/RegreSSHion-CVE-2024-6387 https://www.phoronix.com/forums/forum/software/general-linux-open-source/14…

2 1

New Tumbleweed snapshot 20240701 released!
by Dominique Leuenberger 02 Jul '24

02 Jul '24

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: boost-base boost-extra libjxl (0.10.2 -> 0.10.3) libjxl-gtk (0.10.2 -> 0.10.3) libvpl (2.10.1 -> 2.11.0) openSUSE-release (20240629 -> 20240701) rng-tools (6.16 -> 6.17) virt-manager xfce4-kbdleds-plugin (0.2.5 -> 0.3.0) === Details === ==== boost-base ==== Subpackages: boost-license1_85_0 libboost_filesystem1_85_0 libboost_filesystem1_85_0-x86-64-v3 libboost_iostreams1_85_0 libboost_iostreams1_85_0-x86-64-v3 libboost_locale1_85_0 libboost_locale1_85_0-x86-64-v3 libboost_program_options1_85_0 libboost_program_options1_85_0-x86-64-v3 libboost_thread1_85_0 libboost_thread1_85_0-x86-64-v3 - add patch boost-1.85.0-python-numpy-2.patch from upstream ==== boost-extra ==== Subpackages: libboost_python-py3-1_85_0 libboost_python-py3-1_85_0-x86-64-v3 - add patch boost-1.85.0-python-numpy-2.patch from upstream ==== libjxl ==== Version update (0.10.2 -> 0.10.3) Subpackages: libjxl0_10 libjxl0_10-x86-64-v3 - Update to release 0.10.3 * fix bug in huffman-rle-gradient (e1) specialized decode path ==== libjxl-gtk ==== Version update (0.10.2 -> 0.10.3) Subpackages: gdk-pixbuf-loader-jxl gimp-plugin-jxl - Update to release 0.10.3 * fix bug in huffman-rle-gradient (e1) specialized decode path ==== libvpl ==== Version update (2.10.1 -> 2.11.0) - Update to version 2.11.0 + Added: IntelÂ® VPL API 2.11 support + Removed: Command line tools. They have been moved to a separate repository (https://github.com/intel/libvpl-tools) - Drop samples sub-package as the tools have been removed upstream - Drop u_buildfix-i586.patch, no longer needed nor applies after removal of tools - Use ldconfig_scriptlets macro for post(un) handling. ==== openSUSE-release ==== Version update (20240629 -> 20240701) Subpackages: openSUSE-release-appliance-custom openSUSE-release-dvd - automatically generated by openSUSE-release-tools/pkglistgen ==== rng-tools ==== Version update (6.16 -> 6.17) - update to 6.17: * mix data fed to the kernel byte-wise from multiple sources * added option to attempt more persistent use of slow entropy sources * fix some missing m4 quotes * improved debug output to show FIPS failures more clearly * added a named pipe entropy source * adjusted linux poolsize * fixed some pkcs11 error messages * fixed ignorefail and random_step options ==== virt-manager ==== Subpackages: virt-install virt-manager-common - remove dependency on /usr/bin/python3 using %python3_fix_shebang macro, [bsc#1212476] ==== xfce4-kbdleds-plugin ==== Version update (0.2.5 -> 0.3.0) Subpackages: xfce4-kbdleds-plugin-lang - Update to version 0.3.0 * Ability to show/hide leds * Add missing x11 linker flags

1 0

Submitting Agama 9 and agama-installer-openSUSE to Factory
by Lubos Kocman 02 Jul '24

02 Jul '24

Hello openSUSE! I hope that you all share the excitement from the progress that the Agama/YaST team shared on osc2024! YaST blog has a nice summary of all new features https://yast.opensuse.org/blog/2024-06-28/agama-9. All osc2024 videos should be soon at https://www.youtube.com/playlist?list=PL_AMhvchzBadtOw4K3kWfWhidyhXPnW9P in case you need more context. I sat together with Max and YaST folks by the table at the openSUSE Conference and we were able to get a bootable Leap 16.0 image deployed by Agama 9. Many thanks to the team for their support in incorporating our submissions at https://github.com/openSUSE/agama. Here's the Leap 16 Image, just please don't try to install Leap16/GNOME yet. I hope to get that working by end of the week :) https://download.opensuse.org/repositories/openSUSE:/Leap:/16.0:/Images/ima… With that said, I believe this is the right time to get all bits to Factory so early adopters can get their hands on it. See my Leap 16 feature tracker for a list of initial Agama submissions to Factory https://code.opensuse.org/leap/features/issue/158 agama-installer-openSUSE (the actual deliverable) is a live image that can, at the moment, install a variety of openSUSE distributions, namely MicroOS, *Leap 16, and Tumbleweed. You can find specific distro configs in agama-products-opensuse. After initial feedback from Leap Micro 6.0 GA, I'd also like to consider adding support for Leap Micro 6.X to satisfy a few individuals for who the self-install simply doesn't cut it. Please consider the agama-install-openSUSE as an alternative for early adopters who like to play with new tech. We still have some homework to do as this is currently online installer-only. Yes, you can use Packages DVD with Agama, but that might be too large for some. Being fully transparent here, the long-term plan would be to adopt Agama by default in Tumbleweed, Leap 16 / SLES 16, and Leap Micro 6.X. I can imagine that if everything goes well the transition could happen with Leap 16 GA somewhen in 2nd half of 2025 https://en.opensuse.org/openSUSE:Roadmap#DRAFT_Schedule_for_openSUSE_Leap_1… Many thanks to the Agama/YaST team for all of their hard work! The project is nowhere close where it was last year. Lubos on behalf of openSUSE release team

1 0

drkonqi service
by Eric Schwarzenbach 02 Jul '24

02 Jul '24

Is it expected that the drkonqi service should have been removed by a recent Tumbleweed update? I just zypper dupped for the first time since before Plasma 6.1 dropped, and saw a message about Failed to stop drkonqi-coredump-processor@.service: Unit name drkonqi-coredump-processor@.service is missing the instance name. systemctl status drkonqi-coredump-processor.service gives Unit drkonqi-coredump-processor.service could not be found. nor do I find it with list-units. Web searches don't give me any sense that KDE has moved away from using it...has openSUSE for some reason? The package drkonqi6 is definitely installed on my system. Thanks, Eric

3 2

Re: drkonqi service
by Eric Schwarzenbach 01 Jul '24

01 Jul '24

I get the same as you when I use list-unit-files. Apparently list-units only shows "active" units...perhaps drkonqi-coredump-processor only becomes active when invoked by systemd-coredump. I'm afraid I'm running into complexities of how systemd works that I'm not familiar with. The page https://github.com/KDE/drkonqi indicates that drkonqi-coredump-processor@.service should be enabled. It seems to be disabled on both our systems. It seems reasonable to me that a timeout might stop the service, but not disable it. It's unclear to me what your journalctl messages mean...the show a different service name ("...-pickup", which is not listed according to your list-unit-files / grep command). Is drkonqi-coredump-processor@.serviced intentionally disabled in Tumbleweed by default? Should it be? On 7/1/24 11:35 AM, Lassi Väätämöinen wrote: > On sunnuntaina 30. kesäkuuta 2024 19.30.25 UTC+3 Eric Schwarzenbach wrote: >> nor do I find it with list-units. Web searches don't give me any sense >> that KDE has moved away from using it...has openSUSE for some reason? >> >> The package drkonqi6 is definitely installed on my system. > YEsterday it provided me with crash reports. I had some issues starting Plasma > 6.1.1. now. But for me, DrKonqi is listed, but disable now. Maybe there was a > timeout or some such: > >> sudo systemctl list-unit-files |grep core > drkonqi-coredump-processor@.service disabled enabled > systemd-coredump@.service static - > systemd-coredump.socket static - > > > Journalctl seems to agree with my guess: > > 18:08:04 kaappi systemd[7925]: drkonqi-coredump-pickup.service: Service > reached runtime time limit. Stopping. > 18:08:04 kaappi systemd[7925]: drkonqi-coredump-pickup.service: Failed with > result 'timeout'. > >

1 0