Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
> On Sun, 17 Sep 2023, Florian Schmaus wrote: > > > > sounds perfectly fine. Don't use an attribute if you can put the information in the (otherwise empty) element. Especially, when other elements like already do it that way. > It would require (minor) adjustments to the schema and DTD. Also an update of GLEP 68, in the first place. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
On 2023-09-17 20:28:49, Alexe Stefan wrote:
>
> 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.
The PR is still vulnerable. These checks,
_chown() {
local path=$2 uid=$1
if ! owned_by_root "${path}" ; then
...
are insufficient to fix the vulnerability, because it's the parent
path(s) that are the problem. If any parent path is writable by a
non-root user, that non-root user can swap it out from under you,
even if the thing you're operating on is root:root.
AFAIK it's impossible to fix that in shell. In C, you can do a little
openat() dance ensuring that each component of your path is safe from
the root upwards -- that's why one of the suggestions is to rewrite
opentmpfiles 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?
>
The daemon runs "ln" or "ln -s", basically at its leisure, and
waits for opentmpfiles to run again.
[gentoo-dev] [PATCH] java-pkg-opt-2.eclass: drop EAPI 6
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-pkg-opt-2.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/java-pkg-opt-2.eclass b/eclass/java-pkg-opt-2.eclass
index 3a4b25ec2f0c..0caba1d40e07 100644
--- a/eclass/java-pkg-opt-2.eclass
+++ b/eclass/java-pkg-opt-2.eclass
@@ -6,7 +6,7 @@
# j...@gentoo.org
# @AUTHOR:
# Thomas Matthijs
-# @SUPPORTED_EAPIS: 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @PROVIDES: java-utils-2
# @BLURB: Eclass for package with optional Java support
# @DESCRIPTION:
@@ -14,7 +14,7 @@
# support.
case ${EAPI:-0} in
- [678]) ;;
+ [78]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -50,7 +50,7 @@ java-pkg-opt-2_pkg_setup() {
java-pkg-opt-2_src_prepare() {
use ${JAVA_PKG_OPT_USE} && java-utils-2_src_prepare
case "${EAPI:-0}" in
- [678]) use ${JAVA_PKG_OPT_USE} || eapply_user ;;
+ [78]) use ${JAVA_PKG_OPT_USE} || eapply_user ;;
esac
}
--
2.41.0
Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
On 9/17/23 20:28, Florian Schmaus wrote: sounds perfectly fine. Ideally I'd not limit it to only doi but also arxiv, zenodo, inspirehep. They can all be referenced by https://... . I agree a specific type is kind of unnecessary. However, the same paper can be referenced by all of them. If one wants to capture that redundancy. Could something like this work? zenodo='https://zenodo.org/record/8256635'/> arxiv='https://arxiv.org/pdf/2211.15838' doi='https://doi.org/10.22323/1.414.0245'/> I don't think this grouping is important though, just something useful one could add if one already goes for the GLEP route. Hence, I am not sure why you assume its too much work. If a user wants to list the references epkginfo/equery already shows the homepage or doc links, but not the new reference element, right? Similarly, the references would need extra treatment to be directly shown on packages.gentoo.org.| | Cheers, APN OpenPGP_0xCD7F8280C916D488.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan writes:
> 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.
Up to you.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
On 17/09/2023 14.18, Alexander Neuwirth wrote: Thanks. Instead of using the lang entry I can imagine these other approaches: 2. Adding something specific to GLEP 68, like `type="doi"> https...`. However that seems like a bit too much work for adding something that only a small subset of users (science) cares about. sounds perfectly fine. It would require (minor) adjustments to the schema and DTD. And besides that, packages that do not have a use for this information do not have to pay a cost. Hence, I am not sure why you assume its too much work. Also integration of parsing with existing tools is an extra overhead. Most XML parsers are non-strict. Which means that they ignore elements that they do not know. Therefore, the same argument as above can be made: tools that do not need to extract the information, should not require any adjustments. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
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 Sun, 17 Sep 2023 13:25:20 -0400 Michael Orlitzky wrote: > On 2023-09-17 15:32:46, Marc Joliet wrote: > > I just want to say how amazed I am that you (and Arsen, too) still > > have the patience to try and explain the realities of the situation > > like this, especially after the eudev thread. > > I'm a founding member of the systemd haters club so I'm sympathetic, > but in this case there are only a few realistic paths forward and none > of them involve opentmpfiles. > I'll say I agree too, I would like to stop using systemd-tmpfiles, but opentmpfiles is not a viable choice. Given this commit. https://github.com/OpenRC/opentmpfiles/commit/f33d0ea74bb0ab8bdf53e3df499323a828b3b1df And this comment. https://github.com/OpenRC/opentmpfiles/issues/19#issuecomment-877663396 At this point opentmpfiles seems actually dead and unmaintained, it also seems doubtful that will change in the foreseeable future. Its better to look into alternatives instead.
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] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
On 2023-09-17 15:32:46, Marc Joliet wrote: > I just want to say how amazed I am that you (and Arsen, too) still have the > patience to try and explain the realities of the situation like this, > especially after the eudev thread. I'm a founding member of the systemd haters club so I'm sympathetic, but in this case there are only a few realistic paths forward and none of them involve opentmpfiles.
[gentoo-dev] Last rites: dev-python/coreapi, dev-python/coreschema, dev-python/itypes
# Michał Górny (2023-09-17) # Core API has not been maintained since 2017, and all the repositories # have been archived in 2019. It remained in ::gentoo only # as an optional test dependency, and all reverse dependencies have been # updated not to depend on it. # Removal on 2023-10-17. Bug #914363. dev-python/coreapi dev-python/coreschema dev-python/itypes -- Best regards, Michał Górny
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
Am Sonntag, 17. September 2023, 15:32:46 CEST schrieb Marc Joliet: > Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky: > > On 2023-09-17 08:26:50, Alexe Stefan wrote: > [...] > > I just want to say how amazed I am that you (and Arsen, too) still have the > patience to try and explain the realities of the situation like this, > especially after the eudev thread. (Just to be clear: I mean this as a compliment!) -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
> On Sun, 17 Sep 2023, Alexander Neuwirth wrote: > Thanks. Instead of using the lang entry I can imagine these other > approaches: > 1. doi/arxiv/... links could also easily be plugged in custom upstream > remote ids, but that also feels a bit wrong since all other [upstream > remote > ids](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types) > are repos/source code providers. GLEP 68 rather abstractly says that the remote-id elements should point to "package identification trackers", and its predecessor GLEP 46 explains that this means the upstream source. So this doesn't look like a good fit. > 2. Adding something specific to GLEP 68, like ` type="doi"> https...`. However that seems like a bit too much work for > adding something that only a small subset of users (science) cares > about. Also integration of parsing with existing tools is an extra > overhead. This would require maintenance of another list of types. Looks like the semantic is implicit in the URL, so is a type really needed? A simpler change would be to lift the uniqueness restriction for the doc element, i.e. allow it multiple times for the same language. > 3. Put them also into `HOMEPAGE` of the ebuilds. Again bit of a wrong > place, but with the (minor) advantage of having possibly different/new > references per version. This wouldn't require any changes. > Is any of these three superior/preferable? It depends on how many packages in the Gentoo repository are expected to use the feature. If the answer is less than ten, then IMHO using HOMEPAGE is a reasonable choice. If it would be at least an order of magnitude more, then we could think about updating GLEP 68 (e.g. lift uniqueness of doc). Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Remove outdated reference to tc-has-openmp
On Sun, Sep 17, 2023 at 04:49:41PM +0200, Petr Vaněk wrote:
> tc-has-openmp function was deprecated in commit 9bc832c6d39b
> ("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
> commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
> Due to this, the reference to it in the tc-check-openmp function has
> become redundant and is therefore removed.
There is no difference between two patches I have sent. The second one
was additionally CCed to @MAINTAINER, which I forgot to add in first
attempt.
Petr
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Remove outdated reference to tc-has-openmp
tc-has-openmp function was deprecated in commit 9bc832c6d39b
("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
Due to this, the reference to it in the tc-check-openmp function has
become redundant and is therefore removed.
Signed-off-by: Petr Vaněk
---
eclass/toolchain-funcs.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 556bbac35307..8398ee004a7d 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -576,9 +576,7 @@ _tc-has-openmp() {
# @DESCRIPTION:
# Test for OpenMP support with the current compiler and error out with
# a clear error message, telling the user how to rectify the missing
-# OpenMP support that has been requested by the ebuild. Using this function
-# to test for OpenMP support should be preferred over tc-has-openmp and
-# printing a custom message, as it presents a uniform interface to the user.
+# OpenMP support that has been requested by the ebuild.
#
# You should test for any necessary OpenMP support in pkg_pretend in order to
# warn the user of required toolchain changes. You must still check for OpenMP
--
2.41.0
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Remove outdated reference to tc-has-openmp
tc-has-openmp function was deprecated in commit 9bc832c6d39b
("toolchain-funcs.eclass: deprecate tc-has-openmp") and later removed in
commit eb970274d283 ("toolchain-funcs.eclass: remove tc-has-openmp").
Due to this, the reference to it in the tc-check-openmp function has
become redundant and is therefore removed.
Signed-off-by: Petr Vaněk
---
eclass/toolchain-funcs.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 556bbac35307..8398ee004a7d 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -576,9 +576,7 @@ _tc-has-openmp() {
# @DESCRIPTION:
# Test for OpenMP support with the current compiler and error out with
# a clear error message, telling the user how to rectify the missing
-# OpenMP support that has been requested by the ebuild. Using this function
-# to test for OpenMP support should be preferred over tc-has-openmp and
-# printing a custom message, as it presents a uniform interface to the user.
+# OpenMP support that has been requested by the ebuild.
#
# You should test for any necessary OpenMP support in pkg_pretend in order to
# warn the user of required toolchain changes. You must still check for OpenMP
--
2.41.0
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky: > On 2023-09-17 08:26:50, Alexe Stefan wrote: [...] I just want to say how amazed I am that you (and Arsen, too) still have the patience to try and explain the realities of the situation like this, especially after the eudev thread. Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
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 :-)
Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
Thanks. Instead of using the lang entry I can imagine these other approaches: 1. doi/arxiv/... links could also easily be plugged in custom upstream remote ids, but that also feels a bit wrong since all other [upstream remote ids](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types) are repos/source code providers. 2. Adding something specific to GLEP 68, like `type="doi"> https...`. However that seems like a bit too much work for adding something that only a small subset of users (science) cares about. Also integration of parsing with existing tools is an extra overhead. 3. Put them also into `HOMEPAGE` of the ebuilds. Again bit of a wrong place, but with the (minor) advantage of having possibly different/new references per version. Is any of these three superior/preferable? OpenPGP_0xCD7F8280C916D488.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
On 2023-09-17 08:26:50, 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. The big picture is that the tmpfiles.d specification is impossible to implement securely on a POSIX system. The systemd devs wrote a specification to appease the people who complained, but that doesn't change the fact that the spec is fundamentally flawed unless you happen to be implementing it on a new linux system. (The authors didn't know this at the time, so it was not a dirty trick.) 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. The systemd folks put in a lot of work to make sure that the race window is a small as possible in systemd-tmpfiles. And on linux with kernel hardening, you're safe. Given that no one is working towards replacing tmpfiles completely, here's where that leaves us. We have the systemd utility that is as secure as possible, and opentmpfiles that tries to mimic it but is unmaintained and much less secure. At best, the insecure version could be rewritten in C to make it basically identical to the systemd version? Which has no real problems aside from the fact that it has systemd in the name. And no one is volunteering to do that rewrite in the first place. Newer linux systems are well supported by systemd-tmpfiles, and that's the only place tmpfiles is safe to begin with. It sucks that we're all stuck with tmpfiles now but you're only shooting yourself in the foot if you insist on using the worst possible implementation of it.
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
Arsen Arsenović writes: [snip] >> 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 ^^ C-h C-h... typo'd. > in systemd. > [snip] -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
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. > 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 :-) -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan writes:
> Upstream, it's maintained.
See my other emails for an explanation of why looking at a commit graph
is not good enough to tell if something is maintained.
> Downstream, 2 people volunteered.
And proposed ugly 'fixes' (read: hacks).
> So it is maintained.
>
> The incompatibilities are for some desktop specific situations, and
> there is a pr upstream(hacky, but work in progress).
No they aren't. The APIs eudev is missing (and stubs now) are not in
any way specific to desktop. I also don't buy that desktop-server
dichotomies exist.
> For servers, or minimal desktops(which is what I expect gentoo is
> mostly used for), eudev is fine.
Sorry, I don't buy that an out of date fork with unfixed known bugs that
regularly trails behind with the hwdb is 'fine'. Especially when said
fork has no improvements.
The only reason I see to use eudev is 'I prefer it out of principle'.
This is an okay reason, but it *does not* outweigh QA concerns. As I
said before, if those were to go away, which would be most simply
achieved by reforking up-upstream there would be no reason to omit eudev
anymore, and eudev would hence be back.
I know this is viable since I already tried to do so in order to keep
eudev alive because I expected this ruckus would happen, but nobody
aired interest, and my time to waste is scarce, so I dropped the project
and started using systemd-utils[udev].
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).
My last refork attempt involved a git-filter-repo based script which
reformatted the systemd repository into one that could be git-merge'd
into a tree with a build system. This worked, and it would be easy to
keep up-to-date, but I never finished it.
Hope to review your contributions upstream soon, have a lovely day :-)
--
Arsen Arsenović
signature.asc
Description: PGP signature
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.
Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles
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/
