September 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1184490] New: mame creates a cfg directory in PWD instead of ~/.mame and ignoring ~/.mame/cfg
by bugzilla_noreply＠suse.com 10 Apr '23

10 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1184490 Bug ID: 1184490 Summary: mame creates a cfg directory in PWD instead of ~/.mame and ignoring ~/.mame/cfg 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: ilya(a)ilya.pp.ua QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After updating mame to 0.226, mame started ignoring the configuration directory ~/.mame/cfg/ and started creating it in PWD, i.e. the directory where mame runs from (~/ if you run mame via the menu). In 0.229 nothing has changed. In 0.211 it was no problem. To reproduce, just run "cd /tmp && mame", wait for mame to load the interface, then press Esc to quit mame, and then check /tmp "ls -lah /tmp | grep cfg". -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1047218] New: trackerbug: packages do not build reproducibly from including build time
by bugzilla_noreply＠novell.com 07 Apr '23

07 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1047218 Bug ID: 1047218 Summary: trackerbug: packages do not build reproducibly from including build time Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: SUSE Other Status: CONFIRMED Severity: Normal Priority: P5 - None Component: Development Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- See also https://reproducible-builds.org/ and https://reproducible-builds.org/specs/source-date-epoch/ When packages include the current time of build it results in binaries that differ on every build and thus trigger rebuilds of depending packages and are published to mirrors and users when actually nothing really changed. -- You are receiving this mail because: You are on the CC list for the bug.

2 30

[Bug 1131931] New: OCFS2: Defragmentation error: No space left on device
by bugzilla_noreply＠novell.com 07 Apr '23

07 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1131931 Bug ID: 1131931 Summary: OCFS2: Defragmentation error: No space left on device Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: weikai.wang(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 802412 --> http://bugzilla.suse.com/attachment.cgi?id=802412&action=edit this script is used to generate disk framentation when I used the defragfs.ocfs2 to clean up disk fragmentation that generated by the attached shell script. you could execute the scrip by command "./defragfs_test.sh -d DEVICE -m MOUNT_POINT -n CLUSTER_NAME -s pcmk -o /tmp" You should use the device on your cluster replace DEVICE, use the same way replace MOUNT_POINT and CLUSTER_NAME. Then use the command defragfs.ocfs2 MOUNT_POINT. And if no accident, you will see some message like this: “ defragfs.ocfs2 1.8.5 [1/201]/mnt/ocfs2/tmp_file:Success [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd1" - No space left on device [2/201]/mnt/ocfs2/test_from_dd1:Failed [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd2" - No space left on device [3/201]/mnt/ocfs2/test_from_dd2:Failed [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd3" - No space left on device ” but if you execute defragfs.ocfs2 MOUNT_POINT again, the error message will not show again. and all the defragmentation will pass. please make sure your device's capacity is more tha 1G. Some times this error can make mount, unmount, and mkfs crushed. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1182998] New: libcontainers-common seems to miss prerequires
by bugzilla_noreply＠suse.com 06 Apr '23

06 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1182998 Bug ID: 1182998 Summary: libcontainers-common seems to miss prerequires Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There are several errors during initial installation of libcontainers-common. As result, the configuration is broken and podman not correct working: # 2021-03-04 05:56:10 libcontainers-common-20210112-2.1.noarch.rpm installed ok # Additional rpm output: # /var/tmp/rpm-tmp.fgZbcB: line 4: findmnt: command not found # /var/tmp/rpm-tmp.fgZbcB: line 4: findmnt: command not found # 2021-03-04 05:56:10|install|libcontainers-common|20210112-2.1|noarch||openSUSE-MicroOS-20210302-0|867c95e8e8cd2e09046dc327b743e9134c6072146f59c6f3b357b0e92420b494| # 2021-03-04 05:56:10 openssh-8.4p1-4.1.x86_64.rpm installed ok # Additional rpm output: # find: '/etc/init.d/rc[35].d': No such file or directory # -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1155207] New: systemctl command line completion is very slow
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1155207 Bug ID: 1155207 Summary: systemctl command line completion is very slow Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- systemctl command line completion is very slow Suppose I type: systemctl status smart[tab][tab] and I get nothing. One second, two seconds... so I insist and hit tab several times, and after several seconds I get (one line per second): Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart and then I can type "d" and enter. Why is it that slow? It is an M2 disk. ie, SSD technology. It responds instantly when completing a normal command: Isengard:~ # smart smart_agetty smartctl smartd Isengard:~ # smart And that system is not busy at all, load 0.20. I can replicate the issue on other machines, and has been so probably for a year or so. Google "systemctl completion slow" finds reports on other distributions and several media. <https://bugzilla.redhat.com/show_bug.cgi?id=1491668> <https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1471723> and: <https://github.com/systemd/systemd/issues/7185> -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1159528] New: keybase client package is extremely outdated, plus lacks all gui elements
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1159528 Bug ID: 1159528 Summary: keybase client package is extremely outdated, plus lacks all gui elements Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Mathias.Homann(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- the keybase package that comes packaged in openSUSE Leap 15.1 is outdated... to the ponit of being a prehistoric artefact: bundled comes version 2.11 - current from keybase.io is 5.1.1.... also, it lacks all gui elements - probably because it is such an old version. please update to the latest version. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1126900] New: health-checker: grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system.
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1126900 Bug ID: 1126900 Summary: health-checker: grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: iforster(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- >From a health-checker run: Clearing GRUB flag + grub2-editenv - set health_checker_flag=0 grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system. Starting health check -- You are receiving this mail because: You are on the CC list for the bug.

2 12

[Bug 1176302] New: keyboard: Switch kbd keyboard defaults to xkb based ones
by bugzilla_noreply＠suse.com 05 Apr '23

05 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1176302 Bug ID: 1176302 Summary: keyboard: Switch kbd keyboard defaults to xkb based ones Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: sbrabec(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- In past, kbd had its own keymaps with different names and layouts than xkb. Several years ago we generated a set of new keymaps based on xkb keymaps, and moved old ones to the kbd-legacy sub-package. But these keymaps are still not used by default. To fix this situation, we have to: 1. Change YaST keymap selection. kbd keymap should have the same name as xkb keymap. 2a. Change keymap search path inside kbd. In case of name conflict prefer the one from /usr/share/kbd/keymaps/xkb. or 2b. When YaST will pick keymap, it will use fully qualified path. I would prefer 2a. 3. Write a migration %post script that will perform one-shot migration of legacy keymaps to xkb ones. (I will just fetch the history of keyboard/src/data/keyboards.rb 4. Remove kbd-legacy from the default installation. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1165282] New: Add browse option for selecting custom boot PBR
by bugzilla_noreply＠novell.com 05 Apr '23

05 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1165282 Bug ID: 1165282 Summary: Add browse option for selecting custom boot PBR Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: i686 OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: smetz3(a)gmu.edu QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- When installing with a custom boot, the installer has an entry field for the device into whose PBR the installer will write the loader. It would be nice to have a browse button that presented a list of all known partitions. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1159595] New: Installed vms use a path-id for suspend instead of uuid.
by bugzilla_noreply＠novell.com 05 Apr '23

05 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1159595 Bug ID: 1159595 Summary: Installed vms use a path-id for suspend instead of uuid. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: william.brown(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- When the system is installed with default partitioning (no changes), which should use UUID's, suspend to disk in /etc/default/grub is configured with swap by a path-id instead. This can lead to VM's that are unable to boot when their swap partition changes location (IE changing from virtio to scsi) or a hardware machine that changes pci paths in some way (relocation of a disk controller or disk controller replacement due to RMA etc). This causes machines to be unbootable because the resume=/dev/disk/path-id can never be resolved and has an infinite timeout. The machine then must be forced off and the resolution steps are unclear Work around is to add noresume at boot, and to edit /etc/default/grub post install to remove the resume option. See also: https://bugzilla.suse.com/show_bug.cgi?id=1159236 -- You are receiving this mail because: You are on the CC list for the bug.

2 7