February 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1180615] New: [Package request] asciidoctor-pdf extension
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180615 Bug ID: 1180615 Summary: [Package request] asciidoctor-pdf extension Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: sb56637(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, would it be possible to package the asciidoctor-pdf extension to complement the main asciidoctor package? - https://build.opensuse.org/package/show/openSUSE%3AFactory/rubygem-asciidoc… - https://github.com/asciidoctor/asciidoctor-pdf/releases Thanks a lot! -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1180681] New: perf does not resolve plt symbols from libstdc++ right
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1180681 Bug ID: 1180681 Summary: perf does not resolve plt symbols from libstdc++ right 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: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de CC: martin.liska(a)suse.com, matz(a)suse.com, mliska(a)suse.cz, rguenther(a)suse.com, tonyj(a)suse.com Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1180610 +++ There is a problem with *@plt symbols in some libraries, they are unresolved by perf (memcmp@plt in this case): > 0.26% main2 /usr/lib64/libstdc++.so.6.0.28 0xa51a0 l [.] 0x00000000000a51a0 On the other hand, plt symbols in other libraries are fine (memset@plt in this case): > 0.17% main2 /usr/lib64/libantlr4-runtime.so.4.8 0x4ed10 l [.] memset@plt Dump of memcmp's nth .plt.rela entry: /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10 entry=10 /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10 entry=10 The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070 (perf's computed) = 0x4130. The problem is perf assumes nth entry of .plt.rela to correspond to nth function in .plt, but memcmp is in .plt.sec in libstdc++.so: > Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries: > Offset Info Type Symbol's Value Symbol's Name + Addend > ... > 00000000001dc838 0000007800000007 R_X86_64_JUMP_SLOT 0000000000000000 memcmp(a)GLIBC_2.2.5 + 0 See: https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056… It takes symbol index from sym.r_info. Then it resolves its name from .dynsym, appending @plt to it. Then this name is added to symbol table along with address which is computed as .rela.plt index multiplied by entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on x86_64 too). And from this comes (almost) the offset above: > $ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? ' > 12 .plt 00003fb0 000000000009e020 000000000009e020 0009e020 2**4 > 14 .plt.sec 00003fa0 00000000000a2160 00000000000a2160 000a2160 2**4 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry (header). Now, what is .plt.sec? And how should perf find out whether to consider .plt or .plt.sec? Or generally, how to properly find an address of *@plt like memcmp@plt above? -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1177956] New: [Build 20201020] openQA test fails in await_install: grub2-install fails for i386-pc
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1177956 Bug ID: 1177956 Summary: [Build 20201020] openQA test fails in await_install: grub2-install fails for i386-pc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1443345/modules/awai t_install/steps/9 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: mchang(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: --- With this fairly standard and simple ext4 setup (see https://openqa.opensuse.org/tests/1443345#step/partitioning_filesystem/9 for the YaST view), the installation fails with grub2-install complaining: "failed to get canonical path of `/boot/grub2/i386-pc'." This failure also happens in lvm-encrypt-separate-boot and autoyast_multi_btrfs tests, but doesn't appear to affect standard cryptlvm or btrfs setups. My guess ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-ext4_textmode@64bit fails in [await_install](https://openqa.opensuse.org/tests/1443345/modules/await_inst… ## Test suite description Mantainer: jeriveramoya Test selection of file system ext4 for / partition in textmode for openSUSE distributions ## Reproducible Fails since (at least) Build [20201020](https://openqa.opensuse.org/tests/1443345) (current job) ## Expected result Last good: [20201019](https://openqa.opensuse.org/tests/1441513) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1177957] New: [Build 20201020] openQA test fails in await_install: grub2-install fails for i386-pc
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1177957 Bug ID: 1177957 Summary: [Build 20201020] openQA test fails in await_install: grub2-install fails for i386-pc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1443345/modules/awai t_install/steps/9 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: mchang(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: --- With this fairly standard and simple ext4 setup (see https://openqa.opensuse.org/tests/1443345#step/partitioning_filesystem/9 for the YaST view), the installation fails with grub2-install complaining: "failed to get canonical path of `/boot/grub2/i386-pc'." This failure also happens in lvm-encrypt-separate-boot and autoyast_multi_btrfs tests, but doesn't appear to affect standard cryptlvm or btrfs setups. My guess ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-ext4_textmode@64bit fails in [await_install](https://openqa.opensuse.org/tests/1443345/modules/await_inst… ## Test suite description Mantainer: jeriveramoya Test selection of file system ext4 for / partition in textmode for openSUSE distributions ## Reproducible Fails since (at least) Build [20201020](https://openqa.opensuse.org/tests/1443345) (current job) ## Expected result Last good: [20201019](https://openqa.opensuse.org/tests/1441513) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1195769] New: external mouse gets deactivated if laptop on battery
by bugzilla_noreply＠suse.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195769 Bug ID: 1195769 Summary: external mouse gets deactivated if laptop on battery Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: kadlecf(a)fzu.cz QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- In the latest Tumbleweed on an Asus ZenBook laptop, an external USB mouse works only if attached on booting with power cord plugged. Once I unplug the machine from power and stay on battery, the mouse gets deactivated, and it stays inactive even if I disconnect and reconnect it, till a re-boot with power cord. Before some recent updates, the mouse used to work always, on battery or on external power. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1195033] New: Mailman3 package is empty
by bugzilla_noreply＠suse.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195033 Bug ID: 1195033 Summary: Mailman3 package is empty Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: ae(a)ae-online.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The Mailman 3 Package is empty, i miss the file for etc, mailman.service. In the Web package python3-mailman-web the Apache files are missing. Informationen zu Paket python3-mailman: --------------------------------------- Repository : Main Repository Name : python3-mailman Version : 3.3.0-bp153.2.9 Arch : noarch Anbieter : openSUSE Installierte Gr��e : 7,2 MiB Installiert : Ja Status : aktuell Quellpaket : python-mailman-3.3.0-bp153.2.9.src Zusammenfassung : Mailman -- the GNU mailing list manager Checkout this Package: mailman3-3.3.5-lp153.63.1.noarch.rpm from mailman3-3.3.5-lp153.63.1.noarch.rpm -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1183962] New: System freeze when wake up from sleep
by bugzilla_noreply＠suse.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1183962 Bug ID: 1183962 Summary: System freeze when wake up from sleep 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: cosmin.tanczel(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Machine: Laptop E14 Gen2 When computer wakes up from sleep the whole system freeze. I tried adding snd_hda_codec_hdmi.enable_silent_stream=0 to kernel boot parameters as described in #1180651, but still no luck. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1180884] New: Powerdevil skipping reload action as profile has not changed
by bugzilla_noreply＠suse.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180884 Bug ID: 1180884 Summary: Powerdevil skipping reload action as profile has not changed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: cosmin.tanczel(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have configured powerdevil to change brightness level while on battery. When I remove the power adapter, the battery icons becomes visible in Systray, meaning the system detected that the power cable was removed. But when I hover the mouse on the battery icon the info I got is that the power adapter is still plugged in. Also, I have no message in /var/log/message when I remove the power adapter. When I plug in the power adapter, the battery icon gets hidden, meaning the system recognized that the power adapter was plugged in and I also got the following messages in /var/log/messages: 2021-01-13T14:34:30.349152+02:00 localhost org_kde_powerdevil[2135]: powerdevil: Can't contact ck 2021-01-13T14:34:30.349227+02:00 localhost org_kde_powerdevil[2135]: powerdevil: Currently using activity "b1627b23-a919-40b9-8110-0dc6c8742ebd" 2021-01-13T14:34:30.349250+02:00 localhost org_kde_powerdevil[2135]: powerdevil: () () 2021-01-13T14:34:30.349268+02:00 localhost org_kde_powerdevil[2135]: powerdevil: () () 2021-01-13T14:34:30.349286+02:00 localhost org_kde_powerdevil[2135]: powerdevil: Loading profile for plugged AC 2021-01-13T14:34:30.349310+02:00 localhost org_kde_powerdevil[2135]: powerdevil: Activity is not forcing a profile 2021-01-13T14:34:30.349331+02:00 localhost org_kde_powerdevil[2135]: powerdevil: Skipping action reload routine as profile has not changed 2021-01-13T14:34:35.424074+02:00 localhost kernel: [ 3374.931800] ucsi_acpi USBC000:00: UCSI_GET_PDOS returned 0 bytes Machine: Lenovo ThinkPad E14 System: Kernel: 5.3.18-40-default x86_64 bits: 64 compiler: gcc v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-5.3.18-40-default root=UUID=c7a347e6-8c45-438a-a0b2-11eaaa6dd968 splash=silent quiet mitigations=off Desktop: KDE Plasma 5.18.6 tk: Qt 5.12.7 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.3 Alpha Machine: Type: Laptop System: LENOVO product: 20TA002GRI v: ThinkPad E14 Gen 2 serial: <filter> Chassis: type: 10 serial: <filter> Mobo: LENOVO model: 20TA002GRI serial: <filter> UEFI: LENOVO v: R1EET31W(1.31 ) date: 12/01/2020 Battery: ID-1: BAT0 charge: 45.6 Wh condition: 47.0/45.0 Wh (105%) volts: 12.4/11.1 model: Sunwoda 5B10X025 type: Li-poly serial: <filter> status: Unknown cycles: 4 Device-1: hidpp_battery_0 model: Logitech Marathon Mouse/Performance Plus M705 serial: <filter> charge: 55% (should be ignored) rechargeable: yes status: Discharging -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1171115] New: PERMISSION_SECURITY="secure local" - KDE hangs on logout when choosing "shut down"
by bugzilla_noreply＠novell.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1171115 Bug ID: 1171115 Summary: PERMISSION_SECURITY="secure local" - KDE hangs on logout when choosing "shut down" 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: suse-beta(a)cboltz.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- PERMISSION_SECURITY="secure local" in /etc/sysconfig/security works for most things even in desktop usage, but KDE hangs on logout when choosing "shut down" (german "Herunterfahren"). The fix for this are the following two entries in /etc/polkit-default-privs.local: org.freedesktop.login1.power-off auth_admin_keep:auth_admin_keep:yes org.freedesktop.login1.reboot auth_admin_keep:auth_admin_keep:yes After running /sbin/set_polkit_default_privs I can shut down my computer from the KDE logout dialog again. Please consider to add these two for polkit-default-privs.restrictive. (Without these two lines, the workaround is to logout, and then shutdown from sddm ;-) Sidenotes: - The default in restrictive is "auth_admin_keep", and I guess it's too late in the logout process to show a password dialog, so the logout simply hangs. - The only other local rules I need to live with "permissions.secure" are org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:no:yes org.freedesktop.NetworkManager.network-control no:no:yes # mount / umount USB stick org.freedesktop.udisks2.filesystem-mount auth_admin:auth_admin:yes org.freedesktop.udisks2.eject-media auth_admin:auth_admin:yes -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1118099] New: aws-cli-1.16.48-1.1.noarch requires python3-colorama <= 0.3.9, but this requirement cannot be provided
by bugzilla_noreply＠novell.com 01 Nov '22

01 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1118099 Bug ID: 1118099 Summary: aws-cli-1.16.48-1.1.noarch requires python3-colorama <= 0.3.9, but this requirement cannot be provided Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Cloud:Tools Assignee: public-cloud-maintainers(a)suse.de Reporter: rombert(a)apache.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- It seems that the aws-cli / python3-colorama dance is up again :-) Problem: aws-cli-1.16.48-1.1.noarch requires python3-colorama <= 0.3.9, but this requirement cannot be provided deleted providers: python3-colorama-0.3.9-1.3.noarch Solution 1: deinstallation of aws-cli-1.16.48-1.1.noarch Solution 2: keep obsolete python3-colorama-0.3.9-1.3.noarch Solution 3: break aws-cli-1.16.48-1.1.noarch by ignoring some of its dependencies -- You are receiving this mail because: You are on the CC list for the bug.

2 4