December 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1214167] New: OBS: nothing provides lzip
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1214167 Bug ID: 1214167 Summary: OBS: nothing provides lzip Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService Assignee: screening-team-bugs(a)suse.de Reporter: manfred99(a)gmx.ch QA Contact: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- In the package rcs (https://build.opensuse.org/package/show/devel:tools:scm/rcs) there is a build error for Leap 15.4 and Leap 15.5: "unresolvable: nothing provides lzip" Although both distributions provide lzip, and the required "BuildRequires: lzip" is given in the spec file. The issue seems to be, that OBS builds against a subset of packages (drawing by Jan Engelhardt): SLE-15.5-Base `-- SLE-15.5-Update <- devel:tools:scm is pointing here `-- SLE-15.5-Backports <- lzip is available from here `-- Leap:15.5 `-- Leap:15.5:Update Which explains why this can not work. But there are software projects (such as RCS) which only distribute lzip-compressed release tarballs. IMHO such a basic, widely used compression tool should be available in SLE-15.5-Base or SLE-15.5-Update, so that OBS can use it to build packages. Alternatively there should be a mechanism to provide essential building blocks to OBS (outside of SLE-.*), so that OBS can do its duty. At the moment there is no possibility to build software which provides lzip-tarballs. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1215219] New: xdg-utils: cannot open https/https urls, malformed character
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1215219 Bug ID: 1215219 Summary: xdg-utils: cannot open https/https urls, malformed character Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: gianmarco.torti(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- package installed info: Information for package xdg-utils: ---------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : xdg-utils Version : 1.1.3+20230830-1.1 Arch : noarch Vendor : openSUSE Installed Size : 348.4 KiB Installed : Yes Status : up-to-date Source package : xdg-utils-1.1.3+20230830-1.1.src Upstream URL : https://www.freedesktop.org/wiki/Software/xdg-utils/ with this version is not possible to open any url with http / https prefix , this is the error: xdg-open https://www.kernel.org start : This command cannot be run due to the error: The system cannot find the file specified. At line:1 char:1 + start https\www.kernel.org + ~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand NOTE: opensuse tumbleweed installed in WSL subsystem with older version xdg-utils-1.1.3+20210805-2.3.noarch there are no problems -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1217312] New: Google websites do not work in Firefox
by bugzilla_noreply＠suse.com 29 Aug '24

29 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1217312 Bug ID: 1217312 Summary: Google websites do not work in Firefox 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: bart.vanassche+novell(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Since more than a year, multiple Google websites, e.g. Google Search, Google Docs and Gmail, do not work well with the Firefox software included with openSUSE Tumbleweed. It often happens that loading one of these websites stalls. Logging in to a Google account doesn't work at all. I don't see this issue if I download Firefox binaries from the Mozilla website and load my existing profile (firefox/firefox -profileManager). Does this perhaps mean that there is a problem with changes made to the Firefox software that is available from openSUSE? Tumbleweed version: $ rpm -qf /etc/issue.net openSUSE-release-20231117-2596.1.x86_64 Firefox versions: $ rpm -q MozillaFirefox MozillaFirefox-119.0.1-1.1.x86_64 Binary downloaded from the Mozilla website: firefox-119.0.1.tar.bz2 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[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 1216895] New: VUL-0: CVE-2023-47272: Roundcube 1.5.x before 1.5.6 and 1.6.x before 1.6.5 allows XSS via a Content-Type or Content-Disposition header (used for attachment preview or download).
by bugzilla_noreply＠suse.com 21 Aug '24

21 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1216895 Bug ID: 1216895 Summary: VUL-0: CVE-2023-47272: Roundcube 1.5.x before 1.5.6 and 1.6.x before 1.6.5 allows XSS via a Content-Type or Content-Disposition header (used for attachment preview or download). Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/384151/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: aj(a)ajaissle.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: stoyan.manolov(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- Roundcube 1.5.x before 1.5.6 and 1.6.x before 1.6.5 allows XSS via a Content-Type or Content-Disposition header (used for attachment preview or download). References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-47272 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1217083] New: snapshot 20231107 --> 20231108 boot fails
by bugzilla_noreply＠suse.com 19 Aug '24

19 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1217083 Bug ID: 1217083 Summary: snapshot 20231107 --> 20231108 boot fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: roeland.jansen(a)sue.nl QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Recently I updated 23031107 to 20231108 on two laptops running legacy boot. Both hang some time at console plymouth stuff. dracut then comes up with the inability to find /dev/system/root. It ends up in the dracut emergency shell. in the shell, lvm pvscan will report no physical volumes. It also happens on a virtual machine. (also not UEFI). If I try to recover with an usb stick, no partitions are shown. If I show "all", the installed system is being identified als unknown, architecture unknown. (and yes it's a 64 bit TW stick). I could not recover them anymore. Also, on one of the laptops, grub does not show windosws anmore, the other does. I luckily have a snapshot on my work vm so I can revert back. The following packages are updated when this happens. alsa alsa-devel code kernel-firmware-all kernel-firmware-amdgpu kernel-firmware-ath10k kernel-firmware-ath11k kernel-firmware-atheros kernel-firmware-bluetooth kernel-firmware-bnx2 kernel-firmware-brcm kernel-firmware-chelsio kernel-firmware-dpaa2 kernel-firmware-i915 kernel-firmware-intel kernel-firmware-iwlwifi kernel-firmware-liquidio kernel-firmware-marvell kernel-firmware-media kernel-firmware-mediatek kernel-firmware-mellanox kernel-firmware-mwifiex kernel-firmware-network kernel-firmware-nfp kernel-firmware-nvidia kernel-firmware-platform kernel-firmware-prestera kernel-firmware-qcom kernel-firmware-qlogic kernel-firmware-radeon kernel-firmware-realtek kernel-firmware-serial kernel-firmware-sound kernel-firmware-ti kernel-firmware-ueagle kernel-firmware-usb-network libasound2 libatopology2 libbrotli-devel libbrotlicommon1 libbrotlicommon1-x86-64-v3 libbrotlidec1 libbrotlidec1-x86-64-v3 libbrotlienc1 libbrotlienc1-x86-64-v3 libbytesize-lang libbytesize1 libgusb2 libnghttp2-14 libsqlite3-0 libsqlite3-0-x86-64-v3 libsvn_auth_kwallet-1-0 libxxhash0 openSUSE-release openSUSE-release-appliance-custom openSUSE-release-ftp sqlite3-devel sqlite3-tcl subversion subversion-bash-completion subversion-perl sysuser-shadow ucode-amd wmctrl I tried by mounting in rescue, created a new grub.cfg where osprober does not show windows anymore. The interesting part is that dracut -f will as last line shows "adding boot menu entry for UEFI firmware settings" Basically I will end up in reinstalling windows and linux on both laptops. (in legacy boot) If needed, I can install the non-kernel parts and see what package eventualy triggers this. -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1216717] New: suse-module-tools: 60-io-scheduler.rules:37 Failed to write ATTR{/sys/devices/virtual/block/dm-0/queue/scheduler}, ignoring: No such file or directory
by bugzilla_noreply＠suse.com 19 Aug '24

19 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1216717 Bug ID: 1216717 Summary: suse-module-tools: 60-io-scheduler.rules:37 Failed to write ATTR{/sys/devices/virtual/block/dm-0/queue/scheduler}, ignoring: No such file or directory Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: martin.wilck(a)suse.com Reporter: antonio.feijoo(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Just in case this wasn't reported yet, this error is logged in the journal of a Tumbleweed system with crypto_LUKS devices: Oct 30 15:46:46 localhost (udev-worker)[724]: dm-0: /usr/lib/udev/rules.d/60-io-scheduler.rules:37 Failed to write ATTR{/sys/devices/virtual/block/dm-0/queue/scheduler}, ignoring: No such file or directory Oct 30 15:46:48 localhost (udev-worker)[723]: dm-1: /usr/lib/udev/rules.d/60-io-scheduler.rules:37 Failed to write ATTR{/sys/devices/virtual/block/dm-1/queue/scheduler}, ignoring: No such file or directory # uname -r 6.5.9-1-default # find /sys/devices -name "queue" /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0/queue /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue /sys/devices/virtual/block/dm-1/queue /sys/devices/virtual/block/dm-0/queue # find /sys/devices -name "scheduler" /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0/queue/scheduler /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue/scheduler Not happening in systems with a similar setup using previous kernel versions: - ALP Dolomite Build6.8 localhost:~ # uname -r 6.4.11-1-default localhost:~ # find /sys/devices -name "queue" /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue /sys/devices/virtual/block/dm-0/queue localhost:~ # find /sys/devices -name "scheduler" /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue/scheduler /sys/devices/virtual/block/dm-0/queue/scheduler - Leap 15.5 # uname -r 5.14.21-150500.53-default # find /sys/devices -name "queue" /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0/queue /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue /sys/devices/virtual/block/dm-0/queue # find /sys/devices -name "scheduler" /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0/queue/scheduler /sys/devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio3/block/vda/queue/scheduler /sys/devices/virtual/block/dm-0/queue/scheduler I don't know if it's a kernel bug or if the udev rule needs to be adjusted. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1215586] New: guestfs regression: non functional network due to missing sysconfig-netconfig
by bugzilla_noreply＠suse.com 19 Aug '24

19 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1215586 Bug ID: 1215586 Summary: guestfs regression: non functional network due to missing sysconfig-netconfig Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Tools Assignee: virt-bugs(a)suse.de Reporter: ohering(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- At some point in the past, virt-builder and other tools had proper networking with-in the appliance. This still works by luck in SLE15, but it broke in Tumbleweed. The reason is the transformation of appliance/packagelist.in into /usr/lib64/guestfs/supermin.d/packages. During build the packagelist is passed to supermin, which writes the packages file. In case a package is unavailable during build, it will be missing from the packages file. Also 'systemd' is transformed into 'systemd-mini' (which is not really an issue because other packages require 'systemd'). In case of networking: if the host does not have 'dhcp-client' installed, the network will not start inside the appliance. Once dhcp-client gets installed, it will be put into the appliance. But the dhcp-client scripts expect a functional /sbin/netconfig, which is provided by sysconfig-netconfig. That package is listed in packagelist.in, but will not be written to packages because it is not in BuildRequires. I think most packages from packagelist.in are "lost" during build because they are not in BuildRequires, or because nothing requires them. It feels wrong to put each and every binary which is potentially called by guestfsd into BuildRequires. Instead the "packages" file should be overwritten manually with the list of packages which may be used, if it is installed on the host. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1216355] New: Packman Discord package upgrade lockout defeat inoperative.
by bugzilla_noreply＠suse.com 19 Aug '24

19 Aug '24

https://bugzilla.suse.com/show_bug.cgi?id=1216355 Bug ID: 1216355 Summary: Packman Discord package upgrade lockout defeat inoperative. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: rskunath(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- There is a script in the Packman Discord srpm package (0.0.31-1699.98.pm.1) that is supposed to defeat the upgrade check that Discord does when they release a new version. This pops up a box to grab a deb or a tarball to update outside the Suse system. This script that is in the rpm spec file apparently has not worked for a while. I don't know if it can work, but it is in there and inoperative. The idea according to the script is to bypass the update check lockout and give the package maintainer time to update the Discord package without locking users out of Discord until that is done. This is a very good idea. In the last few Discord update cycles the box pops up and at that point you can't start Discord until the new package is released by the package maintainer. I did see a while ago a forum post about bumping the JSON file revision number by one version to get around this manually: (/usr/lib64/discord/resources and edit the build_info.json file) This appears to work but it's a kludge and the script is a better and a more appropriate way to do this if doing it is still possible. I'm just passing along the discovery and hoping defeating the lockout is still possible. I use Discord daily on the Suse Discord and users getting locked out is disconcerting. Thanks in advance. -- You are receiving this mail because: You are on the CC list for the bug.

1 3