Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/17/23, Arsen Arsenović wrote:
> In the meanwhile, while the two downstream volunteers address that, an
> ::eudev overlay can be established. As I went over in another email I
> posted to this thread, it should not be particularly difficult to
> implement or maintain (nowhere close to LibreSSL, for instance, as eudev
> didn't diverge nearly as much as LibreSSL did, and since
> virtual/{lib,}udev exist).
>
It seems like we will have to do this.
Should we make a new overlay or use an existing one?
If we make a new overlay, where should we host it?
There is the without-systemd overlay on github. Should we use that?
If we make something new, I'd rather it be on something like codeberg.
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
On 9/17/23, orbea wrote: > On Sun, 17 Sep 2023 12:58:00 +0200 > Arsen Arsenović wrote: > >> Alexe Stefan writes: >> >> > One is written in shell, the other is written in c.(no problems >> > here) >> >> Not that implementation language matters. >> >> > One is not part of systemd, the other is. >> >> Both work fine without systemd, but the systemd implementation also >> happens not to be unmaintained and happens to be more complete. > > Here are some other implementations I have found, but I am not sure if > they are drop-in replacements or not. > > https://github.com/eweOS/pawprint > https://github.com/juur/tmpfilesd > >> >> > How are they identical. >> >> The last rites message does not say that opentmpfiles and >> systemd-tmpfiles are identical. That'd do a disservice to the >> actually complete, unmaintained, and (currently) non-CVE-affected >> implementation in systemd. >> >> > I use this on my raspi server, works fine. >> >> 'WOMM' is a fairly terrible measure. >> >> > Gentoo really became a systemd distro, further restricting choice by >> > the day. >> >> [ignoring this nonsensical statement, notice put here for clarity] >> >> >> Gentoo devs aren't obliged to maintain software you like to use. >> systemd-utils[tmpfiles] works on all Gentoo systems, including >> non-systemd ones. Until that changes (which is unlikely), I doubt >> there will be much interest in maintaining a fork from inside Gentoo. >> >> Please take up opentmpfiles maintenance. You have >> https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb >> to address, and probably some other issues. See >> https://github.com/OpenRC/opentmpfiles/issues/19 for context. >> >> The message above implies that a rewrite in C is necessary. >> >> This should be rather easy. The systemd implementation is only ~4k >> LoC (excluding shared code), so I imagine that a complete >> reimplementation should be far less than 10k. Since this is fairly >> elementary stuff, it should be possible to finish in a weekends time. >> >> Submit a PR to re-add opentmpfiles after you're done. >> >> Looking forward to reviewing your contributions upstream. Have a >> lovely day :-) > > > There are 2 open pr's on the opentmpfiles github. One removes the security vulnerability, but is non-compliant with the spec, the other is (at least is a start of) a rewrite in c. >As a result, opentmpfiles never should have tried to implement it, but >its authors didn't know about those problems either. And while >implementing tmpfiles in C has certain unavoidable race conditions, >ho boy is the shell version swiss cheese. There's no safe way >to run chown and chmod (the shell commands) as root in a directory you >don't control, and that's a big part of what opentmpfiles does. The >exploits for the shell version are kindergaren stuff. > Is it really so easy to exploit it? How would you do that?
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/17/23, Arsen Arsenović wrote: > > Alexe Stefan writes: > >> Yet another example of choice being restricted by gentoo. >> However, there at least is a better reason for not keeping libressl in >> ::Gentoo, that reason being qt. > > ... and the swathes of other packages that are not compatible with it... > especially since openssl:3 exists. Please face reality. > >> With eudev, there is even less reason to remove it from ::gentoo. >> The only maintenance burden with eudev is a couple of commits here and >> there, mostly in virtuals. > > There's at least two reasons to remove it (it's unmaintained, out of > date, and incompatible), and at most zero to keep it. > > Fix upstream and the reasons for removal will be gone, and the (illusion > of) choice will be there again. Note that I refuse to accept the idea > that this is choice. The code is the same. > > Have a lovely night. > -- > Arsen Arsenović > Upstream, it's maintained. Downstream, 2 people volunteered. So it is maintained. The incompatibilities are for some desktop specific situations, and there is a pr upstream(hacky, but work in progress). For servers, or minimal desktops(which is what I expect gentoo is mostly used for), eudev is fine.
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
On 9/17/23, David Seifert wrote: > On Sun, 2023-09-17 at 08:26 +0300, Alexe Stefan wrote: >> One is written in shell, the other is written in c.(no problems here) >> One is not part of systemd, the other is. >> How are they identical. >> >> I use this on my raspi server, works fine. >> >> Gentoo really became a systemd distro, further restricting choice by >> the day. >> > > http://www.islinuxaboutchoice.com/ > > That mail is about fedora, the furthest you can go away from choice on linux. However, that page talks about fedora as if all of linux is fedora. Gentoo is not fedora... yet.
[gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
One is written in shell, the other is written in c.(no problems here) One is not part of systemd, the other is. How are they identical. I use this on my raspi server, works fine. Gentoo really became a systemd distro, further restricting choice by the day.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/16/23, David Seifert wrote:
> On Fri, 2023-09-15 at 15:40 -0700, orbea wrote:
>> On Fri, 15 Sep 2023 01:19:22 +0200
>> Arsen Arsenović wrote:
>>
>> > "Eddie Chapman" writes:
>> >
>> > > Not aiming this at you personally but this argument has been made
>> > > more than once in this thread and I personally don't think it
>> > > carries any weight, because it can be levelled at anyone who
>> > > raises
>> > > an issue about anything. If you don't like it, then just go and
>> > > roll your own.
>> >
>> > ::gentoo is supposed to be a coherent set of packages provided by
>> > Gentoo developers, with a reasonable scope. eudev no longer fits
>> > into the 'coherent' part of that definition, and there are zero
>> > advantages to it over systemd-utils[udev].
>> >
>> > The _only_ difference between a sys-fs/eudev::eudev and
>> > sys-fs/eudev::gentoo package that would exist if the former were to
>> > be
>> > made into an overlay is that Gentoo developers would be responsible
>> > for the latter. There are no Gentoo developers interested in being
>> > responsible for the latter (AFAIK), and there is no tangible benefit
>> > to the latter for any Gentoo developer to latch onto.
>> >
>> > Seeing as there is at least half a dozen people seemingly interested
>> > in maintaining eudev, why not just form an overlay? This way,
>> > virtual/{,lib}udev doesn't get polluted with implementations which
>> > don't fullfil the definition of a virtual provider in ::gentoo, nor
>> > with use-flag hacks, but users which wish to use eudev still have
>> > access to it, and upstream eudev gets half a dozen potential
>> > contributors, which are needed, _badly_. At risk of repeating
>> > myself, I'd like to point out again that the only viable approach
>> > for
>> > eudev upstream to take is to re-fork systemd and find a viable way
>> > to
>> > stay up-to-date, while fixing up incompatibilities with musl. I've
>> > made proposals a few years ago and restated them in this thread.
>>
>> I just want to reiterate that the overlay suggestion is bad and the
>> LibreSSL overlay is a good example of why. The result is most of the
>> work is redoing things that ::gentoio has already done by copying
>> ebuild changes where actual changes for LibreSSL itself or for
>> packages
>> not compatible with it is a vast minority of the work.
>>
>
> Many people told you that ::libressl is a waste of time, and you've
> proven to us that it is.
>
>
Yet another example of choice being restricted by gentoo.
However, there at least is a better reason for not keeping libressl in
::Gentoo, that reason being qt.
With eudev, there is even less reason to remove it from ::gentoo.
The only maintenance burden with eudev is a couple of commits here and
there, mostly in virtuals.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/14/23, Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 17:50, Eddie Chapman wrote: >> > > > No one is telling anyone not to use it. The question has been asked "why use > it" > to ascertain reasons for keeping it in ::gentoo. Something not being in > ::gentoo isn't a decree to not use it, it's a statement that it's a > pain to keep maintained > in portage for an entire user base. > > If it was simply ordering/bullying people into not using it, the > advice to form a repo or > talk to guru or simply keep it in your own overlay wouldn't have been > given. > > There's a huge difference between "suitable for a niche use case" and > "suitable > for the entire Gentoo user base should they wish to make use of it". The > latter > is where eudev had deteriorated for some time, again this current libgudev > issue > being the latest example rather than the only one. > > -- > Ninpo > > Gentoo is about choice, and we should keep it that way. If we start removing packages like this, gentoo will become source-based arch. What is the problem here? It's not like someone who doesn't know what they are doing can install eudev by mistake. One has to explicitly chose to use eudev. So what is the problem with keeping the package in ::gentoo. Mask it if you must, like opentmpfiles, but don't remove it.
Re: [gentoo-dev] last rites: sys-fs/eudev
It seems like the discussion got way off-topic. To see where where at, I'll try to summarize what was said so far. The claims are that eudev is unmaintained upstream, downstream and has open bugs. Upstream, last commit was 3 weeks ago. Downstream, Orbea said he is willing to help maintain it. He is known for his great work on libressl(thank you), so there should be no problems here. Most of those bugs are invalid, outdated or being worked upon. Are there any other problems here?
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Dale wrote: > Alexe Stefan wrote: >> >> While my posts may be a little bit inflammatory, no one pointed out >> where I'm wrong. >> I don't hate gentoo, but I don't want choice to be taken away from users. >> If we(the users) only respond to issues that individually impact us, >> choice will be taken away from everyone eventually(unless it's the >> "right" choice as agreed by Lennart & co). It is called "divide and >> conquer". >> I do not hate gentoo. I want to see it offer as much choice as >> possible, not restrict it. >> I had to bear with systemd for some time before going to gentoo. I >> don't want that to happen again. >> >> > > I'm a eudev user. I don't like systemd either. I'm actually having to > deal with it for the first time after installing Ubuntu for a NAS box on > a under powered rig with not a lot of memory. I can honestly say, I > don't like systemd from experience. I'm one who will likely have to > switch to udev even tho I don't care too. While I'm not excited about > it, given the lack of coders wanting to keep it alive, I'll just have to > switch. I may be losing a choice but hey, at least I had one that other > distros never had. Some distros switched with no alternative long ago. > > If I, someone who hates change, can change, I'm not sure why you can't > accept that eudev just may have reached its end of life on Gentoo. I > missed the news item a year or so ago. I had no idea it was not being > maintained on Gentoo. This sort of hit me all at once, most likely the > same as you. Unless someone steps up in the next week or so, I'll be > switching. At the least, I'm grateful to have OpenRC. Don't get me > started on trying to figure out how to restart a service on Ubuntu. As > bad as all the compiling is, Gentoo is a walk in the park. Restart a > service, /etc/init.d/ are close>. Try that in Ubuntu. Forget a hair cut this month. I'm > doing good to have hair. :@ Let's see what happens and if eudev dies, > let's accept it and be grateful for the time we did have a choice, while > some kinks got worked out of systemd udev at least. > > To the other devs reading this thread still. Thanks much from a 20 year > user of Gentoo. It was bumpy at first but it sure has come a > LNG ways. I can't say enough about how much emerge has improved > and how dependencies are resolved with ease for us users. The work on > the emerge command and ebuilds has improved a LOT. I still wish the > error output was more friendly but hey, at least there is a whole lot > less of it. :-D > > Let's deal with what is in front of us. Thanks again to the devs. > > Dale > > :-) :-) > > I'm going back to my hole now. > > I do deal with what is in front of us. Today it's eudev. Tomorrow will be opentmpfiles or openrc.
Re: [gentoo-dev] last rites: sys-fs/eudev
To be clear, I don't say that devs shouldn't get paid. They should just be honest about who pays them to make changes.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Eli Schwartz wrote: > 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. :) > I didn't. Maybe I'll do that from now on. To make it clear, the only way for my contributions to make their way into gentoo is if a dev agrees with them. I do post workarounds and hacks in various places though, including various overlays. > >>>>>> 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 tee
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, 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] 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 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
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
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. On 9/12/23, Alexey Sokolov wrote: > 11.09.2023 22:35, Sam James пишет: >> >> Alexey Sokolov writes: >> >>> 11.09.2023 22:21, Sam James пишет: orbea writes: > On Mon, 11 Sep 2023 21:31:30 +0100 > Sam James wrote: > >> Dale writes: >> >>> orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" wrote: > Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: > >> Upstream is maintained still. >> >> https://github.com/eudev-project/eudev >> > No, it's not. > > Based on what? It has several commits this year and is currently working on both of my systems. Is there something specific showing why its not maintained? . >>> >>> On the link above it says this: >>> >>> >>> On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>> (alphabetical order). >>> >>> >>> It seems to have a upstream that is active but no one is >>> maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>> now. It would seem given the time span that no one wants to take >>> it. >>> >>> Like others, I use it but didn't know it wasn't maintained anymore. >>>I hope someone will step up but if not, looks like we have to use >>> udev. >> >> No, see the linked bugs. Someone has to actually make it compatible >> with the tags API which software is starting to use. > > I think its only a matter of time. > > https://github.com/eudev-project/eudev/pull/253 > > I'll apply the patch and test the builds if it helps, but I don't know > about testing the runtime functionality of libgudev. Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this. >>> >>> Of course. Just like any other PR to any other project :) What's your >>> point? >> >> I don't know what you mean. My point is none of that has been happening. >> > > I see, ok. I would agree with you, however, the author of that PR is a > member of eudev org, so I wouldn't say it's dead just yet. > >>> Also note that the PR is a hack rather than a full implementation of the functionality anyway, which may lead to runtime misbehaviour. >>> >>> And that's fine for programs which don't make use of the new API. >>> >> >> and? Someone has to actually check that? >> >> >> > > -- > Best regards, > Alexey "DarthGandalf" Sokolov > > >
[gentoo-dev] Re: [gentoo-dev-announce] Multiple packages up for grabs (incl. zsh, feh, zathura, qbittorrent)
Just... how? Are there really that few people using them? I thought these were popular packages. Of the list, I only use feh, qbittorrent and libtorrent-rasterbar. Thank you to those who said they are willing to maintain feh, Orbea and Yixun Lan. What is going to happen to the other 2 packages? Hope I won't have to add them to my overlay. On another note, I've seen plenty of people with a reported client of libtorrent. Is it possible to run libtorrent by itself? On 8/26/23, Ionen Wolkens wrote: > Noticed that the following packages have been dropped to m-n > back on August 9 2023, but no mail been sent: > > app-shells/zsh > media-gfx/feh > net-libs/libtorrent-rasterbar > net-p2p/qbittorrent > x11-misc/xclip > > -- > ionen >
Re: [gentoo-dev] www-client/chromium needs a new maintainer
Can you build firefox/librewolf with gcc? Afaik, you can only build it with clang/llvm. Librewolf if the only reason I have clang and llvm on my system. joi, 8 iun. 2023, 10:31 Joonas Niilola a scris: > Luckily few years ago > Mozilla invested in a pretty efficient CI system where they now test > commits/releases using multiple different setups; for example, multiple > different llvm releases, gcc etc. >
Re: [gentoo-dev] www-client/chromium needs a new maintainer
I don't use chromium and I don't know what release cycle it has, but can't
those interested in running chromium use an ebuild that tracks the git tree
and updates after every change.
The maintenance burden would be minimal, and any patches could be applied
with /etc/portage/patches.
If something like this isn't suitable for ::gentoo, it can be added to a
personal overlay.
If the upstream release cycle is too fast, someone could fork the repo and
update the fork as slow as desired.
Maybe something like this:
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the MIT License
EAPI=8
DESCRIPTION="The chromium browser"
HOMEPAGE="https://github.com/chromium/chromium;
EGIT_REPO_URI="https://github.com/chromium/chromium.git;
inherit git-r3
LICENSE="BSD-3"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
DEPEND="|| (sys-devel/gcc
sys-devel/clang )"
RDEPEND="${DEPEND}"
BDEPEND=""
src_configure() {
chromium_configure
}
src_install() {
chromium_compile
mv out/Release/chromedriver{.unstripped,} || die
rm -f out/Release/locales/*.pak.info || die
# Build manpage; bug #684550
sed -e 's|@@PACKAGE@@|chromium-browser|g;
s|@@MENUNAME@@|Chromium|g;' \
chrome/app/resources/manpage.1.in > \
out/Release/chromium-browser.1 || die
# Build desktop file; bug #706786
sed -e 's|@@MENUNAME@@|Chromium|g;
s|@@USR_BIN_SYMLINK_NAME@@|chromium-browser|g;
s|@@PACKAGE@@|chromium-browser|g;
s|\(^Exec=\)/usr/bin/|\1|g;' \
chrome/installer/linux/common/desktop.template > \
out/Release/chromium-browser-chromium.desktop || die
# Build vk_swiftshader_icd.json; bug #827861
sed -e 's|${ICD_LIBRARY_PATH}|./libvk_swiftshader.so|g' \
third_party/swiftshader/src/Vulkan/vk_swiftshader_icd.json.tmpl > \
out/Release/vk_swiftshader_icd.json || die
}
Also, with all this discussion, one can't help but wonder, is
firefox/librewolf also in such danger?
On Wed, Jun 7, 2023 at 7:49 PM Mike Gilbert wrote:
> On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso wrote:
> >
> > That does sound painful.
> >
> > > - Across the 3 channels, you are looking at roughly 12 releases per
> month.
> > > That's a lot of churn.
> >
> > * Why build unstable stuff, why not build only stable releases and fix
> the
> > problems once?
>
> That's certainly an option. The downside is stable releases almost
> always fix security issues, so you are "under the gun" at that point.
>
> > * Looking at chromium-browser-official and the GitHub mirror, it's
> unclear to
> > me which release is stable. How is that sorted out?
>
> Some links for you:
>
> https://chromiumdash.appspot.com/releases?platform=Linux
> https://chromereleases.googleblog.com/
>
> > > - Upstream likes to use modern C++ features, and they write C++ code
> that
> > > tends to break or is unsupported on stable releases of GCC and LLVM.
> >
> > * How common of a problem is the C++ issue?
>
> There are usually some issues with every major Chromium version.
>
> > * I don't know C++, is that a major obstacle?
>
> Yes; you would at least need to teach yourself enough of the language
> to attempt to interpret compiler error message.
>
> > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> > > unbundle a number of these, but maintaining it is a pain.
> >
> > * What tends to go wrong?
>
> - Version mismatches: upstream expects a different version of the
> library than we have stable on Gentoo.
> - Custom patching: sometimes Chromium forks/patches the bundled
> library and there is a delay in sending those changes upstream (if it
> ever happens).
> - Chromium source files sometimes refer to the bundled header files
> directly (#include "third_party/mylib/mylib.h") instead of using a
> generic path like #include .
>
> > > - Using the bundled libraries sometimes is problematic, especially on
> > > non-x86-64 targets which upstream doesn't support well.
> >
> > * What tends to break here?
>
> For example, take ffmpeg. The bundled library uses a pre-configured
> copy of ffmpeg, which can break depending on the user's system. At a
> minimum, we need to reconfigure the bundled ffmpeg to work properly.
>
> > * Is the upstream likely to take patches or are we stuck maintaining a
> patch
> > set for pretty much all non-x86-64 targets?
>
> Upstream supports x86-64 and ARM only. All other targets require
> distro patching.
>
> > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make
> > their way upstream?
>
> Yes, this is why we have a PPC64 patchset (which we mostly steal from
> Raptor Computing).
>
>
Re: [gentoo-dev] www-client/chromium needs a new maintainer
My finger slipped in my last mail. How do you see how many people are using a package? On Wed, Jun 7, 2023 at 10:58 AM Alexe Stefan wrote: > > > mie., 7 iun. 2023, 13:56 Sam James a scris: > >> >> This becomes more pressing as the vulnerabilities pile up: >> https://bugs.gentoo.org/907999. >> >> Nobody interested at all? We have more than enough people *using* it.. >> >> >>
Re: [gentoo-dev] www-client/chromium needs a new maintainer
mie., 7 iun. 2023, 13:56 Sam James a scris: > > This becomes more pressing as the vulnerabilities pile up: > https://bugs.gentoo.org/907999. > > Nobody interested at all? We have more than enough people *using* it.. > > >
Re: [gentoo-dev] [PATCH] profiles: create USE=valgrind global USE flag
So it's only useful for developers that already use valgrind. sâm., 27 mai 2023, 17:13 Sam James a scris: > > Alexe Stefan writes: > > > In that case, is it worth it to enable USE=valgrind globally? > > I have, and I'd say others interested in using Valgrind should too. > > >
Re: [gentoo-dev] [PATCH] profiles: create USE=valgrind global USE flag
In that case, is it worth it to enable USE=valgrind globally? vin., 26 mai 2023, 10:44 Sam James a scris: > > Sam James writes: > > > [[PGP Signed Part:Undecided]] > > > > Sam James writes: > > > >> Alexe Stefan writes: > >> > >>> Does enabling USE=valgrind impact runtime performance in any way? > >> > >> A very small amount because it adds a check at runtime for whether > >> the application is running under Valgrind. The compiler may be able > >> to optimise this a bit if it can determine it's unlikely (if the > >> Valgrind headers don't already do this, they should probably mark > >> them as cold functions). > > > > Sorry, I should say, they're hot functions but the if()s for them > > should be unlikely()'d. > > Alexander Monakov reached out and pointed out this isn't right - they're > actually branchless and just encoded in nops, so there's really > essentially no runtime cost. > > >
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-portage/layman
Regarding the dependency on pyGPG and g-sorcery, I have layman installed without any of those programs installed. vin., 19 mai 2023, 02:08 Sam James a scris: > > Alexe Stefan writes: > > > Layman is still a convenient way of managing overlays. It still works > > as intended. > > Is there any way for it to be kept in the repos? > > Is there an issue for you with using eselect-repository, which is > actively maintained and doesn't depend on unmaintained software > (pyGPG and g-sorcery)? > >
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-portage/layman
What is the alternative to layman -S? I would like to have a way of syncing only my overlays, as there are often fixes pushed multiple times in the same day and I would like to avoid syncing ::gentoo every time I sync my overlays. vin., 19 mai 2023, 02:08 Sam James a scris: > > Alexe Stefan writes: > > > Layman is still a convenient way of managing overlays. It still works > > as intended. > > Is there any way for it to be kept in the repos? > > Is there an issue for you with using eselect-repository, which is > actively maintained and doesn't depend on unmaintained software > (pyGPG and g-sorcery)? > >
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-portage/layman
Layman is still a convenient way of managing overlays. It still works as intended. Is there any way for it to be kept in the repos? vin., 19 mai 2023, 01:35 David Seifert a scris: > # David Seifert (2023-05-19) > # Abandoned, replaced by 'eselect repository', tons of open bugs. > # Removal on 2023-06-18. Bug #761199. > app-portage/layman > >
Re: [gentoo-dev] [PATCH] profiles: create USE=valgrind global USE flag
Does enabling USE=valgrind impact runtime performance in any way? dum., 14 mai 2023, 19:46 Arsen Arsenović a scris: > > Sam James writes: > > > This always has the same meaning in packages - build in annotations to > help > > with e.g. custom memory allocators to reduce noise and improve > Valgrind's accuracy. > > > > All invalid uses of this were already fixed (cases where it was used to > control > > running the testsuite under Valgrind which we don't want to do, it's too > flaky > > under sandbox & not reliable with diff arches.) > > LGTM. thanks! > > > Signed-off-by: Sam James > > --- > > profiles/use.desc | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/profiles/use.desc b/profiles/use.desc > > index 04ca8e845ccd9..675fd291fee22 100644 > > --- a/profiles/use.desc > > +++ b/profiles/use.desc > > @@ -1,4 +1,4 @@ > > -# Copyright 1999-2022 Gentoo Authors > > +# Copyright 1999-2023 Gentoo Authors > > # Distributed under the terms of the GNU General Public License v2 > > > > # Keep them sorted > > @@ -333,6 +333,7 @@ usb - Add USB support to applications that have > optional USB support (e.g. cups) > > v4l - Enable support for video4linux (using linux-headers or userspace > libv4l libraries) > > vaapi - Enable Video Acceleration API for hardware decoding > > vala - Enable bindings for dev-lang/vala > > +valgrind - Enable annotations for accuracy. May slow down runtime > > slightly. Safe to use even if not currently using dev-util/valgrind > > vanilla - Do not add extra patches which change default behaviour; DO > NOT USE > > THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically > > vcd - Video CD support > > vdpau - Enable the Video Decode and Presentation API for Unix > acceleration interface > > > -- > Arsen Arsenović >
