February 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1052740] New: convert X keyboards into kbd and set unicode console font for languages with non-Latin alphabets
by bugzilla_noreply＠novell.com 22 Nov '22

22 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1052740 Bug ID: 1052740 Summary: convert X keyboards into kbd and set unicode console font for languages with non-Latin alphabets Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: opensuse.lietuviu.kalba(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Now openSUSE for languages with Latin alphabets use converted keyboard layouts from X into kbd, also use unicode console font (as converted layouts supports it). Remaining task is to do same transition for non-Latin console keyboard layouts and set appropriate console font. Perhaps we should preconfigure option to switch between native and US QWERTY in console for these non-Latin languages and keyboard layouts. As noted in https://bugzilla.suse.com/show_bug.cgi?id=942896#c70 , As noted in https://bugzilla.suse.com/show_bug.cgi?id=942896#c69 Greek seems not have converted console keyboard layout from X into kbd. For Greek perhaps we can use eurlatgr console font (like for Latin alphabets) All Cyrillic layouts now use UniCyr_8x16.psf font, but this font seems to be compatible with cp866, cp1251, iso8859-5 and koi8-r (according http://www.tldp.org/HOWTO/Belarusian-HOWTO/x28.html) and not compatible with unicode per se. But openSUSE seems don't provide converted layouts for Russian, Ukrainian, Serbian, Bulgarian, Tajik. For Cyrillic alphabets we should use LatArCyrHeb-14, LatArCyrHeb-16+ or LatArCyrHeb-16 console font, that support unicode. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1178338] New: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1178338 Bug ID: 1178338 Summary: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jslaby(a)suse.com QA Contact: jsrain(a)suse.com CC: glin(a)suse.com, jens(a)krieger-juhnke.de, jlee(a)suse.com, jslaby(a)suse.com, mbenes(a)suse.com, mchang(a)suse.com, tiwai(a)suse.com Blocks: 1172292 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1172292 +++ On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium. ===================== Could x86_64 installation media contain this file on the installation media in the EFI partition: EFI/boot/bootia32.efi ? It should be copied from /usr/share/efi/i586/grub.efi from grub2-i386-efi package, the same as is EFI/boot/bootx64.efi from grub2-x86_64-efi. This will add support for 32bit FW with 64-bit CPUs. It used to work fine when I tried last time on such a machine. I had EFI/boot/bootia32.efi on an USB stick and loaded config from a DVD. Then continued the installation the usual way. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1196085] New: Calling external programs from YaST fragile with full paths
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1196085 Bug ID: 1196085 Summary: Calling external programs from YaST fragile with full paths Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: shundhammer(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- After a security audit some years ago we changed all calls to external programs in YaST to use the full path, i.e. from "foobar" to "/sbin/foobar". The rationale was that this would prevent a potential attacker from manipulating the $PATH to include some directory containing a malicious version of the program, i.e. a "/my/hacked/foobar" with $PATH also containing "/my/hacked". With the transition from /bin to /usr/bin and /sbin to /usr/sbin that turned out to be a bad idea since now we need to update those full paths in the YaST code whenever any of those binaries makes that transition, i.e. it's moved from /sbin to /usr/sbin. Worse, if the transition is done in one supported product like Tumbleweed or Leap, yet another one like SLES still uses the old path, we would have to maintain different paths (and not forget to adapt them when that other product makes that transition as well); or we would need to create our own fallback logic to search all the possible paths which one to invoke. But that fallback logic exists, and if handled correctly, it's just as secure as using a full path; but more flexible and not fragile against tools being moved from one system location to another: It's $PATH. We need to make sure that $PATH only contains directories that are not writeable by non-privileged users, and of course not "." (the current directory) or any path that starts with "."; e.g. export PATH="/usr/sbin:/usr/bin:/sbin:/bin" And we already do that in YaST code. So we should migrate calls to external programs back to calling them without the full path and use our secure $PATH instead. For a more in-depth discussion, see also https://github.com/yast/yast-iscsi-client/issues/111 -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1190524] New: baloo keeps my laptop hot
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190524 Bug ID: 1190524 Summary: baloo keeps my laptop hot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: saba(a)sabanet.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Build Identifier: Baloo file indexer is running since days at 100% CPU and I'm not sure if it will ever finish. Reproducible: Always Steps to Reproduce: 1. Installed Tumbleweed from scratch on a brand new notebook (LG gram 2021 i7-1165G7) 2. Copied my home directory from my old laptop (approx. 700GB of data) 3. Watch baloo running at 100% CPU for days/weeks Actual Results: Baloo seems to get slower and slower: gram:~> balooctl status ; sleep 3600 ; balooctl status Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,585 Files waiting for content indexing: 160,364 Files failed to index: 0 Current size of index is 71.48 GiB Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,065 Files waiting for content indexing: 159,844 Files failed to index: 0 Current size of index is 71.48 GiB This means in one hour the number of files waiting to be indexed decreased only by 520 (which would mean 7 seconds to add a single file to the index). At this speed, I'd need to wait another 300 hours before the indexer completed its job. Expected Results: Indexing should complete *much* faster. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1193838] New: LXC /etc/systemd/system.conf is marked executable??
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193838 Bug ID: 1193838 Summary: LXC /etc/systemd/system.conf is marked executable?? 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: dev.dorrejo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, i am practicing LXC, and have the next issue: zypper in --no-recommends lxc Configuration file /etc/systemd/system.conf is marked executable. Please remove executable permission bits. Proceeding anyway. ll /etc/systemd/system.conf -rw-r--r-- 1 root root 1993 Nov 24 19:14 /etc/systemd/system.conf getfacl /etc/systemd/system.conf # file: etc/systemd/system.conf # owner: root # group: root user::rw- group::r-- other::r-- Environment: - VMs using tumbleweed up-to-date - Disabled AppArmor - cgroup systemd.unified_cgroup_hierarchy=0 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1196335] New: [Build C.520.1] kdump failed to start: device or resource busy
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196335 Bug ID: 1196335 Summary: [Build C.520.1] kdump failed to start: device or resource busy Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://openqa.opensuse.org/tests/2204439/modules/jour nal_check/steps/22 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Staging:C-Staging-DVD-x86_64-container-host-microos@64bit-2G-HD40G fails in [journal_check](https://openqa.opensuse.org/tests/2204439/modules/journal_ch… This error appears sporadic, rerunning the test might or might not show the same error: Feb 23 09:28:47.073824 localhost.localdomain systemd[1]: Failed to start Load kdump kernel and initrd. Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: kexec_load failed: Device or resource busy Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: entry = 0x7f554760 flags = 0x3e0001 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: nr_segments = 6 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].buf = 0x7f8e0c0ae010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].bufsz = 0x13fbbb4 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].mem = 0x7a804000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].memsz = 0x13fc000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].buf = 0x7f8e0d4ade10 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].bufsz = 0xb0bdb0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].mem = 0x7bc00000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].memsz = 0x37b4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].buf = 0x5649202ba900 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].bufsz = 0x3fc7 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].mem = 0x7f550000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].buf = 0x5649202b36c0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].bufsz = 0x70e0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].mem = 0x7f554000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].memsz = 0x9000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].buf = 0x5649202b1860 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].bufsz = 0x400 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].mem = 0x7f55d000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].buf = 0x7f8e0c00f010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].bufsz = 0x9ec00 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].mem = 0x7f561000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].memsz = 0x9f000 Feb 23 09:28:47.071528 localhost.localdomain kdump[991]: FAILED to load kdump kernel: /sbin/kexec -p /boot/vmlinuz-5.16.10-5-default --append=" rd.timeout=60 rd.retry=45 console=ttyS0 console=tty kernel.softlockup_panic=1 swapaccount=1 quiet security=selinux selinux=1 enforcing=1 mitigations=auto elevator=deadline sysrq=yes reset_devices acpi_no_memhotplug cgroup_disable=memory nokaslr numa=off irqpoll nr_cpus=1 root=kdump rootflags=bind rd.udev.children-max=8 disable_cpu_apicid=0 panic=1" --initrd=/boot/initrd-kdump , Result: kexec_load failed: Device or resource busy entry = 0x7f554760 flags = 0x3e0001 nr_segments = 6 segment[0].buf = 0x7f8e0c0ae010 segment[0].bufsz = 0x13fbbb4 segment[0].mem = 0x7a804000 segment[0].memsz = 0x13fc000 segment[1].buf = 0x7f8e0d4ade10 segment[1].bufsz = 0xb0bdb0 segment[1].mem = 0x7bc00000 segment[1].memsz = 0x37b4000 segment[2].buf = 0x5649202ba900 segment[2].bufsz = 0x3fc7 segment[2].mem = 0x7f550000 segment[2].memsz = 0x4000 segment[3].buf = 0x5649202b36c0 segment[3].bufsz = 0x70e0 segment[3].mem = 0x7f554 Feb 23 09:28:47.073246 localhost.localdomain systemd[1]: kdump.service: Main process exited, code=exited, status=255/EXCEPTION Feb 23 09:28:47.073509 localhost.localdomain systemd[1]: kdump.service: Failed with result 'exit-code'. ## Test suite description ## Reproducible Fails since (at least) Build [C.520.1](https://openqa.opensuse.org/tests/2204217) ## Expected result Last good: [C.519.7](https://openqa.opensuse.org/tests/2203451) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1082318] New: Packages must not mark license files as %doc
by bugzilla_noreply＠novell.com 21 Nov '22

21 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1082318 Bug ID: 1082318 Summary: Packages must not mark license files as %doc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Certain licenses require that license files must be shipped together with the binaries in all cases. By using the %doc marker, this is no longer guaranteed (e.g. by enabling excludedocs). Thus it is important that for such cases, %license is used instead of %doc. The effect is that the file is always installed, stored in a different directory (/usr/share/licenses/<pkg>/) and can be queried using rpm (e.g. "rpm -qL kernel-firmware"). -- You are receiving this mail because: You are on the CC list for the bug.

2 249

[Bug 1125418] New: GCC 9: xtrabackup build fails
by bugzilla_noreply＠novell.com 20 Nov '22

20 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1125418 Bug ID: 1125418 Summary: GCC 9: xtrabackup 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/build/openSUSE:Factory:Staging:Gcc7/standard/x86… with: [ 471s] inlined from 'virtual String* Item_func_format::val_str_ascii(String*)' at /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/sql/item_strfunc.cc:3214:13: [ 471s] /usr/include/bits/string_fortified.h:34:33: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] [ 471s] 34 | return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); [ 471s] | ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [ 471s] [ 80%] Building CXX object sql/CMakeFiles/sql.dir/item_sum.cc.o -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1115455] New: rkhunter: migrate from cron to systemd timers
by bugzilla_noreply＠novell.com 20 Nov '22

20 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1115455 Bug ID: 1115455 Summary: rkhunter: migrate from cron to systemd timers Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: kstreitova(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kstreitova(a)suse.com Found By: --- Blocker: --- This bug is part of TRACKERBUG bug#1115430. Based on fate#323635 (Reduce usage of cron package in favor of systemd timers) we would like to minimize the number of packages that use cron in favour of systemd timers. It seems that your package uses cron. Please take a look at it and evaluate if it's possible to migrate your package to use systemd timers without impacting behaviour. If it's not possible, please write down the reason. Please note that by default, services are not enabled when the package is installed. You probably want your service to be enabled by default so you should create a submit request on systemd-presets-branding-openSUSE package, modifying default-openSUSE.preset file by adding "enable your_service_name.service". -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1115430] New: [TRACKERBUG-OPENSUSE] FATE#323635: Reduce usage of cron in favour of systemd timers
by bugzilla_noreply＠novell.com 20 Nov '22

20 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1115430 Bug ID: 1115430 Summary: [TRACKERBUG-OPENSUSE] FATE#323635: Reduce usage of cron in favour of systemd timers Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: kstreitova(a)suse.com Reporter: kstreitova(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is a tracker bug for fate#323635 (Reduce usage of cron package in favor of systemd timers). It tracks openSUSE packages only (for SLE packages see bug#1115399). The goal is to minimize the number of openSUSE:Factory packages that use cron in favour of systemd timers. See dependent bugs for more information about particular packages that should be migrated. -- You are receiving this mail because: You are on the CC list for the bug.

2 19