July 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1216393] New: Electron/Chromium can't render h264 in webrtc
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1216393 Bug ID: 1216393 Summary: Electron/Chromium can't render h264 in webrtc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: bjorn.bidar(a)thaodan.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- * Description: When trying to stream WebRTC with h264 in Electron/Chromium the screen stays black even thou OpenH264 is correctly installed. * How to reproduce: 1. Open Chromium 2. Open https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html 3. Click test ** Another option is to use: https://mozilla.github.io/webrtc-landing/pc_test.html 1. Tick require h264 2. Start the video, wait 3. The message now should be "No H264 found in the offer!!!" * Background and reason for the bug: openSUSE builds both Chromium and Electron in a way that h264 isn't compiled into both packages but loaded using the Openh264 provided by openSUSE but blessed by Cisco. However Chromium has to use some of the openh264 to build even thou it's not used during runtime. The gyp option `rtc_use_h264` has be set to true and third_party/openh264 has to be included in the tarball (already the case in the upstream third_party/openh264 tarball). This is due webrtc using openh264 headers in third_party/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1218303] New: VUL-0: CVE-2023-6704: libavif,chromium,ungoogled-chromium: use after free in libavif
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1218303 Bug ID: 1218303 Summary: VUL-0: CVE-2023-6704: libavif,chromium,ungoogled-chromium: use after free in libavif Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: aaronpuchert(a)alice-dsl.net, andrea.mattiazzo(a)suse.com, Andreas.Stieger(a)gmx.de, gmbr3(a)opensuse.org, security-team(a)suse.de Target Milestone: --- Found By: --- Blocker: --- It was reported that libavif before 1.0.3, and as bundled in Chromium, contained a use-after-free bug. colorProperties could be pointing to a dangling pointer if findAlphaItem() resizes the meta.items array. Also bundled in chromium, see bug 1218048 References: https://github.com/AOMediaCodec/libavif/pull/1808 https://github.com/AOMediaCodec/libavif/commit/b984f48be99b41405cb4a7d44380… https://github.com/AOMediaCodec/libavif/releases/tag/v1.0.3 https://bugs.chromium.org/p/chromium/issues/detail?id=1504792 -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1227332] New: chromium/chrome wrapper causes library issues (symbol lookup error)
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1227332 Bug ID: 1227332 Summary: chromium/chrome wrapper causes library issues (symbol lookup error) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Usability Assignee: screening-team-bugs(a)suse.de Reporter: S48GS(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Exact same as https://bugzilla.redhat.com/show_bug.cgi?id=2277228 But they say it fixed in 124+ when im on latest Chrome and Chromium(125+) and it not fixed. Context is openSUSE Tumbleweed. (I show bug for Chromium, but it exact same for google-chrome from google repository) Bug: Run /usr/bin/chromium-browser visit https://fosstorrents.com/distributions/kali-linux/ click any magnet-link (scroll down) Chromium will ask to open with xdg-open or with transmission. to check magnet is registered: xdg-mime query default x-scheme-handler/magnet it should display transmission-gtk.desktop Click open in Chromium - nothing happen with error in terminal: /usr/bin/transmission-gtk: symbol lookup error: /lib64/libgtk-4.so.1: undefined symbol: vkCreateXlibSurfaceKHR Fix/prove that it not problem with anything else: cd /usr/lib64/chromium ./chrome open same link as above - click magnet link - click open - transmission launched and everything works -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225863] New: Chromium crashes on startup
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

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 2

[Bug 1220201] New: Firefox on Wayland - download dialog disappearing
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1220201 Bug ID: 1220201 Summary: Firefox on Wayland - download dialog disappearing Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Using Firefox on Wayland the download dialog is disappearing after chosing "save file" and before selecting the download file and directory. One can see the "enter name ..." dialog for a second, then it vanishes. On the same machine this does not happen with Xorg. There is no error or warning in the journal, i.e. for a crash. Operating System: openSUSE Tumbleweed 20240220 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.7.5-1-default (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15,0 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: Dell Inc. Product Name: XPS 13 9310 2-in-1 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1228154] New: NetworkManager dispatcher script does not finish before sleep, continues after resume
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1228154 Bug ID: 1228154 Summary: NetworkManager dispatcher script does not finish before sleep, continues after resume Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876168 --> https://bugzilla.suse.com/attachment.cgi?id=876168&action=edit journal excerpt Starting with the one of the latest NetworkManager (1.46, 1.48?) versions, my dispatcher script does not finish when going to sleep. It finishes on resume, though, causing some strange effects. For example it is umounting one or two nfs shares before sleep, but for the third one it says "server not responding". All remaining shares stay mounted until the system is resumed. Then the remaining shares are umounted and NetworkManager takes the interface down, only to bring it up again a second later. The runtime of my script is 1 or 2 seconds only, so this seems not to be a problem of hitting the dispatcher timeout, but on the other hand this does not happen, if I remove the nfs umounts. My script and the configuration worked for years, and nothing changed besides the NM version (and all the other parts of Tumbleweed). System is: Operating System: openSUSE Tumbleweed 20240716 KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.9-1-default (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15,0 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: Dell Inc. Product Name: XPS 13 9310 2-in-1 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1223967] New: %suse_build_hwcaps_libs fails to generate -x86_64-v3 packages when shared library is an update-alternatives link
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1223967 Bug ID: 1223967 Summary: %suse_build_hwcaps_libs fails to generate -x86_64-v3 packages when shared library is an update-alternatives link 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: badshah400(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- ## Originally reported on GitHub: https://github.com/openSUSE/obs-build/issues/1001 This came up when trying to enable -v3 hwcaps enhanced libs for `lapack`. As it turns out, `lapack` uses update-alternatives to create a symlink `/usr/lib64/libblas.so.3` pointing to the real library `/usr/lib64/blas/libblas.so.3` via `update-alternatives` called during `post`. The file `/usr/lib64/libblas.so.3` does not exist a build-time, but created by update-alternatives during `post` install. It is also marked as `%ghost` in the package. Apparently `%{?suse_build_hwcaps_libs}` cannot handle this. It tries to copy the non-existent — at build time — `/usr/lib64/libblas.so.3` and fails catastrophically _after_ actually generating the hwaps libs. This is what I see in the log. Note the error: `mv: cannot stat '.cfiles/usr/lib64/liblapack.so.3': No such file or directory` which suggests it is trying to move a non-existent file which will be created during `post` install: > [ 218s] RPMLINT report: > [ 218s] =============== > [ 220s] ============================ rpmlint session starts ============================ > [ 220s] rpmlint: 2.5.0 > [ 220s] configuration: > [ 220s] /opt/testing/lib64/python3.11/rpmlint/configdefaults.toml > [ 220s] /opt/testing/share/rpmlint/cron-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/dbus-services.toml > [ 220s] /opt/testing/share/rpmlint/device-files-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/licenses.toml > [ 220s] /opt/testing/share/rpmlint/opensuse.toml > [ 220s] /opt/testing/share/rpmlint/pam-modules.toml > [ 220s] /opt/testing/share/rpmlint/permissions-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/pie-executables.toml > [ 220s] /opt/testing/share/rpmlint/polkit-rules-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/scoring.toml > [ 220s] /opt/testing/share/rpmlint/security.toml > [ 220s] /opt/testing/share/rpmlint/sudoers-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/sysctl-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/systemd-tmpfiles.toml > [ 220s] /opt/testing/share/rpmlint/users-groups.toml > [ 220s] /opt/testing/share/rpmlint/world-writable-whitelist.toml > [ 220s] /opt/testing/share/rpmlint/zypper-plugins.toml > [ 220s] rpmlintrc: > [ 220s] /home/abuild/rpmbuild/SOURCES/lapack.rpmlintrc > [ 220s] checks: 41, packages: 21 > [ 220s] > [ 220s] libblas3.x86_64: I: package-supports-update-alternatives > [ 220s] libcblas3.x86_64: I: package-supports-update-alternatives > [ 220s] liblapack3.x86_64: I: package-supports-update-alternatives > [ 220s] liblapacke3.x86_64: I: package-supports-update-alternatives > [ 220s] libblas3.x86_64_v3: I: package-supports-update-alternatives > [ 220s] libcblas3.x86_64_v3: I: package-supports-update-alternatives > [ 220s] liblapack3.x86_64_v3: I: package-supports-update-alternatives > [ 220s] liblapacke3.x86_64_v3: I: package-supports-update-alternatives > [ 220s] Check time report (>1% & >0.1s): > [ 220s] Check Duration (in s) Fraction (in %) Checked files > [ 220s] ExtractRpm 0.3 30.3 > [ 220s] SignatureCheck 0.2 19.6 > [ 220s] BinariesCheck 0.2 19.2 > [ 220s] SharedLibraryPolicyCheck 0.2 16.2 > [ 220s] TOTAL 1.0 100.0 > [ 220s] > [ 220s] 21 packages and 0 specfiles checked; 0 errors, 0 warnings, 131 filtered, 0 badness; has taken 1.1 s > [ 220s] > [ 220s] ... cleaning ccache > [ 220s] setting SOURCE_DATE_EPOCH_MTIME to 1714856125 > [ 220s] 1 > [ 220s] ... saving ccache archive > [ 220s] ... creating baselibs > [ 220s] setting SOURCE_DATE_EPOCH_MTIME to 1714856125 > [ 220s] no targets for arch x86_64, skipping lapack-devel > [ 220s] no targets for arch x86_64, skipping liblapack3 > [ 220s] no targets for arch x86_64, skipping lapacke-devel > [ 220s] no targets for arch x86_64, skipping libblas3 > [ 220s] no targets for arch x86_64, skipping liblapacke3 > [ 220s] no targets for arch x86_64, skipping libcblas3 > [ 220s] no targets for arch x86_64, skipping cblas-devel > [ 220s] no targets for arch x86_64, skipping blas-devel > [ 220s] liblapack3(x86_64:x86-64-v3): writing specfile... > [ 220s] liblapack3(x86_64:x86-64-v3): running build... > [ 220s] rpmbuild failed: 256 > [ 220s] re-running in verbose mode: > [ 220s] using SOURCE_DATE_EPOCH with value 1714856124 as build time > [ 220s] Executing(%prep): /usr/bin/bash -e /var/tmp/rpm-tmp.r51odx > [ 220s] + umask 022 > [ 220s] + cd /home/abuild/rpmbuild/BUILD > [ 220s] + RPM_EC=0 > [ 220s] ++ jobs -p > [ 220s] + exit 0 > [ 220s] Executing(%build): /usr/bin/bash -e /var/tmp/rpm-tmp.dHOH58 > [ 220s] + umask 022 > [ 220s] + cd /home/abuild/rpmbuild/BUILD > [ 220s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] ++ dirname /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT > [ 220s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + RPM_EC=0 > [ 220s] ++ jobs -p > [ 220s] + exit 0 > [ 220s] Executing(%install): /usr/bin/bash -e /var/tmp/rpm-tmp.Aiq5Zt > [ 220s] + umask 022 > [ 220s] + cd /home/abuild/rpmbuild/BUILD > [ 220s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT > [ 220s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + rm -rf /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + mkdir /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + cd /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + mkdir -p .cfiles > [ 220s] + pushd .cfiles > [ 220s] ~/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/.cfiles ~/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 220s] + cat > [ 220s] + rpm2cpio //home/abuild/rpmbuild/RPMS/x86_64_v3/liblapack3-3.12.0-94.1.x86_64_v3.rpm > [ 220s] + cpio -i -d -v -E .filelist > [ 220s] ./usr/lib64/lapack/liblapack.so.3 > [ 221s] ./usr/lib64/lapack/liblapack.so.3.12.0 > [ 221s] 15311 blocks > [ 221s] + popd > [ 221s] ~/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64 > [ 221s] + mkdir -p /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3/lapack > [ 221s] + mv .cfiles/usr/lib64/lapack/liblapack.so.3 /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3/lapack/liblapack.so.3 > [ 221s] + mkdir -p /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3/lapack > [ 221s] + mv .cfiles/usr/lib64/lapack/liblapack.so.3.12.0 /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3/lapack/liblapack.so.3.12.0 > [ 221s] + mkdir -p /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3 > [ 221s] + mv .cfiles/usr/lib64/liblapack.so.3 /home/abuild/rpmbuild/BUILDROOT/lapack-3.12.0-94.1.x86_64/usr/lib64/glibc-hwcaps/x86-64-v3/liblapack.so.3 > [ 221s] mv: cannot stat '.cfiles/usr/lib64/liblapack.so.3': No such file or directory > [ 221s] error: Bad exit status from /var/tmp/rpm-tmp.Aiq5Zt (%install) > [ 221s] > [ 221s] RPM build errors: > [ 221s] Bad exit status from /var/tmp/rpm-tmp.Aiq5Zt (%install) > [ 221s] ### VM INTERACTION START ### > [ 221s] [ 217.139930][ T1] sysrq: Power Off > [ 221s] [ 217.141087][ T10] reboot: Power down > [ 221s] ### VM INTERACTION END ### > [ 221s] > [ 221s] i01-ch1d failed "build lapack.spec" at Mon May 6 11:51:16 UTC 2024. > [ 221s] FWIW, here is the baselibs.conf: > ... > > liblapack3 > -/usr/lib(64)?/liblapack.so.3 > requires "update-alternatives" > postin "ln -sf /etc/alternatives/liblapack.so.3_<targettype> /usr/%_lib/liblapack.so.3" > postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/liblapack.so.3 liblapack.so.3_<targettype> /usr/%_lib/lapack/liblapack.so.3 50" > postun "/usr/sbin/update-alternatives --remove liblapack.so.3_<targettype> /usr/%_lib/lapack/liblapack.so.3" > > ... And attached is the full build log if it helps (from https://build.opensuse.org/package/show/home:badshah400:lapackv3/lapack) -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1220814] New: kernel 6.7.6-1-default Oops: unable to handle page faults and workqueue lockup (udev related?)
by bugzilla_noreply＠suse.com 28 Aug '24

28 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1220814 Bug ID: 1220814 Summary: kernel 6.7.6-1-default Oops: unable to handle page faults and workqueue lockup (udev related?) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: michael.burge77(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 873182 --> https://bugzilla.suse.com/attachment.cgi?id=873182&action=edit full journalctl of the third crash I have an old portable with a wonky dc power jack which tends to generate a few quick AC0<->BAT0 events in succession. Starting with kernel 6.7.6-1-default the system locks up. Log is full of ``` Mar 01 17:34:02 ost (udev-worker)[23694]: AC0: Process '/usr/sbin/tlp auto' terminated by signal KILL. Mar 01 17:34:02 ost (udev-worker)[23694]: AC0: Failed to wait for spawned command '/usr/sbin/tlp auto': Input/output error Mar 01 17:34:02 ost (udev-worker)[23694]: AC0: Failed to execute '/usr/sbin/tlp auto', ignoring: Input/output error Mar 01 17:34:17 ost (udev-worker)[24044]: AC0: Process '/usr/sbin/tlp auto' terminated by signal KILL. Mar 01 17:34:17 ost (udev-worker)[24044]: AC0: Failed to wait for spawned command '/usr/sbin/tlp auto': Input/output error Mar 01 17:34:17 ost (udev-worker)[24044]: AC0: Failed to execute '/usr/sbin/tlp auto', ignoring: Input/output error Mar 01 17:34:17 ost plasmashell[2682]: plasma-pk-updates: acPluggedChanged onBattery: false -> true Mar 01 17:34:17 ost kernel: BUG: unable to handle page fault for address: 0000000000007b8a Mar 01 17:34:17 ost kernel: #PF: supervisor read access in kernel mode Mar 01 17:34:17 ost kernel: #PF: error_code(0x0000) - not-present page ``` until it locks up with ``` Mar 01 18:11:29 ost kernel: note: kworker/11:5[23457] exited with irqs disabled Mar 01 18:11:50 ost systemd-logind[1443]: Power key pressed short. Mar 01 18:11:54 ost systemd-logind[1443]: Power key pressed short. Mar 01 18:11:55 ost systemd-logind[1443]: Power key pressed short. Mar 01 18:11:58 ost plasmashell[5912]: [5912:0301/181158.744595:ERROR:command_buffer_proxy_impl.cc(128)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer. Mar 01 18:12:05 ost systemd-logind[1443]: Power key pressed short. Mar 01 18:12:06 ost kernel: BUG: workqueue lockup - pool cpus=11 node=0 flags=0x0 nice=0 stuck for 37s! ``` at which point only holding down the power button works. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1228234] New: SSH Client crashes with option GSSAPIKeyExchange enabled
by bugzilla_noreply＠suse.com 28 Aug '24

28 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1228234 Bug ID: 1228234 Summary: SSH Client crashes with option GSSAPIKeyExchange enabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: luedtke(a)in.tum.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello everyone, I updated 15.5 to 15.6 some days ago after that I noticed that ssh connection doesnt work anymore. I as I found out, as long as GSSAPIKeyExchange option is on the ssh client crashes. Versions on System: opnessh 9.6p1 - 150600.6.9.1 openssh-clients 9.6p1 - 150600.6.9.1 Debug Info of SSH Session: OpenSSH_9.6p1, OpenSSL 3.1.4 24 Oct 2023 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug2: resolving "XXXXX" port 22 debug3: resolve_host: lookup files:22 debug3: channel_clear_timeouts: clearing debug3: ssh_connect_direct: entering debug1: Connecting to files [X.X.X.X] port 22. debug3: set_sock_tos: set socket 3 IP_TOS 0x10 debug1: Connection established. debug1: Local version string SSH-2.0-OpenSSH_9.6 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4 debug1: compat_banner: match: OpenSSH_8.4 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to XXXX:22 as 'USER' debug3: Trying to reverse map address X.X.X.X. debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q== Speicherzugriffsfehler (Speicherabzug geschrieben) Workaround: If you turn off GSSAPIKeyExchange in /etc/ssh/ssh_config (or else you turned it on) everything works fine (even with Kerberos) -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1225801] New: Package libgee does not build with gcc14 because of new errors
by bugzilla_noreply＠suse.com 27 Aug '24

27 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1225801 Bug ID: 1225801 Summary: Package libgee does not build with gcc14 because of new errors 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: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- GCC 14 newly by default treats as errors a number of situations which before were only warnings. For more information see https://gcc.gnu.org/gcc-14/porting_to.html and meta bug #1220571. Because of this, package libgee fails to compile. This can be seen online at: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… It can be reproduced locally with command: osc build --clean --alternative-project home:rguenther:nextgcc See also https://gitlab.com/fweimer-rh/fedora-modernc/-/blob/main/pkg/l/libgee.md?re… and https://bugs.gentoo.org/920315 and https://bugs.gentoo.org/894376 The (first) error (that halts the build) is: [ 11s] concurrentlist.c: In function 'gee_concurrent_list_construct': [ 11s] concurrentlist.c:469:168: error: passing argument 4 of 'gee_hazard_pointer_set_pointer' from incompatible pointer type [-Wincompatible-pointer-types] [ 11s] 469 | gee_hazard_pointer_set_pointer (GEE_CONCURRENT_LIST_TYPE_NODE, (GBoxedCopyFunc) gee_concurrent_list_node_ref, (GDestroyNotify) gee_concurrent_list_node_unref, &self->priv->_tail, _tmp7_, (gsize) 0, (gsize) 0); [ 11s] | ^~~~~~~~~~~~~~~~~~ [ 11s] | | [ 11s] | GeeConcurrentListNode ** {aka struct _GeeConcurrentListNode **} [ 11s] In file included from concurrentlist.c:26: [ 11s] gee.h:2076:54: note: expected 'const void ***' but argument is of type 'GeeConcurrentListNode **' {aka 'struct _GeeConcurrentListNode **'} [ 11s] 2076 | gconstpointer** aptr, [ 11s] | ~~~~~~~~~~~~~~~~^~~~ -- You are receiving this mail because: You are on the CC list for the bug.

1 3