January 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1179867] New: gcovr missing dependency on python3-lxml
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1179867 Bug ID: 1179867 Summary: gcovr missing dependency on python3-lxml Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: sakphul(a)mailbox.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After installing gcovr it fails with the following error: gcovr -j4 -r /home/<user>/test/ -s /home/<user>/test/build Traceback (most recent call last): File "/usr/bin/gcovr", line 6, in <module> from pkg_resources import load_entry_point File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3252, in <module> def _initialize_master_working_set(): File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3235, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3264, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master ws.require(__requires__) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'lxml' distribution was not found and is required by gcovr After installing "python3-lxml" it works. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1180413] diffutils not installed in in the main info directory
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180413 https://bugzilla.suse.com/show_bug.cgi?id=1180413#c11 --- Comment #11 from Christopher Yeleighton <giecrilj(a)stegny.2a.pl> --- (In reply to Fabian Vogt from comment #10) > This is because first, the "new" info is installed and its %filetriggerin > run, and after that the > %filetriggerun from the "old" info: What if you use a package trigger instead? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180413] diffutils not installed in in the main info directory
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180413 https://bugzilla.suse.com/show_bug.cgi?id=1180413#c10 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|KDE Applications |Basesystem Assignee|opensuse-kde-bugs@opensuse. |screening-team-bugs(a)suse.de |org | --- Comment #10 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Christopher Yeleighton from comment #7) > (In reply to Fabian Vogt from comment #4) > > What do you mean by that? If I open KHelpCenter, I can navigate to the > > diffutils info page just fine. > > That probably means you have upgraded your system that had been installed at > a time before %install_info was disabled. Nope, I used the KDE live cd and reinstalled diffutils to work around excludedocs. I see a different issue though, reinstallation/upgrades of the info package clear the info directory: 64f925a549c3:/ # rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/diffutils-3.7-4.1.x86_64.rpm 64f925a549c3:/ # grep sdiff /usr/share/info/dir * sdiff: (diffutils)Invoking sdiff. Merge 2 files side-by-side. 64f925a549c3:/ # rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/info-6.7-1.20.x86_64.rpm 64f925a549c3:/ # grep sdiff /usr/share/info/dir 64f925a549c3:/ # This is because first, the "new" info is installed and its %filetriggerin run, and after that the %filetriggerun from the "old" info: 64f925a549c3:/ # strace -fetrace=execve rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/info-6.7-1.20.x86_64.rpm execve("/usr/bin/rpm", ["rpm", "-U", "--replacepkgs", "/var/cache/zypp/packages/repo-os"...], 0x7ffc4721a160 /* 9 vars */) = 0 strace: Process 483 attached [pid 483] execve("/usr/bin/install-info", ["/usr/bin/install-info", "--info-dir=/usr/share/info", "/usr/share/info/diffutils.info.g"...], 0x7ffd501f7790 /* 9 vars */) = 0 [pid 483] +++ exited with 0 +++ strace: Process 484 attached [pid 484] execve("/usr/bin/install-info", ["/usr/bin/install-info", "--quiet", "--delete", "--info-dir=/usr/share/info", "/usr/share/info/diffutils.info.g"...], 0x7ffd501f7790 /* 9 vars */) = 0 [pid 484] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=483, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- +++ exited with 0 +++ -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179170] grub2 efi posttrans update-bootloader script fails
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1179170 https://bugzilla.suse.com/show_bug.cgi?id=1179170#c7 Raymund Will <rw(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rw(a)suse.com) | --- Comment #7 from Raymund Will <rw(a)suse.com> --- [in reverse order... ;)] 1. efibootmgr-17 (available from [1]) already has `efi_set_verbose(opts.verbose - 2, stderr);` in it's "verbosity handling", so if you try that, please use (at least) '-vvv'. 2. no, I have no recollection of or other idea about what could be going on, but would be interested to learn, whether efibootmgr-17 would make any difference! 3. is it be possible, that this is a "reused" installation, which has been upgraded at least once? Or are there other explanations for the LVM-related warnings in the log? 4. do we need to look into those "leaked file descriptors"? 5. why do we think that updating `grub2-i386-pc` would have any effect on this UEFI machine? 6. how would a failed modification of an UEFI variable, in an otherwise "unchanged" boot setup, lead to a 'grub>' prompt? Are there any error messages from grub before the prompt? And 6) is the most pressing issue reported here, IMHO. AFAICT, something must have gone wrong in the `update-bootloader --refresh` (AKA `grub2-mkconfig`) area, as opposed to `update-bootloader --reinit` (AKA `grub2-install`). IOW, 7. is the contents of `/boot/grub2/grub.cfg` plausible? Same for `/boot/efi/efi/openSUSE/grub.cfg`? Unfortunately more questions that answers... [1] https://download.opensuse.org/repositories/home:/rwill:/branches:/Base:/Sys… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180339] dnf default configuration is missing allow_vendor_change setting
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180339 https://bugzilla.suse.com/show_bug.cgi?id=1180339#c1 --- Comment #1 from Christian V�gl <christian.voegl(a)suse.com> --- Interesting, that setting should default to true. I assume you did not disable it in a *.repo file found under /etc/yum.repos.d? Does adding allow_vendor_change=True to /etc/ fix the error for you? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c15 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mike(a)flingtoad.co | |m), | |needinfo?(fbui(a)suse.com) --- Comment #15 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Fabian Vogt from comment #14) > Created attachment 844939 [details] > systemd debug logs > > (In reply to Franck Bui from comment #13) > > In reply to Fabian Vogt from comment #11) > > > So if unmounting /var needs udev, there's a cycle... > > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > > it fails that way. > > > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > > using the initrd's udev. > > > > Then both /var and /etc are supposed to be unmounted in initrd, no ? > > AFAICT the initrd is not used during shutdown currently. I can trigger that manually by touching /run/initramfs/.need_shutdown only. > > What do /etc/{fstab,crypttab} look like on the affected systems ? > > I just installed MicroOS with encrypted / and /var partitions and was able > to reproduce the problem. > > f224:~ # cat /etc/crypttab > cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach > cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 I can't reproduce the issue anymore with "none x-initrd.attach" added to the cr_var entry here. Can you confirm that? The /var+systemd-udevd cycle still exists, but there's no attempt to detach cr_var. Your commit introducing the x-initrd.attach option (https://github.com/systemd/systemd/commit/1dc85eff1d0dff18aaeaae530c91bf53f…) implies that the initrd is entered again on shutdown, but that doesn't seem to be triggered. Maybe the presence of x-initrd.attach should do that? It's not clear to me whether the device is still getting detached properly on shutdown. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178691] New: parti does not show some partitions
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1178691 Bug ID: 1178691 Summary: parti does not show some partitions Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 843512 --> https://bugzilla.suse.com/attachment.cgi?id=843512&action=edit test file file -k testmbr testmbr: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'SLE-15-SP3-Online-ppc64le69..001'\012- DOS/MBR boot sector; partition 1 : ID=0x96, active, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 0, 791968 sectors; partition 2 : ID=0xba, active 0xba, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 3132799674, 3132799674 sectors; partition 3 : ID=0xba, active 0xba, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 3132799674, 3132799674 sectors; partition 4 : ID=0xba, active 0xba, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 3132799674, 3132799674 sectors\012- DOS/MBR boot sector\012- Apple Driver Map, blocksize 512, blockcount 791968, devtype 1, devid 1, driver data 3132799674, driver count 47802, contains[@0x200]:\012- , contains[@0x400]:\012- (Lepton 3.x), scale 0-0, spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000\012- (Lepton 2.x), scale 0-0, spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000\012- data parti testmbr testmbr: 2048 sectors - - - - - - - - - - - - - - - - file system: fs "iso9660", label "SLE-15-SP3-Online-ppc64le69..001", uuid "2020-10-27-22-34-36-34" - - - - - - - - - - - - - - - - mbr id: 0xbabababa sector size: 512 mbr partition table (chs 0/255/63, inconsistent geo): 1 * 0 - 791967 (size 791968), chs 1023/255/63 - 1023/255/63 type 0x96 (chrp iso9660) fs "iso9660", label "SLE-15-SP3-Online-ppc64le69..001", uuid "2020-10-27-22-34-36-34" - - - - - - - - - - - - - - - - apple partition table: 2 entries sector size: 512 1 1 - 3 (size 2), rel. 0 - 2 (size 2) type[19] "Apple_partition_map", status 0x33 name[5] "Apple" 2 16 - 791968 (size 791952), rel. 0 - 791952 (size 791952) type[9] "Apple_HFS", status 0x33 name[32] "SLE-15-SP3-Online-ppc64le69..001" fs "hfs", label "unknown" Although the output of parti is much easier to read it does not display MSDOS partitions with type ba that exist in the partition table. This is quite misleading. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c14 --- Comment #14 from Fabian Vogt <fvogt(a)suse.com> --- Created attachment 844939 --> https://bugzilla.suse.com/attachment.cgi?id=844939&action=edit systemd debug logs (In reply to Franck Bui from comment #13) > In reply to Fabian Vogt from comment #11) > > So if unmounting /var needs udev, there's a cycle... > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > it fails that way. > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > using the initrd's udev. > > Then both /var and /etc are supposed to be unmounted in initrd, no ? AFAICT the initrd is not used during shutdown currently. > What do /etc/{fstab,crypttab} look like on the affected systems ? I just installed MicroOS with encrypted / and /var partitions and was able to reproduce the problem. f224:~ # cat /etc/crypttab cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 f224:~ # cat /etc/fstab UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c / btrfs ro 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /usr/local btrfs subvol=/@/usr/local 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /srv btrfs subvol=/@/srv 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /root btrfs subvol=/(a)/root,x-initrd.mount 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /opt btrfs subvol=/@/opt 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /home btrfs subvol=/@/home 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/writable btrfs subvol=/@/boot/writable 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /.snapshots btrfs subvol=/(a)/.snapshots 0 0 UUID=72a8d278-c003-4fb8-96dc-bdbf29dcd37a /var btrfs defaults,x-initrd.mount 0 0 overlay /etc overlay defaults,lowerdir=/sysroot/etc,upperdir=/sysroot/var/lib/overlay/1/etc,workdir=/sysroot/var/lib/overlay/work-etc,x-systemd.requires-mounts-for=/var,x-systemd.requires-mounts-for=/sysroot/var,x-initrd.mount 0 0 Logs of the full boot and shutdown with systemd.log_level=debug are attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180607] New: Black screen after return from standby with kernel 5.10.4
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180607 Bug ID: 1180607 Summary: Black screen after return from standby with kernel 5.10.4 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: p.stolz77(a)googlemail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, with Kernel 5.10.4 the system shows a black screen after return from standby. With kernel 5.10.3 all works fine. Operating System: openSUSE Tumbleweed 20210104 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 Kernel Version: 5.10.4-1-default OS Type: 64-bit Processors: 6 �� Intel�� Core�� i5-9400 CPU @ 2.90GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa DRI Intel�� UHD Graphics 630 Peter Stolz -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1180339] dnf default configuration is missing allow_vendor_change setting
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180339 Christian V�gl <christian.voegl(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|pth(a)suse.com |christian.voegl(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0