View previous topic :: View next topic |
Author |
Message |
Ralphred Guru
Joined: 31 Dec 2013 Posts: 504
|
Posted: Sun Sep 24, 2023 5:54 pm Post subject: Buggy sys-apps/systemd-utils-253.6 [udev] |
|
|
A heads up more than a call for help, but the udev component of sys-apps/systemd-utils-253.6 has a "broken path_id", which means some devices that have 'IMPORT{builtin}="path_id"' within their combined rule-set tend to have no rules at all applied during a normal boot process.
A quick butchers at /lib/udev/rules.d/* shows this *could* affect lots of things from gfx cards to multi-seat set-ups, but it was block devices for me, so YMMV.
Running 'udevadm test-builtin path_id <path to problematic /dev node>' seems to highlight any issue if you do have one, so perhaps <banepost> I did the hours of troubleshooting, so I give the info back to you, the people.</banepost> might save some poor soul the time I lost, just by using a quick >>package/accept_keywords echo, or a local overlay.
It was all fixed by reverting to the version of eudev portage was whinging about, or upgrading to the ~ version of systemd-utils. But this does beg the question about having a slotted/eselect systemd-utils so various working parts can be drawn from differing releases should the need arise (Would Sir like a regression this evening?), for Gentoo users with more than one systemd-utils use flag set at least... |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 922 Location: Romania
|
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1685
|
Posted: Sun Sep 24, 2023 6:29 pm Post subject: |
|
|
You've made your point in various places, please try to at least engage with the topic of discussion, or respect my choice to not have to read the same thing in every single topic.
Last edited by sam_ on Sun Sep 24, 2023 6:30 pm; edited 1 time in total |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1685
|
Posted: Sun Sep 24, 2023 6:30 pm Post subject: Re: Buggy sys-apps/systemd-utils-253.6 [udev] |
|
|
Ralphred wrote: | A heads up more than a call for help, but the udev component of sys-apps/systemd-utils-253.6 has a "broken path_id", which means some devices that have 'IMPORT{builtin}="path_id"' within their combined rule-set tend to have no rules at all applied during a normal boot process.
A quick butchers at /lib/udev/rules.d/* shows this *could* affect lots of things from gfx cards to multi-seat set-ups, but it was block devices for me, so YMMV.
Running 'udevadm test-builtin path_id <path to problematic /dev node>' seems to highlight any issue if you do have one, so perhaps <banepost> I did the hours of troubleshooting, so I give the info back to you, the people.</banepost> might save some poor soul the time I lost, just by using a quick >>package/accept_keywords echo, or a local overlay.
It was all fixed by reverting to the version of eudev portage was whinging about, or upgrading to the ~ version of systemd-utils. But this does beg the question about having a slotted/eselect systemd-utils so various working parts can be drawn from differing releases should the need arise (Would Sir like a regression this evening?), for Gentoo users with more than one systemd-utils use flag set at least... |
I've filed stablereqs on your behalf - in future, please do that if you notice a bug in stable which is fixed in ~arch.
As for the proposal: eselect doesn't really work for anything which other packages may depend on, nor libraries. Regressions can and do happen with pretty much every library and application. |
|
Back to top |
|
|
Ralphred Guru
Joined: 31 Dec 2013 Posts: 504
|
Posted: Sun Sep 24, 2023 7:23 pm Post subject: Re: Buggy sys-apps/systemd-utils-253.6 [udev] |
|
|
sam_ wrote: | As for the proposal: eselect doesn't really work for anything which other packages may depend on |
So splitting it into separate packages would be the way forward? |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1685
|
Posted: Sun Sep 24, 2023 7:26 pm Post subject: Re: Buggy sys-apps/systemd-utils-253.6 [udev] |
|
|
Ralphred wrote: | sam_ wrote: | As for the proposal: eselect doesn't really work for anything which other packages may depend on |
So splitting it into separate packages would be the way forward? |
We did that before and it ended up being a lot of maintenance work to have to apply patches in the same place 3-4 times and various components would be out of date. |
|
Back to top |
|
|
|