July 2024 - openSUSE Bugs - openSUSE Mailing Lists

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

13 Sep '24

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 40

[Bug 1225142] New: Kernel oops in nfs
by bugzilla_noreply＠suse.com 13 Sep '24

13 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1225142 Bug ID: 1225142 Summary: Kernel oops in nfs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: msvec(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 875055 --> https://bugzilla.suse.com/attachment.cgi?id=875055&action=edit Kernel oops log As I already mentioned in bug 1223640 I'm getting oops in NFS (see the attached log) It happens in both kernel-default-5.14.21-150500.55.59.1.x86_64 kernel-default-5.14.21-150500.55.62.2.x86_64 Until and including the previous one it's been fine: kernel-default-5.14.21-150500.55.52.1.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1215976] New: Hawk fails to build in Factory
by bugzilla_noreply＠suse.com 12 Sep '24

12 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1215976 Bug ID: 1215976 Summary: Hawk fails to build in Factory Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: aburlakov(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After the update in the Factory, there has disappeared the useradd and groupadd commands. Adding the shadow package in the BuildRequires has fixed it. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1220891] New: HAWK: Update sanity check for passwd existance
by bugzilla_noreply＠suse.com 12 Sep '24

12 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1220891 Bug ID: 1220891 Summary: HAWK: Update sanity check for passwd existance Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: aburlakov(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The /etc/pam.d/passwd is optional in fact, for example there is none in the tumbleeweed. So let's relax the condition: if there is no /etc/pam.d/passwd, check if there is a passwd binary in /usr/bin of /usr/sbin. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1220890] New: Update validation for the newer versions of rails
by bugzilla_noreply＠suse.com 12 Sep '24

12 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1220890 Bug ID: 1220890 Summary: Update validation for the newer versions of rails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: aburlakov(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Starting with Rails6.1 there has changed the validation. Namely, the ActiveModel::Errors has changed it's structure. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1223862] New: Packages with explicit x86_v3 target fail to build
by bugzilla_noreply＠suse.com 12 Sep '24

12 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1223862 Bug ID: 1223862 Summary: Packages with explicit x86_v3 target fail to build Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService Assignee: screening-team-bugs(a)suse.de Reporter: cgoll(a)suse.com QA Contact: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Packages with optimized code for AVX2 (x86_v3) or AVX (x86_v4) need this code streams explicitly enabled during the build process (faiss or gpt4all) so its not possible to use the %{?suse_build_hwcaps_libs} macro. When doing this, the packages are built, but some final scripts fail cleaning up the build root fail with the error: ``` [ 51s] find: cannot delete '//.build.packages/RPMS/x86_64_v3': Directory not empty [ 51s] ``` A failed example can found under: https://build.opensuse.org/package/show/home:mslacken:ml/faiss_bug where the two codestream build for AVX2 and AVX512 fail to build. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1213181] New: ddclient dose not work for cloudflare
by bugzilla_noreply＠suse.com 11 Sep '24

11 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1213181 Bug ID: 1213181 Summary: ddclient dose not work for cloudflare Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: hillwoodroc(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- openSUSE-HW:/home/hillwood # ddclient FATAL: Error loading the Perl module JSON::Any needed for cloudflare update. It's my config: # /etc/ddclient.conf daemon=300 # check every 300 seconds syslog=yes # log update msgs to syslog #mail=root # mail all msgs to root mail-failure=root # mail failed update msgs to root pid=/run/ddclient/ddclient.pid # record PID in file. ssl=yes protocol=cloudflare ttl=1 # use=web # web=checkip.dyndns.org usev6=if, if=br0 login=email password=API Key zone=hillwoodhome.net cloud.home.hillwoodhome.net ddclient 3.10.0 works fine with this config. We should provide an update for Leap. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225660] New: python311-pip package installs in /usr/lib by default
by bugzilla_noreply＠suse.com 11 Sep '24

11 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1225660 Bug ID: 1225660 Summary: python311-pip package installs in /usr/lib by default 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: daniel.garcia(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- In tumbleweed installing a package with pip3 as root installs in the system path /usr/lib. It should install in /usr/local/lib instead. Possibly related to this patch: https://build.opensuse.org/projects/devel:languages:python:Factory/packages… -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1222499] New: runc v1.2.0~rc1 breaks distrobox (and maybe more)
by bugzilla_noreply＠suse.com 11 Sep '24

11 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1222499 Bug ID: 1222499 Summary: runc v1.2.0~rc1 breaks distrobox (and maybe more) 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: fcrozat(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Since runc was updated to v1.2.0~rc1 last week in TW, distrobox (and therefore podman), when forcing runc engine, is no longer able to start container rootless. Error is : Error: unable to start container "988cc7b326ef04596a3d14ccc41bbdb43c74a6420b5e476b5da00b4e381f0d6f": runc: runc create failed: unable to start container process: error during container init: error mounting "/" to rootfs at "/run/host": mount dst=/run/host, dstFd=/proc/thread-self/fd/8, flags=0x5020: operation not permitted: OCI permission denied" ~/.config/containers/containers.conf [containers] [engine] runtime="runc" -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1221644] New: pipewire-pulse stops working when monitor powers off/on again
by bugzilla_noreply＠suse.com 10 Sep '24

10 Sep '24

https://bugzilla.suse.com/show_bug.cgi?id=1221644 Bug ID: 1221644 Summary: pipewire-pulse stops working when monitor powers off/on again Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: hendersj(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I've observed this for some time. I have a triple monitor setup, and two of the three monitors have multiple devices plugged into them. When I lock my screen, one of the monitors switches to the Chromecast input automatically once DPMS kicks off the monitor, and when I switch it back on, pipewire-pulse refuses to play sound until I kill it *and* restart the application that was trying to play sound. This affects both sound input and output - I had a situation earlier today where the monitor was tuned back on (to keep the Chromecast from keeping the screen on all night, I turn it off using ddcutil to turn it off), and after killing pipewire-pulse, I was able to hear a web-based video call, but I could not be heard until I restarted Chrome (ie, my voice input - I tried both a bluetooth headset and a USB headset - would let me hear the other person on the meeting but they could not hear me and I could not control my microphone at all). It seems that a change in audio device availability - even a device that's not in use at he time (I rarely use the speaker on the monitor in question) causes pipewire-pulse to freak out and stop working properly until it is killed and restarts. Not sure what information would be useful from logs - let me know, and I'll see what I can grab. -- You are receiving this mail because: You are on the CC list for the bug.

1 1