[gentoo-dev] Re: Re: Update on the 23.0 profiles
* "Andreas K. Huettel" <2862978.mvXUDI8C0e @pinacolada> : Wrote on Sun, 07 Apr 2024 15:27:42 +0200: >> I see no way of migrating to 23.0 profile because of not-recompilable >> packages that are installed (over 4 years) which block --emptytree, >> and do not wish to be forced to migrate to merged-usr on an openrc box >> without a compelling need (on principle). > That sounds a bit like self-inflicted pain. >> Will patching back the 17.0 profile files into the portage tree if and >> when they are removed work? > Unknown. > >> Are there any options at all for this situation (like freezing the the >> last supported tree protecting it from emerge-syncs, and using an >> overlay for further updates?) > > You can try to just skip these packages (with --exclude) during the > "emerge --emptytree ..." step. It should work, but no guarantees given. I switched the make.conf symlink (from portage/profiles/default/linux/amd64/17.1 to portage/profiles/default/linux/amd64/23.0/split-usr ) and the only difference in the emerge --info output is that LDFLAGS now additionally has "-Wl,-z,pack-relative-relocs" My use pattern is I'm only emerging packages by hand and setting useflags on a case by case basis. Also I have binpkgs going back to 5 years that I don't want to lose (by going to merged-usr, right now I can unpack and test these in a pinch). I also have various other packages outside the gentoo tree which depend on stuff which is not in gentoo portage anymore, which are really not rebuildable, but because of past portage flexibility multiple installed work fine and can be tested at the same time. The question is: Now if I don't attempt to do a rebuild and just update libtool and do further upgrades and installs on a case by case basis, it will will eventually pick up the new profile defaults. Is there any foreseeable downside to just doing this?
[gentoo-dev] Re: Update on the 23.0 profiles
> Thanks for the update and the work on the 23.0 profiles. :) >> Most 17.x profiles have been downgraded to "exp". > I could imagine there is a reason to downgrade those back to 'exp', > could you elaborate a bit on that? > > Isn't it bit strange that a 'stable' profiles gets downgraded back to > 'exp'? Then again, I am not sure about the implications of this nor > about the rationale behind it. > > However, I also notice that there is a outstanding PR that reverts > that [1]. Maybe we should introduce a new state 'oldstable' or so? I see no way of migrating to 23.0 profile because of not-recompilable packages that are installed (over 4 years) which block --emptytree, and do not wish to be forced to migrate to merged-usr on an openrc box without a compelling need (on principle). Will patching back the 17.0 profile files into the portage tree if and when they are removed work? Are there any options at all for this situation (like freezing the the last supported tree protecting it from emerge-syncs, and using an overlay for further updates?)
[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.
[gentoo-dev] Re: [PATCH] 2022-07-28-pipewire-sound-server: add item
>> On Tue, 26 Jul 2022, Sam James wrote: > >> +2. To use PulseAudio's daemon for sound, users should disable >> USE=sound-server for PipeWire, + enable USE=daemon on >> media-sound/pulseaudio, and add media-sound/pulseaudio-daemon to >> their world file: > > "The text body should be wrapped at 72 characters." > https://www.gentoo.org/glep/glep-0042.html#news-item-body This is unecessarily restrictive to force the user to choose between pipewire and pulseaudio for the sound server. It is possible (I am running it now), and should be possible for gentoo to have both installed simultaneously and run one or the other at any given time, through configuration files. [I think the only patch that is required is for alsa-plugins/pulse/conf_pulse.c: (conf_pulse_hook_load_if_running) which can be taught to check if the pipewire daemon is running and quit that particular module. but it is not pipewire aware yet]
[gentoo-dev] Re: About EGO_SUM
* "Robin H. Johnson" : Wrote on Wed, 8 Jun 2022 20:42:48 +: > EGO_SUM vs dependency tarballs: > - bloats ebuilds > - bloats Manifests > - bloats metadata/md5-cache/ (SRC_URI etc) > - doesn't bloat mirrors with gentoo-unique distfiles > - EGO_SUM is verifiable/reproducible from Upstream Go systems > - less downloads on upgrades (only changed Go deps, not entire dep tarballs) > > EGO_SUM data right now adds, to every user's system: > - 2.6MB of text to ebuilds (340k after de-dupe) > - 7MB of text to Manifests (2M after de-dupe) > - 6.4MB+ of text to metadata/md5-cache (I don't have a easy way to > calc deduped amount here) > On the server side: > - The sum total of Go distfiles mirrored on Gentoo mirrors right now > is only 3.4GB. > - less downloads > > Dependency tarballs: > - Right now ~15GiB on each mirror, plus storage of the primary copy > somewhere (dev.g.o right now, but not great) > - Conservatively if the remaining EGO_SUM packages converted to Dep > tarballs, it would need another 8GB each of primary location and > mirrors. > - larger downloads for users who DO want to upgrade a Go package (all > new deps tarball even if only one or two deps changed) > - must be preserved much longer, unless we can introduce a guaranteed > way to regenerate them for any prior ebuild. > > I was trying to introduce a third option, but I haven't had the time to > write an entire GLEP. > > The TL;DR is introducing a 2nd-level Manifest+metadata file, that tries > to move just the metadata out of the tree, in a way that can be > regenerated (specifically, a 1:1 reproducible creation from a given go.sum). > It DOES need to contain slightly more data than the present Manifest, > specifically a full SRC_URI entry for each file (upstream URI plus what > to rename it to on Gentoo side) > > The 2nd-level Manifest would be listed as SRC_URI, and be handled in > src_fetch/src_unpack. Download & verify the extra distfiles, against the > Manifest checksum data (and for Golang against go.sum checksums). > > The Portage mirrordist code needs the most work in this case, as it > would need to fetch the 2nd-level Manifests so it can populate Gentoo > mastermirror with the distfiles mirrored from upstream. > > The storage costs for the proposed idea: > - same 1:1 base distfile storage as EGO_SUM (e.g. upstream distfiles are > mirrored 1:1 content, just different naming) > - Probably 1 Metadata-Manifest file per ebuild $PVR (conceptually it > could be split more or shared between some ebuilds/packages) > - Main tree Manifests: 1 DIST entry per Metadata-Manifest in a given package > - Main tree ebuilds: 1 line for the Metadata-Manifest in the ebuild. > - metadata/md5-cache: 1 src_uri line! > - mirrors: add the Metadata-Manifest [Without claiming to have fully understood the proposal above: around Apr 15th 22 I tried suggesting to WilliamH on IRC that perhaps portage should implement the dirhash approach that go has taken to solve the problem of upstream sources when they invented go.sum. from hash.go in sources go/src/cmd/vendor/golang.org/x/mod/sumdb/dirhash/hash.go // Hash1 is "h1:" followed by the base64-encoded SHA-256 hash of a summary prepared as if by the Unix command:find . -type f | sort | sha256sum loosely speaking the "manifest" could publish this dirhash of contents of go-mod/cache (which would have been bundled in the -deps.tar.xz) The immediate motivation was to avoid the network when I already had the sources locally: instead of downloading a -deps.tar.xz I could create it locally and dump it in distdir. portage would check the (hypothetically) published dirhash and let it through. the local timestamps and uid in my tarball and the upstream tarball wouldn't upset it. One unchecked assumption is that go-mod/cache can be recreated by unpacking sources. If so then with a notion of a "second level manifest" (the equivalent of go.sum) the contents can be assembled without having to store or download the actual -deps tarball. I didn't get very far in convincing WilliamH of my need so I dropped the idea. (I'm not sure if I'm being any clearer, if I'm missing something, do let me know)
