March 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1221286] New: Mesa-demo package missing
by bugzilla_noreply＠suse.com 07 May '24

07 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1221286 Bug ID: 1221286 Summary: Mesa-demo package missing Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: sndirsch(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Mesa-demo package is missing on Leap 15.6. At least Mesa-demo-x would be important to check GL support. Mesa-demo-egl and Mesa-demo-es would be also useful. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1219945] New: gnome terminal server crash on gnome 46
by bugzilla_noreply＠suse.com 07 May '24

07 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1219945 Bug ID: 1219945 Summary: gnome terminal server crash on gnome 46 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de CC: sndirsch(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Latest TW: Mesa 23.3.5 GNOME:Next for the gnome 46 beta. ``` coredumpctl info 21918 | cat Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. PID: 21918 (gnome-terminal-) UID: 1000 (darix) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Thu 2024-02-15 02:04:12 CET (11min ago) Command Line: /usr/libexec/gnome-terminal-server Executable: /usr/libexec/gnome-terminal-server Control Group: /user.slice/user-1000.slice/user(a)1000.service/app.slice/app-org.gnome.Terminal.slice/gnome-terminal-server.service Unit: user(a)1000.service User Unit: gnome-terminal-server.service Slice: user-1000.slice Owner UID: 1000 (darix) Boot ID: 62d8c0f5e0ee48a192c37b6729c4f93e Machine ID: cb7e8828621b42ce840608de3f231bb4 Hostname: fortress.home.nordisch.org Storage: /var/lib/systemd/coredump/core.gnome-terminal-.1000.62d8c0f5e0ee48a192c37b6729c4f93e.21918.1707959052000000.zst (present) Size on Disk: 14.2M Message: Process 21918 (gnome-terminal-) of user 1000 dumped core. Stack trace of thread 21918: #0 0x00007fa419fae199 n/a (iris_dri.so + 0x1ae199) #1 0x00007fa419f68876 n/a (iris_dri.so + 0x168876) #2 0x00007fa419f68bc5 n/a (iris_dri.so + 0x168bc5) #3 0x00007fa419f68dc3 n/a (iris_dri.so + 0x168dc3) #4 0x00007fa43c8e6f25 n/a (libgtk-4.so.1 + 0x4e6f25) #5 0x00007fa43c8e21d9 n/a (libgtk-4.so.1 + 0x4e21d9) #6 0x00007fa43c8cea7f n/a (libgtk-4.so.1 + 0x4cea7f) #7 0x00007fa43c8e6c3b n/a (libgtk-4.so.1 + 0x4e6c3b) #8 0x00007fa43c8863a4 gsk_renderer_render (libgtk-4.so.1 + 0x4863a4) #9 0x00007fa43c692411 n/a (libgtk-4.so.1 + 0x292411) #10 0x00007fa43c6932b5 n/a (libgtk-4.so.1 + 0x2932b5) #11 0x00007fa43c7e1c64 n/a (libgtk-4.so.1 + 0x3e1c64) #12 0x00007fa43d0c7861 n/a (libgobject-2.0.so.0 + 0x17861) #13 0x00007fa43d0dcd06 n/a (libgobject-2.0.so.0 + 0x2cd06) #14 0x00007fa43d0e35c2 g_signal_emit_valist (libgobject-2.0.so.0 + 0x335c2) #15 0x00007fa43d0e366f g_signal_emit (libgobject-2.0.so.0 + 0x3366f) #16 0x00007fa43c867ed2 n/a (libgtk-4.so.1 + 0x467ed2) #17 0x00007fa43d0c7861 n/a (libgobject-2.0.so.0 + 0x17861) #18 0x00007fa43d0dd9c4 n/a (libgobject-2.0.so.0 + 0x2d9c4) #19 0x00007fa43d0e35c2 g_signal_emit_valist (libgobject-2.0.so.0 + 0x335c2) #20 0x00007fa43d0e366f g_signal_emit (libgobject-2.0.so.0 + 0x3366f) #21 0x00007fa43c84d32f n/a (libgtk-4.so.1 + 0x44d32f) #22 0x00007fa43cfc5114 n/a (libglib-2.0.so.0 + 0x60114) #23 0x00007fa43cfc2700 n/a (libglib-2.0.so.0 + 0x5d700) #24 0x00007fa43cfc4348 n/a (libglib-2.0.so.0 + 0x5f348) #25 0x00007fa43cfc49fc g_main_context_iteration (libglib-2.0.so.0 + 0x5f9fc) #26 0x00007fa43d1fd8ed g_application_run (libgio-2.0.so.0 + 0xe98ed) #27 0x0000559e9bfec93d n/a (gnome-terminal-server + 0x1893d) #28 0x00007fa43b82a1f0 __libc_start_call_main (libc.so.6 + 0x2a1f0) #29 0x00007fa43b82a2b9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a2b9) #30 0x0000559e9bfecbc5 n/a (gnome-terminal-server + 0x18bc5) Stack trace of thread 21921: #0 0x00007fa43b90578f __poll (libc.so.6 + 0x10578f) #1 0x00007fa43cfc42ef n/a (libglib-2.0.so.0 + 0x5f2ef) #2 0x00007fa43cfc49fc g_main_context_iteration (libglib-2.0.so.0 + 0x5f9fc) #3 0x00007fa43cfc4a41 n/a (libglib-2.0.so.0 + 0x5fa41) #4 0x00007fa43cff12de n/a (libglib-2.0.so.0 + 0x8c2de) #5 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21919: #0 0x00007fa43b911bcd syscall (libc.so.6 + 0x111bcd) #1 0x00007fa43d01edf0 g_cond_wait (libglib-2.0.so.0 + 0xb9df0) #2 0x00007fa43cf8d0bb n/a (libglib-2.0.so.0 + 0x280bb) #3 0x00007fa43cf8d547 g_async_queue_pop (libglib-2.0.so.0 + 0x28547) #4 0x00007fa43ba4bd93 n/a (libpangoft2-1.0.so.0 + 0xad93) #5 0x00007fa43cff12de n/a (libglib-2.0.so.0 + 0x8c2de) #6 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #7 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21935: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21920: #0 0x00007fa43b911bcd syscall (libc.so.6 + 0x111bcd) #1 0x00007fa43d01edf0 g_cond_wait (libglib-2.0.so.0 + 0xb9df0) #2 0x00007fa43cf8d0bb n/a (libglib-2.0.so.0 + 0x280bb) #3 0x00007fa43cff1ad2 n/a (libglib-2.0.so.0 + 0x8cad2) #4 0x00007fa43cff12de n/a (libglib-2.0.so.0 + 0x8c2de) #5 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21922: #0 0x00007fa43b90578f __poll (libc.so.6 + 0x10578f) #1 0x00007fa43cfc42ef n/a (libglib-2.0.so.0 + 0x5f2ef) #2 0x00007fa43cfc49fc g_main_context_iteration (libglib-2.0.so.0 + 0x5f9fc) #3 0x00007fa43929e99d n/a (libdconfsettings.so + 0x699d) #4 0x00007fa43cff12de n/a (libglib-2.0.so.0 + 0x8c2de) #5 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 22395: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21934: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21936: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21923: #0 0x00007fa43b90578f __poll (libc.so.6 + 0x10578f) #1 0x00007fa43cfc42ef n/a (libglib-2.0.so.0 + 0x5f2ef) #2 0x00007fa43cfc4c1f g_main_loop_run (libglib-2.0.so.0 + 0x5fc1f) #3 0x00007fa43d23a276 n/a (libgio-2.0.so.0 + 0x126276) #4 0x00007fa43cff12de n/a (libglib-2.0.so.0 + 0x8c2de) #5 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 21937: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 859: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 22396: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 860: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 6653: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 10460: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 10461: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 6654: #0 0x00007fa43b88effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fa43b891d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fa419f0f42b n/a (iris_dri.so + 0x10f42b) #3 0x00007fa419f04697 n/a (iris_dri.so + 0x104697) #4 0x00007fa43b892bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fa43b91400c __clone3 (libc.so.6 + 0x11400c) ELF object binary architecture: AMD x86-64 ``` ``` (gdb) bt #0 list_addtail (list=0x559ea1709098, item=0x559ea0ebfbb8) at ../src/util/list.h:83 #1 st_save_zombie_sampler_view (view=<optimized out>, st=0x559ea1707690) at ../src/mesa/state_tracker/st_context.c:214 #2 st_texture_release_all_sampler_views (st=0x559ea17e85b0, stObj=<optimized out>) at ../src/mesa/state_tracker/st_sampler_view.c:272 #3 0x00007fa419f68876 in st_texture_release_all_sampler_views (stObj=0x559ea25f3590, st=<optimized out>) at ../src/mesa/state_tracker/st_sampler_view.c:258 #4 st_delete_texture_sampler_views (stObj=0x559ea25f3590, st=<optimized out>) at ../src/mesa/state_tracker/st_sampler_view.c:292 #5 _mesa_delete_texture_object (ctx=0x559ea17a0f40, texObj=0x559ea25f3590) at ../src/mesa/main/texobj.c:523 #6 0x00007fa419f68bc5 in _mesa_reference_texobj_ (ptr=ptr@entry=0x559ea17b7760, tex=tex@entry=0x559ea0c219f0) at ../src/mesa/main/texobj.c:637 #7 0x00007fa419f68dc3 in _mesa_reference_texobj (tex=<optimized out>, ptr=<optimized out>) at ../src/mesa/main/texobj.h:92 #8 bind_texture_object (ctx=0x559ea17a0f40, unit=2, texObj=0x559ea0c219f0) at ../src/mesa/main/texobj.c:1714 #9 0x00007fa43c8e6f25 in gsk_gl_descriptors_use (self=0x559ea0fe0710) at ../gsk/gpu/gskgldescriptors.c:132 #10 gsk_gpu_shader_op_gl_command_n (op=<optimized out>, frame=0x559ea181b470, state=0x7ffeb2318d70, instance_scale=1) at ../gsk/gpu/gskgpushaderop.c:133 #11 0x00007fa43c8e21d9 in gsk_gpu_op_gl_command (state=0x7ffeb2318d70, frame=0x559ea181b470, op=<optimized out>) at ../gsk/gpu/gskgpuop.c:49 #12 gsk_gpu_render_pass_op_gl_command (op=<optimized out>, frame=0x559ea181b470, state=0x7ffeb2318d70) at ../gsk/gpu/gskgpurenderpassop.c:189 #13 0x00007fa43c8cea7f in gsk_gpu_op_gl_command (state=0x7ffeb2318d70, frame=0x559ea181b470, op=0x7fa421aff010) at ../gsk/gpu/gskgpuop.c:49 #14 gsk_gl_frame_submit (frame=0x559ea181b470, vertex_buffer=<optimized out>, op=0x7fa421aff010) at ../gsk/gpu/gskglframe.c:162 #15 0x00007fa43c8e6c3b in gsk_gpu_frame_render (texture=0x0, viewport=0x7ffeb2318e10, node=0x559ea0d7ae10, region=0x559ea0279200, target=0x559ea1819920, timestamp=90730367859, self=0x559ea181b470) at ../gsk/gpu/gskgpuframe.c:624 #16 gsk_gpu_renderer_render (renderer=<optimized out>, root=0x559ea0d7ae10, region=<optimized out>) at ../gsk/gpu/gskgpurenderer.c:416 #17 0x00007fa43c8863a4 in gsk_renderer_render (renderer=<optimized out>, root=<optimized out>, region=<optimized out>) at ../gsk/gskrenderer.c:509 #18 0x00007fa43c692411 in gtk_widget_render (widget=0x559ea0fb80f0, surface=<optimized out>, region=0x559e9dd7c130) at ../gtk/gtkwidget.c:11971 #19 0x00007fa43c6932b5 in surface_render () at ../gtk/gtkwindow.c:4752 #20 0x00007fa43c7e1c64 in _gdk_marshal_BOOLEAN__BOXEDv (closure=0x559ea17f0da0, return_value=0x7ffeb23191f0, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x559e9e4fec30) at gdk/gdkmarshalers.c:130 #21 0x00007fa43d0c7861 in _g_closure_invoke_va (closure=0x559ea17f0da0, return_value=0x7ffeb23191f0, instance=0x559ea1754830, args=0x7ffeb23192f0, n_params=1, param_types=0x559e9e4fec30) at ../gobject/gclosure.c:897 #22 0x00007fa43d0dcd06 in signal_emit_valist_unlocked (instance=instance@entry=0x559ea1754830, signal_id=signal_id@entry=280, detail=detail@entry=0, var_args=var_args@entry=0x7ffeb23192f0) at ../gobject/gsignal.c:3415 #23 0x00007fa43d0e35c2 in g_signal_emit_valist (instance=0x559ea1754830, signal_id=280, detail=0, var_args=0x7ffeb23192f0) at ../gobject/gsignal.c:3254 #24 0x00007fa43d0e366f in g_signal_emit (instance=instance@entry=0x559ea1754830, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574 #25 0x00007fa43c867ed2 in gdk_surface_paint_on_clock (clock=<optimized out>, data=0x559ea1754830) at ../gdk/gdksurface.c:1370 #26 gdk_surface_paint_on_clock (clock=<optimized out>, data=0x559ea1754830) at ../gdk/gdksurface.c:1346 #27 0x00007fa43d0c7861 in _g_closure_invoke_va (closure=0x559ea1755330, return_value=0x0, instance=0x559ea1755130, args=0x7ffeb2319680, n_params=0, param_types=0x0) at ../gobject/gclosure.c:897 #28 0x00007fa43d0dd9c4 in signal_emit_valist_unlocked (instance=instance@entry=0x559ea1755130, signal_id=signal_id@entry=289, detail=detail@entry=0, var_args=var_args@entry=0x7ffeb2319680) at ../gobject/gsignal.c:3415 #29 0x00007fa43d0e35c2 in g_signal_emit_valist (instance=0x559ea1755130, signal_id=289, detail=0, var_args=0x7ffeb2319680) at ../gobject/gsignal.c:3254 #30 0x00007fa43d0e366f in g_signal_emit (instance=instance@entry=0x559ea1755130, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3574 #31 0x00007fa43c84d32f in _gdk_frame_clock_emit_paint (frame_clock=0x559ea1755130) at ../gdk/gdkframeclock.c:712 #32 gdk_frame_clock_paint_idle (data=data@entry=0x559ea1755130) at ../gdk/gdkframeclockidle.c:634 #33 0x00007fa43cfc5114 in g_timeout_dispatch (source=0x559ea2373ae0, callback=0x7fa43c84ce10 <gdk_frame_clock_paint_idle>, user_data=0x559ea1755130) at ../glib/gmain.c:4989 #34 0x00007fa43cfc2700 in g_main_dispatch (context=0x559e9d9f60c0) at ../glib/gmain.c:3344 #35 g_main_context_dispatch_unlocked (context=context@entry=0x559e9d9f60c0) at ../glib/gmain.c:4152 #36 0x00007fa43cfc4348 in g_main_context_iterate_unlocked (context=context@entry=0x559e9d9f60c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4217 #37 0x00007fa43cfc49fc in g_main_context_iteration (context=context@entry=0x559e9d9f60c0, may_block=may_block@entry=1) at ../glib/gmain.c:4282 #38 0x00007fa43d1fd8ed in g_application_run (application=0x559e9da3a210, argc=0, argv=<optimized out>) at ../gio/gapplication.c:2712 #39 0x0000559e9bfec93d in main (argc=<optimized out>, argv=<optimized out>) at ../src/server.cc:232 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1217299] New: zypp:plugins/zypper-changelog-plugin: Bug repodata is now using zstd compression
by bugzilla_noreply＠suse.com 06 May '24

06 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1217299 Bug ID: 1217299 Summary: zypp:plugins/zypper-changelog-plugin: Bug repodata is now using zstd compression Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: zbalogh(a)suse.com Reporter: ianmepham(a)gmail.com QA Contact: screening-team-bugs(a)suse.de CC: nadvornik(a)suse.com Target Milestone: --- Found By: --- Blocker: --- I'm running Tumbleweed x86_64, all up-to-date as of 18 Nov 2023 with snapshot 20231116. The package zypper-changelog-plugin I'm using is version 0.3-1.2. Recently zypper-changelog has stopped working with no error messages nor any other output given. I've tested both trying to download the changelog for a single package, such as with zypper-changelog --package vim, as well as the changelogs for any upcoming system updates with zypper-changelog ‐‐update I understand that the repodata is now compressed with zstd rather than gz as mentioned in the Factory mailing list here https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… I tested modifying zypper-changelog to accept both gz and zstd compressed repodata so it would work with both the official repos and any other repos which still use gz compression. Please keep in mind that I've only tested this in Tumbleweed. It also requires using zstdcat in place of zcat. Fortunately zstdcat also supports gz compression. The version of zstdcat I tested this with is 1.5.5-3.5. Here's a diff of the changes I've tested to give you an idea of what I mean comparing the current version 0.3-1.2 zypper-changelog and a modified test version: 147c147 < if file.endswith("primary.xml.gz"): --- > if file.endswith(("primary.xml.zst", "primary.xml.gz")): 172c172 < zcat_process = subprocess.Popen(["zcat", --- > zstdcat_process = subprocess.Popen(["zstdcat", 176c176 < stdout_value, stderr_value = zcat_process.communicate() --- > stdout_value, stderr_value = zstdcat_process.communicate() I understand that using a tuple is considered to be more pythonic, but I'm not sure if some may find it more legible to do something like this: if file.endswith("primary.xml.zst") or if file.endswith("primary.xml.gz"): I've not really done stuff like this before so my sincere apologies if I've picked the wrong option or made a mistake in this bug report. I'm also just an amateur with Python too so I may have easily overlooked something. Please ask if you need any more information. Thank you for your time and for such a useful tool. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1221433] New: [python-jirafs] Missing dependency PIL
by bugzilla_noreply＠suse.com 06 May '24

06 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1221433 Bug ID: 1221433 Summary: [python-jirafs] Missing dependency PIL 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: mcepl(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- tumbleweed-pkg~$ jirafs --help Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/jirafs/cmdline.py", line 16, in <module> from jira.utils import JIRAError File "/usr/lib/python3.11/site-packages/jira/__init__.py", line 11, in <module> from jira.client import ( File "/usr/lib/python3.11/site-packages/jira/client.py", line 44, in <module> from PIL import Image ModuleNotFoundError: No module named 'PIL' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/jirafs", line 5, in <module> from jirafs.cmdline import main File "/usr/lib/python3.11/site-packages/jirafs/cmdline.py", line 18, in <module> from jira.exceptions import JIRAError File "/usr/lib/python3.11/site-packages/jira/__init__.py", line 11, in <module> from jira.client import ( File "/usr/lib/python3.11/site-packages/jira/client.py", line 44, in <module> from PIL import Image ModuleNotFoundError: No module named 'PIL' tumbleweed-pkg~$ -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1221017] New: GCC 14: python-ruamel.yaml.clib package fails
by bugzilla_noreply＠suse.com 06 May '24

06 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1221017 Bug ID: 1221017 Summary: GCC 14: python-ruamel.yaml.clib package fails 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: michal.jires(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- Building python-ruamel.yaml.clib with GCC 14 fails here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… Due to (exhaustive list of errors): _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_7CParser___init__’: _ruamel_yaml.c:5929:52: error: passing argument 2 of ‘yaml_parser_set_input’ from incompatible pointer type [-Wincompatible-pointer-types] 5929 | yaml_parser_set_input((&__pyx_v_self->parser), __pyx_f_6ruamel_4yaml_4clib_12_ruamel_yaml_input_handler, ((void *)__pyx_v_self)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | int (*)(void *, char *, int, int *) In file included from _ruamel_yaml.h:2: yaml.h:1370:30: note: expected ‘int (*)(void *, unsigned char *, size_t, size_t *)’ {aka ‘int (*)(void *, unsigned char *, long unsigned int, long unsigned int *)’} but argument is of type ‘int (*)(void *, char *, int, int *)’ 1370 | yaml_read_handler_t *handler, void *data); | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~ In file included from /usr/include/python3.9/bytesobject.h:75, from /usr/include/python3.9/Python.h:92, from _ruamel_yaml.c:16: _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_8CEmitter___init__’: _ruamel_yaml.c:16882:53: error: passing argument 2 of ‘yaml_emitter_set_output’ from incompatible pointer type [-Wincompatible-pointer-types] 16882 | yaml_emitter_set_output((&__pyx_v_self->emitter), __pyx_f_6ruamel_4yaml_4clib_12_ruamel_yaml_output_handler, ((void *)__pyx_v_self)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | int (*)(void *, char *, int) yaml.h:1837:31: note: expected ‘int (*)(void *, unsigned char *, size_t)’ {aka ‘int (*)(void *, unsigned char *, long unsigned int)’} but argument is of type ‘int (*)(void *, char *, int)’ 1837 | yaml_write_handler_t *handler, void *data); | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ error: command '/usr/bin/gcc' failed with exit code 1 See the meta bug#1220571 for more info. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1217828] New: podman not using netavark as default
by bugzilla_noreply＠suse.com 06 May '24

06 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1217828 Bug ID: 1217828 Summary: podman not using netavark as default 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: felix.niederwanger(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- On Tumbleweed, despite being on podman 4.8.0 we are still using CNI instead of netavark as the default network backend https://openqa.opensuse.org/tests/3781263#step/podman/48 This issue was detected while extending the podman tests on Tumbleweed. -- 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 06 May '24

06 May '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 24

[Bug 1221905] New: named crashes on startup: mem.c:736: fatal error: malloc failed: Cannot allocate memory
by bugzilla_noreply＠suse.com 05 May '24

05 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1221905 Bug ID: 1221905 Summary: named crashes on startup: mem.c:736: fatal error: malloc failed: Cannot allocate memory Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: georg.pfuetzenreuter(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 873759 --> https://bugzilla.suse.com/attachment.cgi?id=873759&action=edit strace Hi, BIND from the update repositories works on our virtual machines, but does not start on a physical one: ``` Mar 24 17:20:07 stonehat systemd[1]: Starting Berkeley Internet Name Domain (DNS)... Mar 24 17:20:07 stonehat named[49737]: starting BIND 9.16.48 (Extended Support Version) <id:0dab57e> Mar 24 17:20:07 stonehat named[49737]: running on Linux x86_64 5.14.21-150500.55.52-default #1 SMP PREEMPT_DYNAMIC Tue Mar 5 16:53:41 UTC 2024 (a62851f) Mar 24 17:20:07 stonehat named[49737]: built with '--host=x86_64-suse-linux-gnu' '--build=x86_64-suse-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/et> Mar 24 17:20:07 stonehat named[49737]: running as: named -u named Mar 24 17:20:07 stonehat named[49737]: compiled by GCC 7.5.0 Mar 24 17:20:07 stonehat named[49737]: compiled with OpenSSL version: OpenSSL 1.1.1l-fips 24 Aug 2021 SUSE release SUSE_OPENSSL_RELEASE Mar 24 17:20:07 stonehat named[49737]: linked to OpenSSL version: OpenSSL 1.1.1l-fips 24 Aug 2021 SUSE release 150500.17.25.1 Mar 24 17:20:07 stonehat named[49737]: compiled with libuv version: 1.44.2 Mar 24 17:20:07 stonehat named[49737]: linked to libuv version: 1.44.2 Mar 24 17:20:07 stonehat named[49737]: compiled with libxml2 version: 2.10.3 Mar 24 17:20:07 stonehat named[49737]: linked to libxml2 version: 21003 Mar 24 17:20:07 stonehat named[49737]: compiled with json-c version: 0.13 Mar 24 17:20:07 stonehat named[49737]: linked to json-c version: 0.13 Mar 24 17:20:07 stonehat named[49737]: compiled with zlib version: 1.2.13 Mar 24 17:20:07 stonehat named[49737]: linked to zlib version: 1.2.13 Mar 24 17:20:07 stonehat named[49737]: ---------------------------------------------------- Mar 24 17:20:07 stonehat named[49737]: BIND 9 is maintained by Internet Systems Consortium, Mar 24 17:20:07 stonehat named[49737]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Mar 24 17:20:07 stonehat named[49737]: corporation. Support and training for BIND 9 are Mar 24 17:20:07 stonehat named[49737]: available at https://www.isc.org/support Mar 24 17:20:07 stonehat named[49737]: ---------------------------------------------------- Mar 24 17:20:07 stonehat named[49737]: adjusted limit on open files from 524288 to 1048576 Mar 24 17:20:07 stonehat named[49737]: found 64 CPUs, using 64 worker threads Mar 24 17:20:07 stonehat named[49737]: using 64 UDP listeners per interface Mar 24 17:20:07 stonehat named[49737]: using up to 21000 sockets Mar 24 17:20:07 stonehat named[49737]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 Mar 24 17:20:07 stonehat named[49737]: DS algorithms: SHA-1 SHA-256 SHA-384 Mar 24 17:20:07 stonehat named[49737]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 Mar 24 17:20:07 stonehat named[49737]: TKEY mode 2 support (Diffie-Hellman): yes Mar 24 17:20:07 stonehat named[49737]: TKEY mode 3 support (GSS-API): yes Mar 24 17:20:07 stonehat named[49737]: loading configuration from '/etc/named.conf' Mar 24 17:20:07 stonehat named[49737]: reading built-in trust anchors from file '/etc/bind.keys' Mar 24 17:20:07 stonehat named[49737]: looking for GeoIP2 databases in '/usr/share/GeoIP' Mar 24 17:20:07 stonehat named[49737]: using default UDP/IPv4 port range: [32768, 60999] Mar 24 17:20:07 stonehat named[49737]: using default UDP/IPv6 port range: [32768, 60999] Mar 24 17:20:07 stonehat named[49737]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 24 17:20:07 stonehat named[49737]: listening on IPv4 interface prg2_asgard1, 172.16.201.6#53 Mar 24 17:20:07 stonehat named[49737]: listening on IPv4 interface prg2_asgard2, 172.16.202.6#53 Mar 24 17:20:07 stonehat named[49737]: listening on IPv4 interface private, 192.168.87.1#53 Mar 24 17:20:07 stonehat named[49737]: generating session key for dynamic DNS Mar 24 17:20:07 stonehat named[49737]: sizing zone task pool based on 18 zones Mar 24 17:20:08 stonehat named[49737]: obtaining root key for view _default from '/etc/bind.keys' Mar 24 17:20:08 stonehat named[49737]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Mar 24 17:20:08 stonehat named[49737]: mem.c:736: fatal error: Mar 24 17:20:08 stonehat named[49737]: malloc failed: Cannot allocate memory Mar 24 17:20:08 stonehat named[49737]: exiting (due to fatal error in library) Mar 24 17:20:08 stonehat systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE Mar 24 17:20:08 stonehat systemd[1]: named.service: Failed with result 'exit-code'. Mar 24 17:20:08 stonehat systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). ``` With the bind-9.16.38-150400.5.20.2 package from the GA repository, named starts fine. We don't know which update introduced the problem. I tried disabling "zone-statistics", but that did not help. Strace output while running named in foreground is attached. No related kernel log entries are observed, but dmesg is attached as well. Cheers, Georg -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1222180] New: openssh: rewrite systemd notification without linking systemd
by bugzilla_noreply＠suse.com 03 May '24

03 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1222180 Bug ID: 1222180 Summary: openssh: rewrite systemd notification without linking systemd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- openssh carries this patch: https://build.opensuse.org/projects/openSUSE:Factory/packages/openssh/files… which is linking libsystemd, just for notifying systemd. given the large dependency tree of systemd, this increases the attack surface of openssh, as can be seen via https://www.suse.com/security/cve/CVE-2024-3094.html we should split out sd_notify() into a separate standalone library (or maybe it exists already?) and link that one instead -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1213297] New: No clang-tools package needed by clang >=13 from PackageHub repo
by bugzilla_noreply＠suse.com 03 May '24

03 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1213297 Bug ID: 1213297 Summary: No clang-tools package needed by clang >=13 from PackageHub repo Classification: openSUSE Product: openSUSE Backports Version: SLE-15-SP5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Packages Assignee: packagehub-bugs(a)suse.com Reporter: oleksandr.shchirskyi(a)intel.com QA Contact: packagehub-bugs(a)suse.com Target Milestone: --- Found By: --- Blocker: No There is an issues with LLVM versions >=13 on SLES15 SP5. None of the Package Hub versions can be installed because the Clang-tool dependency is missing. For example, LLVM for SLES15 SP4 includes Clang-tool, but for SP5 it doesn't: https://packagehub.suse.com/packages/llvm13/ The same issue applies to LLVM 14. Here's a brief log example: # grep PRETTY /etc/os-release PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5" # zypper install clang14-devel Refreshing service 'Basesystem_Module_15_SP5_x86_64'. Refreshing service 'Desktop_Applications_Module_15_SP5_x86_64'. Refreshing service 'Development_Tools_Module_15_SP5_x86_64'. Refreshing service 'Legacy_Module_15_SP5_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP5_x86_64'. Refreshing service 'SUSE_Package_Hub_15_SP5_x86_64'. Refreshing service 'Server_Applications_Module_15_SP5_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides 'clang-tools >= 14.0.6' needed by the to be installed clang14-devel-14.0.6-bp155.4.10.x86_64 Solution 1: do not install clang14-devel-14.0.6-bp155.4.10.x86_64 Solution 2: break clang14-devel-14.0.6-bp155.4.10.x86_64 by ignoring some of its dependencies # zypper info clang14-devel Refreshing service 'Basesystem_Module_15_SP5_x86_64'. Refreshing service 'Desktop_Applications_Module_15_SP5_x86_64'. Refreshing service 'Development_Tools_Module_15_SP5_x86_64'. Refreshing service 'Legacy_Module_15_SP5_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP5_x86_64'. Refreshing service 'SUSE_Package_Hub_15_SP5_x86_64'. Refreshing service 'Server_Applications_Module_15_SP5_x86_64'. Loading repository data... Reading installed packages... Information for package clang14-devel: -------------------------------------- Repository : SUSE-PackageHub-15-SP5-Backports-Pool Name : clang14-devel Version : 14.0.6-bp155.4.10 Arch : x86_64 Vendor : openSUSE Support Level : unknown Installed Size : 17.3 MiB Installed : No Status : not installed Source package : llvm14-14.0.6-bp155.4.10.src Upstream URL : https://www.llvm.org/ Summary : CLANG frontend for LLVM (devel package) Description : This package contains the clang (C language) frontend for LLVM. (development files) # zypper search clang | grep tools # At the same moment it's possible to install LLVM >=13 from OpenSUSE repos, for example, adding this to repos config "http://download.opensuse.org/distribution/leap/15.5/repo/oss/" -- You are receiving this mail because: You are on the CC list for the bug.

1 2