February 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1156301] New: Dovecot fails to build with LTO enabled in Tumbleweed
by bugzilla_noreply＠novell.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1156301 Bug ID: 1156301 Summary: Dovecot fails to build with LTO enabled in Tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: suse+build(a)de-korte.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since enabling LTO in Tumbleweed, the dovecot23 package fails to build most of the time with [ 133s] libtool: link: gcc -std=gnu99 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/lib64 -fpic -DPIC -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=thunk -mindirect-branch=thunk -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -DOPENSSL_LOAD_CONF -flto=auto -o test-iostream-ssl test-iostream-ssl.o -pie ./.libs/libssl_iostream_openssl.so ./.libs/libssl_iostream.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lssl -lcrypto -ldl -Wl,-rpath -Wl,/home/abuild/rpmbuild/BUILD/dovecot-2.3.8/src/lib-ssl-iostream/.libs -Wl,-rpath -Wl,/usr/lib64/dovecot/modules [ 136s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: test-iostream-ssl: hidden symbol `t_str_new' in /tmp/test-iostream-ssl.X2QBZZ.ltrans0.ltrans.o is referenced by DSO [ 136s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: final link failed: bad value [ 136s] collect2: error: ld returned 1 exit status [ 136s] make[3]: *** [Makefile:637: test-iostream-ssl] Error 1 Without changing anything, the build completes, but this is a rare occurrence. Disabling LTO solves the build problem. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1204067] New: [Build 20220915] openQA test fails in grub_test since upgrade of qemu-ovmf-x86_64 from 202008-150300.10.14.1 to 202202-150400.3.3
by bugzilla_noreply＠suse.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1204067 Bug ID: 1204067 Summary: [Build 20220915] openQA test fails in grub_test since upgrade of qemu-ovmf-x86_64 from 202008-150300.10.14.1 to 202202-150400.3.3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2675825/modules/grub _test/steps/15 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: tina.mueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-nvme@uefi fails in [grub_test](https://openqa.opensuse.org/tests/2675825/modules/grub_test/step… ## Test suite description Maintainer: rbrown(a)suse.de; Basic installation test to confirm that installing and booting to an nvme as your root disk works ## Reproducible Fails since (at least) Build [20220915](https://openqa.opensuse.org/tests/2675825) (current job) ## Expected result Last good: [20220914](https://openqa.opensuse.org/tests/2663884) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… We confirmed that the qemu-ovmf-x86_64 upgrade is the culprit, because after downgrading again the test worked as expected. We debugged the test and found out that after the installation in the test, the reboot does show the boot menu of the installation medium again, instead of offering to boot from hard disk, and selecting "Boot from Hard Disk" resulted in showing the same installation medium menu again. Ejecting the CD before reboot resulted in an error message: BdsDxe: failed to load Boot0007 "opensuse-secureboot" from HD(...)/\EFI\opensuse\shim.efi: Not found We also have other tests failing, but in different ways, but this might still be related. The ticket for the mentioned failure can be found here: https://progress.opensuse.org/issues/116704 Our workaround will be to downgrade all openQA workers and add a zypper lock. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1207873] New: kinfocenter in MicroOS Desktop Plasma displays incorrect information
by bugzilla_noreply＠suse.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207873 Bug ID: 1207873 Summary: kinfocenter in MicroOS Desktop Plasma displays incorrect information Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: sfalken(a)cloverleaf-linux.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- As currently installed, when going to the "About" page in kinfocenter/system settings, it displays the openSUSE Geeko logo, and a link to the main openSUSE Website. It should be displaying the MicroOS Logo, and link to the MicroOS Desktop Wiki, as that is where we are keeping the most up-to-date information. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1205135] New: windows:mingw:win{32|64}: Packages that do not use the macros specific to the use of the cmake build system
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1205135 Bug ID: 1205135 Summary: windows:mingw:win{32|64}: Packages that do not use the macros specific to the use of the cmake build system Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: fstrba(a)suse.com Reporter: ralf.habacker(a)freenet.de QA Contact: screening-team-bugs(a)suse.de CC: fridrich.strba(a)bluewin.ch, hib(a)hiberis.nl, mkbosmans(a)gmail.com Found By: --- Blocker: --- As documented at https://en.opensuse.org/Build:projects:windows:mingw#Porting_native_cmake_p… there are specific macros for using the cmake build system %_mingw32_cmake[_build|_install] which are not used by the following packages: ./mingw32-ampl-mp ./mingw32-clucene ./mingw32-cmocka ./mingw32-freeocl ./mingw32-glfw ./mingw32-grantlee ./mingw32-hdf5 ./mingw32-kate4-parts ./mingw32-kdewin ./mingw32-kdewin-tools ./mingw32-ktoblzcheck ./mingw32-libattica ./mingw32-libdbusmenu-qt ./mingw32-libechonest ./mingw32-libftdi ./mingw32-libgit2 ./mingw32-libgraphite2 ./mingw32-libjreen ./mingw32-liblastfm ./mingw32-libmodman ./mingw32-libproxy ./mingw32-libqjson ./mingw32-lucene++ ./mingw32-metis ./mingw32-oce ./mingw32-perfectspot ./mingw32-phonon ./mingw32-qt5keychain ./mingw32-qtkeychain ./mingw32-qtsparkle ./mingw32-qtweetlib ./mingw32-quazip ./mingw32-snoregrowl ./mingw32-snorenotify ./mingw32-taglib ./mingw32-win_iconv ./mingw32-zlib -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1208161] New: Timeout waiting for encrypted disk
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208161 Bug ID: 1208161 Summary: Timeout waiting for encrypted disk Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since openSUSE Tumbleweed 20230209 and kernel 6.1.10-1 I got an additional "sleep" time when booting the system. I suppose the following log entries give a hint on the reason. To my surprise the system nevertheless starts normally afterwards. Feb 11 15:50:14 transformer systemd[1]: dev-disk-by\x2duuid-47c6783a\x2d2b0\x24740\x2abd3\x24f0f43f63d8c.device: Job dev-disk-by\x2duuid-47c6783a\x2d2b0\x24740\x2abd3\x24f0f43f63d8c.device/start timed out. Feb 11 15:50:14 transformer systemd[1]: Timed out waiting for device /dev/disk/by-uuid/47c6783a-2b0$740*bd3$f0f43f63d8c. Feb 11 15:50:14 transformer systemd[1]: Dependency failed for Cryptography Setup for root. Feb 11 15:50:14 transformer systemd[1]: Dependency failed for Local Encrypted Volumes. Feb 11 15:50:14 transformer systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'. Feb 11 15:50:14 transformer systemd[1]: systemd-cryptsetup(a)root.service: Job systemd-cryptsetup(a)root.service/start failed with result 'dependency'. Feb 11 15:50:14 transformer systemd[1]: dev-disk-by\x2duuid-47c6783a\x2d2b0\x24740\x2abd3\x24f0f43f63d8c.device: Job dev-disk-by\x2duuid-47c6783a\x2d2b0\x24740\x2abd3\x24f0f43f63d8c.device/start failed with result 'timeout'. Feb 11 15:50:14 transformer systemd[1]: Reached target Block Device Preparation for /dev/mapper/root. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1197954] New: systemd-cryptsetup: Device root is still in use.
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1197954 Bug ID: 1197954 Summary: systemd-cryptsetup: Device root is still in use. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Starting with the Tumbleweed snapshot installed on March, 29th I got back an old error systemd-cryptsetup: Device root is still in use. systemd-cryptsetup: Failed to deactivate: Device or resource busy which shows up in the journal after switching root. I am not sure, but I believe that the reason for this is systemd[1]: plymouth-start.service: Unit process 394 (plymouthd) remains running after unit stopped. systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of a failed condition check (ConditionPathExists=!/run/plymouth/pid). which shows up in the journal just before the "in use" message. So plymouth didn't stop and the encrypted filesystem couldn't be unmounted. Before the last two snapshots the message looked like this: systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1207852] New: INDI 2.0 breaks Stellarium
by bugzilla_noreply＠suse.com 25 Mar '23

25 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207852 Bug ID: 1207852 Summary: INDI 2.0 breaks Stellarium 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: pstivanin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With the upgrade to INDI 2.0, some breaking changes were introduced (https://github.com/indilib/indi/pull/1764) without being mentioned in the release notes whatsoever. These changes break Stellarium and PHD2, because they can no longer be compiled until their code is updated to match the new INDI format. IMHO, we have the following two options available: * we create a new package, libindi1, and we point both Stellarium and PHD2 to it * we rollback INDI to 1.9.9 and KStars to 3.6.2 (because >=3.6.3 requires INDI 2.0) Any preference? -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1178233] New: zypper up does not report any updates in WSL after longer pause
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1178233 Bug ID: 1178233 Summary: zypper up does not report any updates in WSL after longer pause Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: WSL Assignee: sle-ms(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-c(a)suse.de Found By: --- Blocker: --- I do have WSL images with Leap 15.2 and it seems that zypper doesn't register outdated repodata cache. Let's say that I'd start WSL image (bash session) once per two weeks, and if I simply run "zypper up" after these two weeks zypper reports no update, until I clean repodata I didn't call refresh simply up && clean --all && up and that worked fine. However I'd like to avoid situation when zypper simply reports no update with sporadically WSL use and user gets to believe it. My initial thought it's that this is caused by not having any services running inside the "container", however Ludwig things something might be wrong with the date/time inside the image. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1194723] New: automatically add dkms module after kernel update
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 Bug ID: 1194723 Summary: automatically add dkms module after kernel update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: m.schenker(a)posteo.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi there, for certain scenarios I sometimes rely on kernel modules added via dkms. Initially installing them is as easy as the following. cd module-folder dkms install . From other distributions I am used that the module gets re-added/rebuild during a kernel update. However after a kernel update and reboot on Tumbleweed I just receive a message like the following one. modprobe: FATAL: Module vendor-reset not found in directory /lib/modules/5.16.0-1-default While the module still seems installed. user@computer:~/vendor-reset> sudo dkms install . Error! DKMS tree already contains: vendor-reset-0.1.1 You cannot add the same module/version combo more than once. It is not available to the updated kernel. There were two request for similar problems. 1. https://bugzilla.opensuse.org/show_bug.cgi?id=931175 Which resulted in a `don't care, won't fix 2. https://bugzilla.opensuse.org/show_bug.cgi?id=1184671 Which was ignored. I have not created kernel modules myself, so if there is something that needs to be done to the modules so they themselfs trigger an update I would be glad for a nudge in the right direction. However if there is something I would need to do in Tumbleweed I would be glad for help as well. I still see it as something that needs fixing since other Distributions, Arch, Ubuntu handle this on their own. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1207913] New: wpa_supplicant 2.10-4.2 does not authenticate WPA PEAP MSCHAPv2 connections with no certificate
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207913 Bug ID: 1207913 Summary: wpa_supplicant 2.10-4.2 does not authenticate WPA PEAP MSCHAPv2 connections with no certificate Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: sardone(a)duck.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0 Build Identifier: After updating wpa_supplicant from 2.10-4-1 to 2.10-4-2, a previously working WPA2 Enterprise PEAP MSCHAPv2 (no certificate) connection does not authenticate anymore. Reproducible: Always Steps to Reproduce: 1. Make sure you have wpa_supplicant 2.10-4.1 installed 2. Connect successfully to a WPA2 Enterprise PEAP MSCHAPv2 connection with no certificate (e.g. Fastweb's WOW FI on the Italian market) 3. Update to wpa_supplicant to 2.10-4-2 3. Reboot Actual Results: dmesg | grep -i wlp3s0 [ 7.303932] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0 [ 12.109618] wlp3s0: authenticate with 72:d1:1b:18:68:bc [ 12.109667] wlp3s0: 80 MHz not supported, disabling VHT [ 12.119999] wlp3s0: send auth to 72:d1:1b:18:68:bc (try 1/3) [ 12.127652] wlp3s0: authenticated [ 12.130825] wlp3s0: associate with 72:d1:1b:18:68:bc (try 1/3) [ 12.137145] wlp3s0: RX AssocResp from 72:d1:1b:18:68:bc (capab=0x411 status=0 aid=1) [ 12.150270] wlp3s0: associated [ 14.238946] wlp3s0: deauthenticating from 72:d1:1b:18:68:bc by local choice (Reason: 3=DEAUTH_LEAVING) Expected Results: dmesg | grep -i wlp3s0 [ 7.235464] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0 [ 11.788043] wlp3s0: authenticate with 72:d1:1b:18:68:bc [ 11.788057] wlp3s0: 80 MHz not supported, disabling VHT [ 11.799552] wlp3s0: send auth to 72:d1:1b:18:68:bc (try 1/3) [ 11.824332] wlp3s0: authenticated [ 11.826138] wlp3s0: associate with 72:d1:1b:18:68:bc (try 1/3) [ 11.830107] wlp3s0: RX AssocResp from 72:d1:1b:18:68:bc (capab=0x411 status=0 aid=1) [ 11.836770] wlp3s0: associated [ 12.639114] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready Lenovo Thinkpad T480 -- You are receiving this mail because: You are on the CC list for the bug.

1 14