January 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1133277] New: LTO: protobuf abuild fails
by bugzilla_noreply＠novell.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1133277 Bug ID: 1133277 Summary: LTO: protobuf abuild 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 due to: [ 233s] + ../src/protoc --java_out=core/src/main/java -I../src ../src/google/protobuf/descriptor.proto [ 233s] terminate called after throwing an instance of 'std::system_error' [ 233s] what(): Unknown error -1 [ 233s] /var/tmp/rpm-tmp.IcJGkF: line 61: 9707 Aborted ../src/protoc --java_out=core/src/main/java -I../src ../src/google/protobuf/descriptor.proto #0 0x00007ffff7e3fd8b in raise () from /lib64/libc.so.6 #1 0x00007ffff7e29549 in abort () from /lib64/libc.so.6 #2 0x00007ffff7aad63f in ?? () from /usr/lib64/libstdc++.so.6 #3 0x00007ffff7ab8f38 in ?? () from /usr/lib64/libstdc++.so.6 #4 0x00007ffff7ab8f83 in std::terminate() () from /usr/lib64/libstdc++.so.6 #5 0x00007ffff7ab91b4 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #6 0x00007ffff7ab0156 in std::__throw_system_error(int) () from /usr/lib64/libstdc++.so.6 #7 0x00007ffff792741b in std::call_once<void (&)()> (__once=..., __f=<optimized out>) at /usr/include/c++/9/x86_64-suse-linux/bits/gthr-default.h:700 #8 0x00007ffff77fbb83 in global constructors keyed to 65535_0_bytestream.o.132584 () at ./google/protobuf/repeated_field.h:428 #9 0x00007ffff7fe276a in call_init.part () from /lib64/ld-linux-x86-64.so.2 #10 0x00007ffff7fe2866 in _dl_init () from /lib64/ld-linux-x86-64.so.2 #11 0x00007ffff7fd40ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #12 0x0000000000000004 in ?? () #13 0x00007fffffffeb14 in ?? () #14 0x00007fffffffeb50 in ?? () #15 0x00007fffffffeb6e in ?? () #16 0x00007fffffffeb77 in ?? () #17 0x0000000000000000 in ?? () https://github.com/protocolbuffers/protobuf/issues/5923 -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1194809] New: Possible password leak by windows stealing focus
by bugzilla_noreply＠suse.com 23 Mar '23

23 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1194809 Bug ID: 1194809 Summary: Possible password leak by windows stealing focus Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Yesterday I lost (luckily only part of) an important password as follows: I was running pidgin as IRC client. pidgin was configured to autoconnect to some channels on irc.suse.de. I activated the SUSE VPN via the GNOME VPN panel. I continued working in the terminal. I ran a command in the terminal that required typing a password (as usual in terminal applications, typing passwords provides no visual feedback like "***"). I pressed "enter" and nothing happened. At this point I realized that the 2nd half of the password had ended up in the pidgin window. What happened? If an IRC server is unreachable, pidgin polls in the background in a certain interval (a few minutes I think). When the server becomes reachable, it connects to it, which causes the typical startup dialog & messages ("You are connected to irc1.suse.de ....") to be displayed. At this moment, the pidgin window pops up and grabs the keyboard focus. As the window is relatively small and my screen is large, and I was looking at the keyboard while typing (because I usually do when typing passwords), I didn't notice this immediately, and typed part of the password to the pidgin window. This is particularly nasty, because after establishing the VPN connection, the window pops up after a non-deterministic time interval which is between a few seconds and ~5 minutes. You can't "wait" for this to happen, and if you don't, you're likely to forget that the connection process is going on in the background. Also, making matters worse, when the pidgin window pops up because of a message in some chat, the focus isn't necessarily in the chat (tab in the pidgin window) that caused the pop-up, but in some currently selected chat. In the case at hand, I'd typed my password at to libera.chat's "NickServ" bot (which didn't recongnize it as command, but might have logged what I typed). For the time being, I've disabled the "auto-join" feature for all pidgin channels on irc.suse.de. But I'm unsure if that actually helps, because I believe that pidgin would try to connect to IRC accounts nonetheless, and if it does, the typical login / connect dialogs might cause the window to pop up even if no chats are configured to connect automatically. See also https://askubuntu.com/questions/1084032/how-to-prevent-new-windows-from-ste… There someone suggests using > gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict' I've tried that setting on TW (GNOME 41.3) and saw no change in behavior. A simple test is typing something like this in the terminal: > $ gedit & > $ abcdefg.... # continue typing At some point, gedit will pop up and the text will end up in the gedit window. Note that this happens with gedit but not e.g. with emacs or libreoffice writer. So it depends on the application. Also, some applications (e.g. the ssh and gpg askpass tools) use a different API that does this much better - the entire screen gets locked and changes color, so that typing something at the wrong window is practically impossible. This behavior would be inapparopriate for an application like gedit, though. The behavior of gedit and pidgin under GNOME is highly dangerous. I've reason to believe that other Window Managers (or X in general) behave similarly. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1194332] New: kernel lsm boot parameter needs lsm=integrity to use IMA
by bugzilla_noreply＠suse.com 23 Mar '23

23 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1194332 Bug ID: 1194332 Summary: kernel lsm boot parameter needs lsm=integrity to use IMA Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Build 20211229 added 'lsm=apparmor' as a kernel parameter into GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. Please change it to 'lsm=integrity,apparmor' to allow using IMA (e.g. 'ima_policy=tcb' kernel parameter). That avoids kernel oops breaking boot [1]: [ 1.210321][ T1] Kernel panic - not syncing: integrity_inode_get: lsm=integrity required. [ 1.212119][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.12-1-default #1 openSUSE Tumbleweed dacaf19d133e8023737b25567dc90a32d973f26e [ 1.215246][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 1.218496][ T1] Call Trace: [ 1.219715][ T1] <TASK> [ 1.220844][ T1] dump_stack_lvl+0x46/0x5a [ 1.222144][ T1] panic+0xf3/0x2cb [ 1.223326][ T1] integrity_inode_get.cold+0x13/0x13 [ 1.224710][ T1] process_measurement+0x86e/0x960 [ 1.226069][ T1] ? aa_file_perm+0x112/0x480 [ 1.227359][ T1] ? select_task_rq_fair+0x15a/0x1350 [ 1.228744][ T1] ? __kernel_read+0x14a/0x2d0 [ 1.230068][ T1] ? profile_signal_perm.part.0+0x91/0xb0 [ 1.231516][ T1] ima_bprm_check+0x55/0xb0 [ 1.232810][ T1] bprm_execve+0x22a/0x660 [ 1.234104][ T1] ? rest_init+0xc0/0xc0 [ 1.235372][ T1] kernel_execve+0x12e/0x1b0 [ 1.236689][ T1] kernel_init+0x76/0x120 [ 1.237982][ T1] ret_from_fork+0x22/0x30 [ 1.239278][ T1] </TASK> [ 1.240462][ T1] Kernel Offset: 0x7600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 1.243605][ T1] Rebooting in 90 seconds.. [1] https://openqa.opensuse.org/tests/2122167#step/boot_ltp/13 -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1185529] New: libgccjit does not find libgcc/crtbegin.o
by bugzilla_noreply＠suse.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1185529 Bug ID: 1185529 Summary: libgccjit does not find libgcc/crtbegin.o Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: opensusebz(a)halobates.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Trying to compile current emacs with libgccjit11, but the test of libgccjit at configure time fails: (t.c is below) gcc t.c -lgccjit ./a.out ld: cannot find crtbeginS.o: No such file or directory ld: cannot find -lgcc ld: cannot find -lgcc_s libgccjit.so: error: error invoking gcc driver strace shows that the paths seem to be incorrect: strace -e execve -f ./a.out ... [pid 23720] execve("/usr/bin/ld", ["ld", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "-shared", "-o", "/tmp/libgccjit-X37gMf/fake.so", "/usr/lib/../lib64/crti.o", "crtbeginS.o", "-L/lib/../lib64", "-L/usr/lib/../lib64", "/tmp/ccgGNXSP.o", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "-lc", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "crtendS.o", "/usr/lib/../lib64/crtn.o"], 0x14203a0 /* 105 vars */) = 0 crtbegin etc. are in /usr/lib64/gcc/x86_64-suse-linux/ but the driver is not telling the linker that. t.c: #include <libgccjit.h> #include <stdlib.h> #include <stdio.h> int main (int argc, char **argv) { gcc_jit_context *ctxt; gcc_jit_result *result; ctxt = gcc_jit_context_acquire (); if (!ctxt) exit (1); gcc_jit_type *int_type = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT); gcc_jit_function *func = gcc_jit_context_new_function (ctxt, NULL, GCC_JIT_FUNCTION_EXPORTED, int_type, "foo", 0, NULL, 0); gcc_jit_block *block = gcc_jit_function_new_block (func, "foo"); gcc_jit_block_end_with_return ( block, NULL, gcc_jit_context_new_rvalue_from_int (ctxt, int_type, 1)); result = gcc_jit_context_compile (ctxt); if (!result) exit (1); typedef int (*fn_type) (void); fn_type foo = (fn_type)gcc_jit_result_get_code (result, "foo"); if (!foo) exit (1); if (foo () != 1) exit (1); gcc_jit_context_release (ctxt); gcc_jit_result_release (result); return 0; } -- You are receiving this mail because: You are on the CC list for the bug.

1 3

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

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1133283 Bug ID: 1133283 Summary: LTO: rust 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 due to: [ 4348s] = note: /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1315fc6ffe54b9a7.rlib(std-1315fc6ffe54b9a7.std.3yju5qwd-cgu.2.rcgu.o): in function `std::sys_common::gnu::libbacktrace::foreach_symbol_fileline': [ 4348s] /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/src/libstd/sys_common/gnu/libbacktrace.rs:33: undefined reference to `__rdos_backtrace_pcinfo' [ 4348s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1315fc6ffe54b9a7.rlib(std-1315fc6ffe54b9a7.std.3yju5qwd-cgu.2.rcgu.o): in function `std::sys_common::gnu::libbacktrace::init_state': [ 4348s] /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/src/libstd/sys_common/gnu/libbacktrace.rs:169: undefined reference to `__rdos_backtrace_create_state' [ 4348s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1315fc6ffe54b9a7.rlib(std-1315fc6ffe54b9a7.std.3yju5qwd-cgu.2.rcgu.o): in function `std::sys_common::gnu::libbacktrace::resolve_symname': [ 4348s] /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/src/libstd/sys_common/gnu/libbacktrace.rs:72: undefined reference to `__rdos_backtrace_syminfo' [ 4348s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1315fc6ffe54b9a7.rlib(std-1315fc6ffe54b9a7.std.3yju5qwd-cgu.2.rcgu.o): in function `std::sys_common::gnu::libbacktrace::resolve_symname': [ 4348s] /home/abuild/rpmbuild/BUILD/rustc-1.33.0-src/src/libstd/sys_common/gnu/libbacktrace.rs:72: undefined reference to `__rdos_backtrace_syminfo' [ 4348s] collect2: error: ld returned 1 exit status [ 4348s] [ 4348s] [ 4348s] error: aborting due to previous error [ 4348s] [ 4348s] error: Could not compile `rustc-rayon-core`. [ 4348s] warning: build failed, waiting for other jobs to finish... [ 4350s] error: linking with `cc` failed: exit code: 1 -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[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