From je-vv at e.email Fri May 2 03:44:04 2025 From: je-vv at e.email (Javier) Date: Thu, 1 May 2025 19:44:04 -0600 Subject: [artix-general] galaxy autofs needing rebuild and upgrade Message-ID: Hello ! With a recent artix upgrade, libxml2 moved from 2.13.8-1 to 2.14.2-2: > upgraded libxml2 (2.13.8-1 -> 2.14.2-2) As a consequence, software depending on libxml2 should have been re-built at least, given libxml2 doesn't offer even the same sonames: > % ls -l /usr/lib/libxml2.* > lrwxrwxrwx 1 root root 13 Apr 27 11:05 /usr/lib/libxml2.so -> libxml2.so.16* > lrwxrwxrwx 1 root root 17 Apr 27 11:05 /usr/lib/libxml2.so.16 -> libxml2.so.16.0.2* > -rwxr-xr-x 1 root root 1.3M Apr 27 11:05 /usr/lib/libxml2.so.16.0.2* If you notice, libxml2.so.2 is no longer available. Now, it so happens automount from galaxy autofs stopped working: > automount: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory One really quick work around, which works but doesn't seem the right one: > cd /usr/lib/ > ln -s libxml2.so libxml2.so.2 So with it: > % ls -l /usr/lib/libxml2.* > lrwxrwxrwx 1 root root 13 Apr 27 11:05 /usr/lib/libxml2.so -> libxml2.so.16* > lrwxrwxrwx 1 root root 17 Apr 27 11:05 /usr/lib/libxml2.so.16 -> libxml2.so.16.0.2* > -rwxr-xr-x 1 root root 1.3M Apr 27 11:05 /usr/lib/libxml2.so.16.0.2* > lrwxrwxrwx 1 root root 19 Apr 30 23:04 /usr/lib/libxml2.so.2 -> /usr/lib/libxml2.so* And guess what, with it the current "galaxy/autofs 5.1.7-1" works. I looked at the AUR current version which is "5.1.9-5", so it seems the galaxy autofs could get not just a necessary re-build, but also an upgrade. The AUR package without tweaks fails to build given the lack of systemd because it's build with systemd in mind. I guess tweaking the package to not build for/with systemd is not that complex. From [1] it seems it's about removing "--with-systemd" from the "./configure" script args. However I looked on [2] for autofs and didn't find it there to see how it was built on galaxy. That said, it seems the initial work around mentioned is good enough, and I just wanted to point out the package requires re-build and upgrade, :) Thanks ! -- Javier [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=autofs [2] https://gitea.artixlinux.org From artist at artixlinux.org Fri May 2 10:19:40 2025 From: artist at artixlinux.org (Carlo den Otter) Date: Fri, 2 May 2025 10:19:40 +0200 Subject: [artix-general] galaxy autofs needing rebuild and upgrade In-Reply-To: References: Message-ID: <3b94ae3d-5c57-48f6-a74e-af6391351002@artixlinux.org> Thx for reporting. It seems this pkg fell through the cracks during the universe to galaxy repo migration. Problem has been fixed. artist On 5/2/25 03:44, Javier wrote: > Hello ! > > With a recent artix upgrade, libxml2 moved from 2.13.8-1 to 2.14.2-2: > >> upgraded libxml2 (2.13.8-1 -> 2.14.2-2) > > As a consequence, software depending on libxml2 should have been > re-built at least, given libxml2 doesn't offer even the same sonames: > >> % ls -l /usr/lib/libxml2.* >> lrwxrwxrwx 1 root root?? 13 Apr 27 11:05 /usr/lib/libxml2.so -> >> libxml2.so.16* >> lrwxrwxrwx 1 root root?? 17 Apr 27 11:05 /usr/lib/libxml2.so.16 -> >> libxml2.so.16.0.2* >> -rwxr-xr-x 1 root root 1.3M Apr 27 11:05 /usr/lib/libxml2.so.16.0.2* > > If you notice, libxml2.so.2 is no longer available.? Now, it so > happens automount from galaxy autofs stopped working: >> automount: error while loading shared libraries: libxml2.so.2: cannot >> open shared object file: No such file or directory > > One really quick work around, which works but doesn't seem the right one: > >> cd /usr/lib/ >> ln -s libxml2.so libxml2.so.2 > > So with it: > >> % ls -l /usr/lib/libxml2.* >> lrwxrwxrwx 1 root root?? 13 Apr 27 11:05 /usr/lib/libxml2.so -> >> libxml2.so.16* >> lrwxrwxrwx 1 root root?? 17 Apr 27 11:05 /usr/lib/libxml2.so.16 -> >> libxml2.so.16.0.2* >> -rwxr-xr-x 1 root root 1.3M Apr 27 11:05 /usr/lib/libxml2.so.16.0.2* >> lrwxrwxrwx 1 root root?? 19 Apr 30 23:04 /usr/lib/libxml2.so.2 -> >> /usr/lib/libxml2.so* > > And guess what, with it the current "galaxy/autofs 5.1.7-1" works.? I > looked at the AUR current version which is "5.1.9-5", so it seems the > galaxy autofs could get not just a necessary re-build, but also an > upgrade. > > The AUR package without tweaks fails to build given the lack of > systemd because it's build with systemd in mind.? I guess tweaking the > package to not build for/with systemd is not that complex. From [1] it > seems it's about removing "--with-systemd" from the "./configure" > script args.? However I looked on [2] for autofs and didn't find it > there to see how it was built on galaxy. > > That said, it seems the initial work around mentioned is good enough, > and I just wanted to point out the package requires re-build and > upgrade, :) > > Thanks ! > From je-vv at e.email Mon May 12 21:51:26 2025 From: je-vv at e.email (Javier) Date: Mon, 12 May 2025 13:51:26 -0600 Subject: [artix-general] Has anyone gotten seatd stand alone (no elogind, no polkit) allowing yubikey to work as non root? Message-ID: When using seatd stand alone with no logind functionality such as elogind neither turnstile, one needs to include the non root user in each group required for the user to have access to the associated device. I believe there's no specific group for yubikeys being usb devices. I've read about udev rules, but I got before a yubikey usb-a working without udev rules, but I was using elogind which provided dbus seassion and I was launching polkit from sway. Now one needs to use polkit or seatd, but I guess not both (I tried it any ways without success), so I'm guessing polkit works when using elogind. I'm wondering if someone has gotten to be able to have access to the yubikey as non root user... Just in case: > % ykman info > WARNING: PC/SC not available. Smart card (CCID) protocols will not function. > ERROR: No YubiKey detected! > % doas ykman info > doas (vasqueja at m1) password: > Device type: YubiKey 5C Nano > Serial number: 29684086 > Firmware version: 5.7.1 > Form factor: Nano (USB-C) > Enabled USB interfaces: OTP, FIDO, CCID > > Applications > Yubico OTP Enabled > FIDO U2F Enabled > FIDO2 Enabled > OATH Enabled > PIV Enabled > OpenPGP Enabled > YubiHSM Auth Enabled You can see how as root the yubikey is actually detected, but not as non root. As root the yubikey is detected whether or not the pcscd daemon is running or not: > % ps auxww | grep pcscd > 216:root 9725 0.0 0.0 411360 7692 ? Ssl 13:06 0:00 /usr/bin/pcscd -f However as non root it never gets detected regardless... Thanks for any help/hint ! -- Javier From je-vv at e.email Tue May 13 03:32:24 2025 From: je-vv at e.email (Javier) Date: Mon, 12 May 2025 19:32:24 -0600 Subject: [artix-general] Has anyone gotten seatd stand alone (no elogind, no polkit) allowing yubikey to work as non root? In-Reply-To: References: Message-ID: <58c440b8-a7c2-4731-b252-b7f75b62be69@e.email> On 2025-05-12 01:51 PM, Javier wrote: > When using seatd stand alone with no logind functionality such as elogind neither turnstile, one needs to include the non root user in each group required for the user to have access to the associated device. > > I believe there's no specific group for yubikeys being usb devices.? I've read about udev rules, but I got before a yubikey usb-a working without udev rules, but I was using elogind which provided dbus seassion and I was launching polkit from sway.? Now one needs to use polkit or seatd, but I guess not both (I tried it any ways without success), so I'm guessing polkit works when using elogind. > > I'm wondering if someone has gotten to be able to have access to the yubikey as non root user... > > Just in case: > >> % ykman info >> WARNING: PC/SC not available. Smart card (CCID) protocols will not function. >> ERROR: No YubiKey detected! > >> % doas ykman info >> doas (vasqueja at m1) password: >> Device type: YubiKey 5C Nano >> Serial number: 29684086 >> Firmware version: 5.7.1 >> Form factor: Nano (USB-C) >> Enabled USB interfaces: OTP, FIDO, CCID >> >> Applications >> Yubico OTP????? Enabled >> FIDO U2F??????? Enabled >> FIDO2?????????? Enabled >> OATH??????????? Enabled >> PIV???????????? Enabled >> OpenPGP???????? Enabled >> YubiHSM Auth??? Enabled > > You can see how as root the yubikey is actually detected, but not as non root.? As root the yubikey is detected whether or not the pcscd daemon is running or not: > >> % ps auxww | grep pcscd >> 216:root????? 9725? 0.0? 0.0 411360? 7692 ???????? Ssl? 13:06?? 0:00 /usr/bin/pcscd -f > > However as non root it never gets detected regardless... > > Thanks for any help/hint ! > Effectively, moved to elogind + polkit and things work, I tested seatd + polkit which didn't work: > % ykman info > Device type: YubiKey 5C Nano > Serial number: 29684086 > Firmware version: 5.7.1 > Form factor: Nano (USB-C) > Enabled USB interfaces: OTP, FIDO, CCID > > Applications > Yubico OTP Enabled > FIDO U2F Enabled > FIDO2 Enabled > OATH Enabled > PIV Enabled > OpenPGP Enabled > YubiHSM Auth Enabled I'm wondering what's the magic to make seatd alone work... BTW, I browsed unsuccessfully on "/etc/group" for an usb related group, so that I could add my user into, but didn't find anything that ringed any bell to me, :( At least I can do it with elogind + polkit though I was happy not to depend on them, :( Again, any hint or info would be appreciated. Thanks ! -- Javier From ruben at mrbrklyn.com Wed May 14 04:21:32 2025 From: ruben at mrbrklyn.com (Ruben Safir) Date: Tue, 13 May 2025 22:21:32 -0400 Subject: [artix-general] [Hangout - NYLXS] Meeting and Hacking Artix Workshop tomorrow Message-ID: <1b9dc7ae-1eed-41a4-b16e-615d51bd2241@mrbrklyn.com> Here is some basic homework for tomorrows meeting. I am hoping we can make a windowmaker package as a first attempt to understand how pacman works. I'll have my laptop, but it never hurts to bring your. I actually need to convert that laptop to artix, being an older Lenovo thinkpad. Where: 333 Adams St, Brooklyn, NY 11201 Great Room Restaurant and Bar When: 7:30 At the Brooklyn Marriott Lounge. Thursdays - 7:30PM more or less. https://wiki.archlinux.org/title/Creating_packages Reuvain -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 _______________________________________________ Hangout mailing list Hangout at nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout From je-vv at e.email Fri May 16 05:40:07 2025 From: je-vv at e.email (Javier) Date: Thu, 15 May 2025 21:40:07 -0600 Subject: [artix-general] Has anyone gotten seatd stand alone (no elogind, no polkit) allowing yubikey to work as non root? In-Reply-To: <58c440b8-a7c2-4731-b252-b7f75b62be69@e.email> References: <58c440b8-a7c2-4731-b252-b7f75b62be69@e.email> Message-ID: <0f61a223-1802-4224-9614-980c8c377402@e.email> OK, found it, hehe. In several places this was suggested: > % doas groupadd plugdev > % doas gpasswd -a plugdev But that's not sufficient on artix, so I found a void bug [1] indicating that building "pcsclite" with polkit enabled breaks setups not using polkit. Then I went to see the PR fixing the bug [2] and all it did was to disable polkit on the build and remove the polkit dependency. Now looking forward to what void has on master on its build config [3] and I notice it's pretty much the same build config we have on artix [4] except void keeps disabling polkit, while artix enables it instead, and artix enables serial as well which void doesn't (although if the default is to enable things, then perhaps it's the same for both but I have no clue). Another difference is that artix depends on libpolkit-gobject and has a make dependency on polkit, while void doesn't. Curiously enough void offers polkit [5], so I guess the yubikey is working on void whether when users prefer polkit over seatd, and also when users prefer seatd over polkit. Guess what, I applied this patch: > % diff -Naur pcsclite.old/ pcsclite/ > diff -Naur pcsclite.old/PKGBUILD pcsclite/PKGBUILD > --- pcsclite.old/PKGBUILD 2025-04-02 13:49:23.000000000 -0600 > +++ pcsclite/PKGBUILD 2025-05-15 20:54:33.275892038 -0600 > @@ -18,12 +18,10 @@ > ) > depends=( > 'libudev.so' > - 'libpolkit-gobject-1.so' > ) > makedepends=( > 'git' > 'meson' > - 'polkit' > 'udev' > ) > optdepends=( > @@ -48,7 +46,7 @@ > local meson_options=( > -D libsystemd=false > -D libudev=true > - -D polkit=true > + -D polkit=false > -D serial=true > ) > artix-meson PCSC build "${meson_options[@]}" As you see, removing the dependencies of polkit, and disable polkit on the configuration, and with re-built the package, and with the prior group I set, things are working properly while using seatd instead of polkit, and yubikey works on Firefox and also this: > % ykman info > Device type: YubiKey 5C Nano > Serial number: 29684086 > Firmware version: 5.7.1 > Form factor: Nano (USB-C) > Enabled USB interfaces: OTP, FIDO, CCID > > Applications > Yubico OTP Enabled > FIDO U2F Enabled > FIDO2 Enabled > OATH Enabled > PIV Enabled > OpenPGP Enabled > YubiHSM Auth Enabled One of my prior attempts made that prior CLI work but Firefox was not recognizing the yubikey at all. With this void approach even Firefox (well Librefox) works fine. So no issues at all. So here it goes my question to the developers, can this patch be applied to artix? If not, can we have two packages providing pcsclite and conflicting with each other? > pcsclite-polkit > pcsclite-non-polkit I'm thinking just applying the patch will make everyone happy, as mentioned void supports both seatd and polkit, but I'll be happy if pcsclite-non-polkit exists as well. The idea is not to become out of date with the package getting upgrades as I normally do. Could devs help me out? Many thanks ! [1] [Building pcsclite with polkit enabled causes problems for existing setups](https://github.com/void-linux/void-packages/issues/47426) [2] [pcsclite: disable polkit](https://github.com/void-linux/void-packages/commit/0185054e91b57630840e7ce41e3f94cc2a0055bb) [3] [pcsclite void package template](https://github.com/void-linux/void-packages/blob/master/srcpkgs/pcsclite/template) [4] [pcsclite artix package PKGBUILD](https://gitea.artixlinux.org/packages/pcsclite/src/branch/master/PKGBUILD) [5] [polkit void package](https://github.com/void-linux/void-packages/tree/master/srcpkgs/polkit) -- Javier From ruben at mrbrklyn.com Fri May 16 23:11:00 2025 From: ruben at mrbrklyn.com (Ruben Safir) Date: Fri, 16 May 2025 17:11:00 -0400 Subject: [artix-general] NYLXS meeting and Artix Message-ID: Just a note - we had a few more folks come for drinks and discussion (pacman packaging ) this week and it was enjoyable... although I need to find a better venue. While it was quiet, the post-covid hotel lobby is not as accommodating as it once was for computer meetings. Still it was productive and we will start a workshop on pacman which I hope to supplement with some one line resources. The tutorials I am reading are all from Arch. I am wondering if we have artix specific content. Otherwise I will need to write it. I will aim for the next meeting in 2 weeks and open to suggestions for a local. I am thinking maybe in the dining area of Grand Central Station, which might me a decent compromise if we can secure some internet access. More...Quick EditQuote -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From je-vv at e.email Sun May 18 07:13:09 2025 From: je-vv at e.email (Javier) Date: Sat, 17 May 2025 23:13:09 -0600 Subject: [artix-general] Request to devs: can pcsclite be built with the option -D polkit=false Message-ID: Hello ! It so happens when using seatd and not polkit *pcsclite* as it is currently built doesn't allow yubikeys to work as a non root user. I just did what void, which supports both seatd and polkit do, to build *pcslite* with the *-D polkit=false* option, and now I can use my yubikey as non root flawlessly. Here it's my patch: > % diff -Naur pcsclite.old/ pcsclite/ > diff -Naur pcsclite.old/PKGBUILD pcsclite/PKGBUILD > --- pcsclite.old/PKGBUILD 2025-04-02 13:49:23.000000000 -0600 > +++ pcsclite/PKGBUILD 2025-05-15 20:54:33.275892038 -0600 > @@ -18,12 +18,10 @@ > ) > depends=( > 'libudev.so' > - 'libpolkit-gobject-1.so' > ) > makedepends=( > 'git' > 'meson' > - 'polkit' > 'udev' > ) > optdepends=( > @@ -48,7 +46,7 @@ > local meson_options=( > -D libsystemd=false > -D libudev=true > - -D polkit=true > + -D polkit=false > -D serial=true > ) > artix-meson PCSC build "${meson_options[@]}" I also, as the void package template do, removed polkit make and run time dependencies. I might be mistaken, but I believe this should work when using both seatd and polkit, since as mentioned void supports both seatd and polkit. According to *meson_options.txt*: > option('polkit', > type : 'boolean', > description : 'Use polkit to enforce access control') I don't know if that makes polkit require udev rules or not. But as the package is built, even with udev rules there's no way to get *pcsclite* fully work as non user (one might get ykman with udev rules, but browser wouldn't recognize the yubikey at all). It's only until it gets built with *-D polkit=false* that things truly work for seatd. Thanks a lot ! -- Javier From je-vv at e.email Sun May 18 23:57:14 2025 From: je-vv at e.email (Javier) Date: Sun, 18 May 2025 15:57:14 -0600 Subject: [artix-general] v4l-utils now provides edid-decode (could "edid-decode" be added in the "conflicts" and "provides" array for v4l-utils, ) Message-ID: <12e0f64f-e60a-4d84-be17-aaef64a7f165@e.email> With Today's upgrade I faced: > error: failed to commit transaction (conflicting files) > v4l-utils: /usr/bin/edid-decode exists in filesystem (owned by edid-decode-git) > v4l-utils: /usr/share/man/man1/edid-decode.1.gz exists in filesystem (owned by edid-decode-git) > Errors occurred, no packages were upgraded. Then I uninstalled edid-decode-git for the conflict to go away and guess what: > % pacman -Ql v4l-utils | 'grep' edid-decode > v4l-utils /usr/bin/edid-decode > v4l-utils /usr/share/man/man1/edid-decode.1.gz So it seems now v4l-utils provides edid-decode. I'm wondering if devs could avoid the conflict by adding "edid-decode" as part of the arrays *conflicts* and *provides* of the *v4l-utils* PKGBUILD? Thanks ! -- Javier From je-vv at e.email Fri May 23 08:53:28 2025 From: je-vv at e.email (Javier) Date: Fri, 23 May 2025 00:53:28 -0600 Subject: [artix-general] Are dinit service files protected from overwriting on upgrades? Message-ID: <0b5ed13b-5a02-4f56-9afb-609c175dc538@e.email> Hello ! I'm using "chrony" calling "chronyd" with "-r -s" options as shown on the chrony wiki [1] so that the RTC can be corrected on boot after deviations given the time the PD being turned off. But there's no easy way to do this on dinit like the systemd unit which reads the OPTIONS environment variable from "/etc/sysconfig/chronyd" as suggested by the referred wiki and also part of the systemd unit [2]. So what I did to pass those options to "chronyd" was to add them to the service file itself "/etc/dinit.d/chronyd": > command = /usr/bin/chronyd -r -s -n Notice how this can be lost without warning if on an upgrade the service file gets overwritten. So that brought me to ask if files under "/etc/dinit.d" in general are protected from being overwritten, getting instead a "pacnew" extension on the new files but keeping the prior one to the upgrade. That if I got it right gets specified on "backup" array of files to be protected. But I don't know if there's a more generic way to do so for things on "/etc". That said the "chrony-dinit" PKGBUILD [3] doesn't include any backup array. If there's a better way to achieve what I'm looking for without risking losing my changes, please let me know. Or perhaps the "chrony-dinit" package can be improved to allow such daemon options that's valid as well, :) Thanks ! -- Javier [1] https://wiki.archlinux.org/title/Chrony#Example:_intermittently_running_desktops [2] https://gitlab.com/chrony/chrony/-/blob/master/examples/chronyd.service#L13 [3] https://gitea.artixlinux.org/packages/chrony-dinit/src/branch/master/PKGBUILD From je-vv at e.email Fri May 23 09:01:29 2025 From: je-vv at e.email (Javier) Date: Fri, 23 May 2025 01:01:29 -0600 Subject: [artix-general] world/vagrant package requires upgrade Message-ID: Hello ! The current vagrant package on the world repo is sort of broken, first of all it requires a pretty old version of the package "ruby-rexml", actually 3.2.6-2, which can be achieved by preventing the package to be upgraded on "pacman.conf". But the current vagrant package, 2.4.3-1, besides that dependency fails on one of its internal ruby plugins that come with vagrant itself (I can't remember which) but the complaint was about requiring a version of that plugin higher than a value, and the inner plugin version was actually higher, so no way to fix that contradiction. All the vagrant problems went away when installing the current AUR package, currently on version 2.4.6-1, so this is the actual work around. But the package on world requires an upgrade then, to avoid the problems it's currently facing. Thanks ! -- Javier From je-vv at e.email Mon May 26 05:05:58 2025 From: je-vv at e.email (Javier) Date: Sun, 25 May 2025 21:05:58 -0600 Subject: [artix-general] libgit2 upgraded to 1:1.9.0-2.1, which depends on goblins llhttp 9.3 but opendht still depends on current world llhttp 9.2 without a goblins version depending on the goblins llhttp Message-ID: Hi ! Just so you know, with libgit2 upgrade it got broken by not finding "libllhttp.so.9.3": > error while loading shared libraries: libllhttp.so.9.3: cannot open shared object file: No such file or directory This because the current one on "world" is "9.2.1-2", but strangely enough libgit2 requires "9.3.0-1": > % ldd /usr/lib/libgit2.so > ... > libllhttp.so.9.3 => not found But that's not the only software depending on llhttp, also opendht does: > % pacman -Qi llhttp > Name : llhttp > Version : 9.2.1-2 > ... > Required By : libgit2 opendht But it doesn't depend on the goblins llhttp but rather the current world one: > % ldd /usr/lib/libopendht.so > ... > libllhttp.so.9.2 => /usr/lib/libllhttp.so.9.2 (0x00007ba82cdb9000) Sadly that means the problem doesn't go away by just grabbing the goblins llhttp, that has to wait until besides it there's a goblins opendht built on top of that goblins llhttp (9.3). So moving forward there's no easy solution but to also bring opendht to be built with the goblins llhttp and bring those two together then. And the same for all other software depending on llhttp. That said, there's a workaround, just downgrade libgit2 to version prior to Today's upgrade (1:1.9.0-2) and make pacman ignore upgrades to libgit2, so that it remains on its prior world version without upgrading until both opendht and llhttp get upgraded together and not just llhttp. BTW, the same applies to other packages/software which depends on llhttp, whether depending already on the goblins llhttp, or yet depending on the current world llhttp (the goblins one can't just be pushed yet, unless there are goblins versions of the depending software build on top of the goblins llhttp). Greetings ! -- Javier