June 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1222192] New: Package description for cadvisor shows trivy
by bugzilla_noreply＠suse.com 17 Mar '25

17 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222192 Bug ID: 1222192 Summary: Package description for cadvisor shows trivy Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: holdenrf2021(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Also shows on https://software.opensuse.org/package/cadvisor $ sudo zypper if trivy cadvisor [sudo] password for root: Loading repository data... Reading installed packages... Information for package trivy: ------------------------------ Repository : Main Repository (OSS) Name : trivy Version : 0.49.1-1.2 Arch : x86_64 Vendor : openSUSE Installed Size : 274.2 MiB Installed : No Status : not installed Source package : trivy-0.49.1-1.2.src Upstream URL : https://github.com/aquasecurity/trivy Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. Information for package cadvisor: --------------------------------- Repository : Main Repository (OSS) Name : cadvisor Version : 0.46.0-1.8 Arch : x86_64 Vendor : openSUSE Installed Size : 29.9 MiB Installed : No Status : not installed Source package : cadvisor-0.46.0-1.8.src Upstream URL : https://github.com/google/cadvisor Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1226207] New: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226207 Bug ID: 1226207 Summary: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: w01dnick(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- kf6-breeze-icons generate identical icons for both breeze & breeze-dark. While this is not an issue for KF6 apps, that use run-time recoloring, in KF5 apps, like Krusader, when dark color theme is used and icons are breeze-dark symbolic icons are dark on dark background and almost invisible. The reason is this build option: `-DWITH_ICON_GENERATION:BOOL=FALSE` I've tried to make my custom build [1] switching it to TRUE and breeze-dark icons are fine with Krusader now. But I don't know the reasoning behind switching it to FALSE. There is comment: ``` saves ~30MB and installs dangling symlinks ``` Less size is true, though IMHO it's not a good solution to break KF5 apps to save some space. But I can't see any dangling symlinks: ``` find /usr/share/icons/breeze{,-dark} -xtype l ``` doesn't find anything. Any other reason or should I cleanup [1] and make a submit request? [1] https://build.opensuse.org/package/show/home:NickLion:branches:KDE:Framewor… -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1215945] New: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed)
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1215945 Bug ID: 1215945 Summary: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Keywords: build Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: burnus(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: jengelh(a)inai.de Target Milestone: --- Found By: --- Blocker: --- GNU Binutils 2.41 now reveals a bug in the 'asm' code used in ffmpeg-4: ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' While Binutils is pending for opensuse:factory, the new version has already landed in 15.4 and 15.5 such that ffmpeg-4 fails there: https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 ffmpeg-5/6 seemingly got the fix as I do see no fails for 15.4/15.5 for the build of the 4h old package. Upstream FIX: "Fixes assembling with binutil as >= 2.41" at https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/effadce6c756247ea8bae32… See also https://trac.ffmpeg.org/ticket/10405 or (where I found it): The pending Binutils update for openSUSE:factory update is: https://build.opensuse.org/request/show/1113885 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1216537] New: xdg-utils perl requirement
by bugzilla_noreply＠suse.com 13 Mar '25

13 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1216537 Bug ID: 1216537 Summary: xdg-utils perl requirement Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: simonf.lees(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jslaby(a)suse.com Target Milestone: --- Found By: --- Blocker: --- xdg-utils requires perl via /usr/bin/xdg-screensaver. On minimal systems we'd like to avoid any extra script interpreters. Any chance to avoid using perl there? -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1222716] New: libssh tries to read config from wrong crypto-policies location
by bugzilla_noreply＠suse.com 13 Mar '25

13 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222716 Bug ID: 1222716 Summary: libssh tries to read config from wrong crypto-policies location Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: pmonrealgonzalez(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Target Milestone: --- Found By: --- Blocker: --- libssh-config ships /etc/libssh/libssh_server.config which contains # Parse system-wide crypto configuration file Include /usr/etc/crypto-policies/back-ends/libssh.config But there is no such file. It's supposed to be /etc/crypto-policies/back-ends/libssh.config Probably caused by the fix for bug 1211718. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1226116] New: nvidia-open-driver-G06 ... 550.90.07: Fails suspend/recover from powersaving
by bugzilla_noreply＠suse.com 13 Mar '25

13 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226116 Bug ID: 1226116 Summary: nvidia-open-driver-G06 ... 550.90.07: Fails suspend/recover from powersaving Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 3rd Party Driver Assignee: gfx-bugs(a)suse.de Reporter: burnus(a)gmx.de QA Contact: sndirsch(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Created attachment 875386 --> https://bugzilla.suse.com/attachment.cgi?id=875386&action=edit nvidia-bug-report.log.gz from nvidia-bug-report.sh --safe-mode [That's on a Lenovo P1 Gen 6 with "NVIDIA RTX A1000 6GB Laptop GPU".] When going to the suspend mode, it looks quite normal (screen gets dark, powerlight blinks.) However, when one presses a button: (1) it shows the terminal Window - not the Wayland desktop - with two unrelated warnings: i2c_hid_acpi i2c-ELAN0686:00: i2c_hid_get_input: incomplete report (31/65280) iwlwifi 0000:00:14.3: WRT: Invalid buffer destination (2) When going to Alt+F2, it shows a login screen but then nothing works (well, SysRq-{S,U,B} does work), but nothing on that screen nor Alt-Shift-F... When skipping (2): (3) When going to a terminal (e.g. Alt-F1), login is possible. Getting some diagnostic output: * nvidia-bug-report.sh stops early as an access to /proc/driver/nvidia/gpus/0000:01:00.0/information (I think it was that file) got stuck (lsof -p<pid> showed that file) – likewise, nvidia-smi did not output anything (both interruptible by 'ctrl-C'. * A reboot failed with some message by systemd related to nvidia-*.service; I thought it was nvidia-powerd.service, but looking at the logs, it could be also nvidia-suspend.service. In any case, it stated something that disabling (or enabling?) wasn't possible while the service was currently enabled (or disabled?). * "nvidia-bug-report.sh --safe-mode" this did work → see attached file. * * * dmesg showed many lines of the form: kernel: NVRM: kbusVerifyBar2_GM107: MMUTest BAR0 window offset 0x70e000 returned garbage 0x0 The attached .gz file from "nvidia-bug-report.sh --safe-mode" contains both dmesg and "journalctl -b -0" and has the line above 1,750,353 times. The "journalctl -b -0" output it contains (→ attachment) has: Jun 07 20:59:33 tux.net-b.de /usr/bin/nvidia-powerd[1477]: Dbus Connection is established Jun 07 21:29:48 tux.net-b.de suspend[3509]: nvidia-suspend.service Jun 07 21:29:48 tux.net-b.de logger[3509]: <13>Jun 7 21:29:48 suspend: nvidia-suspend.service Jun 07 21:29:48 tux.net-b.de kernel: NVRM: nvCheckFailedNoLog: Check failed: pMemDesc->_pInternalMapping != NULL @ mem_desc.c:2260 Jun 07 21:29:48 tux.net-b.de kernel: NVRM: nvAssertFailedNoLog: Assertion failed: 0 @ mem_utils.c:574 Jun 07 21:29:48 tux.net-b.de kernel: NVRM: nvAssertOkFailedNoLog: Assertion failed: Ran out of a critical resource, other than memory [NV_ERR_INSUFFICIENT_RESOURCES] (0x0000001A) returned from memmgrMemCopy(pMemoryManager, &sysSurface, &vidSurface, copySize, TRANSFER_FLAGS_PREFER_CE) @ fbsr_gm107.c:1156 * * * I think the issue occurred when doing the suspend and not when waking up the system, but I might be mistaken. - I thought wall time showed it, but I am not completely sure as I woke it up quite quickly; however, the quoted assertion fails directly after nvidia-suspend.service, which implies that it happens during the suspend. BTW: With the older 550.78 driver, leaving the laptop a while alone (→ power save mode) ended up with a reboot or shortly showing the terminal (similar output as above) before rebooting. Thus, the 550.78 issue was definitely a suspend/power-save issue. [The triggered reboot would be harder to diagnose than the issue I have now.] * * * Installed nvidia packages (rpm -qa '*nvidia*') - all are now 550.90.07-23.1: nvidia-open-driver-G06-signed-kmp-default-550.90.07_k6.9.3_1-1.1.x86_64 kernel-firmware-nvidia-20240519-1.1.noarch nvidia-compute-G06-32bit-550.90.07-23.1.x86_64 nvidia-gl-G06-550.90.07-23.1.x86_64 nvidia-video-G06-32bit-550.90.07-23.1.x86_64 nvidia-compute-utils-G06-550.90.07-23.1.x86_64 nvidia-video-G06-550.90.07-23.1.x86_64 nvidia-utils-G06-550.90.07-23.1.x86_64 libnvidia-egl-wayland1-1.1.13-1.3.x86_64 nvidia-compute-G06-550.90.07-23.1.x86_64 nvidia-gl-G06-32bit-550.90.07-23.1.x86_64 kernel-firmware-nvidia-gspx-G06-550.90.07-1.1.x86_64 * * * Side remarks: (a) Contrary to the classic drivers, the open kernel driver offers the pageableMemoryAccess property, which permits via Linux kernel HMM support to migrate memory pages to/from the device when a the page is accessed. That's used, e.g., by GCC 15 (mainline) with OpenMP offload support when Unified-Shared Memory (USM) has been requested. See https://gcc.gnu.org/onlinedocs/libgomp/nvptx.html / https://gcc.gnu.org/gcc-15/changes.html (b) The open kernels drivers permit showing the screen to both an external monitor and to the laptop screen, which didn't work with the default/classic driver. (c) The more recent classic/non-'open kernels' driver also tended to crash occasionally (either reboot [typically when doing 'zypper dup'; possibly due to some systemd interaction] - or a freeze with a kernel fail (blinking shift lock; not even SysRq worked), which is a known but unsolved issue for the 550 driver according to the Nvidia Linux forum. Thus, except for the issue reported in this bug, the open-kernels driver is better. :-) And the future (said to be the default with Nvidia's 555 driver). -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1222314] New: YaST doesn't set zypper locales during installation
by bugzilla_noreply＠suse.com 12 Mar '25

12 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222314 Bug ID: 1222314 Summary: YaST doesn't set zypper locales during installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Created attachment 874066 --> https://bugzilla.suse.com/attachment.cgi?id=874066&action=edit YaST installation logs I installed YaST with German locale. While the system has the locale configured as expected (e.g. /etc/locale.conf), zypper does not: ~> sudo zypper locales Code | Language | Requested -----+----------+---------- As a result, language specific packages are missing. -- You are receiving this mail because: You are on the CC list for the bug.

1 52

[Bug 1222496] New: ipv6 dies within a day (or faster) on leap 15.5
by bugzilla_noreply＠suse.com 10 Mar '25

10 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222496 Bug ID: 1222496 Summary: ipv6 dies within a day (or faster) on leap 15.5 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: abittner(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I just recently narrowed down or observed that on a rather new (fresh) leap system (15.5, all updated, default repos, very simple, single gigabit ethernet pcie interface (realtek, onboard, gigabyte GA-P55-UD3 mainboard) the system becomes rather sluggish and networking stuff (only ssh-ing into the machine, some very simple things) is very unresponsive. until i discovered that even simple things such as direkt ipv6 pings onto ipv6 addresses fail and all packets become lost or never get replied. ipv4 works normal. whole network is a simple LAN with a normal soho gateway/home-router (fritzbox, in germany, deutsche telekom fibre provider consumer grade). yast2 shows dhcp4 on the eth0, but i tried having both dhcp4 and dhcp6 enabled to acquire the machines ip settings / assignments. or via neighbor announcement or what this stuff is called for ip6. either way, after less than a day of uptime of this leap 15.5 machine, the ipv6 stack seems to become non-working. once the ipv6 layer is broken I have situations such as this: -------- ping 2001:4860:4860::8844 PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes ^C --- 2001:4860:4860::8844 ping statistics --- 323 packets transmitted, 0 received, 100% packet loss, time 329725ms ------------- /sbin/lspci | grep -i net 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) ------- i am not very fluent with systemd, so I used rcnetwork to reset the network stack or recycle it, and after this command, ipv6 works normal again as well. > sudo rcnetwork restart fixes the stuff. only to again fail after less than a day, I couldnt narrow this down to a more precise time span. maybe completely random. any ideas? thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

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

09 Mar '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 35

[Bug 1221183] New: Upgrade problems with clang-cpp
by bugzilla_noreply＠suse.com 09 Mar '25

09 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1221183 Bug ID: 1221183 Summary: Upgrade problems with clang-cpp Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs(a)suse.de Reporter: franz.sirl-obs(a)lauterbach.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Hi, during a "zypper --releasever=15.6 dup" upgrade from a fully up-to-date 15.5 installation I got the following messages: Checking for file conflicts: ...................................................................................................................................................................[error] Detected 4 file conflicts: File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from install of clang13-13.0.1-bp156.7.42.x86_64 (Main Repository) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang11-11.0.1-150300.3.6.1.x86_64 (@System) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang15-15.0.7-150500.4.4.1.x86_64 (@System) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang7-7.0.1-150100.3.22.2.x86_64 (@System) File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content. Continue? [yes/no] (no): yes Even though this is mostly harmless, it disturbs the upgrade experience and probably can be easily fixed by backporting the clang-cpp/update-alternatives change from clang17 to the other clang versions that are part of Leap. regards, Franz -- You are receiving this mail because: You are on the CC list for the bug.

1 11