July 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1225440] syslog-ng: undefined symbol: fmod
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225440 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |peter(a)czanik.hu -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1225800] Package libesmtp does not build with gcc14 because of new errors
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225800 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |pstivanin(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1225635] New: Steam "doesn't launch" due to .desktop configuration issue
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225635 Bug ID: 1225635 Summary: Steam "doesn't launch" due to .desktop configuration issue Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: crdcastro5(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- In steam's .desktop file there's a line 'PrefersNonDefaultGPU=true'. This causes steam to render itself only on the non-default gpu, which will always be the one not currently in use. Looking at the issues concerning this on the steam github repository, this line was intended to make systems always use a discrete gpu if available. However if you're currently already using video out from your discrete gpu, this will make it render only on the igpu (not desired behavior). Removing this line from the .desktop will make steam render on whichever gpu is currently in use, with games still defaulting to the dedicated gpu if available (desired behavior). I would've submitted a fix for this myself but I'm not sure where to do so. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1225397] postfix gives warnings about deprecated parameters
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225397 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |varkoly(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1227290] New: VUL-0: CVE-2020-28596: PrusaSlicer: Multiple vulnerabilities in prusa-slice since 2.2.0
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1227290 Bug ID: 1227290 Summary: VUL-0: CVE-2020-28596: PrusaSlicer: Multiple vulnerabilities in prusa-slice since 2.2.0 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/277704/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: code(a)bnavigator.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- A stack-based buffer overflow vulnerability exists in the Objparser::objparse() functionality of Prusa Research PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted obj file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-28596 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1220 https://www.cve.org/CVERecord?id=CVE-2020-28596 https://bugzilla.redhat.com/show_bug.cgi?id=2294728 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1227292] New: VUL-0: CVE-2020-28598: PrusaSlicer: out-of-bounds write in the Admesh stl_fix_normal_directions() functionality
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1227292 Bug ID: 1227292 Summary: VUL-0: CVE-2020-28598: PrusaSlicer: out-of-bounds write in the Admesh stl_fix_normal_directions() functionality Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/303974/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: code(a)bnavigator.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- An out-of-bounds write vulnerability exists in the Admesh stl_fix_normal_directions() functionality of Prusa Research PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted AMF file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-28598 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1222 http://www.cvedetails.com/cve/CVE-2020-28598/ https://www.cve.org/CVERecord?id=CVE-2020-28598 https://bugzilla.redhat.com/show_bug.cgi?id=2294728 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1227236] New: System not able to correctly read RAID (1) devices with kernel >=6.9
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1227236 Bug ID: 1227236 Summary: System not able to correctly read RAID (1) devices with kernel >=6.9 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel:Storage Assignee: kernel-bugs(a)suse.de Reporter: timeygaming69(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Overview: Updating to a kernel that is >=6.9.x leads to the system being unable to correctly read and assemble MDADM RAID devices, works fine with older Tumbleweed kernels (e.g. 6.8.x kernels) Steps to Reproduce: 1. Create a RAID 1 device with MDADM, with LVM volumes within, formatted with BTRFS 2. Update to newer kernel version in TW, higher than 6.9 Actual Results: System fails to correctly assemble MD devices, only some LVs are visible and mountable on 1 disk. Secondary disk does not appear to be part of the MD array, and LVs do not appear. OR Replugging the devices cause other LVs that could not be read during boot time to appear, but are not mountable and readable. Original readable LVs are not visible after replugging. Expected Results: All created MD devices and LVs should be assembled and mountable correctly. Build Date & Hardware: I am unsure about the specific build, but I have tried 2 6.8 kernels (6.8.3, 6.8.5) by rolling back the system, and it functions correctly. Updating to a snapshot with a kernel >6.9 causes the issue. Updating to a newer snapshot with the kernel-default package appears to not trigger the issue. Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). Occurs on an installation with MicroOS, and Slowroll with kernel >6.9, have not tested other distributions. Additional Information: System is a X1 Carbon with 2x Seagate Ironwolf drives attached via a USB enclosure. Functioned for 2 years, and tested with new, identical USB enclosures and other laptops to confirm the issue, which is replicated identically. When the devices can be mounted correctly with older kernels, SMART data and BTRFS scrubbing did not identify any issues. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1227116] osinfo still uses deprecated SL-Micro name
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

1 0

[Bug 1189174] Virtual DRM drivers cause excessive framerates, maxing out CPU
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1189174 https://bugzilla.suse.com/show_bug.cgi?id=1189174#c8 --- Comment #8 from Thomas Zimmermann <tzimmermann(a)suse.com> --- (In reply to Fabian Vogt from comment #7) > (In reply to Thomas Zimmermann from comment #6) > > FYI, I've done some work on this issue, but nothing upstream-able. IMHO we > > should first push userspace to fix that. AFAIU they are coupling their > > animation loops to the display refresh rate. That's generally a bad idea. > > Can you elaborate? The wayland protocol design is based around that > approach... Right now, the kernel tells userspace when the current frame has been transferred to the display. For better hardware, that's synced to vertical blanking via a dedicated HW interrupt. But most trivial hardware (and that's the majority actually) doesn't have such a VBLANK interrupt. So the kernel processes frames ASAP. There's no point in waiting. Hence for most display hardware, the rate of frame updates is unpredictable; even if the display mode specifies a certain frequency. And some display modes don't specify a frequency; what shall we do then? To compensate these differences in hardware, the userspace animation loop should therefore always be uncoupled from the actual display update. The compositor would sync its animation to the hardware's available rate of frame updates, but not blindly follow it. Computer games have done that ever since; compositors could likely do something similar. The compositor has a much better knowledge of its animation and can easily take available CPU resources into account. All the kernel can do is to delay the current frame's output. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226664] Wicked crashing with macvlan interface since recent `zypper patch` in systemd-nspawn container
by bugzilla_noreply＠suse.com 02 Jul '24

02 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1226664 https://bugzilla.suse.com/show_bug.cgi?id=1226664#c5 --- Comment #5 from Clemens Famulla-Conrad <cfamullaconrad(a)suse.com> --- Unfortunately yes. Wicked has here the problem that the ifindex for your lower device is given with 2 (but different namespace) and the macvlan device has the ifindex 2 as well. Currently wicked creates a dependency loop by these equal ifindex and doesn't reflect the different namespaces. We are looking for a solution! Fun fact: if you use a interface, which has a ifindex, which isn't known inside the container (e.g. a second ethernet with ifindex==3), you should not face the issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 0