October 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1203617] In plasma5 midnight commander doesn't exit to current directory anymore
by bugzilla_noreply＠suse.com 07 Oct '24

07 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1203617 https://bugzilla.suse.com/show_bug.cgi?id=1203617#c77 Dr. Werner Fink <werner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|werner(a)suse.com |amajer(a)suse.com CC| |werner(a)suse.com --- Comment #77 from Dr. Werner Fink <werner(a)suse.com> --- (In reply to David Rankin from comment #76) > I can confirm on TW, that mc does not exit to the current directory any > longer when sourcing mc-wrapper.sh as the mc startup. Instead, mc reverts > back to exiting to the start directory regardless of the current directory. > The mc-wrapper.sh script has worked for -- ever. So something broke that > setup. This has nothing todo with this bug. The shells do now their jobs with my changes to aaa_base. The rest is the job of mc, see e.g. /usr/share/mc/mc-wrapper.sh MC_USER=`whoami` MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$" /usr/bin/mc -P "$MC_PWD_FILE" "$@" [...] ... and accoringly to man manual page of mc -P file, --printwd=file Print the last working directory to the specified file. This option is not meant to be used directly. Instead, it’s used from a special shell script that automatically changes the current directory of the shell to the last directory Midnight Commander was in. Source the file /usr/libexec/mc/mc.sh (bash and zsh users) or /usr/libexec/mc.csh (tcsh users) respectively to define mc as an alias to the appropriate shell script. I guess that simply the pwd is not that what you expect. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175930] mc: Midnight Commander start slow
by bugzilla_noreply＠suse.com 07 Oct '24

07 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1175930 https://bugzilla.suse.com/show_bug.cgi?id=1175930#c5 --- Comment #5 from Matej Cepl <mcepl(a)suse.com> --- (In reply to David Rankin from comment #4) > As a workaround, using -u --nosubshell allows mc to start normally on the > box with the problem. There are many references to this issue around the > net, but no solution I could find. Thank you, that’s a nice workaround. And yes, I can confirm, that even for me (while working in Distrobox, I am on MicroOS) `mc -u` starts instantaneously, otherwise I can reproduce the problem 100%. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203617] In plasma5 midnight commander doesn't exit to current directory anymore
by bugzilla_noreply＠suse.com 07 Oct '24

07 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1203617 https://bugzilla.suse.com/show_bug.cgi?id=1203617#c76 David Rankin <drankinatty(a)suddenlinkmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drankinatty@suddenlinkmail. | |com --- Comment #76 from David Rankin <drankinatty(a)suddenlinkmail.com> --- I can confirm on TW, that mc does not exit to the current directory any longer when sourcing mc-wrapper.sh as the mc startup. Instead, mc reverts back to exiting to the start directory regardless of the current directory. The mc-wrapper.sh script has worked for -- ever. So something broke that setup. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175930] mc: Midnight Commander start slow
by bugzilla_noreply＠suse.com 07 Oct '24

07 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1175930 https://bugzilla.suse.com/show_bug.cgi?id=1175930#c4 David Rankin <drankinatty(a)suddenlinkmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drankinatty@suddenlinkmail. | |com --- Comment #4 from David Rankin <drankinatty(a)suddenlinkmail.com> --- I can confirm this behavior of slow mc start (on a seeming random basis) on Arch, but I haven't seen it on openSUSE yet. Some Arch boxes have no issue, on one it takes 30 seconds (a very long 30 seconds) for mc to start. As a workaround, using -u --nosubshell allows mc to start normally on the box with the problem. There are many references to this issue around the net, but no solution I could find. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231326] [UX Suggestion] on desktop environment selection
by bugzilla_noreply＠suse.com 07 Oct '24

07 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231326 https://bugzilla.suse.com/show_bug.cgi?id=1231326#c1 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Stefan Hundhammer <shundhammer(a)suse.com> --- We had that many, many years back, and we finally had to remove it again: The size we can realistically add there is much too small to get even the slightest idea what the deskop really looks like. When you scale down a screenshot of a desktop, what is left over to see? Just the background image (which is really completely meaningless to present anything about the desktop) and the outline of some windows. If you go through the artwork pages of the various desktops, you will find that they all look the same except for the background image; and what does that help anybody to find out which one is best? A new user can't get any useful information from that. A screenshot cannot do a desktop the justice it deserves. Plus, it's the machine's role which is not limited to desktops; there are also various server roles; and for them, there could only be either a nondescript icon or no image at all; and having roles with and without an image breaks the whole visual representation. And for business products, those various server roles are the vast majority. It sounded like a good idea back then, but even then it was flawed from the start. This is one of the examples that ideas come and go in cycles. Inevitably, new people will rediscover ideas that have already been brought forward, implemented, tested, found not nearly as good as they sounded, and reverted again. ;-) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231326] New: [UX Suggestion] on desktop environment selection
by bugzilla_noreply＠suse.com 06 Oct '24

06 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231326 Bug ID: 1231326 Summary: [UX Suggestion] on desktop environment selection 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: marcelo.ultraje(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- In the selection of visual environments, it would be helpful to include an image of each one. It would be a small change, but I’ve never seen some of them from this list, and I had to search on Google to get an idea of what they look like visually. i think is a simple improvment that can help users (its a common issue on linux installation but, i think it can help new users) i know theres a great doc but... it isnt present during system installation displaying visually the options can feel https://www.suse.com/c/centos-alternatives-opensuse-choosing-your-own-desti… -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1177837] Installed applications show up in Launcher with a generic icon and only if you type exact complete name
by bugzilla_noreply＠suse.com 06 Oct '24

06 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1177837 https://bugzilla.suse.com/show_bug.cgi?id=1177837#c4 hui <sturm-fr(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NORESPONSE --- Comment #4 from hui <sturm-fr(a)web.de> --- 4 years later we have now Plasma 6 in Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198798] librubberband: update to 2.0.2 or later
by bugzilla_noreply＠suse.com 06 Oct '24

06 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1198798 https://bugzilla.suse.com/show_bug.cgi?id=1198798#c2 hui <sturm-fr(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from hui <sturm-fr(a)web.de> --- librubberband2-3.1.0 in Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1229909] New: Discord outdated (0.0.65 > 0.0.66) and crashes in current non-oss Tumbleweed Repos
by bugzilla_noreply＠suse.com 06 Oct '24

06 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229909 Bug ID: 1229909 Summary: Discord outdated (0.0.65 > 0.0.66) and crashes in current non-oss Tumbleweed Repos 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: coldreactive(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 877018 --> https://bugzilla.suse.com/attachment.cgi?id=877018&action=edit Log for when it crashed. Packman version for whatever reason doesn't crash. Originally made a thread on the openSUSE Forums for troubleshooting: https://forums.opensuse.org/t/discord-keeps-crashing-when-hovering-over-gif… See attached text file for terminal output of what was going on during operation. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1231325] dracut-pcr-signature races with udev for ESP symlinks
by bugzilla_noreply＠suse.com 06 Oct '24

06 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231325 https://bugzilla.suse.com/show_bug.cgi?id=1231325#c2 --- Comment #2 from Andrei Borzenkov <arvidjaar(a)gmail.com> --- (In reply to Andrei Borzenkov from comment #0) > Because currently there is obvious race condition between multiple encrypted > device, each attempting to mount and then unmount LoaderDevice. Having the > proper mount unit will solve this as well. > > Hmm ... I expected that it would race with /boot/efi mount on Tumbleweed, I stay corrected in both cases. /boot/efi is not mounted in initrd, dracut only adds its device to wait for and this it does exactly the same in MicroOS. And it is possible to do read-only mount several times concurrently. Anyway, at the end is proof-of-concept generator that adds dependency on the ESP device. It intentionally does Wants, not Requires, because we want to boot even if something fails here. With it I get ... Oct 06 18:35:00 localhost systemd[1]: Expecting device /dev/disk/by-partuuid/656ba952-d4ff-44c2-8eaf-3f6d5011708f... ... which is likely one of those (oh, joy of mostly useless systemd messages) Oct 06 18:35:01 localhost systemd[1]: Found device QEMU_HARDDISK p.lxroot. Oct 06 18:35:01 localhost systemd[1]: Found device QEMU_HARDDISK EFI. Oct 06 18:35:01 localhost systemd[1]: Found device QEMU_HARDDISK EFI. ... and only after physical disks are confirmed to be present it starts cryptsetup Oct 06 18:35:01 localhost systemd[1]: Starting Cryptography Setup for cr_root... At least, it survived now the usual cold boot test. Of course, any extra code changes timings. I am afraid, the only way to intentionally reproduce the problem is to add the artificial delay to udev rule for the ESP device (to delay symlink creation). E.g. by calling "/bin/sleep 5". So, the generator code ====================== #!/bin/bash set -euo pipefail # If GRUB2 is used, bli.mod needs to be loaded EFIVAR="/sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f" [ -e "$EFIVAR" ] || exit 0 # Read the value of the EFI variable, that contains a header and ends # with '\0' and make it lowercase ESP_UUID="$(dd "if=$EFIVAR" bs=2 skip=2 conv=lcase status=none | tr -d '\0')" DEV="dev-disk-by\\x2dpartuuid-${ESP_UUID//-/\\x2d}.device" mkdir -p "$1/systemd-cryptsetup@.service.d" cat > "$1/systemd-cryptsetup@.service.d/wait-for-ESP.conf" << EOF [Unit] Wants=$DEV After=$DEV EOF exit 0 -- You are receiving this mail because: You are on the CC list for the bug.

1 0