Re: [gentoo-dev] Re: last rites: sys-fs/eudev
On Thu, 14 Sept 2023 at 01:20, Madhu wrote: > > * Rich Freeman > : > Wrote on Tue, 12 Sep 2023 05:18:51 -0400: > > 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. > > One of the planned consequences of this tree-cleaning is the removal > of genkernel, and the use of genkernel to build gentoo's initramfs. > > Genkernel uses eudev for udev, and it works because eudev can be built > statically. > > systemd-udev cannot be built as a static binary again presumably a > carefully thought out design decision behind its design and > philosophy. > > eudev works perfectly well for the job genkernel does, udev is not a > drop-in replacement for udev in genkernel initramfs because it doesn't > support static compilation. Removing eudev leads to a roadmap to > deprecate genkernel last-rite and remove it. genkernel doesn't use eudev from ::gentoo it uses its own private copy. > Gentoo actively removes support for individual configurations, and only > supports is for configurations that fedora has already engineered and > controls because that is where the devs seem to be coming from. What the actual hell are you on about
[gentoo-dev] Re: last rites: sys-fs/eudev
* Rich Freeman : Wrote on Tue, 12 Sep 2023 05:18:51 -0400: > 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. One of the planned consequences of this tree-cleaning is the removal of genkernel, and the use of genkernel to build gentoo's initramfs. Genkernel uses eudev for udev, and it works because eudev can be built statically. systemd-udev cannot be built as a static binary again presumably a carefully thought out design decision behind its design and philosophy. eudev works perfectly well for the job genkernel does, udev is not a drop-in replacement for udev in genkernel initramfs because it doesn't support static compilation. Removing eudev leads to a roadmap to deprecate genkernel last-rite and remove it. I know you are a dracut user, but I've been unable to use dracut with 1. cryptsetup swap + swsuspend + zfs on root. Gentoo actively removes support for individual configurations, and only supports is for configurations that fedora has already engineered and controls because that is where the devs seem to be coming from.
Re: [gentoo-dev] last rites: sys-fs/eudev
Andrew Ammerlaan wrote: > On 12/09/2023 23:23, Eddie Chapman wrote: > >> Andrew Ammerlaan wrote: >>> >>> On 12 September 2023 21:47:31 CEST, Eddie Chapman >>> wrote: >>> Andreas K. Huettel wrote: > * 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? > > This is a misrepresentation of my point. I never said that any rationale > for choosing one piece of software over another must be purely technical. A > license, political issue or whatever may be a legitimate advantage that > one option has over another. I'm simply stating that no one has explicitly > provided any rational for choosing eudev over systemd-utils[udev]. > > From the lack of response to my original question I can only conclude > that the only reason to choose eudev over systemd-utils[udev] is because > the latter package has "systemd" in the name (the horror!). If that is > truly the case it would be a lot simpler to rename sys-apps/systemd-utils > to sys-apps/utilities-from-the-init-system-that-must-not-be-named, then to > continue to maintain eudev. > >>> 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? > > If someone were to step up and say they are willing to spend their time > and effort maintaining eudev and fixing the open issues then sure we can > keep it, I never said otherwise. However this package has been > maintainer-needed for quite a long time now and no one has stepped up, at > some point someone has to pull the plug. > > My point (which again you misrepresented) is that if you can't provided > a solid reason for choosing eudev over systemd-utils[udev] you are going to > have a very hard time convincing others to put in their time and effort > maintaining it, no matter how loudly you complain on the mailing list. So > either maintain it yourself in some overlay, or provide some solid and > convincing argumentation in favor of eudev. And as I already pointed out > above "choice for the sake of choice" is not a convincing argument. > > And then another thing, how is it possible that so many people missed > the news item? They are displayed quite prominently I think, and emerge > will keep buggering you about it until it is marked as read. Just > wondering if there is something that can be improved here. > > Best regards, > Andrew Hi Andrew, I just want to apologise if I made you feel I misrepresented your points. I certainly didn't mean to do that, and I was quite puzzled to read your message just now and hear you say that, and having re-read what you wrote and then
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan writes: > 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. Please, take into account the contents of said commits. One of the more recent ones bumps the version in the .pc file while /stubbing/ only one of the APIs versions up to and including that one added. I've originally advocated for keeping eudev, and have put in some effort to restart the project by essentially reforking systemd 'today' (i.e. at the time a few years ago). Since then it has been effectively demonstrated to me that there is no interest in doing that (which is, mind you, the only viable path for remaining compatible. Note that competition here is perfectly useless, so staying compatible is the only viable path for the existence of the project *at all*); as a result, I began to lose motivation to continue, combined with being quite busy that year, I ended up simply switching to systemd-utils[udev], which was equivalent, except up-to-date, without ever finishing extracting/porting the needed shared code. The merge-base (which is a rough measure but it provides a time frame) of eudev and systemd is from Nov 2012, since then, only 1.3k commits were added to the eudev tree (as opposed to the systemd tree, where 57.5k commits were added, note that not all of those, or even many of those, are udev-related, but many are shared code between udev and other components). On top of that, only 143 of those were added to the repository since Gentoo stopped maintaining eudev. I estimate ~800 commits were added to systemd's udev since the eudev project got separated (and then eudev was already trailing long behind!), without counting shared code, so it's clear that eudev is failing to keep pace, let alone catch up I agree that upstream is alive. That's what life support is. > 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. LibreSSL is an excellent example of a fork that is only useful if it remains compatible failing to be useful because it fails to be compatible. Thank you for bringing it up, it is quite a good cautionary tale. (naturally, I also used that back in the day...) > Most of those bugs are invalid, outdated or being worked upon. > > Are there any other problems here? The approach of forking in the traditional sense is fundamentally flawed here. If you want to keep eudev alive, please, do us all a favor and give upstream a hand at re-forking systemd, and finding a sustainable approach for keeping the fork up-to-date. I originally did this by filtering down the systemd repository into the appropriate directory structure, and then adding in a new build system and extracting the shared code. The filtered repository can then be used as a branch or separate repository that's merged into the new build system (either as a subtree or as the toplevel). This should have kept most of the code easy to update. PS: I had decided to respond to ~5 emails in this thread, but I realized that the answer to all of them would be exactly what I wrote here. This thread feels like a lot of repetition. Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/13/23 9:10 AM, Michael Orlitzky wrote: > On Tue, 2023-09-12 at 22:52 -0400, Eli Schwartz wrote: >> >> Is portage generally expected to successfully complete (including >> internal metadata write stages) when its workdir drive runs out of space >> partway through? >> > > No, but I think what everyone else is forgetting to mention is that if > it's going to fail, we want it to fail as soon as possible, i.e. as > close to the thing that actually went wrong. If we proceed past ENOSPC > or whatever, we could get five or six lines further in the ebuild, and > then some other command will fail but possibly with a crazy unrelated > error message. The consequences of this particular command failing are that: - setuptools will still build, but without spawning a ThreadPoolExecutor to distribute jobs; it builds single threaded - setuptools will still build, but using its default build directory instead of an alternative one; setuptools itself *cannot* fail as a result, but other external commands hardcoding the location of setuptools internal files could fail to find those files (It will still fail when setuptools reports its own ENOSPC, but this is not a crazy unrelated error message.) (Unless portage expects to successfully complete where possible if the workdir drive runs out of space partway through, then quickly has more space freed up for it as soon as monitoring warnings are triggered and no actually-fatal ebuild errors occurred during the window of ENOSPC.) -- Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/13/23 5:27 AM, Ulrich Mueller wrote:
>> On Wed, 13 Sep 2023, Eli Schwartz wrote:
>
>>> "|| 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.
>
> That's a rather bold statement. I can imagine a number of possible
> failures, e.g. no space left on device, quota exceeded, or a low-level
> I/O error of the filesystem. Also fork or exec of the cat command could
> fail (e.g. out of memory).
>
> While either of these may be unlikely here, best practice is to check
> for errors of _all_ external commands.
The implementation of `die` performs a fork+exec of the sed command,
invokes eerror (many times!) which forks to pipe, invokes $() which
forks, and could behave abnormally due to out of memory. It is not safe
to treat `|| die` as error recovery for an out of memory condition.
The implementation of `die` performs multiple writes to files inside of
${PORTAGE_BUILDDIR}, and could behave abnormally due to write failures.
It is not safe to treat `|| die` as error recovery for a write failure
of the ${PORTAGE_BUILDDIR} drive (whatever the reason for that write
failure).
Regarding:
- no space left on device
- quota exceeded
- low-level I/O error of the filesystem
this isn't "a number of possible failures" :) it is the same failure but
elicited by different prompts. Regarding this, I have already commented...
(And the `|| die` is added to the next revision of this patch either way.)
--
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:52 -0400, Eli Schwartz wrote: > > Is portage generally expected to successfully complete (including > internal metadata write stages) when its workdir drive runs out of space > partway through? > No, but I think what everyone else is forgetting to mention is that if it's going to fail, we want it to fail as soon as possible, i.e. as close to the thing that actually went wrong. If we proceed past ENOSPC or whatever, we could get five or six lines further in the ebuild, and then some other command will fail but possibly with a crazy unrelated error message.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 10:34, Alexe Stefan wrote: > > 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? > Yes, the general dip in overall activity and quality of what's going on with upstream eudev maintenance, their approach to the libgudev/sticky tags API change that triggered this discussion being a great example.
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] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
> On Wed, 13 Sep 2023, Eli Schwartz wrote: >> "|| 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. That's a rather bold statement. I can imagine a number of possible failures, e.g. no space left on device, quota exceeded, or a low-level I/O error of the filesystem. Also fork or exec of the cat command could fail (e.g. out of memory). While either of these may be unlikely here, best practice is to check for errors of _all_ external commands.
Re: [gentoo-dev] last rites: sys-fs/eudev
Eli Schwartz wrote: > 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
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 09:55, Andrew Ammerlaan wrote: > And then another thing, how is it possible that so many people missed > the news item? They are displayed quite prominently I think, and emerge > will keep buggering you about it until it is marked as read. Just > wondering if there is something that can be improved here. I think ultimately the news item is irrelevant to the situation at the moment. Soon after the news item, someone else took over and created a new upstream. The news item does not concern the new maintainers, the package was then never removed, and the package from the new upstream was added to ::gentoo. In my opinion it's no mystery that no one would remember what it said. Regards, Arve
Re: [gentoo-dev] last rites: sys-fs/eudev
Andrew Ammerlaan wrote: > > And then another thing, how is it possible that so many people missed > the news item? They are displayed quite prominently I think, and > emerge will keep buggering you about it until it is marked as read. > Just wondering if there is something that can be improved here. > > Best regards, > Andrew I'm pretty good at reading the news items. I seem to recall that you see one only if it affects you, you have a package installed or something. So, if it shows up, it is best to take notice. That said, I don't recall seeing the news item either. I can't imagine me missing it but I also can't imagine me not taking action either. After all, (eu)dev is a important package. One thing is for sure, the name is rather obvious. The first word in the title is eudev. I have yet to figure out how I missed it. Given the number of people who did, could there have been a glitch and it didn't show for some weird reason? Has someone who understands the code checked to see if there was some typo that made it not show for most users? I do think this is worth looking into. It just seems odd. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
On 12/09/2023 23:23, Eddie Chapman wrote: Andrew Ammerlaan wrote: On 12 September 2023 21:47:31 CEST, Eddie Chapman wrote: Andreas K. Huettel wrote: * 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? This is a misrepresentation of my point. I never said that any rationale for choosing one piece of software over another must be purely technical. A license, political issue or whatever may be a legitimate advantage that one option has over another. I'm simply stating that no one has explicitly provided any rational for choosing eudev over systemd-utils[udev]. From the lack of response to my original question I can only conclude that the only reason to choose eudev over systemd-utils[udev] is because the latter package has "systemd" in the name (the horror!). If that is truly the case it would be a lot simpler to rename sys-apps/systemd-utils to sys-apps/utilities-from-the-init-system-that-must-not-be-named, then to continue to maintain eudev. 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? If someone were to step up and say they are willing to spend their time and effort maintaining eudev and fixing the open issues then sure we can keep it, I never said otherwise. However this package has been maintainer-needed for quite a long time now and no one has stepped up, at some point someone has to pull the plug. My point (which again you misrepresented) is that if you can't provided a solid reason for choosing eudev over systemd-utils[udev] you are going to have a very hard time convincing others to put in their time and effort maintaining it, no matter how loudly you complain on the mailing list. So either maintain it yourself in some overlay, or provide some solid and convincing argumentation in favor of eudev. And as I already pointed out above "choice for the sake of choice" is not a convincing argument. And then another thing, how is it possible that so many people missed the news item? They are displayed quite prominently I think, and emerge will keep buggering you about it until it is marked as read. Just wondering if there is something that can be improved here. Best regards, Andrew
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
13.09.2023 03:52, Eli Schwartz пишет:
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?
This is a race with the user - the user could delete some files from
disk just in time for metadata to successfully be written
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
13.09.2023 07:22, Sam James пишет:
Fabian Groffen writes:
[[PGP Signed Part:Undecided]]
On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
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" Sokolov
From 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
+
I might misunderstand this, but is this USE-flag supposed to be set only
during bootstrap, e.g. when host-provided Clang is used? If so, would
it be possible to use has_version or something instead?
Another option is something I think we've done in the past - check
for use prefix and then some extra env var we set in the bootstrap
script.
Somehow I haven't thought about using extra env var, will try that, thanks.
We'll still need the USE-flag for sys-devel/clang-common because it will
install different content with and without it, but that can be limited
to a single package.
I think I'd prefer either your idea or the one I just mention
to a USE, but I don't think I feel very strongly between any of it.
(but given mgorny isn't keen on the USE in the PR at
https://github.com/gentoo/gentoo/pull/32730,
that's a vote against it)
Thanks,
Fabian
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan wrote: > 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. > > And if they are no longer maintained, then what? Post a lot of replies on a mailing list? The point is, right now no one is wanting to maintain eudev. There are a lot of packages that get removed for the exact same reason. Some are no longer useful to anyone, some just don't have anyone to maintain regardless of whether anyone uses them or not. Once they are no longer maintained and things start to break, they get removed. Only if someone steps up to maintain a package, does that package get to live. It's been that way for many years. The packages you gave as examples, will likely have their day as well, one day. I don't think any of your posts has changed that fact. In all honestly, if anyone was interested in stepping up and at least trying to maintain eudev, they most likely aren't now. After all, if they stop maintaining eudev later for whatever reason, they have you to look forward too. I'm sure several devs have your messages sent straight to the trash. One posted as much. You are not accomplishing anything, likely even hurting yourself. I think I'm done here too. Dale :-) :-)
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
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/. 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.
Re: [gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
Fabian Groffen writes:
> [[PGP Signed Part:Undecided]]
> On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
>> 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" Sokolov
>
>> From 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
>> +
>
> I might misunderstand this, but is this USE-flag supposed to be set only
> during bootstrap, e.g. when host-provided Clang is used? If so, would
> it be possible to use has_version or something instead?
Another option is something I think we've done in the past - check
for use prefix and then some extra env var we set in the bootstrap
script.
I think I'd prefer either your idea or the one I just mention
to a USE, but I don't think I feel very strongly between any of it.
(but given mgorny isn't keen on the USE in the PR at
https://github.com/gentoo/gentoo/pull/32730,
that's a vote against it)
>
> Thanks,
> Fabian
>
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] New bootstrap-prefix global USE-flag and patch to llvm.eclass
On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
> 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" Sokolov
> From 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
> +
I might misunderstand this, but is this USE-flag supposed to be set only
during bootstrap, e.g. when host-provided Clang is used? If so, would
it be possible to use has_version or something instead?
Thanks,
Fabian
> 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
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
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 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. > Since you specifically listed this as your last point of my "conspiracy theories", I
