May 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1222044] New: zypper %posttrans fails with "Failed to start jobs"
by bugzilla_noreply＠suse.com 24 Apr '25

24 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1222044 Bug ID: 1222044 Summary: zypper %posttrans fails with "Failed to start jobs" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 873853 --> https://bugzilla.suse.com/attachment.cgi?id=873853&action=edit zypper.log Upgrading from TW Snapshot 20240321 to 20240325 with zypper -v dup had the following output at the end: Ausgabe des Skripts %posttrans(zypper-1.14.70-1.1.x86_64): Failed to start jobs: Failed to enqueue some jobs, see logs for details: No such file or directory Nach-Transaktions-Skripte werden ausgeführt ..............................................................................................................................................................................................[fertig] CommitResult (total 432, done 432, error 0, skipped 0, updateMessages 0) -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1215657] New: VUL-0: CVE-2023-42811: rage-encryption: aes-gcm: chosen ciphertext attack via `decrypt_in_place*` APIs
by bugzilla_noreply＠suse.com 24 Apr '25

24 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1215657 Bug ID: 1215657 Summary: VUL-0: CVE-2023-42811: rage-encryption: aes-gcm: chosen ciphertext attack via `decrypt_in_place*` APIs Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://smash.suse.de/issue/379692/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: william.brown(a)suse.com Reporter: carlos.lopez(a)suse.com QA Contact: security-team(a)suse.de CC: cunix(a)mail.de, security-team(a)suse.de Depends on: 1215654 Target Milestone: --- Found By: Security Response Team Blocker: --- +++ This bug was initially created as a clone of Bug #1215654 +++ CVE-2023-42811 aes-gcm is a pure Rust implementation of the AES-GCM. Starting in version 0.10.0 and prior to version 0.10.3, in the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. If a program using the `aes-gcm` crate's `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery. Version 0.10.3 contains a fix for this issue. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42811 https://www.cve.org/CVERecord?id=CVE-2023-42811 https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309 https://github.com/RustCrypto/AEADs/security/advisories/GHSA-423w-p2w9-r7vq -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1224103] New: Hybrid sleep wakes up on bluetooth device (normal sleep does not)
by bugzilla_noreply＠suse.com 18 Apr '25

18 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1224103 Bug ID: 1224103 Summary: Hybrid sleep wakes up on bluetooth device (normal sleep does not) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: katonag(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- If I send my laptop to hybrid sleep it wakes up when I power on my bluetooth headset. Using simple sleep works as expected. This is only happening since a few weeks. I have also added a rule to udev: ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="8087", ATTR{power/wakeup}="disabled" because my bluetooth adapter shows up in lsusb, but there is no change. The system is Tumbleweed 20240503 with KDE6. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1223674] New: tensorflow-lite fails to build with GCC 13, keeps gcc12 from being removed
by bugzilla_noreply＠suse.com 18 Apr '25

18 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1223674 Bug ID: 1223674 Summary: tensorflow-lite fails to build with GCC 13, keeps gcc12 from being removed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: rguenther(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When building tensorflow-lite with GCC 13 (the default compiler), there's a spurious -Wstringop-overflow diagnostic promoted to an error becuause we build the package with -Werror. Adding -Wno-error=stringop-overflow causes other issues to appear: [ 51s] In file included from /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.cc:16: [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:34:6: warning: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword [ 51s] 34 | enum class FormatConversionChar : uint8_t; [ 51s] | ~~~~ ^~~~~ [ 51s] | ----- [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:34:33: error: found ‘:’ in nested-name-specifier, expected ‘::’ [ 51s] 34 | enum class FormatConversionChar : uint8_t; [ 51s] | ^ [ 51s] | :: ... [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:173:8: warning: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword [ 51s] 173 | enum class Enum : uint8_t { [ 51s] | ~~~~ ^~~~~ [ 51s] | ----- and more Likely fixed in newer upstream versions of tensorflow. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1224386] New: Please package systemd-resolved seperate from systemd-network
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1224386 Bug ID: 1224386 Summary: Please package systemd-resolved seperate from systemd-network Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: systemd-maintainers(a)suse.de Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I get why resolved is packaged with networkd but there's also use cases where resolved would be very , very useful, even with NetworkManager eg. I want it for openSUSE Aeon, with GNOME, with NetworkManager, but using resovled for more intelligent DNS resolution as people hop networks/VPNs. Could we please package -resolved as it's own seperate thing and have it required by -networkd, as I really wouldn't like to have -networkd installed if I can avoid it. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1220905] New: salt-master: Error loading known_hosts
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1220905 Bug ID: 1220905 Summary: salt-master: Error loading known_hosts Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Python Assignee: python-maintainers(a)suse.com Reporter: egotthold(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- This error is happening to me on openSUSE MicroOS 20240302 (the logs reveal this has been happening for a good while already). The error is known upstream and is due to a combination of changes in pygit2 and how Salt is starting up its daemon. https://github.com/saltstack/salt/issues/64121#issuecomment-1705658539 Since we are not using the onedir packaging yet one cannot downgrade to another pygit2 version via salt-pip. I am not that deep into the codebase to know if a systemd drop-in that specifies the user used for running the salt-master.service as "salt", is enough. The log of the salt-master is spammed with the following message: Mar 04 00:01:51 esprimo-1 salt-master[30997]: [ERROR ] Error occurred fetching git_pillar remote 'main git(a)gitlab.com:<user>/<repo>.git': error loading known_hosts: Mar 04 00:01:51 esprimo-1 salt-master[30997]: Traceback (most recent call last): Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib/python3.11/site-packages/salt/utils/gitfs.py", line 1996, in _fetch Mar 04 00:01:51 esprimo-1 salt-master[30997]: fetch_results = origin.fetch(**fetch_kwargs) Mar 04 00:01:51 esprimo-1 salt-master[30997]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/remotes.py", line 155, in fetch Mar 04 00:01:51 esprimo-1 salt-master[30997]: payload.check_error(err) Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/callbacks.py", line 99, in check_error Mar 04 00:01:51 esprimo-1 salt-master[30997]: check_error(error_code) Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/errors.py", line 65, in check_error Mar 04 00:01:51 esprimo-1 salt-master[30997]: raise GitError(message) Mar 04 00:01:51 esprimo-1 salt-master[30997]: _pygit2.GitError: error loading known_hosts: -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1217885] New: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user"
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1217885 Bug ID: 1217885 Summary: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: dracut-maintainers(a)suse.de Reporter: antonio.feijoo(a)suse.com QA Contact: qa-bugs(a)suse.de CC: nfbrown(a)suse.com Target Milestone: --- Found By: --- Blocker: --- CC: nfbrown(a)suse.com Flags: needinfo?(nfbrown(a)suse.com) Created attachment 871199 --> https://bugzilla.suse.com/attachment.cgi?id=871199&action=edit dracut patch While testing the dracut nfs module in Tumbleweed, I found this warning in the journal: > Dec 07 14:07:30 localhost systemd[1]: Starting dracut pre-udev hook... > Dec 07 14:07:30 localhost kernel: RPC: Registered named UNIX socket transport m> > Dec 07 14:07:30 localhost kernel: RPC: Registered udp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp-with-tls transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp NFSv4.1 backchannel trans> > Dec 07 14:07:30 localhost rpc.statd[363]: Version 2.6.3 starting > Dec 07 14:07:30 localhost rpc.statd[363]: Initializing NSM state > ---> Dec 07 14:07:30 localhost rpc.statd[363]: Running as root. chown /var/lib/nfs to choose different user > Dec 07 14:07:30 localhost rpc.idmapd[477]: Setting log level to 0 > Dec 07 14:07:30 localhost rpc.idmapd[477]: libnfsidmap: requested translation method, 'nsswitch', is not available > Dec 07 14:07:30 localhost systemd[1]: Finished dracut pre-udev hook. I never saw this in SLE, but then I noticed that nfs-utils adds the statd user via sysusers.d configuration since version 2.5.1: > $ rpm -qf /usr/lib/sysusers.d/statd-user.conf > nfs-client-2.6.3-41.1.x86_64 > $ cat /usr/lib/sysusers.d/statd-user.conf > # Type Name ID GECOS [HOME] Shell > u statd - "NFS statd daemon" /var/lib/nfs - Also, the nfs-utils.spec file defines: > # lib/nfs must be root-owned. > # sm and sm.back and contents should be statd:statd, > # but only chown if the dirs are currently root-owned. > # This is needed for some upgraded, but chown is best avoided > # when not necessary > ... > %{_sysusersdir}/statd-user.conf > %dir %{_localstatedir}/lib/nfs > %dir %{_localstatedir}/lib/nfs/rpc_pipefs > %dir %{_localstatedir}/lib/nfs/v4recovery > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm.bak > %ghost %{_localstatedir}/lib/nfs/state Neil, I can't find this in nfs-utils upstream, is this SUSE-specific? how bad is this warning? should we add a custom patch (maybe similar to the one attached) to the dracut nfs module to avoid it? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1225296 Bug ID: 1225296 Summary: Dual monitor not recognised after upgrade 15.5 to 15.6 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: martin.schmidt(a)io-warnemuende.de QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Moin, moin, I am using openSUSE 15.5 on an old intel based x86 PC, equipped with a simple nvidia gforce and two monitors. The monitors are using a displayport connnection from the graphics card to the monitors via an Y-shaped cable. Both monitors are recognised correctly and can be configured to form a single graphical work space, when the system is up and running. After upgrading to openSUSE 15.6 this does not work any more. When booting, monitor 1 shows some firmware screen and the openSUSE boot screen, where the OS version (several subversions of 15.6 and frozen snapshots of 15.5) can be selected. Using the default option (15.6 from harddrive), the output of the boot process is moving to monitor 2, but monitor 1 is going to a "power saving sleep mode" and stays inactive frome here on. The boot process is finished correctly with monitor 2 as the only graphical device. Monitor 1 cannot be activated again. Switching off monitor 2 before booting, the system comes up without any valid output device. Monitor 1 goes to sleep after the system boot started. I did not check the system status with a remote ssh-connection yet. Switching off monitor 1 before booting, lets the system come up completely with monitor 2. Also the initial hardware screen is diplayerd there. In turn, booting from a read-only snapshot with openSUSE 15.5, both monitors are used as before. The nouveau-dri drivers are used, no propriatary nvidia driver is installed. Some upgrade history: - just to test, if the few graphic card cores could be used in a cuda environment, cuda was installed under 15.5. This failed and cuda was deinstalled. However, when upgrading later from 15.5 to 15.6 the cuda development environment was reinstalled automatically together with nvidia drivers. As a result the nvidia drivers allowed only for a single low resolution vga monitor. May be, this happened, since the nvidia repository was not deleted and there was some leftover from the cuda test. - with the ascii-yast the nvidia drivers (gforce003/004) and cuda could be removed and the nouveau-dri drivers where reinstalled - together with dependencies. This allows for a single monitor OS_15.6 system with high resolution, but the second monitor (monitor 1) is lost during the boot process as described above. Before I try to install from scratch just with the hope that the error goes away, I am reporting this strange behaviour here. May be, this helps to streamline the distribution. Any hints are very welcome - especially how to modify the bootloader options. Cheers, Martin Schmidt -- You are receiving this mail because: You are on the CC list for the bug.

1 36

[Bug 1216966] New: cmake 3.27.7 needed to properly support zlib 1.3
by bugzilla_noreply＠suse.com 12 Apr '25

12 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1216966 Bug ID: 1216966 Summary: cmake 3.27.7 needed to properly support zlib 1.3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: simonf.lees(a)suse.com Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- 3.27.2 which is currently in TW causes: ``` [ 5s] -- Found ZLIB: /usr/lib64/libz.so (found version "1.3.#define ZLIB_VERSION "1.3"") ``` when test building with the 3.27.7 from the devel project. the zlib handling works properly again. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1219183] New: Error in kmp build logfile
by bugzilla_noreply＠suse.com 08 Apr '25

08 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1219183 Bug ID: 1219183 Summary: Error in kmp build logfile Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: noreply.section+dev(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When building kernel modules on OBS the following error shows up in the logs: /usr/lib/rpm/find-requires.ksyms: line 84: /usr/lib/rpm/symset-table: No such file or directory I think this started happening after the recent update to rpm-config-SUSE-20240118 Nevertheless, compilations are successful and modules don't seem to be negatively affected. As an example https://build.opensuse.org/build/openSUSE:Factory/standard/x86_64/vhba-kmp/… but I think it happens for any kmp. -- You are receiving this mail because: You are on the CC list for the bug.

1 2