openSUSE Bugs June 2022

bugs@lists.opensuse.org

2 participants
2505 discussions

[Bug 1135030] New: LTO: ceph build fails
by bugzilla_noreply＠novell.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1135030 Bug ID: 1135030 Summary: LTO: ceph build fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Fails here: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… due to: [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_aio_create_completion' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create_with_context' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_version' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create2' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_nobjects_list_next' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_env' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_set' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_create' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_ioctx_create2' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_argv' [ 8864s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_read_file' -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 1165294] New: haveged is marked as deleted after reboot
by bugzilla_noreply＠novell.com 22 Mar '23

22 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1165294 Bug ID: 1165294 Summary: haveged is marked as deleted after reboot 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: hpj(a)urpla.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, *After reboot*, a couple of my TW systems show: $ zyp ps Verbosity: 2 Checking for running processes using deleted libraries... The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ----+------+-----+------+-------------------+--------- +------------------------------ 531 | 1 | 0 | root | haveged (deleted) | haveged | /lib64/ld-2.31.so | | | | | | /lib64/libc-2.31.so | | | | | | /usr/sbin/haveged (deleted) | | | | | | /usr/lib64/libhavege.so.1.1.0 You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated. Reboot is probably not necessary. Marcus Meissner noted on the factory ML, that: > It is ran in the initrd and probably still running after transition to the > regular system. > > (Likely pulled in via dracut-fips module) Shouldn't a transition from initrd to regular operation include a restart of this service then? -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1183965] New: makedumpfile, crash: are not able to read kenrel log from the lockless ringbuffer added in kernel-5.10
by bugzilla_noreply＠suse.com 22 Mar '23

22 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1183965 Bug ID: 1183965 Summary: makedumpfile, crash: are not able to read kenrel log from the lockless ringbuffer added in kernel-5.10 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: pmladek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- kernel-5.10 started storing kernel (printk) messages in a new lockless ringbuffer. As a result makedumpfile and crash tools are not able to read the kernel log from vmcore 5.10+ kernels. crasdump is important tool for kernel debugging. The log is usually the first thing that people look at. These never kernels are already used in openSUSE Tumbleweek. The needed changes are already upstream. It is just a matter to backport them. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1194193] New: Difficult login to bugzilla.opensuse.org
by bugzilla_noreply＠suse.com 22 Mar '23

22 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194193 Bug ID: 1194193 Summary: Difficult login to bugzilla.opensuse.org Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bugzilla Assignee: screening-team-bugs(a)suse.de Reporter: noga.dany(a)gmail.com QA Contact: novbugzilla-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- How to reproduce: * Go to https://bugzilla.opensuse.org * Click login * Fill username and password * Nothing happens How to workaround: * Go to https://bugzilla.suse.com/ * Login there * Go to https://bugzilla.opensuse.org * Login works -- You are receiving this mail because: You are on the CC list for the bug.

1 29

[Bug 1190261] New: Kernel scriptlets: XXX: Only call mokutil if UEFI and shim are used
by bugzilla_noreply＠suse.com 22 Mar '23

22 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1190261 Bug ID: 1190261 Summary: Kernel scriptlets: XXX: Only call mokutil if UEFI and shim are used 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: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Spin-off from bug 1189841. From https://github.com/openSUSE/suse-module-tools/pull/33: @mwilck: so why not test this? e.g. like this: if [ "$(mokutil --sb-state 2>/dev/null)" = "SecureBoot enabled" ]; then ... fi @hramrach: ??? The part that github displays as context for this comment does not look relevant @hramrach hramrach 21 hours ago Member Right, if you refer to XXX: Only call mokutil if UEFI and shim are used then I have no opinion on that. Should be probably handled in a separate bug and the implications of any possible check discussed to death. @hramrach hramrach 21 hours ago Member Actually, there is the problem that on arm64 you suddenly get from no shim to shim on SP update without any warning so this is really hairy to get right. Really deserves a separate bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1196048] New: audit file watches do not really work?
by bugzilla_noreply＠suse.com 22 Mar '23

22 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1196048 Bug ID: 1196048 Summary: audit file watches do not really work? 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: meissner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- auditctl -e 1 auditctl -w /etc/issue if i do echo hallo >> /etc/issue -> not audited if i do vim /etc/issue ... remove hallo line and save ... -> audited cat /etc/issue -> not audited Not sure if I am doing it right. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1193250] New: Fully switch TW to DRM graphics drivers and disable fbdev drivers
by bugzilla_noreply＠suse.com 22 Mar '23

22 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1193250 Bug ID: 1193250 Summary: Fully switch TW to DRM graphics drivers and disable fbdev drivers Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: tzimmermann(a)suse.com QA Contact: gfx-bugs(a)suse.de Found By: --- Blocker: --- In TW, we mostly use fbdev vesafb and efifb drivers for early-boot display output and as fallback. This has a number of problems, such as * Most modern Wayland compositors don't support fbdev any longer. Even X' support is bolted-on. Generally, userspace support for fbdev is slowly fading. See bug 1187154. * Handover from fbdev to native DRM drivers is unreliable and can result in stuck systems during boot. See bug 1181913. Therefore, replace TW's fbdev drivers with simpledrm and maybe other DRM drivers. -- You are receiving this mail because: You are on the CC list for the bug.

1 80

[Bug 1198616] New: Emacs segfaults in xterm (or urxvt) without DISPLAY
by bugzilla_noreply＠suse.com 21 Mar '23

21 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1198616 Bug ID: 1198616 Summary: Emacs segfaults in xterm (or urxvt) without DISPLAY 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: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrading to Tumbleweed 20220415 and emacs-28.1-393.10.x86_64, when I open xterm and unset DISPLAY, emacs almost always crashes. Even with -Q. Sometimes I can get something that looks like a potentially useful backtrace in gdb, sometimes not. The potentially useful one is: Thread 1 "emacs-gtk" received signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x00000000004707a9 in () #1 0x00000000004748d3 in update_frame () #2 0x00000000004a0fd5 in () #3 0x00000000004976a9 in message3_nolog () #4 0x0000000000497978 in message3 () #5 0x00000000005df970 in Fmessage () #6 0x00000000005e3d81 in funcall_subr () #7 0x00000000005e2723 in Ffuncall () #8 0x0000000000629c70 in exec_byte_code () #9 0x00000000005e22e8 in () #10 0x00000000005e25bd in Ffuncall () #11 0x0000000000611308 in Fload () #12 0x00000000005e3e76 in funcall_subr () #13 0x00000000005e2723 in Ffuncall () #14 0x0000000000629c70 in exec_byte_code () #15 0x00000000005e22e8 in () #16 0x00000000005e7e31 in () #17 0x00000000005e8161 in eval_sub () #18 0x00000000006137af in () #19 0x000000000061600d in () #20 0x0000000000616371 in Feval_buffer () #21 0x00000000005e3e76 in funcall_subr () #22 0x00000000005e2723 in Ffuncall () #23 0x0000000000629c70 in exec_byte_code () #24 0x00000000005e22e8 in () #25 0x00000000005e25bd in Ffuncall () #26 0x0000000000611308 in Fload () #27 0x00000000005e3e76 in funcall_subr () #28 0x00000000005e2723 in Ffuncall () #29 0x0000000000629c70 in exec_byte_code () #30 0x00000000005e22e8 in () #31 0x00000000005e25bd in Ffuncall () #32 0x0000000000629c70 in exec_byte_code () #33 0x00000000005e22e8 in () #34 0x00000000005e25bd in Ffuncall () #35 0x0000000000629c70 in exec_byte_code () #36 0x00000000005e22e8 in () #37 0x00000000005e7e31 in () #38 0x00000000005e8161 in eval_sub () #39 0x000000000055f346 in () #40 0x00000000005e0cf7 in internal_condition_case () #41 0x000000000055f7b2 in () #42 0x00000000005e0c51 in internal_catch () #43 0x000000000055fb5b in () #44 0x000000000055fc5f in recursive_edit_1 () #45 0x000000000055fde3 in Frecursive_edit () #46 0x000000000046ae2c in main () (gdb) info threads Id Target Id Frame * 1 Thread 0x7fffec13b480 (LWP 18954) "emacs-gtk" 0x00000000004707a9 in ?? () 2 Thread 0x7fffeb347640 (LWP 18960) "gmain" 0x00007fffef35752f in __GI___poll (fds=0xb48020, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fffeb347640 (LWP 18960))] #0 0x00007fffef35752f in __GI___poll (fds=0xb48020, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 29 return SYSCALL_CANCEL (poll, fds, nfds, timeout); (gdb) bt #0 0x00007fffef35752f in __GI___poll (fds=0xb48020, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007ffff6ef144e in () at /lib64/libglib-2.0.so.0 #2 0x00007ffff6ef156f in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007ffff6ef15c1 in () at /lib64/libglib-2.0.so.0 #4 0x00007ffff6f1bac5 in () at /lib64/libglib-2.0.so.0 #5 0x00007fffef2db2ba in start_thread (arg=<optimized out>) at pthread_create.c:442 #6 0x00007fffef365460 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Emacs seems to run fine in GNU screen (so this is my workaround) or in a virtual terminal. emacs-x11 and emacs-nox are also affected, except that both seem not crash under gdb (at least not now) and after that one successful start they also work in the same xterm window. But not in new ones. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1180882] New: perf does not build reproducibly
by bugzilla_noreply＠suse.com 20 Mar '23

20 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1180882 Bug ID: 1180882 Summary: perf does not build reproducibly Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1041090 Found By: Development Blocker: --- While working on reproducible builds for SLE and openSUSE, I found that our perf package differs across builds. /usr/bin/perf differs in ELF section .dynsym /usr/bin/perf differs in ELF section .rela.dyn because nftw in https://github.com/torvalds/linux/blob/v5.3/tools/perf/pmu-events/jevents.c… reads pmu-events/arch/x86/*/*.json in random filesystem readdir order -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 952198] New: django-admin does not work, django-admin.py does
by bugzilla_noreply＠novell.com 20 Mar '23

20 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=952198 Bug ID: 952198 Summary: django-admin does not work, django-admin.py does Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 RC1 1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: o.kurz(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- observation: The django tutorial https://docs.djangoproject.com/en/1.8/intro/tutorial01/ suggests to use the tool "django-admin" with django >= v1.7 which is also available in Leap but does not work. "django-admin.py" also exists and works ok. steps to reproduce: - "zypper in python-Django python-sqlite" # confirm uninstallation of blocker package - "django-admin startproject mysite" - observe error with python traceback problem: unknown so far. Is ist maybe related that python-Django (still) uses python2? workaround: - Use django-admin.py which works flawlessly, e.g. example project can be configured and run: "django-admin.py startproject mysite && python manage.py migrate && python manage.py runserver", connect with webbrowser to http://localhost:8000. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

← Newer
1
...
5
6
7
8
9
10
11
...
251
Older →

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs June 2022