Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23 1:03 AM, Alexe Stefan wrote: > On 9/13/23, Eli Schwartz wrote: >> On 9/13/23 12:35 AM, Alexe Stefan wrote: >>> On 9/13/23, Matt Turner wrote: On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan wrote: > Is it such a burden to make a couple of commits once in a while? I see no commits from your email address in gentoo.git, so that might be a question for you. >>> >>> I and plenty of others have their overlays. Should I try to get my >>> ebuilds into ::gentoo? >> >> >> That seems to be rather missing the point. Why are you going out of your >> way to make a distinction between: >> >> - contributing ebuilds that would otherwise not be present in ::gentoo >> at all >> >> - helping fix issues in existing ebuilds that are part of ::gentoo and >> need to be kept in good working order >> >> Both are valid ways to demonstrate a commitment to collaboratively >> improving the Gentoo project. The one you *didn't* mention is easier to >> do, though, so I'd probably suggest trying that first. >> > > I do open bugs and threads about various issues regarding packages, > and propose solutions. Sometimes their gentoo maintainers agree, > sometimes they don't. What else should I do? I don't have commit > access. I am not sure what you're saying here. If you don't have commit access, how do you intend to get your ebuilds into ::gentoo? If you don't need commit access to get your ebuilds into ::gentoo, then what's stopping you from getting your patches against existing ebuilds into ::gentoo? Given that you were originally responding to Matt's remark that you have no commits in ::gentoo associated with your email address, I am merely pointing out that you are performing a bit of self-gatekeeping by interpreting this as "my ebuilds" rather than "my code contributions". If you propose solutions, do you include a demonstration patch to apply against ::gentoo that implements your proposed solution? Because that would make it very easy to have those solutions become associated with you. :) > How many commits were made in the last year to accommodate eudev? I'm not your monkey. > Regarding the bugs, what else did you expect when no news item was > given? Right, we should have done something *else* to keep eudev going. Welcome to my killfile. >>> >>> Something I said in this thread struck a chord? >> >> >> I think it's a very fair assessment to make that this thread is quite >> hostile to the Gentoo Developers as a whole, and hostile behavior >> towards the Gentoo Developers does indeed strike a chord. >> >> I am not completely sure why you find it important or desirable to >> highlight the fact that you elicit strong negative emotions in others, >> mind you. But I'm sure you have very good reasons for it. >> >> >> -- >> Eli Schwartz >> >> >> > > I don't think I said anything about you? > I do not like to see choice being taken away for no good reason, > especially in regards to such a contested topic. And I don't like signing up to this mailing list in order to email in a patch against ::gentoo to improve the speed of compilation for python libraries and make them more easily tested and debuggable, and getting my inbox filled with a bunch of yelling, hateful people who go around insulting the hard work of the Gentoo Developers, complaining that they didn't put in even MORE hard work, and figuratively screaming to the heavens about how it's a conspiracy to deny choice. You, in particular, even admitted you don't use eudev! But you're still more than happy to pontificate about how it's, I dunno, the most useful thing since sliced bread, or so I assume from the absolute moaning and wailing and gnashing of teeth about its removal. And you call it a contested topic! Contested by people who don't use it and are only contesting it in order to stir up trouble! And not content to stick with pontificating about how useful the philosophical concept of choice between two copies of the same code with different marketing names that you don't even use is, you have to describe it as > intentional crippling of systemd alternatives > regardless of how much money changes hands (???) > Do devs receive prizes based on how many useful packages they remove? > Don't answer that, we all already know the answer. (lmao) > most of those bugs were listed in the mask comment just to > increase the number of open bugs. I start to wonder: given you appear to despise the Gentoo Project with an almighty hatred, why do you use the darned thing anyway. It's a conspiracy to torment you and deny you choice, the Developers are getting secretly paid to remove packages that disagree with the New World Order of systemd, blah blah blah. Clearly Gentoo just has it in for you, so you'd better escape before it's too late. Can you please just not do this? -- Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Eli Schwartz wrote: > On 9/13/23 12:35 AM, Alexe Stefan wrote: >> On 9/13/23, Matt Turner wrote: >>> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >>> wrote: Is it such a burden to make a couple of commits once in a while? >>> >>> I see no commits from your email address in gentoo.git, so that might >>> be a question for you. >>> >> >> I and plenty of others have their overlays. Should I try to get my >> ebuilds into ::gentoo? > > > That seems to be rather missing the point. Why are you going out of your > way to make a distinction between: > > - contributing ebuilds that would otherwise not be present in ::gentoo > at all > > - helping fix issues in existing ebuilds that are part of ::gentoo and > need to be kept in good working order > > Both are valid ways to demonstrate a commitment to collaboratively > improving the Gentoo project. The one you *didn't* mention is easier to > do, though, so I'd probably suggest trying that first. > I do open bugs and threads about various issues regarding packages, and propose solutions. Sometimes their gentoo maintainers agree, sometimes they don't. What else should I do? I don't have commit access. > How many commits were made in the last year to accommodate eudev? >>> >>> I'm not your monkey. >>> Regarding the bugs, what else did you expect when no news item was given? >>> >>> Right, we should have done something *else* to keep eudev going. >>> >>> Welcome to my killfile. >>> >>> >> >> Something I said in this thread struck a chord? > > > I think it's a very fair assessment to make that this thread is quite > hostile to the Gentoo Developers as a whole, and hostile behavior > towards the Gentoo Developers does indeed strike a chord. > > I am not completely sure why you find it important or desirable to > highlight the fact that you elicit strong negative emotions in others, > mind you. But I'm sure you have very good reasons for it. > > > -- > Eli Schwartz > > > I don't think I said anything about you? I do not like to see choice being taken away for no good reason, especially in regards to such a contested topic.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23 12:35 AM, Alexe Stefan wrote: > On 9/13/23, Matt Turner wrote: >> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >> wrote: >>> Is it such a burden to make a couple of commits once in a while? >> >> I see no commits from your email address in gentoo.git, so that might >> be a question for you. >> > > I and plenty of others have their overlays. Should I try to get my > ebuilds into ::gentoo? That seems to be rather missing the point. Why are you going out of your way to make a distinction between: - contributing ebuilds that would otherwise not be present in ::gentoo at all - helping fix issues in existing ebuilds that are part of ::gentoo and need to be kept in good working order Both are valid ways to demonstrate a commitment to collaboratively improving the Gentoo project. The one you *didn't* mention is easier to do, though, so I'd probably suggest trying that first. >>> How many commits were made in the last year to accommodate eudev? >> >> I'm not your monkey. >> >>> Regarding the bugs, what else did you expect when no news item was given? >> >> Right, we should have done something *else* to keep eudev going. >> >> Welcome to my killfile. >> >> > > Something I said in this thread struck a chord? I think it's a very fair assessment to make that this thread is quite hostile to the Gentoo Developers as a whole, and hostile behavior towards the Gentoo Developers does indeed strike a chord. I am not completely sure why you find it important or desirable to highlight the fact that you elicit strong negative emotions in others, mind you. But I'm sure you have very good reasons for it. -- Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan > wrote: >> >> On 9/13/23, Matt Turner wrote: >> > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: >> >> Why would you think that by having an alternative in tree it means >> >> that >> >> everyone else is then forced into doing work that they don't want to >> >> and >> >> it will inconvenience everyone? >> > >> > Because it's already happened! >> > >> > commit 6404b064d63d182da4a8a193533a188cdf832d41 >> > Author: Mike Gilbert >> > Date: Sun Jul 30 14:07:47 2023 -0400 >> > >> > virtual/libudev: add eudev and sticky-tags USE flags >> > >> > eudev lacks API support for the new libudev functions that >> > differentiate >> > between sticky and current tags on device events. >> > >> > Add a USE flag so we can depend on the new API from libgudev. >> > >> > >> > commit 319b4ed88674af738bd3fd90e56dc06c88de15db >> > Author: Mike Gilbert >> > Date: Sun Jul 30 14:10:44 2023 -0400 >> > >> > dev-libs/libgudev: depend on virtual/libudev[sticky-tags] >> > >> > >> > And as a result we have had at least three bug reports from users >> > complaining that they cannot update: >> > >> > https://bugs.gentoo.org/913702 >> > https://bugs.gentoo.org/913900 >> > https://bugs.gentoo.org/913954 >> > >> >> What if someone came along now and said >> >> they were willing to "step up" and maintain eudev and they were >> >> suitably >> >> qualified? Is that really going to force everyone else to modify their >> >> ways? >> > >> > It doesn't matter what people say. It matters what they do. And so far >> > no one has done anything in more than two years to make eudev worth >> > keeping. >> > >> > But the core of the issue for me is -- how is eudev even the slightest >> > bit better in any way than systemd-utils[udev]? >> > >> > >> >> Is it such a burden to make a couple of commits once in a while? > > I see no commits from your email address in gentoo.git, so that might > be a question for you. > I and plenty of others have their overlays. Should I try to get my ebuilds into ::gentoo? > >> How many commits were made in the last year to accommodate eudev? > > I'm not your monkey. > >> Regarding the bugs, what else did you expect when no news item was given? > > Right, we should have done something *else* to keep eudev going. > > Welcome to my killfile. > > Something I said in this thread struck a chord?
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Eli Schwartz writes:
> On 9/12/23 10:26 PM, Michał Górny wrote:
>> On Tue, 2023-09-12 at 22:07 -0400, Eli Schwartz wrote:
>>> On 9/12/23 3:56 PM, Ulrich Mueller wrote:
> On Tue, 12 Sep 2023, Eli Schwartz wrote:
> + mkdir -p "${BUILD_DIR}" || die
> + local -x
> DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
> + cat > "${DIST_EXTRA_CONFIG}" <<-EOF
> + [build]
> + build_base = ${BUILD_DIR}/build
> +
> + [build_ext]
> + parallel = ${jobs}
> + EOF
"|| die" should also be added for the cat command.
>>>
>>>
>>> Redirecting output to a file in a directory you have just guaranteed to
>>> exist cannot fail.
>>
>> Eh, you make me prove you wrong:
>>
>> # cat > dupa <<-EOF
>> blahblah
>>> EOF
>> cat: write error: No space left on device
>
>
> ಠ_ಠ
>
> Is portage generally expected to successfully complete (including
> internal metadata write stages) when its workdir drive runs out of space
> partway through?
oh you
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/12/23 3:47 PM, Eddie Chapman wrote: > Andreas K. Huettel wrote: >> The eudev experiment has failed. >> * It was false labeling from the start.[*] >> * It's barely alive and not keeping up with udev upstream. > > Why does it have to? It is advertised as a fork after all. It provides libudev.pc; this means that it is either engaged in deceptive and malicious false advertising, or... ... it is intended to provide compatibility with udev. Hint: it is intended to provide compatibility with udev. But, it does so with an OLD version of udev. Other projects throughout the Linux ecosystem may depend on libudev.pc to provide API services; they have the right to use the advertised API of libudev.pc (and depend on a suitable version of it), but eudev cannot fulfill this contract as used by projects which e.g. use the sticky-tags API. Thus, eudev is failing its goal to be a compatible replacement, because it is not keeping up with udev upstream. >> * It's effectively unmaintained in Gentoo. > > That could change. Isn't that why a last rite comes with 30 days notice? Your question is a fallacy. Why are you pretending that the person you are replying to has claimed it isn't going to change? The person you are replying to is describing the current state of affairs that led to the last rite. Who are you arguing against? >> * You don't gain anything from using it instead of udev. >> (Nobody does.) > > Is there only 1 tool for the job? Why do we have both the OpenIPMI and > ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be > better if we just choose one of each of those pairs and concentrate on it? This isn't a fallacy -- it has progressed onwards and is now a mendacious, twisting attempt at deception. For the benefit of other people reading this discussion -- Firefox and Chrome are vastly different programs, providing vastly different tools, that both share a fairly vague, general domain (open web pages). wget and curl, or openIPMI and ipmitool, are less extreme examples of this general concept: they are different tools taking different approaches to perform a somewhat more specific task, with pros and cons of each approach. eudev does not provide distinct functionality, which leads us on to... >> >> So why should anyone put up the effort to package it? > > Same question for the above choices and plenty of other examples. > > What's wrong with having an alternative purely for competition? > >> [*] Take something out of the systemd tarball, reapply every commit, >> make tiny changes so it looks different, > > That's basically how most forks start isn't it? There are two problems with this statement. The first is that it's wrong, that's not how most forks start. The second is that you used the word "start", without perhaps realizing that starts usually come with an afterwards that is distinguished from the start by not being the start. But let's discuss what it means to fork software. There's a few different reasons why a software project might fork: - the maintainers of the project lost (or never possessed) legal control over the trademark to some corporate interest, and "fork" their own project to a new name due to abuse against users by said corporate interest, in order to reform the community and carry on their operations as normal. Examples: Sun OpenOffice.org -> LibreOffice. In non-software, Freenode becoming Libera.Chat - a project dies because its sole maintainer(s) disappear and cannot be contacted or are unresponsive w.r.t. the project. The community forks, changes its name, and arranges a new development team to "carry on the torch" in memory of the old project. Example: TrueCrypt -> VeraCrypt - a project has some end-user functionality proposed, and rejected. The people who want that feature decide to make their own project, based on the first project but with all their favorite features instead of the first project's favorite features. They take the codebase and start making lots of changes to implement end-user functionality which they enjoy, and and the first project makes lots of changes that *they* enjoy. Rapidly, it becomes increasingly difficult to find changes from one that are relevant to the other. Example: gnome vs. cinnamon desktop - a project changes in ways that some users are unhappy about, and those users create a fork that's exactly the same as the first project, but "with X removed", and which regularly syncs with the first project to retrieve desired features while excluding undesired features. The third case is what most people think of when they talk about forks. eudev is the fourth case, as its stated goal is to be "a fork of systemd", with the motivation of "isolating udev from [...] systemd". eudev lacks mission independence, its driving goal is to accomplish the same aims as systemd-udev except modularizing it well enough that it is neutral regarding the init system you are running as
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/12/23 10:26 PM, Michał Górny wrote:
> On Tue, 2023-09-12 at 22:07 -0400, Eli Schwartz wrote:
>> On 9/12/23 3:56 PM, Ulrich Mueller wrote:
On Tue, 12 Sep 2023, Eli Schwartz wrote:
>>>
+ mkdir -p "${BUILD_DIR}" || die
+ local -x
DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
+ cat > "${DIST_EXTRA_CONFIG}" <<-EOF
+ [build]
+ build_base = ${BUILD_DIR}/build
+
+ [build_ext]
+ parallel = ${jobs}
+ EOF
>>>
>>> "|| die" should also be added for the cat command.
>>
>>
>> Redirecting output to a file in a directory you have just guaranteed to
>> exist cannot fail.
>
> Eh, you make me prove you wrong:
>
> # cat > dupa <<-EOF
> blahblah
>> EOF
> cat: write error: No space left on device
ಠ_ಠ
Is portage generally expected to successfully complete (including
internal metadata write stages) when its workdir drive runs out of space
partway through?
--
Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On Tue, 2023-09-12 at 22:07 -0400, Eli Schwartz wrote:
> On 9/12/23 3:56 PM, Ulrich Mueller wrote:
> > > > > > > On Tue, 12 Sep 2023, Eli Schwartz wrote:
> >
> > > + mkdir -p "${BUILD_DIR}" || die
> > > + local -x
> > > DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
> > > + cat > "${DIST_EXTRA_CONFIG}" <<-EOF
> > > + [build]
> > > + build_base = ${BUILD_DIR}/build
> > > +
> > > + [build_ext]
> > > + parallel = ${jobs}
> > > + EOF
> >
> > "|| die" should also be added for the cat command.
>
>
> Redirecting output to a file in a directory you have just guaranteed to
> exist cannot fail.
Eh, you make me prove you wrong:
# cat > dupa <<-EOF
blahblah
> EOF
cat: write error: No space left on device
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/12/23 3:56 PM, Ulrich Mueller wrote:
>> On Tue, 12 Sep 2023, Eli Schwartz wrote:
>
>> +mkdir -p "${BUILD_DIR}" || die
>> +local -x
>> DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
>> +cat > "${DIST_EXTRA_CONFIG}" <<-EOF
>> +[build]
>> +build_base = ${BUILD_DIR}/build
>> +
>> +[build_ext]
>> +parallel = ${jobs}
>> +EOF
>
> "|| die" should also be added for the cat command.
Redirecting output to a file in a directory you have just guaranteed to
exist cannot fail. (mkdir -p will return nonzero and die, if it exits
without having guaranteed its target is a directory on disk. There is
one loophole, and that is if its target already existed beforehand, but
the mkdir -p process did not have write permissions for it; mkdir will
not check permissions if it detects it doesn't have to do work. This
should not be the case inside the workdir, or something has gone
significantly wrong beforehand.)
That being said, as a style guide concern I can see why being cautious
is generally desirable, as it's much easier to review code that uses it
when it isn't strictly necessary than code that doesn't use it when it
turns out to be necessary.
I'm not very used to this yet :) so I blindly assumed while writing it
that it wasn't necessary to do some additional typing and add this for
call sites that shouldn't be able to fail. I will add this in the next
revision.
--
Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 02:23, Alex Boag-Munroe wrote: > > >Matt Turner wrote: > >> On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > >> > >>> Why would you think that by having an alternative in tree it means that > >>> everyone else is then forced into doing work that they don't want to > >>> and it will inconvenience everyone? > >> > >> Because it's already happened! > >> > >> commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert > >> > >> Date: Sun Jul 30 14:07:47 2023 -0400 > >> > >> virtual/libudev: add eudev and sticky-tags USE flags > >> > >> eudev lacks API support for the new libudev functions that differentiate > >> between sticky and current tags on device events. > >> > >> Add a USE flag so we can depend on the new API from libgudev. > >> > >> commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert > >> > >> Date: Sun Jul 30 14:10:44 2023 -0400 > >> > >> dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > >> > >> And as a result we have had at least three bug reports from users > >> complaining that they cannot update: > >> > >> https://bugs.gentoo.org/913702 > >> https://bugs.gentoo.org/913900 > >> https://bugs.gentoo.org/913954 > > > >If I'm not mistaken these 3 bug reports are all from users trying to run > >their systems free of systemd, i.e. with eudev. So it is the eudev users, > >not the udev (presumably the majority) ones who have been inconvenienced. > > > >But I think I see your point that here eudev is causing problems for > >Gentoo devs who are seeing perhaps an influx of users complaining because > >of the problem created by eudev not keeping up with udev API changes. > > > >However, perhaps a better approach might have been a news item informing > >users of dev-libs/libgudev i.e. desktop users that using eudev with > >dev-libs/libgudev is no longer going to be possible going forward (which > >is out of control of Gentoo) and that they had a choice of either > >uninstalling their desktop environment (if it depended on > >dev-libs/libgudev) or switching to udev. Then people who just run servers > >can continue using eudev if they wish, and there would be no need to > >remove it completely from the tree. This is the approach I have argued > >for earlier in this thread. > > > >>> What if someone came along now and said > >>> they were willing to "step up" and maintain eudev and they were suitably > >>> qualified? Is that really going to force everyone else to modify their > >>> ways? > > > >> It doesn't matter what people say. It matters what they do. And so far > >> no one has done anything in more than two years to make eudev worth > >> keeping. > > > >Yes I agree that actions matter not words. However, maintainership does > >have to start with at least some words such as "OK I will step up and take > >care of it" > > > >> But the core of the issue for me is -- how is eudev even the slightest > >> bit better in any way than systemd-utils[udev]? > > > >Ok granted, as of right now eudev has not added any value as it has simply > >forked, made some small changes but essentially does the same job. > >However, again you're missing the point, there is a very significant > >number of users who for subjective/political/whatever non-technical > >reasons want eudev instead of udev. These are valid reasons, and before > >you try and argue they are not examine your own software choices and ask > >yourself if you always choose something entirely on technical merit. > > > >And, to be honest, eudev does not *have* to do anything different. If it > >provides roughly the same functionality as udev (minus new APIs) then it > >serves its purpose and is good enough for those users who use it. There > >are many examples of alternatives of one software or another that provide > >roughly the same functionality and yet we don't discard one of them simply > >because it is not adding features that make it subjectively better than > >the other one. > > > >Also, I don't think it's fair to just write the project off because it has > >just been existing, providing the same functionality. There have been bug > >fixes and new releases, isn't that the minimum we expect? It is certainly > >not abandoned and dead as it has been characterised here. Maybe it will > >become a proper fork in future and add something that udev doesn't have, > >who knows. > > OK a quick qualifier for me as a respondent: > > I hate systemd with a passion, a key reason I use Gentoo is openrc and I > wholeheartedly am of the belief that Poettering is an arse and systemd > becoming defacto/ubiquitous in Linux was a dark day. I have contributed to > the gentoo repo and regularly assist in #gentoo on IRC as well as having > submitted my fair share of bugs (and suggested fixes for them). > > That said, eudev is no hill to die on. The way Gentoo splits out udev from > systemd accomplishes the goal of not having systemd "managing" your system, > which was the goal of eudev. Also the
Re: [gentoo-dev] last rites: sys-fs/eudev
>Matt Turner wrote: >> On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: >> >>> Why would you think that by having an alternative in tree it means that >>> everyone else is then forced into doing work that they don't want to >>> and it will inconvenience everyone? >> >> Because it's already happened! >> >> commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert >> >> Date: Sun Jul 30 14:07:47 2023 -0400 >> >> virtual/libudev: add eudev and sticky-tags USE flags >> >> eudev lacks API support for the new libudev functions that differentiate >> between sticky and current tags on device events. >> >> Add a USE flag so we can depend on the new API from libgudev. >> >> commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert >> >> Date: Sun Jul 30 14:10:44 2023 -0400 >> >> dev-libs/libgudev: depend on virtual/libudev[sticky-tags] >> >> And as a result we have had at least three bug reports from users >> complaining that they cannot update: >> >> https://bugs.gentoo.org/913702 >> https://bugs.gentoo.org/913900 >> https://bugs.gentoo.org/913954 > >If I'm not mistaken these 3 bug reports are all from users trying to run >their systems free of systemd, i.e. with eudev. So it is the eudev users, >not the udev (presumably the majority) ones who have been inconvenienced. > >But I think I see your point that here eudev is causing problems for >Gentoo devs who are seeing perhaps an influx of users complaining because >of the problem created by eudev not keeping up with udev API changes. > >However, perhaps a better approach might have been a news item informing >users of dev-libs/libgudev i.e. desktop users that using eudev with >dev-libs/libgudev is no longer going to be possible going forward (which >is out of control of Gentoo) and that they had a choice of either >uninstalling their desktop environment (if it depended on >dev-libs/libgudev) or switching to udev. Then people who just run servers >can continue using eudev if they wish, and there would be no need to >remove it completely from the tree. This is the approach I have argued >for earlier in this thread. > >>> What if someone came along now and said >>> they were willing to "step up" and maintain eudev and they were suitably >>> qualified? Is that really going to force everyone else to modify their >>> ways? > >> It doesn't matter what people say. It matters what they do. And so far >> no one has done anything in more than two years to make eudev worth >> keeping. > >Yes I agree that actions matter not words. However, maintainership does >have to start with at least some words such as "OK I will step up and take >care of it" > >> But the core of the issue for me is -- how is eudev even the slightest >> bit better in any way than systemd-utils[udev]? > >Ok granted, as of right now eudev has not added any value as it has simply >forked, made some small changes but essentially does the same job. >However, again you're missing the point, there is a very significant >number of users who for subjective/political/whatever non-technical >reasons want eudev instead of udev. These are valid reasons, and before >you try and argue they are not examine your own software choices and ask >yourself if you always choose something entirely on technical merit. > >And, to be honest, eudev does not *have* to do anything different. If it >provides roughly the same functionality as udev (minus new APIs) then it >serves its purpose and is good enough for those users who use it. There >are many examples of alternatives of one software or another that provide >roughly the same functionality and yet we don't discard one of them simply >because it is not adding features that make it subjectively better than >the other one. > >Also, I don't think it's fair to just write the project off because it has >just been existing, providing the same functionality. There have been bug >fixes and new releases, isn't that the minimum we expect? It is certainly >not abandoned and dead as it has been characterised here. Maybe it will >become a proper fork in future and add something that udev doesn't have, >who knows. OK a quick qualifier for me as a respondent: I hate systemd with a passion, a key reason I use Gentoo is openrc and I wholeheartedly am of the belief that Poettering is an arse and systemd becoming defacto/ubiquitous in Linux was a dark day. I have contributed to the gentoo repo and regularly assist in #gentoo on IRC as well as having submitted my fair share of bugs (and suggested fixes for them). That said, eudev is no hill to die on. The way Gentoo splits out udev from systemd accomplishes the goal of not having systemd "managing" your system, which was the goal of eudev. Also the goal of eudev was to be a DROP IN REPLACEMENT for udev, this is no longer the case. The thrust of the complaints about the removal seems to be "but it's going to be HARD to maintain this in an overlay" which is kinda the point of why it's being binned from
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan: ... > I use a static /dev. That won't just stop work ing after an update, > regardless of how much money changes hands. Nice to se a fellow static /dev user. > What does eudev need to do and doesn't do? From discussion in various > places, I understand that it must set permissions for a devtmpfs and > maybe create some symlinks. Does it not do that? >From what I understand, it is all about usb devices which comes and goes, automounting things, and thoose things which only have dynamic minor numbers. If it weren't for that there wouldn't be a need for any *dev process. ... > There is this quote from "the doctor" on the forums that sums up all > the insanity: > > >As for software depending on what /dev you use, maybe he hasn't been paying > >attention but there is no sane reason any userspace application should care > >how > >the entries in /dev are made. There is also no sane reason to break your API > >every few months when the good idea fairy comes to call. Ack. Regards, /Karl Hammar
Re: [gentoo-dev] last rites: sys-fs/eudev
Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > >> Why would you think that by having an alternative in tree it means that >> everyone else is then forced into doing work that they don't want to >> and it will inconvenience everyone? > > Because it's already happened! > > commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert > > Date: Sun Jul 30 14:07:47 2023 -0400 > > virtual/libudev: add eudev and sticky-tags USE flags > > eudev lacks API support for the new libudev functions that differentiate > between sticky and current tags on device events. > > Add a USE flag so we can depend on the new API from libgudev. > > commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert > > Date: Sun Jul 30 14:10:44 2023 -0400 > > dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > > And as a result we have had at least three bug reports from users > complaining that they cannot update: > > https://bugs.gentoo.org/913702 > https://bugs.gentoo.org/913900 > https://bugs.gentoo.org/913954 If I'm not mistaken these 3 bug reports are all from users trying to run their systems free of systemd, i.e. with eudev. So it is the eudev users, not the udev (presumably the majority) ones who have been inconvenienced. But I think I see your point that here eudev is causing problems for Gentoo devs who are seeing perhaps an influx of users complaining because of the problem created by eudev not keeping up with udev API changes. However, perhaps a better approach might have been a news item informing users of dev-libs/libgudev i.e. desktop users that using eudev with dev-libs/libgudev is no longer going to be possible going forward (which is out of control of Gentoo) and that they had a choice of either uninstalling their desktop environment (if it depended on dev-libs/libgudev) or switching to udev. Then people who just run servers can continue using eudev if they wish, and there would be no need to remove it completely from the tree. This is the approach I have argued for earlier in this thread. >> What if someone came along now and said >> they were willing to "step up" and maintain eudev and they were suitably >> qualified? Is that really going to force everyone else to modify their >> ways? > It doesn't matter what people say. It matters what they do. And so far > no one has done anything in more than two years to make eudev worth > keeping. Yes I agree that actions matter not words. However, maintainership does have to start with at least some words such as "OK I will step up and take care of it" > But the core of the issue for me is -- how is eudev even the slightest > bit better in any way than systemd-utils[udev]? Ok granted, as of right now eudev has not added any value as it has simply forked, made some small changes but essentially does the same job. However, again you're missing the point, there is a very significant number of users who for subjective/political/whatever non-technical reasons want eudev instead of udev. These are valid reasons, and before you try and argue they are not examine your own software choices and ask yourself if you always choose something entirely on technical merit. And, to be honest, eudev does not *have* to do anything different. If it provides roughly the same functionality as udev (minus new APIs) then it serves its purpose and is good enough for those users who use it. There are many examples of alternatives of one software or another that provide roughly the same functionality and yet we don't discard one of them simply because it is not adding features that make it subjectively better than the other one. Also, I don't think it's fair to just write the project off because it has just been existing, providing the same functionality. There have been bug fixes and new releases, isn't that the minimum we expect? It is certainly not abandoned and dead as it has been characterised here. Maybe it will become a proper fork in future and add something that udev doesn't have, who knows.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan wrote: > > On 9/13/23, Matt Turner wrote: > > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > >> Why would you think that by having an alternative in tree it means that > >> everyone else is then forced into doing work that they don't want to and > >> it will inconvenience everyone? > > > > Because it's already happened! > > > > commit 6404b064d63d182da4a8a193533a188cdf832d41 > > Author: Mike Gilbert > > Date: Sun Jul 30 14:07:47 2023 -0400 > > > > virtual/libudev: add eudev and sticky-tags USE flags > > > > eudev lacks API support for the new libudev functions that > > differentiate > > between sticky and current tags on device events. > > > > Add a USE flag so we can depend on the new API from libgudev. > > > > > > commit 319b4ed88674af738bd3fd90e56dc06c88de15db > > Author: Mike Gilbert > > Date: Sun Jul 30 14:10:44 2023 -0400 > > > > dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > > > > > > And as a result we have had at least three bug reports from users > > complaining that they cannot update: > > > > https://bugs.gentoo.org/913702 > > https://bugs.gentoo.org/913900 > > https://bugs.gentoo.org/913954 > > > >> What if someone came along now and said > >> they were willing to "step up" and maintain eudev and they were suitably > >> qualified? Is that really going to force everyone else to modify their > >> ways? > > > > It doesn't matter what people say. It matters what they do. And so far > > no one has done anything in more than two years to make eudev worth > > keeping. > > > > But the core of the issue for me is -- how is eudev even the slightest > > bit better in any way than systemd-utils[udev]? > > > > > > Is it such a burden to make a couple of commits once in a while? I see no commits from your email address in gentoo.git, so that might be a question for you. > How many commits were made in the last year to accommodate eudev? I'm not your monkey. > Regarding the bugs, what else did you expect when no news item was given? Right, we should have done something *else* to keep eudev going. Welcome to my killfile.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: >> Why would you think that by having an alternative in tree it means that >> everyone else is then forced into doing work that they don't want to and >> it will inconvenience everyone? > > Because it's already happened! > > commit 6404b064d63d182da4a8a193533a188cdf832d41 > Author: Mike Gilbert > Date: Sun Jul 30 14:07:47 2023 -0400 > > virtual/libudev: add eudev and sticky-tags USE flags > > eudev lacks API support for the new libudev functions that > differentiate > between sticky and current tags on device events. > > Add a USE flag so we can depend on the new API from libgudev. > > > commit 319b4ed88674af738bd3fd90e56dc06c88de15db > Author: Mike Gilbert > Date: Sun Jul 30 14:10:44 2023 -0400 > > dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > > > And as a result we have had at least three bug reports from users > complaining that they cannot update: > > https://bugs.gentoo.org/913702 > https://bugs.gentoo.org/913900 > https://bugs.gentoo.org/913954 > >> What if someone came along now and said >> they were willing to "step up" and maintain eudev and they were suitably >> qualified? Is that really going to force everyone else to modify their >> ways? > > It doesn't matter what people say. It matters what they do. And so far > no one has done anything in more than two years to make eudev worth > keeping. > > But the core of the issue for me is -- how is eudev even the slightest > bit better in any way than systemd-utils[udev]? > > Is it such a burden to make a couple of commits once in a while? How many commits were made in the last year to accommodate eudev? Regarding the bugs, what else did you expect when no news item was given?
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > Why would you think that by having an alternative in tree it means that > everyone else is then forced into doing work that they don't want to and > it will inconvenience everyone? Because it's already happened! commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert Date: Sun Jul 30 14:07:47 2023 -0400 virtual/libudev: add eudev and sticky-tags USE flags eudev lacks API support for the new libudev functions that differentiate between sticky and current tags on device events. Add a USE flag so we can depend on the new API from libgudev. commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert Date: Sun Jul 30 14:10:44 2023 -0400 dev-libs/libgudev: depend on virtual/libudev[sticky-tags] And as a result we have had at least three bug reports from users complaining that they cannot update: https://bugs.gentoo.org/913702 https://bugs.gentoo.org/913900 https://bugs.gentoo.org/913954 > What if someone came along now and said > they were willing to "step up" and maintain eudev and they were suitably > qualified? Is that really going to force everyone else to modify their > ways? It doesn't matter what people say. It matters what they do. And so far no one has done anything in more than two years to make eudev worth keeping. But the core of the issue for me is -- how is eudev even the slightest bit better in any way than systemd-utils[udev]?
Re: [gentoo-dev] last rites: sys-fs/eudev
Andrew Ammerlaan wrote: > > On 12 September 2023 21:47:31 CEST, Eddie Chapman wrote: > >> Andreas K. Huettel wrote: >> >>> The eudev experiment has failed. >>> * It was false labeling from the start.[*] >>> * It's barely alive and not keeping up with udev upstream. >> >> Why does it have to? It is advertised as a fork after all. >> >>> * It's effectively unmaintained in Gentoo. >> >> That could change. Isn't that why a last rite comes with 30 days >> notice? >> >>> * You don't gain anything from using it instead of udev. >>> (Nobody does.) >>> >> Is there only 1 tool for the job? Why do we have both the OpenIPMI and >> ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it >> be better if we just choose one of each of those pairs and concentrate >> on it? >>> >>> So why should anyone put up the effort to package it? >> >> Same question for the above choices and plenty of other examples. >> >> What's wrong with having an alternative purely for competition? > > Having options is only valuable if the different options actually bring > something to the table. Choice for the sake of choice is just a waste of > time and effort. Firefox is clearly different then Chrome, each comes > with its own advantages and disadvantages, and based on this a user can > make an educated choice. What I have not yet read in any message in this > long thread, is **why** one would want to use eudev, what are its > advantages? Why not use sys-apps/systemd-utils[udev]? You really are on a slippery slope if you're going to insist that someone "ought" to use a certain software, that there is no advantage in using an alternative and therefore you shouldn't. Also, people choose alternatives for entirely non-technical reasons which are valid. These might be political, license, or they just like the author or community of one project better than another. Microsoft Office is probably a better office suite technically and feature-wise than Libreoffice, yet many people use Libreoffice instead. That doesn't mean Libreoffice users are "just plain wrong". Why do we have so many Linux distributions if they all offer largely the same set of software? Why use Ubuntu over Debian or vice versa? What's the point of openrc? Which is better GCC or Clang/LLVM? > You are free to spend your time and effort on whatever you wish, maintain > eudev as proxy or in some overlay, but don't expect others to put in > their time and effort if you can't convince them the extra choice has > value and is therefore worth their time and effort. > > Best regards, > Andrew Why would you think that by having an alternative in tree it means that everyone else is then forced into doing work that they don't want to and it will inconvenience everyone? What if someone came along now and said they were willing to "step up" and maintain eudev and they were suitably qualified? Is that really going to force everyone else to modify their ways?
Re: [gentoo-dev] last rites: sys-fs/eudev
Eli Schwartz wrote: > On 9/12/23 3:05 PM, orbea wrote: >> On Tue, 12 Sep 2023 14:51:34 -0400 >> Matt Turner wrote: >>> Conspiracy alert! >>> >>> It's been more than 2 years since >>> https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html >>> >>> >>> People have had plenty of time. More chances than were fair have been >>> given. Nothing has changed, except eudev has further diverged from >>> upstream udev. >>> >> >> Unfortunately this flew under the radar for a lot of people, when I >> asked Sam about this on irc a while ago I was informed (As I >> understood) that eudev was still going to be an option into the future >> and as the ebuild was still getting updates I never considered this is >> how the core Gentoo devs felt. > > It sounds to me like the last-rite system has worked and achieved the > desired goal then. It is no longer flying under the radar, and for > people who use eudev and wish to see it be a supported option, a fire > has been lit under them to get involved. > > Do keep in mind that based on commit history the only person that > cares about eudev at all for years now is Sam, and that's apparently > out of mere obligation. He is not listed as an eudev project member or > package maintainer, the actual eudev project should likely acknowledge > reality and disband in order to more effectively communicate their > intent. > > None of this is or ever was sustainable -- do not expect people who > don't use a thing, aren't willing to maintain a thing, but intercede > out of obligation to be an effective maintainer or be willing to do so > in perpetuity. > > If I had to take a wild guess, "it is still going to be an option into > the future" actually meant "we aren't ready to treeclean it yet, > people still use it, so we're gonna see how low-effort it is to keep > it limping along without any maintainers but also maybe someone would > like to maintain it". > > Sure enough, the total lack of gentoo maintainers for this package > meant that once people who were engaging with ebuild updates *purely* > out of a sense of obligation could no longer justify continuing to do > so when the package wasn't compatible with its reverse dependencies, > those people decided that it was time to step down. > > It's great to see people who do care and actually use the software, > step up in their place. > > Picking fairly random message to reply too. I'm a regular user, for some 20 years now. I'm also a eudev user at the moment. I'm also not a fan of systemd and friends. It's why I started using eudev long ago. So, like eudev, not much on systemd stuff and currently use eudev. With that info shared, this is my take on this. It seems that while eudev is alive upstream for other distros, no one cares to maintain it on Gentoo anymore because it doesn't serve a purpose other than avoiding systemd. While I kinda like that purpose, I'm not maintaining eudev either. If no one steps up and pinky swears to maintain eudev, it will and should be removed from the tree. After all, this is about 2 years past due it seems. While I wish someone would maintain eudev, I'm not going to jump up and down demanding or even implying someone should do so. It sounds like it was easier in the past to maintain it but upcoming changes is going to make that more time consuming and require more work. It appears no one is yet willing to take that effort on. In my opinion, this thread has raised the awareness of the eudev situation long ago. If no one steps up, then it is time to retire eudev and all of us eudev lovers will just have to switch. This is just the way FOSS works sometimes. I recall switching from udev to eudev. It was as simple as unmerge one, emerge the other. I assume it will be pretty simple and straight forward this time to do the reverse. I did see somewhere that one should check configs and make sure there is no systemd/udev entries, in case it masks or prevents something from being installed. I already checked mine. My vote, give it time. If someone steps up, great. If not, we just have to switch to udev and move on. Debating it even more is unlikely to change anything and may even send some running away. I just wish we knew just how many people actually used eudev. Based on this thread, I know of 2. I know one of them can't code. That's me!! ;-) My $0.02 worth. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 4:25 PM orbea wrote: > > On Tue, 12 Sep 2023 14:51:34 -0400 > Matt Turner wrote: > > > On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > > > > > On Tue, 12 Sep 2023 15:17:00 +0100 > > > Sam James wrote: > > > > > > > Rich Freeman writes: > > > > > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > > > wrote: > > > > >> in Gentoo. Have any of these 4 maintainers publicly said > > > > >> (anywhere) that they are not interested in being maintainers > > > > >> anymore (which is fine if that is the case)? We're not talking > > > > >> here about a lone maintainer of some peripheral package that's > > > > >> disappeared leaving an orphaned package. > > > > > > > > > > It isn't like somebody is censoring the lists or waging commit > > > > > wars on the metadata.xml/mask file. If somebody was eager to > > > > > maintain it I'm sure they'd have spoken up. > > > > > > > > > >> I'm an outsider to Gentoo development (just a heavy user for > > > > >> over a decade both personally and professionally) so I might > > > > >> have missed something. I just find it puzzling. > > > > > > > > > > I'm not puzzled by what is going on, or by your email, because > > > > > it happens basically anytime a high-profile package is > > > > > treecleaned. Yes, Gentoo is about choice, but somebody has to > > > > > actually do work to make the choices viable. There are always > > > > > more people interested in using software than maintaining it. > > > > > The frustration is completely understandable, but also kinda > > > > > unavoidable. > > > > > > > > > > Repo QA standards don't mean that it has to barely work for your > > > > > specific use case. The package has to deal with compatibility > > > > > issues with stuff you don't use as well, which is why > > > > > maintaining a system package can be hard work. It is usually > > > > > less of an issue for more ordinary applications, which tend to > > > > > have fewer interactions. If it is "good enough" for you as it > > > > > is, then just move it to a private overlay and keep using it. > > > > > You probably would need to override a virtual or two as well. > > > > > Or publish your work somewhere others can use it. > > > > > > > > Yes. We value having a coherent system with decent UX and we have > > > > to choose what we can support. Users are free to override those > > > > choices in local repositories - and if they want advice on the > > > > best way to do so, they're free to ask. > > > > > > > > > > As evidenced by the ::libressl overlay where I am repeatedly > > > copy/pasting changes from ::gentoo that have nothing to do with > > > libressl this is not a very good solution. This is a huge amount of > > > redundant and pointless effort that would be better suited being > > > directly in the ::gentoo repo. > > > > I think most people aren't going to be swayed by "it's really > > inefficient for me to do $xyz outside of ::gentoo" where xyz is > > something that they find useless. > > It doesn't matter if it sways you or not, the reality is that your > argument amounts to forcing people to do a lot of extra redundant work > solving problems that have already been solved out of spite. The lack of awareness here is really something.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 12 September 2023 21:47:31 CEST, Eddie Chapman wrote: >Andreas K. Huettel wrote: >> The eudev experiment has failed. >> * It was false labeling from the start.[*] >> * It's barely alive and not keeping up with udev upstream. > >Why does it have to? It is advertised as a fork after all. > >> * It's effectively unmaintained in Gentoo. > >That could change. Isn't that why a last rite comes with 30 days notice? > >> * You don't gain anything from using it instead of udev. >> (Nobody does.) > >Is there only 1 tool for the job? Why do we have both the OpenIPMI and >ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be >better if we just choose one of each of those pairs and concentrate on it? >> >> So why should anyone put up the effort to package it? > >Same question for the above choices and plenty of other examples. > >What's wrong with having an alternative purely for competition? Having options is only valuable if the different options actually bring something to the table. Choice for the sake of choice is just a waste of time and effort. Firefox is clearly different then Chrome, each comes with its own advantages and disadvantages, and based on this a user can make an educated choice. What I have not yet read in any message in this long thread, is **why** one would want to use eudev, what are its advantages? Why not use sys-apps/systemd-utils[udev]? You are free to spend your time and effort on whatever you wish, maintain eudev as proxy or in some overlay, but don't expect others to put in their time and effort if you can't convince them the extra choice has value and is therefore worth their time and effort. Best regards, Andrew
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/12/23 3:05 PM, orbea wrote: On Tue, 12 Sep 2023 14:51:34 -0400 Matt Turner wrote: Conspiracy alert! It's been more than 2 years since https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html People have had plenty of time. More chances than were fair have been given. Nothing has changed, except eudev has further diverged from upstream udev. Unfortunately this flew under the radar for a lot of people, when I asked Sam about this on irc a while ago I was informed (As I understood) that eudev was still going to be an option into the future and as the ebuild was still getting updates I never considered this is how the core Gentoo devs felt. It sounds to me like the last-rite system has worked and achieved the desired goal then. It is no longer flying under the radar, and for people who use eudev and wish to see it be a supported option, a fire has been lit under them to get involved. Do keep in mind that based on commit history the only person that cares about eudev at all for years now is Sam, and that's apparently out of mere obligation. He is not listed as an eudev project member or package maintainer, the actual eudev project should likely acknowledge reality and disband in order to more effectively communicate their intent. None of this is or ever was sustainable -- do not expect people who don't use a thing, aren't willing to maintain a thing, but intercede out of obligation to be an effective maintainer or be willing to do so in perpetuity. If I had to take a wild guess, "it is still going to be an option into the future" actually meant "we aren't ready to treeclean it yet, people still use it, so we're gonna see how low-effort it is to keep it limping along without any maintainers but also maybe someone would like to maintain it". Sure enough, the total lack of gentoo maintainers for this package meant that once people who were engaging with ebuild updates *purely* out of a sense of obligation could no longer justify continuing to do so when the package wasn't compatible with its reverse dependencies, those people decided that it was time to step down. It's great to see people who do care and actually use the software, step up in their place. -- Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
> On Tue, 12 Sep 2023, Eli Schwartz wrote:
> + mkdir -p "${BUILD_DIR}" || die
> + local -x
> DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
> + cat > "${DIST_EXTRA_CONFIG}" <<-EOF
> + [build]
> + build_base = ${BUILD_DIR}/build
> +
> + [build_ext]
> + parallel = ${jobs}
> + EOF
"|| die" should also be added for the cat command.
Re: [gentoo-dev] last rites: sys-fs/eudev
Andreas K. Huettel wrote: I'm an outsider to Gentoo development (just a heavy user for over a decade both personally and professionally) so I might have missed something. I just find it puzzling. >>> >>> I'm not puzzled by what is going on, or by your email, because it >>> happens basically anytime a high-profile package is treecleaned. Yes, >>> Gentoo is about choice, but somebody has to actually do work to make >>> the choices viable. There are always more people interested in >>> using software than maintaining it. The frustration is completely >>> understandable, but also kinda unavoidable. >> >> It starts to bother me that so many people straight away assume that >> when someone questions things it's because they are a frustrated user > > > > The eudev experiment has failed. > * It was false labeling from the start.[*] > * It's barely alive and not keeping up with udev upstream. Why does it have to? It is advertised as a fork after all. > * It's effectively unmaintained in Gentoo. That could change. Isn't that why a last rite comes with 30 days notice? > * You don't gain anything from using it instead of udev. > (Nobody does.) Is there only 1 tool for the job? Why do we have both the OpenIPMI and ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be better if we just choose one of each of those pairs and concentrate on it? > > So why should anyone put up the effort to package it? Same question for the above choices and plenty of other examples. What's wrong with having an alternative purely for competition? > [*] Take something out of the systemd tarball, reapply every commit, > make tiny changes so it looks different, That's basically how most forks start isn't it? > sell it to the anti-systemd crowd. > Sadly no profit, since open source... > -- > Andreas K. Hüttel > dilfri...@gentoo.org Gentoo Linux developer > (council, toolchain, base-system, perl, libreoffice) >
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, 12 Sep 2023 20:06:32 +0100 "Eddie Chapman" wrote: > orbea wrote: > > On Tue, 12 Sep 2023 20:23:49 +0300 > > Alexe Stefan wrote: > > > >> All this makes me wonder, what really is the reason for this > >> shitshow. Something tells me systemd and it's shims will never be > >> without a maintainer, regardless of how "popular" they are among > >> gentoo folks. All this seems like intentional crippling of systemd > >> alternatives. I don't use eudev, but I don't like seeing choice > >> being taken away for such paper-thin reasons. The "reasons" listed > >> for the removal are "dead upstream", which is false, and open > >> "bugs", most of which are at most differences in the default > >> behavior. > > > > I see 9 issues listed for sys-fs/eudev on the Gentoo tracker. > > > > I closed 1 as invalid. > > > > https://bugs.gentoo.org/904741 > > > > And submitted an upstream PR for another. > > > > https://bugs.gentoo.org/771705 > > https://github.com/eudev-project/eudev/pull/261 > > > > As for the rest... > > > > Possibly invalid? > > > > https://bugs.gentoo.org/667686 (Outdated?) > > https://bugs.gentoo.org/711462 > > > > Possibly outdated? > > > > https://bugs.gentoo.org/713106 > > > > And the last 4 need to further investigation. > > > > https://bugs.gentoo.org/851255 > > https://bugs.gentoo.org/770358 > > https://bugs.gentoo.org/668880 > > https://bugs.gentoo.org/753134 > > > > > > Surprisingly I don't see an issue for sticky-tags. > > > >> I use a static /dev. That won't just stop working after an update, > >> regardless of how much money changes hands. > >> > >> What does eudev need to do and doesn't do? From discussion in > >> various places, I understand that it must set permissions for a > >> devtmpfs and maybe create some symlinks. Does it not do that? I > >> know that Lennart wants to do everything and do it poorly, but > >> eudev doesn't have to do that too. What's the point of a for then? > >> > >> Overlays were mentioned in this thread. If we remove everything > >> from ::gentoo in favor of overlays, what is the point of ::gentoo > >> then? Do devs receive prizes based on how many useful packages > >> they remove? Don't answer that, we all already know the answer. > >> > >> There is this quote from "the doctor" on the forums that sums up > >> all the insanity: > >> > >>> As for software depending on what /dev you use, maybe he hasn't > >>> been paying >attention but there is no sane reason any userspace > >>> application should care how >the entries in /dev are made. There > >>> is also no sane reason to break your API >every few months when > >>> the good idea fairy comes to call. > >> > >> As for this: > >> > >>> Alexe Stefan writes: > >>> > Must eudev be 100% compatible with all the garbage that gets > shoved into udev to stay in ::gentoo? I don't see mdev being > held to that standard. > >> > >>> Please don't top-post. > >> > >>> mdev is not a provider of virtual/libudev and doesn't pretend to > >>> be via its pkgconfig file. > >> > >> What if eudev has to pretend, not because of build or runtime > >> failures, but because of needless pesky pkgconfig checks? Should > >> the default eudev setup include virtual/libudev in > >> package.provided? I think it's better the way it is. > > Number of open bugs on its own is really not a good argument for > removing a package. sys-fs/udev has about 15 open bugs currently so > go figure. But the > sticky-tags API issue, to be fair to those who argue for eudev > removal, is the main issue, rather than the open bugs. Agreed, that does seem the most pressing issue as far as I can tell, the followup would probably be the cross-compile issue I submitted an upstream PR for. > > But I want to ask: what are the obstacles to keeping eudev in tree but > effectively only for non-desktop use cases? I would love to hear > specific reasons from those who are pro-removal why eudev can't exist > at least for the server use case. > > Because the sticky-tags issue only really affects desktop users. And > if some important server package comes along in future and wants to > use a new udev API feature, then implementing individual features in > eudev is more of a realistic proposition than the continual burden of > implementing everything. Even with a desktop its not necessarily an issue for someone using a minimal window manager. Everything I want works just fine on my eudev gaming system including Steam. The only thing in the ::gentoo repo that requires sticky-tags is dev-libs/libgudev which I believe is mostly required by desktop managers such as Gnome. It appears to be optional in even XFCE, but I am not sure of the ramifications of disabling the system-info USE flag in xfce-base/libxfce4ui. Additionally the workaround PR proposed for the upstream eudev repo would make libgudev happy while potentially working satisfactorily in many cases? This would require testing I can't accomplish. > > I have many Gentoo server
[gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
Bug: https://bugs.gentoo.org/758167
Full PR is at https://github.com/gentoo/gentoo/pull/32730
Several LLVM packages require this early return, otherwise they fail to
build on Darwin. I'll also need this USE-flag for
sys-devel/clang-common, to distinguish between stage2 and stage3 of
bootstrap-prefix.sh to configure clang differently.
--
Best regards,
Alexey "DarthGandalf" SokolovFrom de2bd1abc3e5c7607413633d132c604c6a801802 Mon Sep 17 00:00:00 2001
From: Alexey Sokolov
Date: Mon, 11 Sep 2023 23:26:49 +0100
Subject: [PATCH] llvm.eclass: add global USE flag bootstrap-prefix
Mask it everywhere except for prefix profiles
Without this, stage2's LLVM packages fail to build.
Bug: https://bugs.gentoo.org/758167
Signed-off-by: Alexey Sokolov
---
eclass/llvm.eclass| 7 +++
profiles/base/use.mask| 4
profiles/features/prefix/use.mask | 4
profiles/use.desc | 1 +
4 files changed, 16 insertions(+)
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
index 8198650aad9a7..87c2cedb3a376 100644
--- a/eclass/llvm.eclass
+++ b/eclass/llvm.eclass
@@ -64,6 +64,8 @@ esac
if [[ ! ${_LLVM_ECLASS} ]]; then
_LLVM_ECLASS=1
+IUSE="bootstrap-prefix"
+
# make sure that the versions installing straight into /usr/bin
# are uninstalled
DEPEND="!!sys-devel/llvm:0"
@@ -242,6 +244,11 @@ llvm_fix_tool_path() {
llvm_pkg_setup() {
debug-print-function ${FUNCNAME} "${@}"
+ if use bootstrap-prefix; then
+ # AppleClang has unparseable version numbers, but it's irrelevant anyway
+ return
+ fi
+
if [[ ${MERGE_TYPE} != binary ]]; then
LLVM_SLOT=$(get_llvm_slot "${LLVM_MAX_SLOT}")
diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 1d4f5b92865df..cc86fde21097a 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -8,6 +8,10 @@
# eudev is masked for removal
eudev
+# Alexey Sokolov (2023-09-11)
+# Only needed during bootstrap of prefix
+bootstrap-prefix
+
# David Seifert (2023-09-09)
# EOL upstream in 2 months, causes major headaches for OpenSSL 1.1
# masking. Removal on 2023-10-09.
diff --git a/profiles/features/prefix/use.mask b/profiles/features/prefix/use.mask
index 482ce57f04485..1f43ca23fd101 100644
--- a/profiles/features/prefix/use.mask
+++ b/profiles/features/prefix/use.mask
@@ -4,6 +4,10 @@
# prefix USE flag should always be unmasked in prefix profiles
-prefix
+# Alexey Sokolov (2023-09-11)
+# Allow bootstrapping the prefix
+-bootstrap-prefix
+
# USE flags inherited by the base/use.defaults file that shouldn't be in Prefix
gpm
diff --git a/profiles/use.desc b/profiles/use.desc
index 6034f3bf6fc31..37c64f43759da 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -29,6 +29,7 @@ big-endian - Big-endian toolchain support
bindist - Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues)
blas - Add support for the virtual/blas numerical library
bluetooth - Enable Bluetooth Support
+bootstrap-prefix - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for bootstrapping Gentoo Prefix
branding - Enable Gentoo specific branding
build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1]
bzip2 - Use the bzlib compression library
Re: [gentoo-dev] last rites: sys-fs/eudev
> >> I'm an outsider to Gentoo development (just a heavy user for over a > >> decade both personally and professionally) so I might have missed > >> something. I just find it puzzling. > > > > I'm not puzzled by what is going on, or by your email, because it > > happens basically anytime a high-profile package is treecleaned. Yes, > > Gentoo is about choice, but somebody has to actually do work to make > > the choices viable. There are always more people interested in using > > software than maintaining it. The frustration is completely > > understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user The eudev experiment has failed. * It was false labeling from the start.[*] * It's barely alive and not keeping up with udev upstream. * It's effectively unmaintained in Gentoo. * You don't gain anything from using it instead of udev. (Nobody does.) So why should anyone put up the effort to package it? [*] Take something out of the systemd tarball, reapply every commit, make tiny changes so it looks different, sell it to the anti-systemd crowd. Sadly no profit, since open source... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: unconditionally warn on occluded packages in cwd
If the current directory masks packages that would be installed and
contains different contents, it can cause testing issues that otherwise
go unnoticed. This warning can stop being experimental and opt-in
Suggested-by: Michał Górny
Signed-off-by: Eli Schwartz
---
eclass/python-utils-r1.eclass | 4
1 file changed, 4 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index bd30c1203180..50aeabae1c17 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1242,10 +1242,6 @@ _python_check_EPYTHON() {
_python_check_occluded_packages() {
debug-print-function ${FUNCNAME} "${@}"
- # DO NOT ENABLE THIS unless you're going to check for false
- # positives before filing bugs.
- [[ ! ${PYTHON_EXPERIMENTAL_QA} ]] && return
-
[[ -z ${BUILD_DIR} || ! -d ${BUILD_DIR}/install ]] && return
local sitedir="${BUILD_DIR}/install$(python_get_sitedir)"
--
2.41.0
[gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Previously, setup.py was handled by:
- manually passing makejobs, with a heuristic to guess whether it was a
time saver to do so.
- rm -rf'ing the build directory in between python versions to prevent
cross-version contamination
This is because in PEP 517 mode, it doesn't accept build options
specific to a setuptools phase. So a crude hack is to just build_ext
twice, once explicitly and once internally as part of bdist_wheel, and
pray that in the latter case it detects that there's nothing to do.
Unfortunately, sometimes build_ext does NOT detect that there is nothing
to do -- e.g. for codegen tools such as mypyc, that produce *.c files
which are different every time you try building. As for build
directories, those were given up on as hopeless.
There's a better hack which is to set a magic environment variable for a
setup.cfg file which is parsed additionally to the one provided by the
project. It can contain additional settings, such as the build-base and
parallelism, which means that bdist_wheel intrinsically builds
extensions in parallel the only time it is called. And we can set the
output directory for all build artifacts to outside of the source tree,
so it is no longer necessary to delete them (which among other things,
makes debugging difficult).
This is similar to .pydistutils.cfg, but is processed later and can be
in arbitrary locations. Since we store it in the per-impl build
directory we don't need to wipe it after using it to avoid leakage.
Signed-off-by: Eli Schwartz
---
eclass/distutils-r1.eclass | 48 --
1 file changed, 10 insertions(+), 38 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 91de144e1110..dd197a5f0693 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1461,12 +1461,6 @@ distutils_pep517_install() {
[[ -n ${wheel} ]] || die "No wheel name returned"
distutils_wheel_install "${root}" "${WHEEL_BUILD_DIR}/${wheel}"
-
- # clean the build tree; otherwise we may end up with PyPy3
- # extensions duplicated into CPython dists
- if [[ ${DISTUTILS_USE_PEP517:-setuptools} == setuptools ]]; then
- rm -rf build || die
- fi
}
# @FUNCTION: distutils-r1_python_compile
@@ -1478,9 +1472,6 @@ distutils_pep517_install() {
#
# If DISTUTILS_USE_PEP517 is set to any other value, builds a wheel
# using the PEP517 backend and installs it into ${BUILD_DIR}/install.
-# May additionally call build_ext prior to that when using setuptools
-# and the eclass detects a potential benefit from parallel extension
-# builds.
#
# In legacy mode, runs 'esetup.py build'. Any parameters passed to this
# function will be appended to setup.py invocation, i.e. passed
@@ -1495,40 +1486,21 @@ distutils-r1_python_compile() {
# call setup.py build when using setuptools (either via
PEP517
# or in legacy mode)
- if [[ ${DISTUTILS_USE_PEP517} ]]; then
- if [[ -d build ]]; then
- eqawarn "A 'build' directory exists
already. Artifacts from this directory may"
- eqawarn "be picked up by setuptools
when building for another interpreter."
- eqawarn "Please remove this directory
prior to building."
- fi
- else
- _distutils-r1_copy_egg_info
- fi
-
# distutils is parallel-capable since py3.5
local jobs=$(makeopts_jobs "${MAKEOPTS} ${*}")
if [[ ${DISTUTILS_USE_PEP517} ]]; then
- # issue build_ext only if it looks like we have
at least
- # two source files to build; setuptools is
expensive
- # to start and parallel builds can only benefit
us if we're
- # compiling at least two files
- #
- # see extension.py for list of suffixes
- # .pyx is added for Cython
- #
- # esetup.py does not respect SYSROOT, so skip
it there
- if [[ -z ${SYSROOT} && ${DISTUTILS_EXT} && 1
-ne ${jobs}
- && 2 -eq $(
- find '(' -name '*.c' -o -name
'*.cc' -o -name '*.cpp' \
- -o -name '*.cxx' -o
-name '*.c++' -o -name '*.m' \
- -o -name '*.mm' -o
-name '*.pyx' ')' -printf '\n' |
- head -n 2 | wc -l
- )
-
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea wrote: > On Tue, 12 Sep 2023 20:23:49 +0300 > Alexe Stefan wrote: > >> All this makes me wonder, what really is the reason for this shitshow. >> Something tells me systemd and it's shims will never be without a >> maintainer, regardless of how "popular" they are among gentoo folks. All >> this seems like intentional crippling of systemd alternatives. I don't >> use eudev, but I don't like seeing choice being taken away for such >> paper-thin reasons. The "reasons" listed for the removal are "dead >> upstream", which is false, and open "bugs", most of which are at most >> differences in the default behavior. > > I see 9 issues listed for sys-fs/eudev on the Gentoo tracker. > > I closed 1 as invalid. > > https://bugs.gentoo.org/904741 > > And submitted an upstream PR for another. > > https://bugs.gentoo.org/771705 > https://github.com/eudev-project/eudev/pull/261 > > As for the rest... > > Possibly invalid? > > https://bugs.gentoo.org/667686 (Outdated?) > https://bugs.gentoo.org/711462 > > Possibly outdated? > > https://bugs.gentoo.org/713106 > > And the last 4 need to further investigation. > > https://bugs.gentoo.org/851255 > https://bugs.gentoo.org/770358 > https://bugs.gentoo.org/668880 > https://bugs.gentoo.org/753134 > > > Surprisingly I don't see an issue for sticky-tags. > >> I use a static /dev. That won't just stop working after an update, >> regardless of how much money changes hands. >> >> What does eudev need to do and doesn't do? From discussion in various >> places, I understand that it must set permissions for a devtmpfs and >> maybe create some symlinks. Does it not do that? I know that Lennart >> wants to do everything and do it poorly, but eudev doesn't have to do >> that too. What's the point of a for then? >> >> Overlays were mentioned in this thread. If we remove everything from >> ::gentoo in favor of overlays, what is the point of ::gentoo then? Do >> devs receive prizes based on how many useful packages they remove? Don't >> answer that, we all already know the answer. >> >> There is this quote from "the doctor" on the forums that sums up all >> the insanity: >> >>> As for software depending on what /dev you use, maybe he hasn't been >>> paying >attention but there is no sane reason any userspace application >>> should care how >the entries in /dev are made. There is also no sane >>> reason to break your API >every few months when the good idea fairy >>> comes to call. >> >> As for this: >> >>> Alexe Stefan writes: >>> Must eudev be 100% compatible with all the garbage that gets shoved into udev to stay in ::gentoo? I don't see mdev being held to that standard. >> >>> Please don't top-post. >> >>> mdev is not a provider of virtual/libudev and doesn't pretend to be >>> via its pkgconfig file. >> >> What if eudev has to pretend, not because of build or runtime >> failures, but because of needless pesky pkgconfig checks? Should the >> default eudev setup include virtual/libudev in package.provided? I think >> it's better the way it is. Number of open bugs on its own is really not a good argument for removing a package. sys-fs/udev has about 15 open bugs currently so go figure. But the sticky-tags API issue, to be fair to those who argue for eudev removal, is the main issue, rather than the open bugs. But I want to ask: what are the obstacles to keeping eudev in tree but effectively only for non-desktop use cases? I would love to hear specific reasons from those who are pro-removal why eudev can't exist at least for the server use case. Because the sticky-tags issue only really affects desktop users. And if some important server package comes along in future and wants to use a new udev API feature, then implementing individual features in eudev is more of a realistic proposition than the continual burden of implementing everything. I have many Gentoo server instances out there and I really can't see any sensible reason why eudev can't continue being the udev provider in those scenarios, and surely portage can easily handle marking eudev as not compatible with desktop package installations. Then for desktop users the choice is between eudev or a desktop. Granted it's not ideal but it's better than no eudev at all in tree, and I'm sure there are other similar situations in tree currently where the user has to make a choice between one or the other thing. Now I know the argument that might come back is "well sure, but who's going to do the work needed to be able to make the choice possible?". Well, let's see, maybe someone will volunteer, but I just want to know first is there any insurmountable obstacle that makes that scenario not even possible?
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, 12 Sep 2023 14:51:34 -0400 Matt Turner wrote: > On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > > > On Tue, 12 Sep 2023 15:17:00 +0100 > > Sam James wrote: > > > > > Rich Freeman writes: > > > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > > wrote: > > > >> in Gentoo. Have any of these 4 maintainers publicly said > > > >> (anywhere) that they are not interested in being maintainers > > > >> anymore (which is fine if that is the case)? We're not talking > > > >> here about a lone maintainer of some peripheral package that's > > > >> disappeared leaving an orphaned package. > > > > > > > > It isn't like somebody is censoring the lists or waging commit > > > > wars on the metadata.xml/mask file. If somebody was eager to > > > > maintain it I'm sure they'd have spoken up. > > > > > > > >> I'm an outsider to Gentoo development (just a heavy user for > > > >> over a decade both personally and professionally) so I might > > > >> have missed something. I just find it puzzling. > > > > > > > > I'm not puzzled by what is going on, or by your email, because > > > > it happens basically anytime a high-profile package is > > > > treecleaned. Yes, Gentoo is about choice, but somebody has to > > > > actually do work to make the choices viable. There are always > > > > more people interested in using software than maintaining it. > > > > The frustration is completely understandable, but also kinda > > > > unavoidable. > > > > > > > > Repo QA standards don't mean that it has to barely work for your > > > > specific use case. The package has to deal with compatibility > > > > issues with stuff you don't use as well, which is why > > > > maintaining a system package can be hard work. It is usually > > > > less of an issue for more ordinary applications, which tend to > > > > have fewer interactions. If it is "good enough" for you as it > > > > is, then just move it to a private overlay and keep using it. > > > > You probably would need to override a virtual or two as well. > > > > Or publish your work somewhere others can use it. > > > > > > Yes. We value having a coherent system with decent UX and we have > > > to choose what we can support. Users are free to override those > > > choices in local repositories - and if they want advice on the > > > best way to do so, they're free to ask. > > > > > > > As evidenced by the ::libressl overlay where I am repeatedly > > copy/pasting changes from ::gentoo that have nothing to do with > > libressl this is not a very good solution. This is a huge amount of > > redundant and pointless effort that would be better suited being > > directly in the ::gentoo repo. > > I think most people aren't going to be swayed by "it's really > inefficient for me to do $xyz outside of ::gentoo" where xyz is > something that they find useless. It doesn't matter if it sways you or not, the reality is that your argument amounts to forcing people to do a lot of extra redundant work solving problems that have already been solved out of spite. > > > What would be required so this is not required for eudev too? At the > > risk of repeating myself its working on my systems and I am willing > > to look at bugs and put in effort into keeping it functional. > > > > I don't think this is a matter of not having people willing to put > > effort in, but that no one wants to let them have the chance. > > Conspiracy alert! > > It's been more than 2 years since > https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html > > People have had plenty of time. More chances than were fair have been > given. Nothing has changed, except eudev has further diverged from > upstream udev. > Unfortunately this flew under the radar for a lot of people, when I asked Sam about this on irc a while ago I was informed (As I understood) that eudev was still going to be an option into the future and as the ebuild was still getting updates I never considered this is how the core Gentoo devs felt.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/12/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan > wrote: >> All this makes me wonder, what really is the reason for this shitshow. >> Something tells me systemd and it's shims will never be without a >> maintainer, regardless of how "popular" they are among gentoo folks. >> All this seems like intentional crippling of systemd alternatives. I >> don't use eudev, but I don't like seeing choice being taken away for >> such paper-thin reasons. >> The "reasons" listed for the removal are "dead upstream", which is >> false, and open "bugs", most of which are at most differences in the >> default behavior. >> I use a static /dev. That won't just stop working after an update, >> regardless of how much money changes hands. >> >> What does eudev need to do and doesn't do? From discussion in various >> places, I understand that it must set permissions for a devtmpfs and >> maybe create some symlinks. Does it not do that? >> I know that Lennart wants to do everything and do it poorly, but eudev >> doesn't have to do that too. What's the point of a for then? >> >> Overlays were mentioned in this thread. If we remove everything from >> ::gentoo in favor of overlays, what is the point of ::gentoo then? Do >> devs receive prizes based on how many useful packages they remove? >> Don't answer that, we all already know the answer. >> >> There is this quote from "the doctor" on the forums that sums up all >> the insanity: >> >> >As for software depending on what /dev you use, maybe he hasn't been >> > paying >attention but there is no sane reason any userspace application >> > should care how >the entries in /dev are made. There is also no sane >> > reason to break your API >every few months when the good idea fairy >> > comes to call. >> >> As for this: >> >> >Alexe Stefan writes: >> >> >> Must eudev be 100% compatible with all the garbage that gets shoved >> >> into udev to stay in ::gentoo? I don't see mdev being held to that >> >> standard. >> >> >Please don't top-post. >> >> >mdev is not a provider of virtual/libudev and doesn't pretend to be >> >via its pkgconfig file. >> >> What if eudev has to pretend, not because of build or runtime >> failures, but because of needless pesky pkgconfig checks? Should the >> default eudev setup include virtual/libudev in package.provided? I >> think it's better the way it is. >> > > Lots of bad faith in this post. This is bad and you should feel bad. > > Say what you will, but tell me where I was wrong in my post. The reasons listed for the last rites are "dead upstream", which is false and those bugs. Orbea wrote more about those bugs, but it seems like most of those bugs were listed in the mask comment just to increase the number of open bugs.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan wrote: > All this makes me wonder, what really is the reason for this shitshow. > Something tells me systemd and it's shims will never be without a > maintainer, regardless of how "popular" they are among gentoo folks. > All this seems like intentional crippling of systemd alternatives. I > don't use eudev, but I don't like seeing choice being taken away for > such paper-thin reasons. > The "reasons" listed for the removal are "dead upstream", which is > false, and open "bugs", most of which are at most differences in the > default behavior. > I use a static /dev. That won't just stop working after an update, > regardless of how much money changes hands. > > What does eudev need to do and doesn't do? From discussion in various > places, I understand that it must set permissions for a devtmpfs and > maybe create some symlinks. Does it not do that? > I know that Lennart wants to do everything and do it poorly, but eudev > doesn't have to do that too. What's the point of a for then? > > Overlays were mentioned in this thread. If we remove everything from > ::gentoo in favor of overlays, what is the point of ::gentoo then? Do > devs receive prizes based on how many useful packages they remove? > Don't answer that, we all already know the answer. > > There is this quote from "the doctor" on the forums that sums up all > the insanity: > > >As for software depending on what /dev you use, maybe he hasn't been paying > >>attention but there is no sane reason any userspace application should care > >how >the entries in /dev are made. There is also no sane reason to break > >your API >every few months when the good idea fairy comes to call. > > As for this: > > >Alexe Stefan writes: > > >> Must eudev be 100% compatible with all the garbage that gets shoved > >> into udev to stay in ::gentoo? I don't see mdev being held to that > >> standard. > > >Please don't top-post. > > >mdev is not a provider of virtual/libudev and doesn't pretend to be > >via its pkgconfig file. > > What if eudev has to pretend, not because of build or runtime > failures, but because of needless pesky pkgconfig checks? Should the > default eudev setup include virtual/libudev in package.provided? I > think it's better the way it is. > Lots of bad faith in this post. This is bad and you should feel bad.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > On Tue, 12 Sep 2023 15:17:00 +0100 > Sam James wrote: > > > Rich Freeman writes: > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > wrote: > > >> in Gentoo. Have any of these 4 maintainers publicly said > > >> (anywhere) that they are not interested in being maintainers > > >> anymore (which is fine if that is the case)? We're not talking > > >> here about a lone maintainer of some peripheral package that's > > >> disappeared leaving an orphaned package. > > > > > > It isn't like somebody is censoring the lists or waging commit wars > > > on the metadata.xml/mask file. If somebody was eager to maintain > > > it I'm sure they'd have spoken up. > > > > > >> I'm an outsider to Gentoo development (just a heavy user for over > > >> a decade both personally and professionally) so I might have > > >> missed something. I just find it puzzling. > > > > > > I'm not puzzled by what is going on, or by your email, because it > > > happens basically anytime a high-profile package is treecleaned. > > > Yes, Gentoo is about choice, but somebody has to actually do work > > > to make the choices viable. There are always more people > > > interested in using software than maintaining it. The frustration > > > is completely understandable, but also kinda unavoidable. > > > > > > Repo QA standards don't mean that it has to barely work for your > > > specific use case. The package has to deal with compatibility > > > issues with stuff you don't use as well, which is why maintaining a > > > system package can be hard work. It is usually less of an issue > > > for more ordinary applications, which tend to have fewer > > > interactions. If it is "good enough" for you as it is, then just > > > move it to a private overlay and keep using it. You probably would > > > need to override a virtual or two as well. Or publish your work > > > somewhere others can use it. > > > > Yes. We value having a coherent system with decent UX and we have > > to choose what we can support. Users are free to override those > > choices in local repositories - and if they want advice on the best > > way to do so, they're free to ask. > > > > As evidenced by the ::libressl overlay where I am repeatedly > copy/pasting changes from ::gentoo that have nothing to do with > libressl this is not a very good solution. This is a huge amount of > redundant and pointless effort that would be better suited being > directly in the ::gentoo repo. I think most people aren't going to be swayed by "it's really inefficient for me to do $xyz outside of ::gentoo" where xyz is something that they find useless. > What would be required so this is not required for eudev too? At the > risk of repeating myself its working on my systems and I am willing to > look at bugs and put in effort into keeping it functional. > > I don't think this is a matter of not having people willing to put > effort in, but that no one wants to let them have the chance. Conspiracy alert! It's been more than 2 years since https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html People have had plenty of time. More chances than were fair have been given. Nothing has changed, except eudev has further diverged from upstream udev.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 11:04 AM Eddie Chapman wrote: > Yes I regularly do this if there is a piece of software not in the tree, I > have a local repo full of stuff. But this argument doesn't hold as much > weight when it comes to a package like this which is integrated in the > core of the system. People who really want to continue using it are going > to experience a lot of pain trying to maintain it for themselves out of > tree, much more so than they would normally. That's one reason why I think > the decision deserves more scrutiny. Yes, people who insist on using a piece of software that's basically stagnant are going to have trouble trying to maintain it themselves. You're right. You're just missing that this is because of upstream eudev not backporting anything anymore. Take a look at https://openhub.net/p/eudev 12 month summary * 22 Commits - Down -97 (81%) from previous 12 months * 5 Contributors - Down -5 (50%) from previous 12 months There used to be backports from upstream udev like this: https://github.com/eudev-project/eudev/commit/9d4010a3629ebc1d915b7f2d3e2d7be83d79b4f4 But it seems that no one does that anymore since blueness stopped. blueness -- one of the original maintainers of eudev and the author of the news item that says the reason for eudev's existence no longer applies... So tl;dr: we're sorry eudev is no longer viable. We kept it in ::gentoo for far longer than it should have been.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, 12 Sep 2023 20:23:49 +0300 Alexe Stefan wrote: > All this makes me wonder, what really is the reason for this shitshow. > Something tells me systemd and it's shims will never be without a > maintainer, regardless of how "popular" they are among gentoo folks. > All this seems like intentional crippling of systemd alternatives. I > don't use eudev, but I don't like seeing choice being taken away for > such paper-thin reasons. > The "reasons" listed for the removal are "dead upstream", which is > false, and open "bugs", most of which are at most differences in the > default behavior. I see 9 issues listed for sys-fs/eudev on the Gentoo tracker. I closed 1 as invalid. https://bugs.gentoo.org/904741 And submitted an upstream PR for another. https://bugs.gentoo.org/771705 https://github.com/eudev-project/eudev/pull/261 As for the rest... Possibly invalid? https://bugs.gentoo.org/667686 (Outdated?) https://bugs.gentoo.org/711462 Possibly outdated? https://bugs.gentoo.org/713106 And the last 4 need to further investigation. https://bugs.gentoo.org/851255 https://bugs.gentoo.org/770358 https://bugs.gentoo.org/668880 https://bugs.gentoo.org/753134 Surprisingly I don't see an issue for sticky-tags. > I use a static /dev. That won't just stop working after an update, > regardless of how much money changes hands. > > What does eudev need to do and doesn't do? From discussion in various > places, I understand that it must set permissions for a devtmpfs and > maybe create some symlinks. Does it not do that? > I know that Lennart wants to do everything and do it poorly, but eudev > doesn't have to do that too. What's the point of a for then? > > Overlays were mentioned in this thread. If we remove everything from > ::gentoo in favor of overlays, what is the point of ::gentoo then? Do > devs receive prizes based on how many useful packages they remove? > Don't answer that, we all already know the answer. > > There is this quote from "the doctor" on the forums that sums up all > the insanity: > > >As for software depending on what /dev you use, maybe he hasn't been > >paying >attention but there is no sane reason any userspace > >application should care how >the entries in /dev are made. There is > >also no sane reason to break your API >every few months when the > >good idea fairy comes to call. > > As for this: > > >Alexe Stefan writes: > > >> Must eudev be 100% compatible with all the garbage that gets shoved > >> into udev to stay in ::gentoo? I don't see mdev being held to that > >> standard. > > >Please don't top-post. > > >mdev is not a provider of virtual/libudev and doesn't pretend to be > >via its pkgconfig file. > > What if eudev has to pretend, not because of build or runtime > failures, but because of needless pesky pkgconfig checks? Should the > default eudev setup include virtual/libudev in package.provided? I > think it's better the way it is. >
Re: [gentoo-dev] last rites: sys-fs/eudev
All this makes me wonder, what really is the reason for this shitshow. Something tells me systemd and it's shims will never be without a maintainer, regardless of how "popular" they are among gentoo folks. All this seems like intentional crippling of systemd alternatives. I don't use eudev, but I don't like seeing choice being taken away for such paper-thin reasons. The "reasons" listed for the removal are "dead upstream", which is false, and open "bugs", most of which are at most differences in the default behavior. I use a static /dev. That won't just stop working after an update, regardless of how much money changes hands. What does eudev need to do and doesn't do? From discussion in various places, I understand that it must set permissions for a devtmpfs and maybe create some symlinks. Does it not do that? I know that Lennart wants to do everything and do it poorly, but eudev doesn't have to do that too. What's the point of a for then? Overlays were mentioned in this thread. If we remove everything from ::gentoo in favor of overlays, what is the point of ::gentoo then? Do devs receive prizes based on how many useful packages they remove? Don't answer that, we all already know the answer. There is this quote from "the doctor" on the forums that sums up all the insanity: >As for software depending on what /dev you use, maybe he hasn't been paying >>attention but there is no sane reason any userspace application should care >how >the entries in /dev are made. There is also no sane reason to break your >API >every few months when the good idea fairy comes to call. As for this: >Alexe Stefan writes: >> Must eudev be 100% compatible with all the garbage that gets shoved >> into udev to stay in ::gentoo? I don't see mdev being held to that >> standard. >Please don't top-post. >mdev is not a provider of virtual/libudev and doesn't pretend to be >via its pkgconfig file. What if eudev has to pretend, not because of build or runtime failures, but because of needless pesky pkgconfig checks? Should the default eudev setup include virtual/libudev in package.provided? I think it's better the way it is.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, 12 Sep 2023 15:17:00 +0100 Sam James wrote: > Rich Freeman writes: > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > wrote: > >> in Gentoo. Have any of these 4 maintainers publicly said > >> (anywhere) that they are not interested in being maintainers > >> anymore (which is fine if that is the case)? We're not talking > >> here about a lone maintainer of some peripheral package that's > >> disappeared leaving an orphaned package. > > > > It isn't like somebody is censoring the lists or waging commit wars > > on the metadata.xml/mask file. If somebody was eager to maintain > > it I'm sure they'd have spoken up. > > > >> I'm an outsider to Gentoo development (just a heavy user for over > >> a decade both personally and professionally) so I might have > >> missed something. I just find it puzzling. > > > > I'm not puzzled by what is going on, or by your email, because it > > happens basically anytime a high-profile package is treecleaned. > > Yes, Gentoo is about choice, but somebody has to actually do work > > to make the choices viable. There are always more people > > interested in using software than maintaining it. The frustration > > is completely understandable, but also kinda unavoidable. > > > > Repo QA standards don't mean that it has to barely work for your > > specific use case. The package has to deal with compatibility > > issues with stuff you don't use as well, which is why maintaining a > > system package can be hard work. It is usually less of an issue > > for more ordinary applications, which tend to have fewer > > interactions. If it is "good enough" for you as it is, then just > > move it to a private overlay and keep using it. You probably would > > need to override a virtual or two as well. Or publish your work > > somewhere others can use it. > > Yes. We value having a coherent system with decent UX and we have > to choose what we can support. Users are free to override those > choices in local repositories - and if they want advice on the best > way to do so, they're free to ask. > As evidenced by the ::libressl overlay where I am repeatedly copy/pasting changes from ::gentoo that have nothing to do with libressl this is not a very good solution. This is a huge amount of redundant and pointless effort that would be better suited being directly in the ::gentoo repo. What would be required so this is not required for eudev too? At the risk of repeating myself its working on my systems and I am willing to look at bugs and put in effort into keeping it functional. I don't think this is a matter of not having people willing to put effort in, but that no one wants to let them have the chance.
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > martin-kokos wrote: >> --- Original Message --- >> On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman >> wrote: >> >>> Sam James wrote: >>> "Eddie Chapman" ed...@ehuk.net writes: >>> So what's the situation with the current Gentoo maintainers? >>> Have >>> they disappeared? I often see on here packages being offered up >>> for grabs. Why hasn't there been a call to give others the >>> opportunity to volunteer as maintainers rather than going >>> straight to last riting the package? Or >>> has that happened and I've missed it, in which case I apologise. >> >> There was a year ago or so and nothing really came out of it. But >> see above wrt 'tags'. > > A year is a long time, there might well now be people willing to > take over maintaining it that were not willing to 1 year ago, if > that is what is required. They have a month to step up anyway, although that will involve upstream activity too. >>> >>> I see there was already a change in the tree yesterday that assumes >>> sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, >>> sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually >>> been decided behind the scenes already? This starts to smell a little >>> ugly unless I've completely misunderstood something. I hope I'm wrong. >>> >>> One thing I don't understand: the Gentoo project page for eudev lists 4 >>> members including the lead, and FWICT they are mostly still active in >>> other areas of Gentoo (recent commits to the tree in other packages). >>> The >>> project lead is also an original author of eudev. I find it hard to >>> believe that all 4 of these people have completely lost interest in >>> eudev in Gentoo. Have any of these 4 maintainers publicly said >>> (anywhere) that >>> they are not interested in being maintainers anymore (which is fine if >>> that is the case)? We're not talking here about a lone maintainer of >>> some peripheral package that's disappeared leaving an orphaned package. >>> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I don't understand why there is need to go off of *hints and clues* >> whether its active development or whether the project maintainers want to >> maintain it or not. The project lead has explained the original reason for >> eudev being part of base and why that reason has passed. Issue decided 2 >> years ago. >> >> https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.htm >> l >> >> If there were maintainers to suport it for 2 extra years, that's very >> nice of them. Speculating, without them, after their decision to >> last-rite and asking to support eudev indefinitely, without giving any >> insightful reason as to why, seems ... not a great way to motivate >> someone to do something extra for me. >> >> Martin >> > > Thank you Martin and Sam for pointing out to me the news item above from 2 > years ago, which for some reason I missed originally, so I wasn't aware > this is how the people listed as current maintainers felt. > > This seems like a crucial piece of information that was sadly omitted from > the original last rite message. > > Maybe there is a lesson here somewhere about communication and last riting > of core system packages. I've just pushed https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d1669686c56dc7f05750d9b36db1c2f9001275a which I think should help. That's a fair point, thank you. It's also easy to forget that people might have missed an item etc.
Re: [gentoo-dev] last rites: sys-fs/eudev
Sam James wrote: > > Rich Freeman writes: > >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> >>> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >>> that they are not interested in being maintainers anymore (which is >>> fine if that is the case)? We're not talking here about a lone >>> maintainer of some peripheral package that's disappeared leaving an >>> orphaned package. >> >> It isn't like somebody is censoring the lists or waging commit wars on >> the metadata.xml/mask file. If somebody was eager to maintain it I'm >> sure they'd have spoken up. >> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I'm not puzzled by what is going on, or by your email, because it >> happens basically anytime a high-profile package is treecleaned. Yes, >> Gentoo is about choice, but somebody has to actually do work to make >> the choices viable. There are always more people interested in using >> software than maintaining it. The frustration is completely >> understandable, but also kinda unavoidable. >> >> Repo QA standards don't mean that it has to barely work for your >> specific use case. The package has to deal with compatibility issues >> with stuff you don't use as well, which is why maintaining a system >> package can be hard work. It is usually less of an issue for more >> ordinary applications, which tend to have fewer interactions. If it is >> "good enough" for you as it is, then just move it to a private >> overlay and keep using it. You probably would need to override a virtual >> or two as well. Or publish your work somewhere others can use it. > > Yes. We value having a coherent system with decent UX and we have > to choose what we can support. Users are free to override those choices in > local repositories - and if they want advice on the best way to do so, > they're free to ask. Yes I regularly do this if there is a piece of software not in the tree, I have a local repo full of stuff. But this argument doesn't hold as much weight when it comes to a package like this which is integrated in the core of the system. People who really want to continue using it are going to experience a lot of pain trying to maintain it for themselves out of tree, much more so than they would normally. That's one reason why I think the decision deserves more scrutiny.
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Rich Freeman wrote: >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> >>> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >>> that they are not interested in being maintainers anymore (which is fine >>> if that is the case)? We're not talking here about a lone maintainer of >>> some peripheral package that's disappeared leaving an orphaned package. >> >> It isn't like somebody is censoring the lists or waging commit wars on >> the metadata.xml/mask file. If somebody was eager to maintain it I'm sure >> they'd have spoken up. >> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I'm not puzzled by what is going on, or by your email, because it >> happens basically anytime a high-profile package is treecleaned. Yes, >> Gentoo is about choice, but somebody has to actually do work to make >> the choices viable. There are always more people interested in using >> software than maintaining it. The frustration is completely >> understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user who just > wants everyone else to do the work for them. And the same old argument > keeps being repeated over and over again *as if they think that no one > gets it* apart from us devs. I've been a free & oss software user for over > 20 years and I find it very patronising whenever it happens. The reality > is that are very few people in this community that don't understand the > fundamentals of free software, that no one is being paid, no one is > obligated, we are all volunteers, well then why don't you do it, etc, etc. > I've never asked or expected anyone to actually step up and do the work > and if you read my messages you will see that I've never even implied it. > No, but other people in the thread have, and the expectation is others will read it too. This is one of those topics where in particular we get a lot of it. Suggestions of "something smelly" then do imply some of the things you're saying. We're used to conspiratorial suggestions with this topic too. >> Repo QA standards don't mean that it has to barely work for your >> specific use case. The package has to deal with compatibility issues with >> stuff you don't use as well, which is why maintaining a system package can >> be hard work. It is usually less of an issue for more ordinary >> applications, which tend to have fewer interactions. If it is "good >> enough" for you as it is, then just move it to a private overlay and keep >> using it. You probably would need to override a virtual or two as well. >> Or publish your work somewhere others can use >> it. > > I see, so again I just don't get it do I? I'm just a user who is in their > own little world and all they care about is what works for them, and I > don't think or understand anything about the bigger picture. I wouldn't read that much into it. Rich is always verbose (and I mean no insult there), he's just being explicit about the options. > >> -- >> Rich
Re: [gentoo-dev] last rites: sys-fs/eudev
martin-kokos wrote: > --- Original Message --- > On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman > wrote: > >> Sam James wrote: >> >>> "Eddie Chapman" ed...@ehuk.net writes: >>> >> So what's the situation with the current Gentoo maintainers? >> Have >> they disappeared? I often see on here packages being offered up >> for grabs. Why hasn't there been a call to give others the >> opportunity to volunteer as maintainers rather than going >> straight to last riting the package? Or >> has that happened and I've missed it, in which case I apologise. > > There was a year ago or so and nothing really came out of it. But > see above wrt 'tags'. A year is a long time, there might well now be people willing to take over maintaining it that were not willing to 1 year ago, if that is what is required. >>> >>> They have a month to step up anyway, although that will involve >>> upstream activity too. >> >> I see there was already a change in the tree yesterday that assumes >> sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, >> sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually >> been decided behind the scenes already? This starts to smell a little >> ugly unless I've completely misunderstood something. I hope I'm wrong. >> >> One thing I don't understand: the Gentoo project page for eudev lists 4 >> members including the lead, and FWICT they are mostly still active in >> other areas of Gentoo (recent commits to the tree in other packages). >> The >> project lead is also an original author of eudev. I find it hard to >> believe that all 4 of these people have completely lost interest in >> eudev in Gentoo. Have any of these 4 maintainers publicly said >> (anywhere) that >> they are not interested in being maintainers anymore (which is fine if >> that is the case)? We're not talking here about a lone maintainer of >> some peripheral package that's disappeared leaving an orphaned package. >> >> I'm an outsider to Gentoo development (just a heavy user for over a >> decade both personally and professionally) so I might have missed >> something. I just find it puzzling. > > I don't understand why there is need to go off of *hints and clues* > whether its active development or whether the project maintainers want to > maintain it or not. The project lead has explained the original reason for > eudev being part of base and why that reason has passed. Issue decided 2 > years ago. > > https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.htm > l > > If there were maintainers to suport it for 2 extra years, that's very > nice of them. Speculating, without them, after their decision to > last-rite and asking to support eudev indefinitely, without giving any > insightful reason as to why, seems ... not a great way to motivate > someone to do something extra for me. > > Martin > Thank you Martin and Sam for pointing out to me the news item above from 2 years ago, which for some reason I missed originally, so I wasn't aware this is how the people listed as current maintainers felt. This seems like a crucial piece of information that was sadly omitted from the original last rite message. Maybe there is a lesson here somewhere about communication and last riting of core system packages.
Re: [gentoo-dev] last rites: sys-fs/eudev
Rich Freeman wrote: > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: > >> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >> that they are not interested in being maintainers anymore (which is fine >> if that is the case)? We're not talking here about a lone maintainer of >> some peripheral package that's disappeared leaving an orphaned package. > > It isn't like somebody is censoring the lists or waging commit wars on > the metadata.xml/mask file. If somebody was eager to maintain it I'm sure > they'd have spoken up. > >> I'm an outsider to Gentoo development (just a heavy user for over a >> decade both personally and professionally) so I might have missed >> something. I just find it puzzling. > > I'm not puzzled by what is going on, or by your email, because it > happens basically anytime a high-profile package is treecleaned. Yes, > Gentoo is about choice, but somebody has to actually do work to make > the choices viable. There are always more people interested in using > software than maintaining it. The frustration is completely > understandable, but also kinda unavoidable. It starts to bother me that so many people straight away assume that when someone questions things it's because they are a frustrated user who just wants everyone else to do the work for them. And the same old argument keeps being repeated over and over again *as if they think that no one gets it* apart from us devs. I've been a free & oss software user for over 20 years and I find it very patronising whenever it happens. The reality is that are very few people in this community that don't understand the fundamentals of free software, that no one is being paid, no one is obligated, we are all volunteers, well then why don't you do it, etc, etc. I've never asked or expected anyone to actually step up and do the work and if you read my messages you will see that I've never even implied it. > Repo QA standards don't mean that it has to barely work for your > specific use case. The package has to deal with compatibility issues with > stuff you don't use as well, which is why maintaining a system package can > be hard work. It is usually less of an issue for more ordinary > applications, which tend to have fewer interactions. If it is "good > enough" for you as it is, then just move it to a private overlay and keep > using it. You probably would need to override a virtual or two as well. > Or publish your work somewhere others can use > it. I see, so again I just don't get it do I? I'm just a user who is in their own little world and all they care about is what works for them, and I don't think or understand anything about the bigger picture. > -- > Rich
Re: [gentoo-dev] last rites: sys-fs/eudev
--- Original Message --- On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman wrote: > Sam James wrote: > > > "Eddie Chapman" ed...@ehuk.net writes: > > > > > > > So what's the situation with the current Gentoo maintainers? Have > > > > > they disappeared? I often see on here packages being offered up for > > > > > grabs. Why > > > > > hasn't there been a call to give others the opportunity to volunteer > > > > > as maintainers rather than going straight to last riting the package? > > > > > Or > > > > > has that happened and I've missed it, in which case I apologise. > > > > > > > > There was a year ago or so and nothing really came out of it. But see > > > > above wrt 'tags'. > > > > > > A year is a long time, there might well now be people willing to take > > > over maintaining it that were not willing to 1 year ago, if that is what > > > is required. > > > > They have a month to step up anyway, although that will involve > > upstream activity too. > > > I see there was already a change in the tree yesterday that assumes > sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, > sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been > decided behind the scenes already? This starts to smell a little ugly > unless I've completely misunderstood something. I hope I'm wrong. > > One thing I don't understand: the Gentoo project page for eudev lists 4 > members including the lead, and FWICT they are mostly still active in > other areas of Gentoo (recent commits to the tree in other packages). The > project lead is also an original author of eudev. I find it hard to > believe that all 4 of these people have completely lost interest in eudev > in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that > they are not interested in being maintainers anymore (which is fine if > that is the case)? We're not talking here about a lone maintainer of some > peripheral package that's disappeared leaving an orphaned package. > > I'm an outsider to Gentoo development (just a heavy user for over a decade > both personally and professionally) so I might have missed something. I > just find it puzzling. I don't understand why there is need to go off of *hints and clues* whether its active development or whether the project maintainers want to maintain it or not. The project lead has explained the original reason for eudev being part of base and why that reason has passed. Issue decided 2 years ago. https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html If there were maintainers to suport it for 2 extra years, that's very nice of them. Speculating, without them, after their decision to last-rite and asking to support eudev indefinitely, without giving any insightful reason as to why, seems ... not a great way to motivate someone to do something extra for me. Martin
Re: [gentoo-dev] last rites: sys-fs/eudev
Rich Freeman writes: > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that >> they are not interested in being maintainers anymore (which is fine if >> that is the case)? We're not talking here about a lone maintainer of some >> peripheral package that's disappeared leaving an orphaned package. > > It isn't like somebody is censoring the lists or waging commit wars on > the metadata.xml/mask file. If somebody was eager to maintain it I'm > sure they'd have spoken up. > >> I'm an outsider to Gentoo development (just a heavy user for over a decade >> both personally and professionally) so I might have missed something. I >> just find it puzzling. > > I'm not puzzled by what is going on, or by your email, because it > happens basically anytime a high-profile package is treecleaned. Yes, > Gentoo is about choice, but somebody has to actually do work to make > the choices viable. There are always more people interested in using > software than maintaining it. The frustration is completely > understandable, but also kinda unavoidable. > > Repo QA standards don't mean that it has to barely work for your > specific use case. The package has to deal with compatibility issues > with stuff you don't use as well, which is why maintaining a system > package can be hard work. It is usually less of an issue for more > ordinary applications, which tend to have fewer interactions. If it > is "good enough" for you as it is, then just move it to a private > overlay and keep using it. You probably would need to override a > virtual or two as well. Or publish your work somewhere others can use > it. Yes. We value having a coherent system with decent UX and we have to choose what we can support. Users are free to override those choices in local repositories - and if they want advice on the best way to do so, they're free to ask.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: > in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that > they are not interested in being maintainers anymore (which is fine if > that is the case)? We're not talking here about a lone maintainer of some > peripheral package that's disappeared leaving an orphaned package. It isn't like somebody is censoring the lists or waging commit wars on the metadata.xml/mask file. If somebody was eager to maintain it I'm sure they'd have spoken up. > I'm an outsider to Gentoo development (just a heavy user for over a decade > both personally and professionally) so I might have missed something. I > just find it puzzling. I'm not puzzled by what is going on, or by your email, because it happens basically anytime a high-profile package is treecleaned. Yes, Gentoo is about choice, but somebody has to actually do work to make the choices viable. There are always more people interested in using software than maintaining it. The frustration is completely understandable, but also kinda unavoidable. Repo QA standards don't mean that it has to barely work for your specific use case. The package has to deal with compatibility issues with stuff you don't use as well, which is why maintaining a system package can be hard work. It is usually less of an issue for more ordinary applications, which tend to have fewer interactions. If it is "good enough" for you as it is, then just move it to a private overlay and keep using it. You probably would need to override a virtual or two as well. Or publish your work somewhere others can use it. -- Rich
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Sam James wrote: >> >> "Eddie Chapman" writes: > So what's the situation with the current Gentoo maintainers? Have > they disappeared? I often see on here packages being offered up for > grabs. Why > hasn't there been a call to give others the opportunity to volunteer > as maintainers rather than going straight to last riting the package? > Or > has that happened and I've missed it, in which case I apologise. There was a year ago or so and nothing really came out of it. But see above wrt 'tags'. >>> >>> A year is a long time, there might well now be people willing to take >>> over maintaining it that were not willing to 1 year ago, if that is what >>> is required. >> >> They have a month to step up anyway, although that will involve >> upstream activity too. > > I see there was already a change in the tree yesterday that assumes > sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, > sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been > decided behind the scenes already? This starts to smell a little ugly > unless I've completely misunderstood something. I hope I'm wrong. I think someone just didn't want to bother waiting to clean it up there given it's unlikely anyone will bother taking it over. It's not exactly something which can't be undone. > > One thing I don't understand: the Gentoo project page for eudev lists 4 > members including the lead, and FWICT they are mostly still active in > other areas of Gentoo (recent commits to the tree in other packages). The > project lead is also an original author of eudev. blueness being the same person who wrote the news item last year saying it's dead and it no longer serves a purpose. > I find it hard to > believe that all 4 of these people have completely lost interest in eudev > in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that > they are not interested in being maintainers anymore (which is fine if > that is the case)? We're not talking here about a lone maintainer of some > peripheral package that's disappeared leaving an orphaned package. > That happened really with the discussion w/ blueness et. al when it was last-rited (or before it was last-rited) originally.
Re: [gentoo-dev] last rites: sys-fs/eudev
Sam James wrote: > > "Eddie Chapman" writes: So what's the situation with the current Gentoo maintainers? Have they disappeared? I often see on here packages being offered up for grabs. Why hasn't there been a call to give others the opportunity to volunteer as maintainers rather than going straight to last riting the package? Or has that happened and I've missed it, in which case I apologise. >>> >>> There was a year ago or so and nothing really came out of it. But see >>> above wrt 'tags'. >> >> A year is a long time, there might well now be people willing to take >> over maintaining it that were not willing to 1 year ago, if that is what >> is required. > > They have a month to step up anyway, although that will involve > upstream activity too. I see there was already a change in the tree yesterday that assumes sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been decided behind the scenes already? This starts to smell a little ugly unless I've completely misunderstood something. I hope I'm wrong. One thing I don't understand: the Gentoo project page for eudev lists 4 members including the lead, and FWICT they are mostly still active in other areas of Gentoo (recent commits to the tree in other packages). The project lead is also an original author of eudev. I find it hard to believe that all 4 of these people have completely lost interest in eudev in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that they are not interested in being maintainers anymore (which is fine if that is the case)? We're not talking here about a lone maintainer of some peripheral package that's disappeared leaving an orphaned package. I'm an outsider to Gentoo development (just a heavy user for over a decade both personally and professionally) so I might have missed something. I just find it puzzling.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue 12 Sep 2023 05:18:51 GMT, Rich Freeman wrote: > Sorry for this being a bit of a ramble. I do feel for your situation, > but I don't want to see you fighting the wrong battle. Disclaimer: > this is just my outside observation having seen many a treecleaning > frustration in the past. I don't speak for any authority in Gentoo > here. I agree about the wrong battle. For those who want to use it after the treeclean, why don’t you add it to guru (or a personal overlay if it’s not accepted)? -- Alarig
Re: [gentoo-dev] last rites: sys-fs/eudev
On Mon, Sep 11, 2023 at 10:34 PM orbea wrote: > > Regardless the disappointment is a valid concern when Gentoo is willing > to pull the rug up from under users feet under erroneous claims of the > project being dead. > As a complete outsider, I think this conversation is focusing on the wrong issue. IMO the main reason it is getting treecleaned is the lack of a maintainer. Everything about this entire back-and-forth screams lack-of-maintainer. You're essentially arguing that the Gentoo devs are out of touch with the real status of upstream. To a point I'd agree - that's because normally it is a maintainer who stays on top of that stuff. This is a fairly critical system package for anybody who has it installed. You don't want something like that not getting attention when it has a problem, whether upstream or packaging-related. Blueness kinda summed it up in his original news item. This isn't something that can be handled by a drive-by commit or two, or a loosely involved proxy-maintainer. Somebody needs to really step up and take ownership of eudev for it to be viable. Even if upstream were great I wouldn't want to be using a stale package that is barely maintained. What is really needed is somebody stepping up and saying I will maintain this. If they were a Gentoo dev then the mask would probably be gone already (IMO never would have happened if they stepped up before now). If it were a proxy I don't want to speculate too much but they'd probably need to have a good history with such things. Without anybody saying "I will personally fix this stuff" I just don't see the treecleaning process stopping. Arguing about the state of upstream isn't going to change much, and if there were a maintainer they'd just be dealing with it. Sorry for this being a bit of a ramble. I do feel for your situation, but I don't want to see you fighting the wrong battle. Disclaimer: this is just my outside observation having seen many a treecleaning frustration in the past. I don't speak for any authority in Gentoo here. -- Rich
