From dudemanguy at artixlinux.org Tue Dec 1 00:16:25 2020 From: dudemanguy at artixlinux.org (Dudemanguy) Date: Mon, 30 Nov 2020 17:16:25 -0600 Subject: [artix-general] [s6] alsactl restore not working after boot In-Reply-To: <5e6a92f2-c2d0-7073-e75f-a56ccb32040d@e.email> References: <74676e65-f573-0b1c-0fdd-c941508a426b@e.email> <52fcf3ab-3969-53ec-794b-d665af1c096c@e.email> <627bf199-9e1c-3628-53a9-9fb1a8909dd0@artixlinux.org> <5e6a92f2-c2d0-7073-e75f-a56ccb32040d@e.email> Message-ID: <7199109b-87ad-7ad9-1475-7bc77e6a6c33@artixlinux.org> On 11/30/20 4:55 PM, Javier via artix-general wrote: > Found these guys on gremlins:? clamav-s6 cryptsetup-s6 lvm2-s6 > s6-scripts, so I upgraded them to the gremlins versions, except by > clamav-s6, which gremlins' version is pretty old compared to the world > one (perhaps a stuck package in gremlins needing removal?).? But > unfortunately no luck.? Same message after boot...? BTW, I did 2 reboots > after the upgrade, with a "alsactl store" in the middle just in case, > and same results. > > Did I miss upgrading something? > > Thanks ! There definitely shouldn't be a clamav-s6 in gremlins. Not sure what happened there. Did alsa-utils-s6 upgrade for you yet? That's in world. From je-vv at e.email Tue Dec 1 02:07:27 2020 From: je-vv at e.email (Javier) Date: Mon, 30 Nov 2020 19:07:27 -0600 Subject: [artix-general] [s6] alsactl restore not working after boot In-Reply-To: <7199109b-87ad-7ad9-1475-7bc77e6a6c33@artixlinux.org> References: <74676e65-f573-0b1c-0fdd-c941508a426b@e.email> <52fcf3ab-3969-53ec-794b-d665af1c096c@e.email> <627bf199-9e1c-3628-53a9-9fb1a8909dd0@artixlinux.org> <5e6a92f2-c2d0-7073-e75f-a56ccb32040d@e.email> <7199109b-87ad-7ad9-1475-7bc77e6a6c33@artixlinux.org> Message-ID: <95d67cfd-6d1c-022e-05a9-337dfeae3196@e.email> On 11/30/20 5:16 PM, Dudemanguy via artix-general wrote: > On 11/30/20 4:55 PM, Javier via artix-general wrote: >> Did I miss upgrading something? >> >> Thanks ! > > There definitely shouldn't be a clamav-s6 in gremlins. Not sure what > happened there. Did alsa-utils-s6 upgrade for you yet? That's in world. I guess it was a matter of time to get alsa-utils-s6 besides the other s6 scripts... I already got Today's version of alsa-utils-s6, along with the other s6 scripts updates, and I didn't get the message after boot anymore, and if I open alsamixer it looks like the one I set prior to the reboot... Thanks a lot ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Tue Dec 1 02:34:46 2020 From: je-vv at e.email (Javier) Date: Mon, 30 Nov 2020 19:34:46 -0600 Subject: [artix-general] [artix-gen] python2-pillow missing to provide "python2-pillow6", which is required by kodi Message-ID: <6a21275a-3975-2c2d-5fc5-d571e6544536@e.email> On arch community repo python2-pillow provides python2-pillow6, which is required by kodi, but the artix galaxy repo python2-pillow is a bit out of sync with the arch one and doesn't provide it. Therefore, in order to get kodi in the system, the arch community package is required and used, rather than the galaxy one... I think the galaxy one requires to get in sync with the arch one. Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From shironeko at waifu.club Wed Dec 2 11:10:56 2020 From: shironeko at waifu.club (Yunxiang Li) Date: Wed, 02 Dec 2020 18:10:56 +0800 Subject: [artix-general] Fixes for dbus-s6 Message-ID: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> In dbus-s6 the init script overwrites /etc/machine-id everytime, however machine-id should not change across reboots. This causes problems for programs that expects this behavior, like pulseaudio which stores their setting in a file named after the machine-id, therefore it will not remember the settings if rebooted. The fix is simple, change the second line of /etc/s6/sv/dbus-srv/run to foreground { dbus-uuidgen --ensure=/etc/machine-id } It might be better to use the default location for the machine-id, which is /var/lib/dbus/machine-id and make /etc/machine-id a symlink to it, in which case we can just use foreground { dbus-uuidgen --ensure } I'm not sure how would this change be done tho, at least /var/lib/dbus needs to be created somehow. From dudemanguy at artixlinux.org Thu Dec 3 01:44:03 2020 From: dudemanguy at artixlinux.org (Dudemanguy) Date: Wed, 2 Dec 2020 18:44:03 -0600 Subject: [artix-general] Fixes for dbus-s6 In-Reply-To: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> References: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> Message-ID: On 12/2/20 4:10 AM, Yunxiang Li via artix-general wrote: > In dbus-s6 the init script overwrites /etc/machine-id everytime, however > machine-id should not change across reboots. This causes problems for programs > that expects this behavior, like pulseaudio which stores their setting in a file > named after the machine-id, therefore it will not remember the settings if > rebooted. > > The fix is simple, change the second line of /etc/s6/sv/dbus-srv/run to > > foreground { dbus-uuidgen --ensure=/etc/machine-id } > > It might be better to use the default location for the machine-id, which is > /var/lib/dbus/machine-id and make /etc/machine-id a symlink to it, in which case > we can just use > > foreground { dbus-uuidgen --ensure } > > I'm not sure how would this change be done tho, at least /var/lib/dbus needs to > be created somehow. > The dbus-uuidgen page says: >The important properties of the machine UUID are that 1) it remains unchanged until the next reboot https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html So it should be fine for it to change on every reboot. I'm not sure what pulseaudio setting exactly expects the UUID to always be the same, but that doesn't sound like correct behavior. Technically, the script as it is will always overwrite machine-id if you bring down and back up (something you probably shouldn't do but still). That could be improved. That being said, the page does also mention using /var/lib/dbus/machine-id. I'm not sure what Arch does here exactly. It seems like a good idea to try and implement it somehow though. From dudemanguy at artixlinux.org Thu Dec 3 05:47:23 2020 From: dudemanguy at artixlinux.org (Dudemanguy) Date: Wed, 2 Dec 2020 22:47:23 -0600 Subject: [artix-general] Fixes for dbus-s6 In-Reply-To: References: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> Message-ID: <9cdd0f57-1abb-d33a-afba-f1ca65a19857@artixlinux.org> On 12/2/20 6:44 PM, Dudemanguy via artix-general wrote: > The dbus-uuidgen page says: > >The important properties of the machine UUID are that 1) it remains > unchanged until the next reboot > https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html > > So it should be fine for it to change on every reboot. I'm not sure what > pulseaudio setting exactly expects the UUID to always be the same, but > that doesn't sound like correct behavior. Technically, the script as it > is will always overwrite machine-id if you bring down and back up > (something you probably shouldn't do but still). That could be improved. > > That being said, the page does also mention using > /var/lib/dbus/machine-id. I'm not sure what Arch does here exactly. It > seems like a good idea to try and implement it somehow though. So as a followup on this. It turns out that the systemd manual page for machine-id says: > The machine ID is usually generated from a random source during system > installation or first boot and stays constant for all subsequent > boots. https://www.freedesktop.org/software/systemd/man/machine-id.html This isn't the same as the dbus spec but unfortunately it seems some applications do expect the machine-id to always persist across boot (thanks systemd). I've introduced an option in the conf file in the dbus-srv directory to always regenerate the /etc/machine-id whenever the service is brought up (previously it always did this). It defaults to "no" for compatibility but you can change it to "yes" if you're extra paranoid (like me). Currently in gremlins. From shironeko at waifu.club Thu Dec 3 02:53:31 2020 From: shironeko at waifu.club (Yunxiang Li) Date: Thu, 03 Dec 2020 09:53:31 +0800 Subject: [artix-general] Fixes for dbus-s6 Message-ID: <1eeb69fe644e24be0984991695a483a7bb44a107.camel@waifu.club> > The dbus-uuidgen page says: > > The important properties of the machine UUID are that 1) it remains > unchanged until the next reboot > https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html > > So it should be fine for it to change on every reboot. I'm not sure what > pulseaudio setting exactly expects the UUID to always be the same, but > that doesn't sound like correct behavior. Technically, the script as it > is will always overwrite machine-id if you bring down and back up > (something you probably shouldn't do but still). That could be improved. The machine-id man page thinks differently > The machine ID is usually generated from a random source during system > installation or first boot and stays constant for all subsequent boots. > Optionally, for stateless systems, it is generated during runtime during early > boot if necessary. https://www.freedesktop.org/software/systemd/man/machine-id.html Given that it is already used this way, I think the correct thing would be to not set it every boot. > That being said, the page does also mention using > /var/lib/dbus/machine-id. I'm not sure what Arch does here exactly. It > seems like a good idea to try and implement it somehow though. My impression is that /var/lib/dbus/machine-id is a dbus thing, and systemd took it over to /etc/machine-id. systemd recommends to symlink the otherway around, probably makes a little bit more sense now that I think about it, given that /etc is probably mounted earlier than /var. From je-vv at e.email Thu Dec 10 03:01:24 2020 From: je-vv at e.email (Javier) Date: Wed, 9 Dec 2020 20:01:24 -0600 Subject: [artix-general] Fixes for dbus-s6 In-Reply-To: <9cdd0f57-1abb-d33a-afba-f1ca65a19857@artixlinux.org> References: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> <9cdd0f57-1abb-d33a-afba-f1ca65a19857@artixlinux.org> Message-ID: <714240ce-3ac0-9550-349c-290408760756@e.email> On 12/2/20 10:47 PM, Dudemanguy via artix-general wrote: > This isn't the same as the dbus spec but unfortunately it seems some > applications do expect the machine-id to always persist across boot > (thanks systemd). I've introduced an option in the conf file in the > dbus-srv directory to always regenerate the /etc/machine-id whenever > the service is brought up (previously it always did this). It defaults > to "no" for compatibility but you can change it to "yes" if you're extra > paranoid (like me). Currently in gremlins. Well, I would have preferred having the default on "yes", :) At any rate, what I've seen is that such configurations don't require re-generating, /etc/s6/rc/compiled-, right? On reboot or the service re-init, one just gets the config changes, right? Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 2288 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Thu Dec 10 03:13:59 2020 From: je-vv at e.email (Javier) Date: Wed, 9 Dec 2020 20:13:59 -0600 Subject: [artix-general] [artix-gen] python2-pillow missing to provide "python2-pillow6", which is required by kodi In-Reply-To: <6a21275a-3975-2c2d-5fc5-d571e6544536@e.email> References: <6a21275a-3975-2c2d-5fc5-d571e6544536@e.email> Message-ID: <6056a54c-2790-7edb-c5a5-b54fe35efdc7@e.email> On 11/30/20 7:34 PM, Javier via artix-general wrote: > On arch community repo python2-pillow provides python2-pillow6, which is required by kodi, but the artix galaxy repo python2-pillow is a bit out of sync with the arch one and doesn't provide it.? Therefore, in order to get kodi in the system, the arch community package is required and used, rather than the galaxy one...? I think the galaxy one requires to get in sync with the arch one. > > Thanks ! It seems this was solved by removing the package from galaxy, :) Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 2288 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Thu Dec 10 03:48:41 2020 From: je-vv at e.email (Javier) Date: Wed, 9 Dec 2020 20:48:41 -0600 Subject: [artix-general] Was pandoc-bin dropped from artix official repos? In-Reply-To: <20201113093955.61ecafa740311a54a55ea301@posteo.net> References: <20201113093955.61ecafa740311a54a55ea301@posteo.net> Message-ID: >> pandoc-bin is under AUR, but a few weeks back it was added to the artix repos. On Today's upgrade, it seems it was removed from the artix repos. >> >> No issue with that, but I'm wondering if that's permanent, or a glitch, and then now I move to use AUR back again, or I should wait for the package to come back to the artix repos? BTW, it's still on the artix repos, but was renamed to plain pandoc. Which really confused me as well as the haskell-pandoc-crossref-bin package from AUR. The AUR pandoc-crossref-bin package is expecting pandoc-bin, not plain pandoc... If you'd ask me, I'd preferred to keep pandoc-bin as the name, since that's the package being installed, but I can deal with the name change I'd guess, changing the AUR package on every update it has... Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 2288 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dudemanguy at artixlinux.org Thu Dec 10 05:08:43 2020 From: dudemanguy at artixlinux.org (Dudemanguy) Date: Wed, 9 Dec 2020 22:08:43 -0600 Subject: [artix-general] Fixes for dbus-s6 In-Reply-To: <714240ce-3ac0-9550-349c-290408760756@e.email> References: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> <9cdd0f57-1abb-d33a-afba-f1ca65a19857@artixlinux.org> <714240ce-3ac0-9550-349c-290408760756@e.email> Message-ID: On 12/9/20 8:01 PM, Javier via artix-general wrote: > Well, I would have preferred having the default on "yes", :)? At any > rate, what I've seen is that such configurations don't require > re-generating, /etc/s6/rc/compiled-, right?? On reboot or the > service re-init, one just gets the config changes, right? Yup, no need to regenerate the database for any *.conf file. The script only needs to parse it. From je-vv at e.email Thu Dec 10 05:09:42 2020 From: je-vv at e.email (Javier) Date: Wed, 9 Dec 2020 22:09:42 -0600 Subject: [artix-general] Fixes for dbus-s6 In-Reply-To: References: <1f42a7e416d0c7543f558cc3227cc536c0ee04e4.camel@waifu.club> <9cdd0f57-1abb-d33a-afba-f1ca65a19857@artixlinux.org> <714240ce-3ac0-9550-349c-290408760756@e.email> Message-ID: <6dcc40f8-935f-e672-eda7-4ad2dc8bc091@e.email> On 12/9/20 10:08 PM, Dudemanguy via artix-general wrote: > Yup, no need to regenerate the database for any *.conf file. The script > only needs to parse it. Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x4D6C8D58AD385CAA.asc Type: application/pgp-keys Size: 2288 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From somenxavier at posteo.net Thu Dec 10 15:28:44 2020 From: somenxavier at posteo.net (Xavier B.) Date: Thu, 10 Dec 2020 15:28:44 +0100 Subject: [artix-general] Was pandoc-bin dropped from artix official repos? In-Reply-To: References: <20201113093955.61ecafa740311a54a55ea301@posteo.net> Message-ID: <20201210152844.cd7621a01b833eefb4f09777@posteo.net> Yes. Javier I'm with you: I prefer pandoc-bin name because it's could be confused with typical pandoc package Xavier On Wed, 9 Dec 2020 20:48:41 -0600 Javier via artix-general ha escrit: > >> pandoc-bin is under AUR, but a few weeks back it was added to the artix repos. On Today's upgrade, it seems it was removed from the artix repos. > >> > >> No issue with that, but I'm wondering if that's permanent, or a glitch, and then now I move to use AUR back again, or I should wait for the package to come back to the artix repos? > > BTW, it's still on the artix repos, but was renamed to plain pandoc. Which really confused me as well as the haskell-pandoc-crossref-bin package from AUR. The AUR pandoc-crossref-bin package is expecting pandoc-bin, not plain pandoc... If you'd ask me, I'd preferred to keep pandoc-bin as the name, since that's the package being installed, but I can deal with the name change I'd guess, changing the AUR package on every update it has... > > Thanks ! > > -- > Javier From je-vv at e.email Tue Dec 15 05:55:53 2020 From: je-vv at e.email (Javier) Date: Mon, 14 Dec 2020 22:55:53 -0600 Subject: [artix-general] re2 package requires update to prevent electron apps crashing Message-ID: <986687e0-db26-9802-dfa0-9044482915b9@e.email> Electron from community has received an upgrade, but it requires also an upgrade on re2, which is already provided by extra, but is still missing in world. An example: > % /usr/bin/element-desktop > electron: error while loading shared libraries: libre2.so.9: cannot open shared object file: No such file or directory Installing the extra more up to date re2 package, rather than the world one, is good work around, however extra still needs to update re2. Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Wed Dec 16 06:13:10 2020 From: je-vv at e.email (Javier) Date: Tue, 15 Dec 2020 23:13:10 -0600 Subject: [artix-general] re2 package requires update to prevent electron apps crashing In-Reply-To: <986687e0-db26-9802-dfa0-9044482915b9@e.email> References: <986687e0-db26-9802-dfa0-9044482915b9@e.email> Message-ID: <89765027-9b2a-80d0-154f-c6438fa00d8a@e.email> On 12/14/20 10:55 PM, Javier via artix-general wrote: > Electron from community has received an upgrade, but it requires also an upgrade on re2, which is already provided by extra, but is still? missing in world.? An example: > >> % /usr/bin/element-desktop electron: error while loading shared libraries: libre2.so.9: cannot open shared object file: No such file or directory > > Installing the extra more up to date re2 package, rather than the world one, is good work around, however extra still needs to update re2. BTW, Today a new re2 package from world showed up, same version as the one on extra, and it could be used instead of the one in extra with no issues. Thanks ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: