June 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1218653] New: Gimp 3 scheduled for May - Lets start the preparations
by bugzilla_noreply＠suse.com 24 Jan '25

24 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1218653 Bug ID: 1218653 Summary: Gimp 3 scheduled for May - Lets start the preparations Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- - https://www.phoronix.com/news/GIMP-3.0-May-2024-Schedule - https://librearts.org/2023/11/gimp-3-0-roadmap/ current test packages are in: https://build.opensuse.org/project/show/graphics:gimp:master i dropped a mail to Jehan to find out if the master snapshots of gegl and babl are still needed or not. if we want to have parallel buildable packages it would be easy to rename the master gimp package to gimp3 and apply this patch: ``` Index: gimp.spec =================================================================== --- gimp.spec (revision 1878) +++ gimp.spec (working copy) @@ -67,14 +67,16 @@ %global abiver 5 %global apiver 3.0 -Name: gimp +%define pkg_name gimp + +Name: gimp3 Version: 3.0 Release: 0 Summary: The GNU Image Manipulation Program License: GPL-3.0-or-later Group: Productivity/Graphics/Bitmap Editors URL: https://www.gimp.org/ -Source: %{name}-%{version}.tar.zst +Source: %{pkg_name}-%{version}.tar.zst Source1: macros.gimp # openSUSE palette file Source2: openSUSE.gpl @@ -184,6 +186,7 @@ Provides: gimp-2.0 = %{version} Provides: gimp(abi) = %{abiver} Provides: gimp(api) = %{apiver} +Conflicts: gimp %description The GIMP is an image composition and editing program, which can be @@ -296,7 +299,7 @@ %endif %prep -%autosetup -p1 +%autosetup -p1 -n %{pkg_name}-%{version} %build #define _lto_cflags %{nil} ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 31

[Bug 1218424] New: go1.22 release tracking
by bugzilla_noreply＠suse.com 24 Jan '25

24 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1218424 Bug ID: 1218424 Summary: go1.22 release tracking 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: jkowalczyk(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- go1.22 (expected February 2024) is a major release of Go. Minor releases of go1.22.x will be provided through February 2025. This issue tracks go1.22.x releases packaged and submitted initially to openSUSE:Factory and can be referenced in submissions to additional repositories. Go Release Cycle https://github.com/golang/go/wiki/Go-Release-Cycle Go Release history https://golang.org/doc/devel/release.html -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1226807] New: minicom cannot run as user due to /run/lock permissions
by bugzilla_noreply＠suse.com 23 Jan '25

23 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1226807 Bug ID: 1226807 Summary: minicom cannot run as user due to /run/lock permissions Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: aaron.w2(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When running minicom as a user in the dialout group I now get an error message that it cannot create a lock file. This worked in 15.5. Minicom is attempting to create the lockfile in /run/lock but only root has write access to this directory. Minicom uses lockdev which requires access to /var/lock. One way to fix this is to build minicom without lockdev. Lockdev is fundamentally broken because it requires write access to /run/lock, which is a security nightmare. When minicom is built without lockdev the location of the lockfiles can be specified to be someplace other than /var/lock. See https://systemd-devel.freedesktop.narkive.com/vCJLfMo2/headsup-var-lock-and… for a discussion. As an interim solution, I added an ACL to allow the dialout group to write to /run/lock, though this is far from ideal. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1224434] New: Page cache invalidation failure during direct I/O write
by bugzilla_noreply＠suse.com 22 Jan '25

22 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1224434 Bug ID: 1224434 Summary: Page cache invalidation failure during direct I/O write Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: PowerPC-64 URL: https://openqa.opensuse.org/tests/4202483/modules/AD03 3/steps/8 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: avinesh.kumar(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-ppc64le-ltp_aiodio_part1@ppc64le fails in [AD033](https://openqa.opensuse.org/tests/4202483/modules/AD033/steps/8) ## Test suite description LTP_ENV=TMPDIR=/var/tmp is to test on btrfs instead of tmpfs ## Reproducible Fails since (at least) Build [20240131](https://openqa.opensuse.org/tests/3907534) Last good: Unknown ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=ppc64le&distri=opensu… -------- LTP Test - https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/io/l… we run this test with various combinations of write block size and I/O numbers (https://github.com/linux-test-project/ltp/blob/master/runtest/ltp-aiodio.pa…) failing scenarios on ppc64le: AD033 aiocp -b 4k -n 4 -f DIRECT AD035 aiocp -b 4k -n 8 -f DIRECT AD037 aiocp -b 4k -n 16 -f DIRECT (few times doesn't fail) AD039 aiocp -b 4k -n 32 -f DIRECT (few times doesn't fail) AD047 aiocp -b 8k -n 4 -f DIRECT AD049 aiocp -b 8k -n 8 -f DIRECT AD051 aiocp -b 8k -n 16 -f DIRECT (few times doesn't fail) AD061 aiocp -b 16k -n 4 -f DIRECT AD063 aiocp -b 16k -n 8 -f DIRECT AD075 aiocp -b 32k -n 4 -f DIRECT dmesg log during each of these failures: OpenQA::run_ltp.pm: Starting AD032 OpenQA::run_ltp.pm: Starting AD033 [ 48.470444][ T62] Page cache invalidation failure on direct I/O. Possible data corruption due to collision with buffered I/O! [ 48.471404][ T62] File: /var/tmp/LTP_aioTBsaEH/dstfile.bin PID: 62 Comm: kworker/1:1 OpenQA::run_ltp.pm: Starting AD034 OpenQA::run_ltp.pm: Starting AD035 This issue is not present on aarch64 and x86_64 tumbleweed builds. And on SLE15-SP6, we are not seeing this on ppc64le also. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1216739] New: sssd: support configs and drop-ins in /usr
by bugzilla_noreply＠suse.com 21 Jan '25

21 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1216739 Bug ID: 1216739 Summary: sssd: support configs and drop-ins in /usr Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: scabrero(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: ckowalczyk(a)suse.com, jengelh(a)inai.de, scabrero(a)suse.com Target Milestone: --- Found By: --- Blocker: --- sssd ships configs in /etc. In order to be able to ship configs as packages, support for having configs in /usr is desireable as well. Any chance to simplement /usr/etc support? -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1225965] New: Improve KDE Discover bug reporting button
by bugzilla_noreply＠suse.com 21 Jan '25

21 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1225965 Bug ID: 1225965 Summary: Improve KDE Discover bug reporting button Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: shundhammer(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Whenever we have a generic package issues that affects multiple users like (bug 1225174), we get a whole to of bug reports and duplicates. All that users seem to be doing is copy the text "<html>Dependency resolution failed:<br/><br/>[...] </html>", report a bug in a random component. Bonus: If the component is YaST, Huha gets angry like in bug 1225949. We do not see the bugs that were not reported due to bugzilla pointing out the possible duplicate, but in the example above we got 14 reports. These users may or may not have read through the duplicated bug, or read the recommendation there. https://github.com/KDE/discover/blob/d644b2a1000c04f084d39a4ef8a3402abf6417… Let's improve user experience here. Some ideas: 0. Direct the user to zypper/YaST for self-service resolution of the conflict. 1. Direct the user to a landing page with instructions for #0. 2. Direct the user to bugzilla search first 3. Take the message - extract package names only, strip arch/installed version, sort, and make a hash from it. Use that as the bug alias for automatic reduplication. 4. or even a fuzzy hash 5. Use a bugzilla whiteboard field with self-service fix instructions -- You are receiving this mail because: You are on the CC list for the bug.

1 24

[Bug 1221429] New: Presence dialog for ssh id_ed25519_sk keys not showing up
by bugzilla_noreply＠suse.com 21 Jan '25

21 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1221429 Bug ID: 1221429 Summary: Presence dialog for ssh id_ed25519_sk keys not showing up Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: felix.niederwanger(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When logging in via ssh using a id_ed25519_sk key (e.g. Yubikey), typically ssh prompts a dialog, prompting the user to push the presence key on the hardware dongle. In Plasma6 when doing ssh against a host that requires this presence button to be pushed, the dialog does not show up. The login still works, ssh just blocks and when I push the button it works, but the confirmation dialog does not show up anymore. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1222473] New: VUL-0: CVE-2024-22189: dnscrypt-proxy: quic-go: memory exhaustion attack against QUIC's connection ID mechanism
by bugzilla_noreply＠suse.com 20 Jan '25

20 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1222473 Bug ID: 1222473 Summary: VUL-0: CVE-2024-22189: dnscrypt-proxy: quic-go: memory exhaustion attack against QUIC's connection ID mechanism Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://smash.suse.de/issue/400376/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: cunix(a)mail.de Reporter: camila.matos(a)suse.com QA Contact: qa-bugs(a)suse.de CC: camila.matos(a)suse.com, security-team(a)suse.de, smash_bz(a)suse.de Blocks: 1222461 Target Milestone: --- Found By: Security Response Team Blocker: --- +++ This bug was initially created as a clone of Bug #1222461 +++ quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.42.0, an attacker can cause its peer to run out of memory sending a large number of `NEW_CONNECTION_ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE_CONNECTION_ID` frame. The attacker can prevent the receiver from sending out (the vast majority of) these `RETIRE_CONNECTION_ID` frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. Version 0.42.0 contains a patch for the issue. No known workarounds are available. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-22189 https://www.cve.org/CVERecord?id=CVE-2024-22189 https://github.com/quic-go/quic-go/commit/4a99b816ae3ab03ae5449d15aac45147c… https://github.com/quic-go/quic-go/security/advisories/GHSA-c33x-xqrf-c478 https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-manageme… https://www.youtube.com/watch?v=JqXtYcZAtIA&t=3683s https://bugzilla.redhat.com/show_bug.cgi?id=2273513 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1225863] New: Chromium crashes on startup
by bugzilla_noreply＠suse.com 19 Jan '25

19 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1225863 Bug ID: 1225863 Summary: Chromium crashes on startup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: dev(a)dominik-schmidt.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After updating openSUSE Tumbleweed the other day Chromium is now crashing for me on startup (i.e. I don't get to see a window at all). My system is completely up to date, I switched all packages from packman to repo-oss. When running Chromium in GDB I can retrieve this backtrace: > 0x000055555e2ec853 in partition_alloc::internal::FreelistCorruptionDetected(unsigned long) () > (gdb) bt > #0 0x000055555e2ec853 in partition_alloc::internal::FreelistCorruptionDetected(unsigned long) () > #1 0x000055555e2fc487 in allocator_shim::internal::PartitionMalloc(allocator_shim::AllocatorDispatch const*, unsigned long, void*) () > #2 0x000055555dc170f2 in base::allocator::dispatcher::internal::DispatcherImpl<base::PoissonAllocationSampler>::AllocFn(allocator_shim::AllocatorDispatch const*, unsigned long, void*) () > #3 0x000055555e2fba1b in malloc () > #4 0x00007ffff36aa75e in strdup () at /lib64/libc.so.6 > #5 0x00007ffff72a7439 in () at /lib64/libfontconfig.so.1 > #6 0x00007ffff72a8f3c in () at /lib64/libfontconfig.so.1 > #7 0x00007ffff72ad2c5 in () at /lib64/libfontconfig.so.1 > #8 0x00007ffff71ce988 in () at /lib64/libexpat.so.1 > #9 0x00007ffff71cb7c4 in () at /lib64/libexpat.so.1 > #10 0x00007ffff71cdc49 in () at /lib64/libexpat.so.1 > #11 0x00007ffff71c2258 in () at /lib64/libexpat.so.1 > #12 0x00007ffff71ca3e5 in XML_ParseBuffer () at /lib64/libexpat.so.1 > #13 0x00007ffff72a97d5 in () at /lib64/libfontconfig.so.1 > #14 0x00007ffff72aa11e in () at /lib64/libfontconfig.so.1 > #15 0x00007ffff72924ef in () at /lib64/libfontconfig.so.1 > #16 0x00007ffff728d5b9 in () at /lib64/libfontconfig.so.1 > #17 0x00007ffff72927d9 in FcInit () at /lib64/libfontconfig.so.1 > #18 0x000055555f0e7a78 in base::NoDestructor<gfx::(anonymous namespace)::GlobalFontConfig>::NoDestructor<>() () > #19 0x000055555f0e7a06 in base::internal::Invoker<base::internal::FunctorTraits<gfx::InitializeGlobalFontConfigAsync()::$_0&&>, base::internal::BindState<false, false, false, gfx::InitializeGlobalFontConfigAsync()::$_0>, void ()>::RunOnce(base::internal::BindStateBase*) () > #20 0x000055555e236f4b in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) () > #21 0x000055555e25aef8 in base::internal::TaskTracker::RunTaskImpl(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::internal::SequenceToken const&) () > #22 0x000055555e25afc1 in base::internal::TaskTracker::RunSkipOnShutdown(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::internal::SequenceToken const&) () > #23 0x000055555e25abf3 in base::internal::TaskTracker::RunTask(base::internal::Task, base::internal::TaskSource*, base::TaskTraits const&) () > #24 0x000055555e25a717 in base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource) () > #25 0x000055555e26d2df in base::internal::WorkerThread::RunWorker() () > #26 0x000055555e26ceaa in base::internal::WorkerThread::RunPooledWorker() () > #27 0x000055555e26cd2a in base::internal::WorkerThread::ThreadMain() () > #28 0x000055555e28a08a in base::(anonymous namespace)::ThreadFunc(void*) () > #29 0x00007ffff3692ba2 in start_thread () at /lib64/libc.so.6 > #30 0x00007ffff371400c in clone3 () at /lib64/libc.so.6 I also tried 125.0.6422.141-1965.1-x86_64 from network:chromium/chromium, but it shows the same behavior. As it looks related to fontconfig, I ran > fc-cache -f -v as user and root with no success either. Happy to provide any additional system information, logs, outputs... Thanks in advance -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1222505] New: ckermit: cannot create lock file in /var/lock
by bugzilla_noreply＠suse.com 17 Jan '25

17 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1222505 Bug ID: 1222505 Summary: ckermit: cannot create lock file in /var/lock Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: ceggers(a)arri.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Kermit needs to create a lock file for the used serial port (e.g. /dev/ttyUSB0) under /var/lock (symlink to /run/lock). Until Leap 15.5, that directory was owned by group "lock", so it was sufficient to add the current user to the "lock" group. But now the directory is owned by group "root", so using the "lock" group is not sufficient anymore. Reproducible: Always Steps to Reproduce: 1. Add current user to "dialout" group (and create re-login after that). 2. Ensure that step 1. was successful (e.g. by using the "id" command). 3. kermit -l /dev/ttyUSB0 Actual Results: Kermit gives an error "can't open device". Using "set line /dev/ttyUSB0" in kermit's interactive mode gives a more precise error message: "Sorry, write access to UUCP lockfile directory denied." Expected Results: kermit should have created the lock file and open /dev/ttyUSB0 A workaround is to change the group of /run/lock to "dialout" (and to add the current user to this group). But this change is lost after every reboot. Possibly related to https://bugzilla.opensuse.org/show_bug.cgi?id=624290 ("ckermit from contrib repository does not use lockdev, so cannot write to /var/lock"). The packet installed is: $ rpm -q ckermit --info Name : ckermit Version : 9.0.302 Release : 150000.3.3.1 Architecture: x86_64 Install Date: Mo 08 Apr 2024 09:44:42 CEST Group : Hardware/Modem Size : 2621762 License : BSD-3-Clause Signature : RSA/SHA256, Fr 01 Apr 2022 13:39:36 CEST, Key ID 70af9e8139db7c82 Source RPM : ckermit-9.0.302-150000.3.3.1.src.rpm Build Date : Fr 01 Apr 2022 13:39:14 CEST Build Host : goat10 Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> URL : http://www.kermitproject.org/ Summary : A Combined Serial and Network Communication Software Package Description : C-Kermit is a combined serial and network communication software package offering a consistent, medium-independent, and cross-platform approach to connection establishment, terminal sessions, file transfer, character-set translation, and automation of communication tasks. Distribution: SUSE Linux Enterprise 15 -- You are receiving this mail because: You are on the CC list for the bug.

1 4