September 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1213796] New: java-20-openjdk fails to compile in 2034
by bugzilla_noreply＠suse.com 04 Dec '23

04 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1213796 Bug ID: 1213796 Summary: java-20-openjdk fails to compile in 2034 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Java Assignee: java-maintainers(a)suse.de Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fstrba(a)suse.com Target Milestone: --- Found By: --- Blocker: --- While working on reproducible builds for openSUSE, I found that our java-20-openjdk package fails to compile in 2034 to reproduce: osc co openSUSE:Factory/java-20-openjdk && cd $_ osc build --clean --noservice -j1 --vm-type=kvm \ --build-opt=--vm-custom-opt="-rtc base=2034-02-02T00:00:00" \ standard x86_64 [ 284s] /usr/lib64/jvm/java/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/configure-support/classes.jsa -Xshare:auto -cp /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/buildtools/jdk_tools_classes build.tools.generatecharacter.CharacterName /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/src/java.base/share/data/unicodedata/UnicodeData.txt /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/jdk/modules/java.base/java/lang/uniName.dat [ 284s] /usr/bin/rm -f /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/jdk/modules/java.base/java/util/currency.data [ 284s] /usr/lib64/jvm/java/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/configure-support/classes.jsa -Xshare:auto -cp /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/buildtools/jdk_tools_classes build.tools.generatecurrencydata.GenerateCurrencyData -o /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/jdk/modules/java.base/java/util/currency.data.tmp -i /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/src/java.base/share/data/currency/CurrencyData.properties [ 285s] Error: time is more than 10 years from present: 1672527600000 [ 285s] java.lang.RuntimeException: time is more than 10 years from present: 1672527600000 [ 285s] at build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:315) [ 285s] at build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:254) [ 285s] at build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:185) [ 285s] gmake[3]: *** [Gendata.gmk:55: /home/abuild/rpmbuild/BUILD/jdk20u-jdk-20.0.1-9/build/jdk/modules/java.base/java/util/currency.data] Error 1 [ 285s] gmake[2]: *** [make/Main.gmk:147: java.base-gendata] Error 2 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1215179] New: /run/lock no longer belongs to the "lock" group; it is now in "root"
by bugzilla_noreply＠suse.com 30 Nov '23

30 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1215179 Bug ID: 1215179 Summary: /run/lock no longer belongs to the "lock" group; it is now in "root" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: David(a)WalkerStreet.info QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Sometime in the past few weeks, the ownership of /var/lock in Tumbleweed changed from root:lock to root:root, breaking OpenHAB3's ability to create lock files within that directory, unless it's given membership in the root group by adding "SupplementaryGroups=root" in its systemd .service configuration (which isn't the best security strategy). This problem is very similar to bug #552095, which was reported nearly 14 years ago and later resolved, although in a way that doesn't apply to my use case. What this change deliberate? If not, could it be reversed? If it can't be reversed, suggestions for a workaround would be appreciated. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1212958] New: evolution hogging CP?U
by bugzilla_noreply＠suse.com 27 Nov '23

27 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1212958 Bug ID: 1212958 Summary: evolution hogging CP?U Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When evolution is open fan keeps spinning. It order of magnitude more cpu time than 3 browsers each with number of tabs open together. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1215364] New: makedumpfile update for Linux 6.6 kernel using radix mm
by bugzilla_noreply＠suse.com 27 Nov '23

27 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1215364 Bug ID: 1215364 Summary: makedumpfile update for Linux 6.6 kernel using radix mm Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: PowerPC-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Since commit 368a0590d954: (powerpc/book3s64/vmemmap: switch radix to use a different vmemmap handling function) makedumpfile is not compatible with kernels using radix mm. Makedumpfile should be updated when upstream implements a fix. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1214249] New: rsync crashes when built with glibc-2.38
by bugzilla_noreply＠suse.com 23 Nov '23

23 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1214249 Bug ID: 1214249 Summary: rsync crashes when built with glibc-2.38 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: david.anes(a)suse.com Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de CC: pmonrealgonzalez(a)suse.com, schwab(a)suse.com Target Milestone: --- Found By: --- Blocker: --- rsync crashes in vim-plugins' build: https://build.opensuse.org/package/live_build_log/editors/vim-plugins/openS… I believe it's due to glibc-2.38 update. If I update glibc to 2.38 only, rsync-3.2.7-3.1 does not crash. As soon as I update to rsync-3.2.7-3.2 (I believe the one rebuilt against this very new glibc), I see: $ rsync -FFXHav '--filter=merge global-rsync-filter' Align-37-43/ xxx sending incremental file list *** buffer overflow detected ***: terminated rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(231) [Receiver=3.2.7] Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen]) gdb says: > #3 0x00007f2a31226917 in __GI_abort () at abort.c:79 > #4 0x00007f2a312277e3 in __libc_message (fmt=fmt@entry=0x7f2a313b030c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150 > #5 0x00007f2a31327bdb in __GI___fortify_fail (msg=msg@entry=0x7f2a313b02f3 "buffer overflow detected") at fortify_fail.c:24 > #6 0x00007f2a31327506 in __GI___chk_fail () at chk_fail.c:28 > #7 0x00007f2a31329279 in __strlcpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at strlcpy_chk.c:28 > 27 if (__glibc_unlikely (s1len < n)) > 28 __chk_fail (); > #8 0x0000559d0acf778a in strlcpy (__n=4096, __src=0x7ffece39ae20 "xslaby/pokus/Align-37-43/", __dest=0x559d0ad61886 <dirbuf.lto_priv+6> "") > at /usr/include/bits/string_fortified.h:156 > 156 return __strlcpy_chk (__dest, __src, __n, __glibc_objsize (__dest)); How does it come __glibc_objsize(dirbuf.lto_priv+6) is less than 4096? > #9 setup_merge_file (mergelist_num=mergelist_num@entry=0, ex=ex@entry=0x559d0bf84b40, lp=lp@entry=0x559d0bf84b90) at /usr/src/debug/rsync-3.2.7/exclude.c:737 737 strlcpy(y, save, MAXPATHLEN); > #10 0x0000559d0acf7d94 in push_local_filters (dir=dir@entry=0x7ffece39c000 ".", dirlen=dirlen@entry=1) at /usr/src/debug/rsync-3.2.7/exclude.c:806 > #11 0x0000559d0acf8259 in change_local_filter_dir (dname=0x7ffece39c000 ".", dlen=1, dir_depth=0) at /usr/src/debug/rsync-3.2.7/exclude.c:899 > #12 0x0000559d0acef91c in send_file_list (f=4, argc=0, argv=0x559d0bf84898) at /usr/src/debug/rsync-3.2.7/flist.c:2453 > #13 0x0000559d0ad07d4b in client_run (f_in=f_in@entry=5, f_out=f_out@entry=4, pid=pid@entry=6659, argc=argc@entry=1, argv=argv@entry=0x559d0bf84890) > at /usr/src/debug/rsync-3.2.7/main.c:1315 > #14 0x0000559d0ace2bdb in start_client (argv=0x559d0bf84890, argc=1) at /usr/src/debug/rsync-3.2.7/main.c:1613 > #15 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/rsync-3.2.7/main.c:1873 -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1214845] New: libvirtError: Unable to find 'memory' cgroups controller mount
by bugzilla_noreply＠suse.com 21 Nov '23

21 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1214845 Bug ID: 1214845 Summary: libvirtError: Unable to find 'memory' cgroups controller mount Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: chrisvte(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After I updated to kernel 6.4.11-1-default, every time I booted a LXC I was getting this error: “libvirtError: internal error: Unable to find ‘memory’ cgroups controller mount” I replicated the installation in a minipc (Intel N5105) and it worked perfectly, so I did a new installation in the first computer (AMD Ryzen 5600G) and, again, I got the same error of the beginning. I tried in other two computers (AMD Ryzen 5900X and Intel i5-1135G7) and I got the same error. If I added “systemd.unified_cgroup_hierarchy=0” to the boot line, the error went away, but it was really unstable (containers stopped working after a while). I usually install the tools of virtualization through Yast (KVM Server and KVM tools). After that I install a few more packages: libvirt-client, libvirt-daemon, libvirt-daemon-lxc, libvirt-daemon-driver-lxc, system-user-libvirt-dbus. Finally, I add the user to groups libvirt, qemu and kvm. Reboot and run. The details of the error using Virt-Manager: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn ret = fn(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/object/domain.py", line 1425, in startup self._backend.create() File "/usr/lib64/python3.11/site-packages/libvirt.py", line 1373, in create raise libvirtError('virDomainCreate() failed') libvirt.libvirtError: Unable to find 'memory' cgroups controller mount And using command line: # virsh -d 0 -c lxc:// start 101-PiHole start: domain(optdata): 101-PiHole start: found option <domain>: 101-PiHole start: <domain> trying as domain NAME error: Failed to start domain '101-PiHole' error: internal error: Unable to find 'memory' cgroups controller mount About the system: # mount | grep cgroup cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) # uname -a Linux 6.4.11-1-default #1 SMP PREEMPT_DYNAMIC Thu Aug 17 04:57:43 UTC 2023 (2a5b3f6) x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1214403] New: Bluetooth stack will often choose a really poor codec (mono, audibly low bitrate) when on different distribution it was fine
by bugzilla_noreply＠suse.com 21 Nov '23

21 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1214403 Bug ID: 1214403 Summary: Bluetooth stack will often choose a really poor codec (mono, audibly low bitrate) when on different distribution it was fine Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: el(a)horse64.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- OpenSUSE's bluetooth and audio stack will often choose a really poor codec (mono, audibly low bitrate) with my Anker Soundcore Life Q30 headphones when on different distribution it was fine. Also, randomly shooting down pulseaudio and bluetoothd and disconnecting and reconnecting will fix it at some point, but possibly lead to other issues down the line like things no longer properly reconnecting on their own, it's a total mess. Since this worked on a different Linux distribution with the same hardware, this seems to be some sort of problem specifically with how the bluetooth and audio stack is configured on OpenSUSE and not e.g. a hardware or radio interference problem. I'm seeing this on the GNOME desktop, which I also used previously with the other distribution. Also, switching through all codec choices in pavucontrol doesn't fix it, which makes this even more annoying. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1213608] New: "./Inkscape-0e150ed-x86_64.AppImage --appimage-mount" behaves strangely
by bugzilla_noreply＠suse.com 20 Nov '23

20 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1213608 Bug ID: 1213608 Summary: "./Inkscape-0e150ed-x86_64.AppImage --appimage-mount" behaves strangely Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Trying the new Inkscape 1.3 as appimage, I used "./Inkscape-0e150ed-x86_64.AppImage --appimage-mount" to mount the image as root, and that seems to succeed with message "/tmp/.mount_InkscaYEqRgu". However when I try to access that directory from another terminal I only get "permission denied, even for "ls -d": > ll /tmp/.mount_InkscaYEqRgu ls: cannot access '/tmp/.mount_InkscaYEqRgu': Permission denied > ll -d /tmp/.mount_InkscaYEqRgu ls: cannot access '/tmp/.mount_InkscaYEqRgu': Permission denied Oddly, the directory exists, because I can access it as root: # ll /tmp/.mount_InkscaYEqRgu insgesamt 100 -rwxr-xr-x 1 root root 3075 21. Jul 14:26 AppRun -rw-r--r-- 1 root root 40270 21. Jul 14:27 .DirIcon drwxr-xr-x 5 root root 0 26. Mai 16:05 etc drwxr-xr-x 4 root root 0 8. Jul 2021 lib drwxr-xr-x 2 root root 0 21. Jul 14:27 lib64 -rw-r--r-- 1 root root 19274 21. Jul 14:27 org.inkscape.Inkscape.desktop -rw-r--r-- 1 root root 40270 21. Jul 14:26 org.inkscape.Inkscape.png drwxr-xr-x 6 root root 0 8. Jul 2021 usr The problem seems to be this (from stace): statx(AT_FDCWD, "/tmp/.mount_InkscaYEqRgu", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, 0x7fff110a3fb0) = -1 EACCES (Permission denied) When trying to use the appimage as non-root, it won't work either: > ./Inkscape-0e150ed-x86_64.AppImage fuse: failed to exec fusermount: Permission denied Cannot mount AppImage, please check your FUSE setup. You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information open dir error: No such file or directory -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1214192] New: totem DVD source is required to play but is not installed
by bugzilla_noreply＠suse.com 20 Nov '23

20 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1214192 Bug ID: 1214192 Summary: totem DVD source is required to play but is not installed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: batpul(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- On 15.5 totem says it cannot play DVDs: "DVD source is required to play but is not installed" and it offers to install additional software which then fails. This is now installed: libdvdcss2-1.4.3+3-lp155.10.1.x86_64 libdvdnav4-6.1.1-bp155.2.13.x86_64 libdvdread4-6.0.0-150000.3.2.1.x86_64 libtotem-plparser-mini18-3.26.6-150400.2.9.x86_64 libtotem-plparser18-3.26.6-150400.2.9.x86_64 totem-3.38.2-150400.2.12.x86_64 totem-lang-3.38.2-150400.2.12.noarch totem-pl-parser-3.26.6-150400.2.9.x86_64 totem-pl-parser-lang-3.26.6-150400.2.9.noarch totem-plugins-3.38.2-150400.2.12.x86_64 PackageKit-gstreamer-plugin-1.2.4-150400.3.6.1.x86_64 gstreamer-1.20-plugin-openh264-1.20.3-1.sle150500.2.x86_64 gstreamer-1.22.0-150500.3.2.3.x86_64 gstreamer-lang-1.22.0-150500.3.2.3.noarch gstreamer-libnice-0.1.21-150500.1.1.x86_64 gstreamer-plugin-cluttergst3-3.0.27-150400.1.11.x86_64 gstreamer-plugin-pipewire-0.3.64-150500.1.2.x86_64 gstreamer-plugins-bad-1.22.0-lp155.2.8.x86_64 gstreamer-plugins-bad-lang-1.22.0-lp155.2.8.noarch gstreamer-plugins-base-1.22.0-150500.3.3.1.x86_64 gstreamer-plugins-base-lang-1.22.0-150500.3.3.1.noarch gstreamer-plugins-farstream-0.2.9+4-150400.1.12.x86_64 gstreamer-plugins-good-1.22.0-150500.4.3.1.x86_64 gstreamer-plugins-good-gtk-1.22.0-150500.4.3.1.x86_64 gstreamer-plugins-good-lang-1.22.0-150500.4.3.1.noarch gstreamer-plugins-libav-1.22.0-bp155.1.5.x86_64 gstreamer-plugins-rs-0.10.1+git20230213.9cd68ff-150500.2.16.x86_64 gstreamer-plugins-ugly-1.22.0-150500.3.3.1.x86_64 gstreamer-plugins-ugly-lang-1.22.0-150500.3.3.1.noarch gstreamer-utils-1.22.0-150500.3.2.3.x86_64 libgstreamer-1_0-0-1.22.0-150500.3.2.3.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1215482] New: polkit: permissions of /usr/share/polkit-1/rules.d
by bugzilla_noreply＠suse.com 20 Nov '23

20 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1215482 Bug ID: 1215482 Summary: polkit: permissions of /usr/share/polkit-1/rules.d Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: meissner(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- /usr/share/polkit-1/rules.d is 0750 root:polkit. As the content comes from the OS vendor, there's nothing secret about it. So changing to 755 root:root should be fine. That would avoid having gid!=0 stuff in /usr -- You are receiving this mail because: You are on the CC list for the bug.

1 3