October 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1230333] New: docker-buildx: move to be a subpackage of Docker
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230333 Bug ID: 1230333 Summary: docker-buildx: move to be a subpackage of Docker Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: asarai(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- docker-buildx is a component of Docker, it makes very little sense to maintain it as a separate package (especially since docker-stable will probably mean we need to maintain a docker-stable-buildx fork anyway). It's simplest to just maintain it as a subpackage. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1230331] New: docker: add Requires for docker-buildx
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230331 Bug ID: 1230331 Summary: docker: add Requires for docker-buildx Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: asarai(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The standard built-in "docker build" has been marked as deprecated since Docker 23.0[1]. It is not yet planned for deletion, but given that it will probably not receive any updates we should probably mark docker-buildx as Requires. [1]: https://docs.docker.com/engine/deprecated/#legacy-builder-fallback -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1229450] New: libbpf: failed to find '.BTF' ELF section in vmlinux
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1229450 Bug ID: 1229450 Summary: libbpf: failed to find '.BTF' ELF section in vmlinux Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876820 --> https://bugzilla.suse.com/attachment.cgi?id=876820&action=edit Devel:Kernel:master/kernel-source:kernel-vanilla/LEGACYX86/i586 build log The kernel builds result in random build failures while creating BTF. For example https://build.opensuse.org/package/live_build_log/Kernel:vanilla/kernel-sou…: > libbpf: failed to find '.BTF' ELF section in vmlinux > FAILED: load BTF from vmlinux: No data available > make[2]: *** [../scripts/Makefile.vmlinux:34: vmlinux] Error 255 > make[2]: *** Deleting file 'vmlinux' > make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-vanilla-6.11~rc3.338.gc3f2d783a459/linux-6.11-rc3-338-gc3f2d783a459/Makefile:1158: vmlinux] Error 2 > make: *** [../Makefile:224: __sub-make] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.olf5Nu (%build) arm seems to fail reliably. But for example in ibs://Devel:Kernel:master/kernel-source:kernel-vanilla/LEGACYX86/i586, it looks like it is sort of random. kernel-debug and kernel-vanilla fails for i586, but -default and -pae are built currently. See the job history for kernel-vanilla in there (the failed boot log is attached): > time package reason code build time worker > 2024-07-15 07:41:48 kernel-source:kernel-vanilla source change succeeded 47m 53s h01-ch5a:3 > 2024-07-15 23:56:48 kernel-source:kernel-vanilla source change succeeded 47m 57s h01-ch5b:5 > 2024-07-18 11:12:40 kernel-source:kernel-vanilla source change succeeded 48m 46s h01-ch5b:2 > 2024-07-26 20:01:29 kernel-source:kernel-vanilla source change succeeded 52m 40s h01-ch4b:2 > 2024-07-29 09:07:35 kernel-source:kernel-vanilla source change succeeded 52m 53s h01-ch4a:6 > 2024-08-03 11:38:55 kernel-source:kernel-vanilla source change failed 25m 16s h01-ch4b:8 > 2024-08-04 23:48:15 kernel-source:kernel-vanilla source change failed 25m 14s h01-ch4b:7 > 2024-08-06 16:37:35 kernel-source:kernel-vanilla source change succeeded 53m 25s h01-ch4b:4 > 2024-08-09 19:44:44 kernel-source:kernel-vanilla source change failed 26m 4s h01-ch5a:2 > 2024-08-11 22:48:56 kernel-source:kernel-vanilla source change failed 0m 38s h01-ch4b:6 > 2024-08-12 16:44:52 kernel-source:kernel-vanilla source change succeeded 54m 0s h01-ch5b:5 > 2024-08-15 21:49:11 kernel-source:kernel-vanilla source change failed 25m 25s h01-ch4b:1 > 2024-08-19 01:53:01 kernel-source:kernel-vanilla source change succeeded 50m 9s h01-ch4a:5 > 2024-08-19 11:33:50 kernel-source:kernel-vanilla source change succeeded 55m 9s h01-ch5b:1 > 2024-08-19 17:23:59 kernel-source:kernel-vanilla source change failed 25m 16s h01-ch5a:3 -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1222314] New: YaST doesn't set zypper locales during installation
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

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 51

[Bug 1212877] New: [RPi4] cannot wake up after suspend triggered
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1212877 Bug ID: 1212877 Summary: [RPi4] cannot wake up after suspend triggered Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: zluo(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 867900 --> https://bugzilla.suse.com/attachment.cgi?id=867900&action=edit yast2 logs ssh to my RPi 4 Model B, later I see following -- p200300ea3707b36b055205817bcf9853:~ # Broadcast message from root@localhost (Fri 2023-06-30 06:03:37 UTC): The system will suspend now! -- then I try to wake it up by hitting keyboard and click on mouse, nothing happened on screen. attache yast2logs. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1224150] New: [Build 20240511] boot_encrypt: grub does not ask for encryption key
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1224150 Bug ID: 1224150 Summary: [Build 20240511] boot_encrypt: grub does not ask for encryption key Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/4179275/modules/boot _encrypt/steps/2 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation Grub no longer asks for the decryption key. The snapshot contained a grub2 change: +- Fix gcc error with CFLAGS=-Og + * grub2-grubenv-in-btrfs-header.patch + Which sounds harmless there were also plymouth changes, but the failure seems too early for plymouth openQA test in scenario opensuse-Tumbleweed-NET-x86_64-lvm-encrypt-separate-boot@64bit fails in [boot_encrypt](https://openqa.opensuse.org/tests/4179275/modules/boot_encryp… ## Test suite description Same as lvm-full-encrypt, but with separate boot not encrypted partition. Maintainer: riafarov INSTALLONLY=1 UNENCRYPTED_BOOT=1 DESKTOP=gnome ENCRYPT=1 FULL_LVM_ENCRYPT=1 ## Reproducible Fails since (at least) Build [20240509](https://openqa.opensuse.org/tests/4172240) ## Expected result Last good: [20240508](https://openqa.opensuse.org/tests/4169788) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1212947] New: Disable fbdev userspace interfaces and programs
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1212947 Bug ID: 1212947 Summary: Disable fbdev userspace interfaces and programs 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: tzimmermann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- We want to remove fbdev from kernel and userspace as far as possible. Linux 6.6 will allow us to disable fbdev's userspace interfaces, most noteably /dev/fb*. Enable this feature in the TW kernel. Framebuffer support has been an endless source of bugs. Not giving userspace access to it's internals and framebuffer memory will close a possible entry point for all sorts of malware. Please note that the framebuffer console is implemented entirely within the kernel and will not be affected by this change. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1231048] New: systemd-experimental: error message about homed
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1231048 Bug ID: 1231048 Summary: systemd-experimental: error message about homed 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: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- If I install systemd-experimental I get the following error message: Failed to preset unit: Unit systemd-homed.service does not exist systemd-homed is not part of systemd-experimental. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1232244] New: AUDIT-0: xfce4-power-manager: New PolKit rules added
by bugzilla_noreply＠suse.com 16 Dec '24

16 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1232244 Bug ID: 1232244 Summary: AUDIT-0: xfce4-power-manager: New PolKit rules added Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: manfred.h(a)gmx.net QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 878186 --> https://bugzilla.suse.com/attachment.cgi?id=878186&action=edit Full build log xfce4-power-manager-4.19.3 has added polkit rules [ 43s] RPMLINT report: [ 43s] =============== [ 44s] xfce4-power-manager.x86_64: E: polkit-unauthorized-privilege (Badness: 10000) org.xfce.power.xfce4-pm-helper (auth_admin:auth_admin:yes) [ 44s] The package allows unprivileged users to carry out privileged operations [ 44s] without authentication. This could cause security problems if not done [ 44s] carefully. If the package is intended for inclusion in any SUSE product please [ 44s] open a bug report to request review of the package by the security team. [ 44s] Please refer to [ 44s] https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for [ 44s] more information. [ 44s] [ 44s] (none): E: badness 10000 exceeds threshold 1000, aborting. OBS repo: https://build.opensuse.org/package/show/home:manfred-h:X11:xfce:4.19/xfce4-… -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 15 Dec '24

15 Dec '24

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 32