November 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1204332] akregator-lang not installed by default => only english language for a french installation
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204332 https://bugzilla.suse.com/show_bug.cgi?id=1204332#c3 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Stefan Hundhammer <shundhammer(a)suse.com> --- When I try to access those y2logs, I get "The attachment you are attempting to access has been removed." But I bet when you enter this command: grep -i recommend /etc/sysconfig/yast2 you'll get PKGMGR_RECOMMENDED="no" Right? That means you are installing packages without recommended ones, which is what that akregator-lang package is: The akregator main package can live perfectly well without its -lang package, but then you won't get any translations. This is why there is a difference between hard "required" packages and less stringent "recommended" ones. Some users prefer it like that to save disk space and have less packages for system complexity and (possibly) more system security (because of less system components). This is a setting that you can change in the YaST package manager in the "Dependencies" menu at "[x] Install Recommended Packages" (or manually in /etc/sysconfig/yast2). I tried on my Leap 15.4 (where I also don't have "akregator" installed): With recommended packages, when I select "akregator", it automatically selects "akregator-lang"; without recommended, it doesn't. Please check that setting and reopen if that wasn't your problem. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1129466] New: fwupd cannot update BIOS with UEFI Secure Boot enabled because of missing fwupdx64.efi.signed
by bugzilla_noreply＠novell.com 10 Nov '22

10 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1129466 Bug ID: 1129466 Summary: fwupd cannot update BIOS with UEFI Secure Boot enabled because of missing fwupdx64.efi.signed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: pujos.michael(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- fwdupd 1.2.3-2.1 cannot update the BIOS on my laptop because of this error: $fwupdmgr get-devices ... 20MBCTO1WW System Firmware DeviceId: 65b6a9dc7b7df18bdff003584b51bf21373e3aa6 Guid: 1e1fe415-74e8-49e1-9508-106b3d13d50d Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a Guid: 171800c9-1a51-5fd9-a32b-7b3999cb1c4e Plugin: uefi Flags: internal|require-ac|supported|registered|needs-reboot Version: 0.1.18 VersionLowest: 0.1.0 Icon: computer Created: 2019-03-15 UpdateError: /usr/lib/fwupd/efi/fwupdx64.efi.signed cannot be found Apparently, if Secure Boot is enabled (my case and I believe TW default on UEFI installs), it looks for /usr/lib/fwupd/efi/fwupdx64.efi.signed. This file is missing but it turns out that /usr/lib/fwupd/efi/fwupdx64.efi is present AND signed: $pesign -S -i /usr/lib/fwupd/efi/fwupdx64.efi --------------------------------------------- certificate address is 0x7f0e55679f78 Content was not encrypted. Content is detached; signature cannot be verified. The signer's common name is openSUSE Secure Boot Signkey The signer's email address is build(a)opensuse.org Signing time: Tue Mar 05, 2019 There were certs or crls included. --------------------------------------------- So the fix is simply so make a symlink and restart fwupd so it sees the change: $ln -s /usr/lib/fwupd/fwupdx64.efi /usr/lib/fwupd/fwupdx64.efi.signed $systemctl restart fwupd Then the error goes away in 'fwupdmgr get-devices' and you can supposedly update with 'fwupdmgr update' (didn't try it at updating the BIOS is rather scary and I do not absolutely need this update currently). So I think the package should be updated to make the symlink (or rename the file if keeping fwupdx64.efi is unecessary). -- You are receiving this mail because: You are on the CC list for the bug.

2 19

[Bug 1204928] AUDIT-0: openSUSE Leap Micro 5.3 RC/GM security audit
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204928 https://bugzilla.suse.com/show_bug.cgi?id=1204928#c4 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Johannes Segitz <jsegitz(a)suse.com> --- I had a look and it's on the same level as SLES Micro, so happy releasing :) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204703] VUL-0: CVE-2022-3676: In Eclipse Openj9 before version 0.35.0, interface calls can be inlined without a runtime type check. Malicious bytecode could make use of this inlining to access or modify memory via an incompatible type.
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204703 SMASH SMASH <smash_bz(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |CVSSv3.1:SUSE:CVE-2022-3676 | |:6.5:(AV:N/AC:L/PR:N/UI:N/S | |:U/C:L/I:L/A:N) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205236] New: [Staging] icu 72.1 breaks nodejs18/nodejs19
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205236 Bug ID: 1205236 Summary: [Staging] icu 72.1 breaks nodejs18/nodejs19 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: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- icu 72.1 has been submitted for inclusion into openSUSE Tumbleweed https://build.opensuse.org/request/show/1031330 During the staging process, we have identified nodejs1[89] failing to build with it. * NodeJS 18 https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… * NodeJS 19 https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1205042] [TRACKERBUG] Set openssl 3.0.7 as the default openssl in TW
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205042 http://bugzilla.opensuse.org/show_bug.cgi?id=1205042#c16 --- Comment #16 from OBSbugzilla Bot <bwiedemann+obsbugzillabot(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1205042) was mentioned in https://build.opensuse.org/request/show/1035017 Factory / python-pyzmq -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204360] Fix determination for canonical path of “/boot/grub2” (by a distribution upgrade)
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204360 https://bugzilla.suse.com/show_bug.cgi?id=1204360#c4 --- Comment #4 from Michael Chang <mchang(a)suse.com> --- (In reply to Franck Bui from comment #3) > (In reply to Michael Chang from comment #1) > > As a start we can check with systemd-maintainers to get better understanding > > the consequence of missing automount unit file mentioned above. > > Hi Michael, sorry for the late reply. > > What makes you think that the automount unit is missing ? In attachment 862208 y2log has these lines of output. > Error output: Unit boot.mount does not exist, proceeding anyway. > Error output: Unit home.mount does not exist, proceeding anyway. > Error output: Created symlink /run/systemd/system/boot.mount �� /dev/null. > Error output: Created symlink /run/systemd/system/home.mount �� /dev/null. > Error output: Created symlink /run/systemd/system/tmp.mount �� /dev/null. > Error output: Created symlink /run/systemd/system/var-lib-nfs-rpc_pipefs.mount > > @Markus, can you please run `systemctl status boot.automount` to check > whether it's missing or not ? I think that was an offline upgrade from SUSE's installation media, therefore suspecting an issue in the live system. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c6 --- Comment #6 from Eric Levy <contact(a)ericlevy.name> --- Thank you for the explanation. I had no idea about such support coming from tukit. I had reviewed the manual for the command transactional-update, but I have not found any comprehensive guide, tutorial, or manual for the overall system, that is, the general design of the TU framework. I have generally found only documentation for specific components, or high-level overviews of the concept. A comprehensive document that targets the practical use cases for administrators and users, would be very helpful. Elaboration of the inner plumbing would be a helpful too, as an indispensable resource for disaster recovery. To my mind, such a document would useful overall much more so than just a blog post on this particular subject, especially because it may be hard for the right person to find the resource at the time when needed. However, it certainly might help someone at some time, and certainly would be more helpful for the subject than any resource I have found so far. Yes, I agree you found a flaw regarding the privileges of the user shell, which could be resolved through appropriate modifications of the concept. You could simply allow any user to enter the open transaction, with regular permissions. At the present time, I feel compelled to push back against the idea of lack of isolation being a major problem. Locations storing user data are meant to be manipulated by operations initiated by the user, in ways that the user understands. My motivation for submitting the request is that in a vanilla installation, it is possible for the an administrator to install a package on an active system, immediately interact with the modified system, and then, if desired, reverse the system changes, or add new ones. Surely it is possible that such a sequence would leave artifacts in data locations, but such effects are well understood, and no more harmful in the transactional scenario than in the classical one. For cases where some isolation is desired, you could consider adding an option for providing the full environment through temporary snapshots, such that the changes to these locations within the test session will be lost, even if the changes to the system are committed. The purpose would be to test operations, for resolving whether the new system image is one that would be useful for future boot sessions, or not. For example, the build operation is reproducible. If it succeeds in the test environment, it will succeed in new system configuration, once it would become active. Please remember also, if I am not mistaken, that rollback of a previous transaction will not roll back modifications to data directories occurring during any boot sessions following the transaction. Thus, you could be providing more isolation than available currently, by opening the possibility for utilizing the system changes in a special session. My understanding would be that if an administrator must roll back a transaction, any problems encountered would be the same as the ones that cause you to hesitate on the idea I am proposing. The proposed method is simply a means to test the consequences of a transaction before committing it for future boot sessions, and without interrupting the boot session of the live system. Once the changes are confirmed, and the transaction committed, then the system would be rebooted, with predictable effects. If I am not making some important oversight, you might consider supporting the work flow through an accessible set of operations in the tool chain. I believe the concerns I have raised originally are rather common, and without a way to address them, it may be harder for many sites to adopt the system, or to find ways to resolve unforeseen problems after adoption. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204332] akregator-lang not installed by default => only english language for a french installation
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204332 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(epistemepromeneur | |(a)free.fr) | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c5 --- Comment #5 from Ignaz Forster <iforster(a)suse.com> --- Most of the described functionality is available via the `tukit` command already. Your example would look as follows: 1. sudo tukit open 2. sudo tukit call <id> bash a. sudo zypper in somepackage b. exit 3 has conceptual problems. First of all there is the problem that you want to access data in your user's home, so you'd have to switch back to that user first (as you are calling the outer command with sudo). But as /home is not part of the root file system it is also not mounted by default in the transactional-update environment. The following commands could be used to get the behavior you want (minus the ro part): 3. sudo tukit call <id> bash a. mount -o subvol=@/home b. su - user c. cd ~/project d. make e. exit f. exit 4. sudo tukit close <id> To get a "full" emulation of the new system you could also use `mount -a` in step 3a, which would also mount directories such as /var and /srv into the transactional-update environment, but that will obviously break the isolation. Due to that I don't really want to include that as an official command, but it may be worth writing a blog post or a Wiki entry about this? -- You are receiving this mail because: You are on the CC list for the bug.

1 0