June 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1226398] selinux - swtpm - virt-manager can no longer start vm
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226398 Cathy Hu <cathy.hu(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown(a)suse.com Assignee|rbrown(a)suse.com |cathy.hu(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226418] yast2-audit-laf rules are not preserved across reboots
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226418 https://bugzilla.suse.com/show_bug.cgi?id=1226418#c1 --- Comment #1 from Stefan Hundhammer <shundhammer(a)suse.com> --- First observation: That code has not changed at all for at least two years on the YaST side. https://github.com/yast/yast-audit-laf That implies that this behavior is very unlikely to be new. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226330] [r600]Garbage on screen after switching VTs from/to Plasma Wayland session
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226330 https://bugzilla.suse.com/show_bug.cgi?id=1226330#c6 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(srid(a)rkmail.ru) --- Comment #6 from Takashi Iwai <tiwai(a)suse.com> --- Thanks. It means that the bug is still in the latest upstream, and it should be tracked by the upstream tracker. To be sure, could you try the latest 6.10-rc kernel in OBS Kernel:HEAD:Backport repo? http://download.opensuse.org/repositories/Kernel:/HEAD:/Backport/standard/ Once after confirming that the issue persists, please boot with boot options "log_buf_len=1M drm.debug=0x1e", try to reproduce the problem, and upload the dmesg output to Bugzilla as an attachment. Give the output of hwinfo as well. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226398] selinux - swtpm - virt-manager can no longer start vm
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226398 Cathy Hu <cathy.hu(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cathy.hu(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226302] Leap 15.6 cannot boot up successfully on RPi 4
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226302 https://bugzilla.suse.com/show_bug.cgi?id=1226302#c2 Ivan Ivanov <ivan.ivanov(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(zluo(a)suse.com) CC| |ivan.ivanov(a)suse.com, | |zluo(a)suse.com --- Comment #2 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- Hi Zaoliang Luo, could you attach serial console to device and capture boot log? Or even if you don't see login promt on display could you try to SSH to device? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226418] New: yast2-audit-laf rules are not preserved across reboots
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1226418 Bug ID: 1226418 Summary: yast2-audit-laf rules are not preserved across reboots Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: nvbugs(a)hhecht.e4ward.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- With yast2-audit-laf-4.6.0-150600.1.2 on a fresh Leap 15.6 install: The Yast audit module provides a tab "rules for 'auditctl'" that allows one to edit the audit rules for the system. Unfortunately, any changes made here are lost on reboot, and are thus somewhat useless (and confusingly so). The reason is that augenrules.service runs augenrules --load. The manpage says: ...merges all component audit rules files, found in the audit rules directory, /etc/audit/rules.d, placing the merged file in /etc/audit/audit.rules I.e., it overwrites /etc/audit/audit.rules, as this is not part of the merge set. Yast loads from and saves to audit.rules only, so it is essentially ephemeral. This is clearly wrong, but I am not sure what the correct behavior here should be. If Yast edits e.g., /etc/audit/rules.d/yast.rules, then users will falsely get the idea that they are editing all the rules, rather than just some of them. This is likely to be confusing in a different way, especially as the default configuration contains "-a task,never", which disables all syscall (and thus, even more confusingly, filesystem watch) rules. The alternative would be to continue to edit audit.rules but disable augenrules.service. In the latter case, rules.d should probably not be part of the package, as it would be ignored. Or perhaps yast can only display a warning, instead of the edit widget, if there is anything in rules.d and augenrules.service is enabled? None of this seems fully satisfactory. The underlying problem is how the audit software handles configuration files, of course: augenrules is both less flexible and distinctly un-Linuxy compared to e.g., the #includedir of sudoers. Changing this would probably be confusing in a yet a different way, however. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1226388] Yast2 iSCSI LIO server reports internal error after targetcli exits with status 255
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

1 0

[Bug 1218158] [usr-merge] yast-nfs-(server|client) hardcoded configuration file /etc/idmapd.conf
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1218158 https://bugzilla.suse.com/show_bug.cgi?id=1218158#c19 Michal Filka <mfilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #19 from Michal Filka <mfilka(a)suse.com> --- access to idmapd.conf was removed in yast-nfs-{client,server} 5.0.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1221183] Upgrade problems with clang-cpp
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c23 --- Comment #23 from Richard Biener <rguenther(a)suse.com> --- (In reply to Richard Biener from comment #22) > (In reply to Aaron Puchert from comment #21) > [...] > > (In reply to Franz Sirl from comment #20) > > > The specific problem is the global object > > > clang::format::FormatTokenLexer::CSharpAttributeTargets from libclang-cpp > > > has global constructors/destructors. The object seemingly is merged by the > > > shared loader when 2 libclang-cpp with different versions are loaded. > > > > That would surprise me. I think that copy relocations allow the linking > > application to interpose the library variable with their own copy, but this > > should still be subject to symbol versioning. At least I'd hope so. > > This should work for the symbols in the libraries themselves. I'm not sure > how users go though since two versions are likely pulled in only indirectly, > aka App X uses LLVM15 and library Y which uses LLVM13. Iff both App X and > library Y instantiate a "LLVM typed object/template" then those > instantiations > will not have a symbol version and those could be subject to false > interposition (usually COMDAT handling). The solution would be for > library Y to better constrain what it exports of course, but that's not the > rule in the C++ world unfortunately. Oh, and "naming" the library differently doesn't help of course, the library SONAME is not part of instantiated objects. The problem here is really the C++ ODR. GNU C++ offers kind-of a workaround via ABI-tags, but I don't think they are widely used besides in GCCs C++ standard library. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1221183] Upgrade problems with clang-cpp
by bugzilla_noreply＠suse.com 17 Jun '24

17 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c22 --- Comment #22 from Richard Biener <rguenther(a)suse.com> --- (In reply to Aaron Puchert from comment #21) [...] > (In reply to Franz Sirl from comment #20) > > The specific problem is the global object > > clang::format::FormatTokenLexer::CSharpAttributeTargets from libclang-cpp > > has global constructors/destructors. The object seemingly is merged by the > > shared loader when 2 libclang-cpp with different versions are loaded. > > That would surprise me. I think that copy relocations allow the linking > application to interpose the library variable with their own copy, but this > should still be subject to symbol versioning. At least I'd hope so. This should work for the symbols in the libraries themselves. I'm not sure how users go though since two versions are likely pulled in only indirectly, aka App X uses LLVM15 and library Y which uses LLVM13. Iff both App X and library Y instantiate a "LLVM typed object/template" then those instantiations will not have a symbol version and those could be subject to false interposition (usually COMDAT handling). The solution would be for library Y to better constrain what it exports of course, but that's not the rule in the C++ world unfortunately. -- You are receiving this mail because: You are on the CC list for the bug.

1 0