May 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1218120] New: jetty-artifact-remote-resources: reproducible builds issue
by bugzilla_noreply＠suse.com 06 Mar '25

06 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1218120 Bug ID: 1218120 Summary: jetty-artifact-remote-resources: reproducible builds issue Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: fstrba(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: Development Blocker: --- While working on reproducible builds for openSUSE, I found that our jetty-artifact-remote-resources varies from filesystem-readdir-order. It probably needs an extra sort somewhere. example diff is --- old//usr/share/java/jetty-artifact-remote-resources/jetty-artifact-remote-resources.jar/META-INF/maven/remote-resources.xml +++ new//usr/share/java/jetty-artifact-remote-resources/jetty-artifact-remote-resources.jar/META-INF/maven/remote-resources.xml @@ -3,9 +3,9 @@ xmlns="http://maven.apache.org/remote-resources/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <remoteResources> - <remoteResource>about.html</remoteResource> - <remoteResource>META-INF/LICENSE</remoteResource> <remoteResource>META-INF/NOTICE.txt</remoteResource> + <remoteResource>META-INF/LICENSE</remoteResource> + <remoteResource>about.html</remoteResource> </remoteResources> <sourceEncoding>UTF-8</sourceEncoding> </remoteResourcesBundle> jetty-distribution-remote-resources is also affected. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1219137] New: qemu user space builds broken with kernel 6.7
by bugzilla_noreply＠suse.com 03 Mar '25

03 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1219137 Bug ID: 1219137 Summary: qemu user space builds broken with kernel 6.7 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: schwab(a)suse.de QA Contact: qa-bugs(a)suse.de CC: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Since commit 1c5976ef0f7a the kernel deregisters all binfmt_misc handler when the binfmt_misc filesystem is unmounted. The build script has this: # RPM specific post checks are in /usr/lib/build/checks if test -n "$RPMS" -a -d "$BUILD_ROOT/usr/lib/build/checks" ; then # workaround for broken 13.1 check scripts which umount /proc if test -n "$RUNNING_IN_VM" -a "$BUILD_ROOT" = / ; then umount -n $BUILD_ROOT/proc/sys/fs/binfmt_misc 2>/dev/null fi This means that after this point the emulation no longer works. [ 272s] ... checking for files with abuild user/group [ 272s] /.build/build: line 1922: /bin/env: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error [ 272s] /.build/build: line 1926: /bin/rpm: cannot execute binary file: Exec format error According to the commit, this should be reported as a regression so that this behaviour is reverted for the initial binfmt_misc mount. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1212954] New: amdgpu: Monitor displaying wrong resolution
by bugzilla_noreply＠suse.com 03 Mar '25

03 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1212954 Bug ID: 1212954 Summary: amdgpu: Monitor displaying wrong resolution Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: holgi(a)suse.com QA Contact: gfx-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 867944 --> https://bugzilla.suse.com/attachment.cgi?id=867944&action=edit IMG_20230703_164538751_HDR.jpg Having a 4K monitor (SAMSUNG LU28R55) attached to the docking station of my ThinkPad via HDMI I can easily 1:1 mirror the screen output of the laptop and the monitor with openSUSE Leap 15.4. Doing the same with openSUSE Leap 15.5 will result in monitor displaying a resolution 1980x2160 instead of the set 1980x1080. Using a 4x different screen (Philips) is working fine. Photo of monitor attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 30

[Bug 1224995] New: Native Firefox package on Plasma Wayland runs the KDE File Picker under XWayland, not respecting HDPI scaling
by bugzilla_noreply＠suse.com 03 Mar '25

03 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1224995 Bug ID: 1224995 Summary: Native Firefox package on Plasma Wayland runs the KDE File Picker under XWayland, not respecting HDPI scaling Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: radicalite(a)proton.me QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 875025 --> https://bugzilla.suse.com/attachment.cgi?id=875025&action=edit Filepicker comparsion between Native Firefox on TW and Flatpak Firefox When using the file picker from the native Firefox package, the file picker runs in XWayland, this isn't noticeable on non HiDPI displays unless there's a HiDPI display connected, or are simply using a HiDPI screen as the only screen, then this becomes instantly noticeable. This behaviour isn't consistent with applications from the rest of the system (moving aside VLC, but the app itself runs entirely under XWayland by default...), as they run the file picker under Wayland, following the correct scaling setting. the Firefox flatpak also runs the file picker under Wayland correctly (via Portal). This behaviour also doesn't happen with the native Firefox package on TWGNOME, running the GTK file picker under Wayland with respect to scaling, so I assume this happens from the OpenSUSE KDE patches added to Firefox? Install is a fresh TWKDE install. Comparison in image Operating System: openSUSE Tumbleweed 20240520 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.9.1-1-default (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-6267U CPU @ 2.90GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® Iris® Graphics 550 Manufacturer: Apple Inc. Product Name: MacBookPro13,2 System Version: 1.0 Display config is 2560x1600@175%@60hz (Built-in Screen) set to left 1920x1080@100%@120hz (Acer Technologies VG242Y) set to right, set as primary display. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1214189] New: vdpauinfo segfaults and coredumps
by bugzilla_noreply＠suse.com 02 Mar '25

02 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1214189 Bug ID: 1214189 Summary: vdpauinfo segfaults and coredumps Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: carlos.e.r(a)opensuse.org QA Contact: gfx-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868762 --> https://bugzilla.suse.com/attachment.cgi?id=868762&action=edit tar file with the strace files Derives from Bug 1210427 Machine is a Lenovo Laptop, Lenovo L14 Gen3 that I bought this year. Laicolasse:~/tmp/2 # strace --output=vdpauinfo.strace --follow-forks --output-separately vdpauinfo display: :0.0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types ------------------------------------------- 420 16384 16384 NV12 YV12 422 16384 16384 UYVY YUYV 444 16384 16384 Y8U8V8A8 V8U8Y8A8 Decoder capabilities: name level macbs width height ---------------------------------------------------- MPEG1 --- not supported --- MPEG2_SIMPLE 3 65536 4096 4096 MPEG2_MAIN 3 65536 4096 4096 H264_BASELINE --- not supported --- H264_MAIN --- not supported --- H264_HIGH --- not supported --- VC1_SIMPLE --- not supported --- VC1_MAIN --- not supported --- VC1_ADVANCED --- not supported --- MPEG4_PART2_SP 3 65536 4096 4096 MPEG4_PART2_ASP 5 65536 4096 4096 DIVX4_QMOBILE --- not supported --- DIVX4_MOBILE --- not supported --- DIVX4_HOME_THEATER --- not supported --- DIVX4_HD_1080P --- not supported --- DIVX5_QMOBILE --- not supported --- DIVX5_MOBILE --- not supported --- DIVX5_HOME_THEATER --- not supported --- DIVX5_HD_1080P --- not supported --- H264_CONSTRAINED_BASELINE --- not supported --- H264_EXTENDED --- not supported --- H264_PROGRESSIVE_HIGH --- not supported --- H264_CONSTRAINED_HIGH --- not supported --- H264_HIGH_444_PREDICTIVE --- not supported --- HEVC_MAIN --- not supported --- HEVC_MAIN_10 --- not supported --- HEVC_MAIN_STILL --- not supported --- HEVC_MAIN_12 --- not supported --- HEVC_MAIN_444 --- not supported --- Output surface: name width height nat types ---------------------------------------------------- B8G8R8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 I8A8 R8G8B8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 I8A8 R10G10B10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 I8A8 B10G10R10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 I8A8 Bitmap surface: name width height ------------------------------ B8G8R8A8 16384 16384 R8G8B8A8 16384 16384 R10G10B10A2 16384 16384 B10G10R10A2 16384 16384 A8 16384 16384 Video mixer: feature name sup ------------------------------------ DEINTERLACE_TEMPORAL y DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESS y LUMA_KEY y HIGH QUALITY SCALING - L1 y HIGH QUALITY SCALING - L2 - HIGH QUALITY SCALING - L3 - HIGH QUALITY SCALING - L4 - HIGH QUALITY SCALING - L5 - HIGH QUALITY SCALING - L6 - HIGH QUALITY SCALING - L7 - HIGH QUALITY SCALING - L8 - HIGH QUALITY SCALING - L9 - parameter name sup min max ----------------------------------------------------- VIDEO_SURFACE_WIDTH y 48 4096 VIDEO_SURFACE_HEIGHT y 48 4096 CHROMA_TYPE y LAYERS y 0 4 attribute name sup min max ----------------------------------------------------- BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVEL y 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMA y LUMA_KEY_MAX_LUMA y Segmentation fault (core dumped) Laicolasse:~/tmp/2 # ls vdpauinfo.strace.6031 vdpauinfo.strace.6035 vdpauinfo.strace.6039 vdpauinfo.strace.6043 vdpauinfo.strace.6032 vdpauinfo.strace.6036 vdpauinfo.strace.6040 vdpauinfo.strace.6044 vdpauinfo.strace.6033 vdpauinfo.strace.6037 vdpauinfo.strace.6041 vdpauinfo.strace.6045 vdpauinfo.strace.6034 vdpauinfo.strace.6038 vdpauinfo.strace.6042 Laicolasse:~/tmp/2 # I will attach the trace files in a tar. Laicolasse:~ # coredumpctl TIME PID UID GID SIG COREFILE EXE SIZE Fri 2023-08-11 12:48:59 CEST 6031 0 0 SIGSEGV present /usr/bin/vdpauinfo 2.0M Fri 2023-08-11 12:48:59 CEST 6028 0 0 SIGSEGV none /usr/bin/strace n/a Laicolasse:~ # So relevant file should be vdpauinfo.strace.6031 Laicolasse:~ # inxi -SGaz System: Kernel: 5.14.21-150500.55.12-default arch: x86_64 bits: 64 compiler: gcc v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.12-default root=UUID=858cc569-e2ae-4d12-adf6-3a06ade8281c security=apparmor no_console_suspend splash=silent resume=/dev/disk/by-label/Swap preempt=full quiet mitigations=auto Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.34 info: xfce4-panel wm: xfwm v: 4.18.0 dm: 1: GDM v: 41.3 2: SDDM note: stopped Distro: openSUSE Leap 15.5 Graphics: Device-1: AMD Barcelo vendor: Lenovo driver: amdgpu v: kernel arch: RDNA-2 code: Navi-2x process: TSMC n7 (7nm) built: 2020-22 pcie: gen: 3 speed: 8 GT/s lanes: 16 link-max: gen: 4 speed: 16 GT/s ports: active: eDP-1 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 07:00.0 chip-ID: 1002:15e7 class-ID: 0300 temp: 46.0 C Device-2: Luxvisions Innotech Integrated RGB Camera type: USB driver: uvcvideo bus-ID: 3-3.2:4 chip-ID: 30c9:0050 class-ID: fe01 serial: <filter> Display: server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 compositor: xfwm v: 4.18.0 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93") Monitor-1: eDP-1 mapped: eDP model: AU Optronics 0x639c built: 2021 res: 1920x1080 hz: 60 dpi: 158 gamma: 1.2 size: 309x174mm (12.17x6.85") diag: 355mm (14") ratio: 16:9 modes: max: 1920x1080 min: 640x480 API: OpenGL v: 4.6 Mesa 22.3.5 renderer: AMD Radeon Graphics (renoir LLVM 15.0.7 DRM 3.49 5.14.21-150500.55.12-default) direct render: Yes Laicolasse:~ # -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1222534] New: No wired network after hibernation
by bugzilla_noreply＠suse.com 26 Feb '25

26 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1222534 Bug ID: 1222534 Summary: No wired network after hibernation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: jonzn4suse(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Operating System: openSUSE Tumbleweed 20240405 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.4-rc1-1-default (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5825U with Radeon Graphics Memory: 62.1 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: HP Product Name: HP ProBook 455 15.6 inch G9 Notebook PC System Version: SBKPF I can turn on WiFi and it works, but to fix the wired issue, I have to reboot. The below logs keeps repeating until a reboot. LOGS: Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.4741] device (enp1s0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <warn> [1712657390.4744] device (enp1s0): Activation: failed for connection 'Wired Connection' Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.4744] device (enp1s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): canceled DHCP transaction Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): activation: beginning transaction (timeout in 45 seconds) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): state changed no lease Tuesday, April 9, 2024 6:09:50 AM EDT kernel r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon Files changed, reloading. Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon No service file found in /etc/avahi/services. Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5760] policy: auto-activating connection 'Wired Connection' (21000dbf-984d-4441-91e7-1f4c01a5b834) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5763] device (enp1s0): Activation: starting connection 'Wired Connection' (21000dbf-984d-4441-91e7-1f4c01a5b834) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5764] device (enp1s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5766] device (enp1s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT kernel r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5937] device (enp1s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5939] dhcp4 (enp1s0): activation: beginning transaction (timeout in 45 seconds) Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon Files changed, reloading. Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon No service file found in /etc/avahi/services. I will also test sleep to see if it has the same issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1219733] New: qemu ipxe roms will stop compiling with binutils update
by bugzilla_noreply＠suse.com 24 Feb '25

24 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1219733 Bug ID: 1219733 Summary: qemu ipxe roms will stop compiling with binutils update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Tools Assignee: virt-bugs(a)suse.de Reporter: matz(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- We're preparing a binutils update to version 2.42 in openSUSE:Factory:Staging:A ( https://build.opensuse.org/request/show/1144349 ), and qemu-ipxe assembly sources hit a problem there: [ 3712s] gcc -E -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce -fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 -mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone -fstack-protector-strong -mstack-protector-guard=global -Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g -ffreestanding -fcommon -Wall -W -Wformat-nonliteral -fno-dwarf2-cfi-asm -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation -Wno-address-of-packed-member -Wno-array-bounds -Wno-dangling-pointer -Werror -ffunction-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DCONFIG=qemu -DLOCAL_CONFIG=qemu -DASSEMBLY -DOBJECT=stack arch/x86/core/stack.S | as --64 --divide --fatal-warnings -o bin-x86_64-efi/stack.o [ 3712s] arch/x86/core/stack.S: Assembler messages: [ 3712s] arch/x86/core/stack.S:3: Warning: 64bit mode not supported on `i386' (consider swapping .arch and .code directives). [ 3712s] {standard input}: Error: 1 warning, treating warnings as errors The problem (see below) is newly diagnosed, from upstream it's an error. I made binutils only emit a warning for this (as also other packages hit this), but unfortunately qemu iPXE sources are built with --fatal-warnings, so the demotion to warnings doesn't help here. The problem is the following. Assembly files using the '.arch i386' directive need to have their code-size set _beforehand_ to either 32bit or 16bit. The '--64' cmdline argument sets it to 64bit resulting in the error message. You cannot get rid of this cmdline argument (or replace it with --32) because then a different kind of ELF object file would be generated. So, what needs to happen is for such code: .arch i386 ... other directives ... .code16 # or .code32 to move (or add) the .codeXX directive in front of the .arch directive. I will momentarily attach a patch to do that in all files from the roms/ipxe subdir. I've verified that this fixes the error message and lets qemu 8.2.0 build with the new binutils. Tumbleweed (or at least the Staging:A) still uses qemu 8.1.something, but as the iPXE repo gets virtually no changes at all the patch should also apply to that tree as is. (The build-test happens in home:matz2:branches:Virtualization/qemu/15.5 ) Can I convince someone from the qemu team to please integrate this patch into the qemu package for at least tumbleweed? -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1221680] New: kubefirst: completion files problem
by bugzilla_noreply＠suse.com 21 Feb '25

21 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1221680 Bug ID: 1221680 Summary: kubefirst: completion files problem Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: opensuse_buildservice(a)ojkastl.de Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: Development Blocker: --- While working on reproducible builds for openSUSE, I found that our kubefirst 2.4.2 package varies in its completion files /usr/share/bash-completion/completions/kubefirst @@ -1,4 +1,4 @@ -checking for a newer version failed (cannot get Homebrew formula) with: Get "https://raw.githubusercontent.com/Homebrew/homebrew-core/master/Formula/k/k…": dial tcp: lookup raw.githubusercontent.com on [::1]:53: read udp [::1]:33232->[::1]:53: read: connection refused# bash completion V2 for kubefirst -*- shell-script -*- +checking for a newer version failed (cannot get Homebrew formula) with: Get "https://raw.githubusercontent.com/Homebrew/homebrew-core/master/Formula/k/k…": dial tcp: lookup raw.githubusercontent.com on [::1]:53: read udp [::1]:38072->[::1]:53: read: connection refused# bash completion V2 for kubefirst -*- shell-script -*- __kubefirst_debug() { ... more diff in https://rb.zq1.de/compare.factory-20240228/diffs/kubefirst-compare.out This line looks like it should not be there in the first place = bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1221763] New: ptrace(PTRACE_ATTACH) fails on processes of the same user
by bugzilla_noreply＠suse.com 21 Feb '25

21 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1221763 Bug ID: 1221763 Summary: ptrace(PTRACE_ATTACH) fails on processes of the same user Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: giuliano.belinassi(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Recent updates of tumbleweed broke `ptrace(PTRACE_ATTACH, ...)` when attaching to a process from the same user. This breaks attaching a debugger (gdb) to a process and userspace livepatching. A single line reproducer in a clean system is: ``` $ sleep 5000 & gdb -p $(pidof sleep) ``` If you see the following message: ``` Attaching to process 12606 ptrace: Operation not permitted. ``` This means ptrace is not working. As a contrast, running gdb with sudo works as intended. Value of /proc/sys/kernel/yama/ptrace_scope: ``` $ cat /proc/sys/kernel/yama/ptrace_scope 1 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 41

[Bug 1224781] New: VUL-0: CVE-2024-35192: trivy: credential leak via malicious registry
by bugzilla_noreply＠suse.com 20 Feb '25

20 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1224781 Bug ID: 1224781 Summary: VUL-0: CVE-2024-35192: trivy: credential leak via malicious registry Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/406773/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: dmueller(a)suse.com Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: carlos.lopez(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- Trivy is a security scanner. Prior to 0.51.2, if a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Systems are not affected if the default credential provider chain is unable to obtain valid credentials. This vulnerability only applies when scanning container images directly from a registry. This vulnerability is fixed in 0.51.2. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-35192 https://www.cve.org/CVERecord?id=CVE-2024-35192 https://github.com/aquasecurity/trivy/commit/e7f14f729de259551203f313e57d2d… https://github.com/aquasecurity/trivy/security/advisories/GHSA-xcq4-m2r3-cm… -- You are receiving this mail because: You are on the CC list for the bug.

1 7