May 2022 - openSUSE Users - openSUSE Mailing Lists

problem with MAX_DAYS_IN_TMP= ??
by jdd＠dodin.org 22 May '22

22 May '22

zypper ref says on my 15.3: Repository 'SUSE:SLE-15-SP3:GA' is invalid. I find in https://www.suse.com/support/kb/doc/?id=000018127 Resolution Please clean up temporary directories in /tmp or /var/tmp. Do have the system clean up these directories on boot please edit /etc/sysconfig/cron and change the values for: but in this cron file I see ## The Parameters MAX_DAYS_IN_TMP, MAX_DAYS_IN_LONG_TMP, TMP_DIRS_TO_CLEAR, ## LONG_TMP_DIRS_TO_CLEAR, CLEAR_TMP_DIRS_AT_BOOTUP and OWNER_TO_KEEP_IN_TMP have ## been converted to systemd-tmpfiles settings in /etc/tmpfiles.d/tmp.conf. ## Please check and modify to your needs. ## See 'man tmpfiles.d' for details. there is no tmp.conf file on my 15.3 install and the tmpfiles.d man page is not that clear for me. any help? notice than cleaning the tmp dir manually didn't help (but I can't reboot just now) thanks jdd -- http://dodin.org http://valeriedodin.com

5 8

Upgrade of 15.3 to 15.4 (beta? rc?) went fine
by cagsm 21 May '22

21 May '22

Users, upgrading online some 15.3 to 15.4 just today (beta? rc?) via zypper and golbal parameter --releasever=15.4 went fine over here with a rather simple test system. Too bad 15.4 is very conservative and old in various software versions and so on. Is a tumbleweed more suited when not wanting to risk stability and not opting in for data loss? ty

5 12

15.4 Beta Report - All Good (2 Bugs Filed - 3 Bugs Fixed) Working Like a Champ
by David C. Rankin 21 May '22

21 May '22

All, Short report on 15.4 Beta, after relatively smooth install, ext4 w BIOS Boot, / and /home, Minimal Desktop, (IceWM), Addition and install of KDE3, two bugs filed: * https://bugzilla.opensuse.org/show_bug.cgi?id=1199473 (Not a kde bug - Gnome stripped subcategories from xdg menu (grab 15.3 package) * https://bugzilla.opensuse.org/show_bug.cgi?id=1199643 (both icon-select and shortcut dialog issues - FIXED; Yasuhiko Kamata has been a Rock Star) While I haven't gotten to cinelerra yet or kdevelop, etc..., all other desktop aspects: * libreoffice, Tbird, FF. gcc-7 and gcc-11 installed and working fine. * OO calc has a full-screen hang if launched on first use through the calc icon, but launching libreoffice starts windowed and choosing calc there opens calc windowed setting whatever wasn't set causing hang. * goal of Qt4 removal may be a bit premature, issues remain, but factory:frameworks5 repo contains all qt6-4 libs, so there is a ready workaround while the transition takes place. * No showstoppers, great job all and kudos to the openSUSE/SLE devs. Looks like 15.4 is a keeper. -- David C. Rankin, J.D.,P.E.

1 1

list directory in ext4 filesystem
by Dave Howorth 20 May '22

20 May '22

Is there any way to display the contents of a directory in an ext4 filesystem? I don't mean an ls, I mean a byte by byte inspection of the actual directory structure. I have what is apparently a rather large directory, which is also empty: $ ls -ld files/ drwxr-xr-x 2 motion motion 3215360 May 9 00:55 files/ $ ls -l files/ total 0 od for example won't open it: $ od files od: files: read error: Is a directory 0000000 it's on the root filesystem which is supposedly clean: $ sudo e2fsck -n -v /dev/root e2fsck 1.42.5 (29-Jul-2012) Warning! /dev/root is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. root: clean, 90733/897600 files, 1419737/3583744 blocks (it's a rather old SD-card-based system I'd rather not reinstall) I'm tempted to just delete the directory and recreate it, but I'd like to understand what happened first if I can.

2 1

Will 15.2 cinelerra repo work for 15.4?
by David C. Rankin 20 May '22

20 May '22

Devs, The last cinelerra repo is 15.2: https://cinelerra-gg.org/download/pkgs/leap15.2/ Will that be compatible with 15.4 from a library standpoint? I know some packages like virtualbox, cinelerra, etc.. are relatively generic from a build version standpoint. -- David C. Rankin, J.D.,P.E.

3 2

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

19 May '22

Dne čtvrtek 19. května 2022 10:45:04 CEST, Benjamin Berg napsal(a): > Hi, > > On Thu, 2022-05-19 at 00:17 +0200, Lukáš Krejza wrote: > > Dne čtvrtek 19. května 2022 0:04:06 CEST, Neal Gompa napsal(a): > > > > 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. > There never was a plan to merge the TOD branch back into libfprint > upstream. > > For any driver that is open source, we are or course happy to work with > the developers to integrate it into upstream libfprint. > > The TOD branch exists to enable non-free code to be loaded (into the > GPL'ed fprintd binary). There are good reasons for me to accept that > this is happening and I have little power to do anything against it. > However, I hope that there is no false impression that upstream > libfprint is condoning the existence of the TOD branch and non-free > drivers in particular. > > > 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 . > > Not really. The TOD fork just adds an extra feature that allows side > loading more code. It makes little sense to ignore valid bug reports > for the main library. Doing so would be detrimental to everyone, > including users of upstream libfprint. > > All I am doing in that bug is not actively sabotaging users of the TOD > fork as there is a benefit to everyone. > > > Also, developers themselves are pointing users to the fork, as you can see > > here: https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/267 > > People wear multiple hats, so the line can be blurry. The person > posting the link contributed the goodixmoc driver, and is likely also > involved with the non-free goodix driver that appears to exists for > other chipsets. > > I didn't delete the reference. But I also don't feel that the > discussion there gives the impression that upstream is condoning the > existence of the TOD branch and loading non-free code. > > Benjamin Thank you Benjamin for explaining your opinion about the situation and clearing it out further. I have contacted board and asked for their decision, they should have also ability to contact SUSE legal team, if required. Regards, Gryffus

1 0

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