May 2022 - openSUSE Users - openSUSE Mailing Lists

15.4 Beta - Hangs on shutdown (will not turn off - stops with unresponsive text login shown)
by David C. Rankin 19 May '22

19 May '22

All, 15.4 hangs on shutdown. It can reboot, but doesn't release drive making the 15.4 drive unavailable for subsequent boot until a full shutdown is performed. Several releases ago this was also an issue. I'm on 15.0 now, but will shutdown and reboot into 15.4 and check journal and follow-up. Is there a known issue or list of things to check if the journal doesn't provide anything conclusive. (if I recall from last time it wasn't much help) -- David C. Rankin, J.D.,P.E.

1 1

Re: Request of testing new fingerprint reader library
by Lukáš Krejza 18 May '22

18 May '22

Dne čtvrtek 19. května 2022 0:04:06 CEST, Neal Gompa napsal(a): > On Wed, May 18, 2022 at 5:51 PM Lukáš Krejza <gryffus(a)hkfree.org> wrote: > > Hello list(s), > > > > we, together with Florian "Sp1rit" have created packages for "new" > > libfprint- tod library/fork, which is going to replace current one used > > in distribution. This library has advantage of loading external drivers > > as libraries, typically closed source ones. These closed source drivers > > are soon going to appear on Packman as "libfprint2-tod1-*" packages (the > > SR is pending). The library source code is located on > > https://gitlab.freedesktop.org/3v1n0/libfprint/-/ tree/tod and is always > > re-based on current libfprint "upstream". It is also the default one in > > Ubuntu, Arch and Debian (if i checked correctly). > > > > We are able to test the closed source drivers, since we have access to > > devices using them. However, what we cannot test are fingerprint readers, > > that are supported directly by libfprint library. > > > > For this, i would like to ask anyone, who is using his fingerprint reader > > on openSUSE Tumbleweed with libfprint library to test with this new > > library using following steps: > > > > 1) Add home:sp1rit:factory repository: > > :~> sudo zypper ar --refresh --name libfprint-tod https:// > > > > download.opensuse.org/repositories/home:/sp1rit:/factory/openSUSE_Tumblewe > > ed/ home:sp1rit:factory.repo > > > > 2) Install libfprint-2-2 package from it (and do NOT install libfprint-2- > > > > tod1): > > :~> sudo zypper in --from libfprint-tod libfprint-2-2 fprintd > > > > 3) Open one terminal window, su to root and start fprintd in debug mode: > > :~> su [enter] > > :~ # env G_MESSAGES_DEBUG=all /usr/libexec/fprintd > > > > 4) Open second terminal window and enroll or verify fingerprint (as normal > > > > user): > > :~> fprintd-enroll > > > > or > > > > :~> fprintd-verify > > > > That is all. After this test, please send us output from the terminal > > window, that you started fprintd in debug mode (step 3) in. You can use > > https:// paste.opensuse.org/ for that. > > > > For switching back to original libfprint, just remove the repository: > > :~> sudo zypper rr libfprint-tod > > > > and install original libfprint > > > > :~> sudo zypper in libfprint-2-2 fprintd > > > > That should be all. > > > > @Fridrich, @Matthias, @Timo: > > I am CCing you in case you missed discussion that happened on Factory ML. > > If you have any objection against planned switch, please step up now. We > > will be doing SR to hardware/libfprint in forthcomming days, when we get > > some confirmation that it is working correctly for the users using > > "native" libfprint. > > > > Thanks very much to everyone involved for helping openSUSE get better and > > better! > > Is there any plan to reconcile this back into mainline? Or is this a > permanent incompatible fork of libfprint? The previous discussion[1] > didn't seem to indicate there was any such plan going on. It seems > kind of bad to switch to a fork like this without at least some kind > of plan for reconciling them. > > [1]: > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/ > 6R75CILJ3GAUSKMNJ7ERYZLH75QF5UHX/ The original plan was to do that, but since it has not been the case yet (and it is already some time that this fork exist), distributions started to switch to this one for the time being. It does not seem that this fork will merge back to mainline anytime soon, so we are just following general "trend" of other distros to support more use-cases and hardware for the users. Also, the mainline devs are actively solving bugs reported by users using the "-tod" fork, as you can see for example here: https://gitlab.freedesktop.org/ libfprint/libfprint/-/issues/436 . Also, developers themselves are pointing users to the fork, as you can see here: https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/267 Regards, Gryffus

1 0

Request of testing new fingerprint reader library
by Lukáš Krejza 18 May '22

18 May '22

Hello list(s), we, together with Florian "Sp1rit" have created packages for "new" libfprint- tod library/fork, which is going to replace current one used in distribution. This library has advantage of loading external drivers as libraries, typically closed source ones. These closed source drivers are soon going to appear on Packman as "libfprint2-tod1-*" packages (the SR is pending). The library source code is located on https://gitlab.freedesktop.org/3v1n0/libfprint/-/ tree/tod and is always re-based on current libfprint "upstream". It is also the default one in Ubuntu, Arch and Debian (if i checked correctly). We are able to test the closed source drivers, since we have access to devices using them. However, what we cannot test are fingerprint readers, that are supported directly by libfprint library. For this, i would like to ask anyone, who is using his fingerprint reader on openSUSE Tumbleweed with libfprint library to test with this new library using following steps: 1) Add home:sp1rit:factory repository: :~> sudo zypper ar --refresh --name libfprint-tod https:// download.opensuse.org/repositories/home:/sp1rit:/factory/openSUSE_Tumblewee… home:sp1rit:factory.repo 2) Install libfprint-2-2 package from it (and do NOT install libfprint-2- tod1): :~> sudo zypper in --from libfprint-tod libfprint-2-2 fprintd 3) Open one terminal window, su to root and start fprintd in debug mode: :~> su [enter] :~ # env G_MESSAGES_DEBUG=all /usr/libexec/fprintd 4) Open second terminal window and enroll or verify fingerprint (as normal user): :~> fprintd-enroll or :~> fprintd-verify That is all. After this test, please send us output from the terminal window, that you started fprintd in debug mode (step 3) in. You can use https:// paste.opensuse.org/ for that. For switching back to original libfprint, just remove the repository: :~> sudo zypper rr libfprint-tod and install original libfprint :~> sudo zypper in libfprint-2-2 fprintd That should be all. @Fridrich, @Matthias, @Timo: I am CCing you in case you missed discussion that happened on Factory ML. If you have any objection against planned switch, please step up now. We will be doing SR to hardware/libfprint in forthcomming days, when we get some confirmation that it is working correctly for the users using "native" libfprint. Thanks very much to everyone involved for helping openSUSE get better and better! Regards and happy hacking, Gryffus

1 0

How to disable Green screen with 3-squares on boot? Remove all plymouth? (nvidia driver)
by David C. Rankin 18 May '22

18 May '22

All, How do I get rid the the green boot screen with the three little squares that light a bit? I have the nvidia driver installed, so I think that kills anything useful the screen does. On 15.0 it was something like rpm -e all of plymouth. Will that still work or is there an easier way just to disable it? -- David C. Rankin, J.D.,P.E.

2 2

With Beta do we 'zypper up' or 'zypper dup' to update packages? (growing list of NOT installed)
by David C. Rankin 18 May '22

18 May '22

All, I don't know why, but I seem to recall that with a Beta release, we should 'zypper dup' to update packages instead of 'zypper up'. I've been doing 'zypper up' out of habit and I have a growing list of The following 22 package updates will NOT be installed: Is this due to using 'up' instead of 'dup' on a Beta or is this just newer versions blocked due to "vendor change" not being automatically allowed? -- David C. Rankin, J.D.,P.E.

3 4

15.4 Beta - Update or patch keepassxc for bug 7813 (natural sort)
by David C. Rankin 18 May '22

18 May '22

Devs, keepassxc is currently ver 2.6.6. This is an older keepassxc that doesn't provide a natural sort of the entries: https://github.com/keepassxreboot/keepassxc/issues/7813 In the current version for 15.4, entries sort: A B ... Y Z a b ... y z For large collections of entries, this makes it impossible to find the key you are looking for unless you can remember whether you started the Title with an uppercase or lowercase letter. This is fixed in current version 2.7.1 and you get a natural case-insensitive sort for the entries. -- David C. Rankin, J.D.,P.E.

2 2

[oS-en] XFCE problem: when there is no internet, xfce fails to restore the session
by Carlos E. R. 17 May '22

17 May '22

XFCE problem: when there is no internet, xfce fails to restore the session On boot, I have to login, make sure the network manager connection activates (the connection is slow, via tethering), and when it connects, i have to kill the X session with ctrl-alt-backspace twice, so that session is not saved. When it restarts, then it recovers the per-pre-session, the correct one. I have been experiencing this on two computers, but only now identified to origin. -- Cheers / Saludos, Carlos E. R. (from 15.3)

1 0

Unnecessary .spec entry: Obsoletes: keepassx < 2.0.4 (prevents install of non-conflicting package)
by David C. Rankin 17 May '22

17 May '22

Devs, I just spent 30 minutes rebuilding keepassxc to remove the unneeded line in the .spec of Obsoletes: keepassx < 2.0.4 keepassxc does not conflict with keepassx in any way. All the Obsoletes does is prevent someone from building and installing both at the same time. Linux is about choice, and if I choose to install both so I can edit my older keepassx files before import into keepassxc -- then I should be able to do so. The changelog states this was done because keepassx depends on Qt4 and at some point that dependency will no longer be available. I get that. But while it is -- don't put Obsoletes in the keepassxc file, because the Qt4 files are still available. In fact there are Qt6 packages that specifically provide the Qt6 & Qt4 dependencies because Qt4 isn't completely gone yet. Even when it isn't packages by openSUSE any longer, if I'm creative enough to provide the dependency on my own, the keepassxc package shouldn't be so arrogant as to tell me it's either one or the other, but I can't have both installed. That's just categorically false. I'd expect something like this on Windows, but not Linux. I would certainly vote to remove this line from the .spec before the actual 15.4 release. (not to mention the keepassxc package is a full 68X larger than keepassx and takes about that many times longer to build), e.g. -rw-r--r-- 1 david david 773248 May 17 00:33 keepassx-0.4.3-9.1.x86_64.rpm -rw-r--r-- 1 david david 51992192 May 17 01:19 keepassxc-2.6.6-bp154.2.59.x86_64.rpm -rw-r--r-- 1 david david 998640 May 17 01:19 keepassxc-lang-2.6.6-bp154.2.59.noarch.rpm Poor laptop thought it was building PHP again...... -- David C. Rankin, J.D.,P.E.

2 1

Re: X virtual frame buffer
by Roger Oberholtzer 17 May '22

17 May '22

Auto-login makes no difference here. I wish I had access to the system now, but it is not currently available. The X log ends saying that as no display was found, X will not be started. I need to find a way to not have the X server do that. Those were the three options I was considering. On Mon, May 16, 2022 at 5:43 PM Bill Swisher <bill(a)luddites.org> wrote: > > On 5/16/22 04:10, Roger Oberholtzer wrote: > > Hmmmm...what I do is let the remote computer boot with my profile doing an > auto-login, available in yast/user/advanced. I have 'alias ssh="ssh -X"', I > haven't found many things that won't work from a xterm. I just need to know how > to get to them, I spend a lot of my time in a xterm. They run really slow over > the internet, slowly over the WiFi and better over a 1Gbs switch, but they do > seem to work. I just tested LibreOffice, which I have 'alias > oo="/usr/bin/libreoffice"', the oo is a relic from OpenOffice. vlc useless and > complains about the audio when I screw up and try to run it at 1Gbs. Hope this > helps, if not then sorry to have taken up your time. -- Roger Oberholtzer

1 0

TW fish filesystem bug in Dolphin.
by Ariez Vachha - openSUSE 17 May '22

17 May '22

TW fish filesystem bug in dolphin. Dolphin tries to open directories such as conf.d as a regular file when clicked on. Navigating via the address bar works fine. The underlying sshfs fused filesystem is working fine i.e. F4 open terminal in Dolphin and changing directory works fine. How to reproduce: 1. Open fish://server.com/some-dir/ 2. Open directory with .d extension by clicking Expected result; directory opens in dolphin Observed result; dolphin tries to open the directory as a regular file. Regards, Ariez ajv(a)opensuse.org

1 1