Gentoo 2024

[Grogan]

As of the other day, my LFS system is no longer binary compatible with my Arch. I pretty much stopped working on it when I ported it to the new rig, except for kernels and firefox and a few other things I build in common. Now I'd have to work on it, at least glibc and the gnu toolchain. At this time my firefox builds wouldn't even run. I could do that (and still may if I don't think of something that's going to make me happy). It's mostly for a glorified rescue disk... work on one distro from the other but it's also good to have something non-silly to boot to when I have important things to do. Rescue usage is somewhat limited too now because the kernel and bootloader are on the fat32 UEFI. If booting is what I need to fix, I'm SOL, I'd have to boot from USB anyway. (On my old computer with MBR disks I had grub separated from both LFS and Arch, on a small partition with an old Slackware install that doesn't get touched)

Anyway, I really liked Crux for a simple, hybrid source based distro. It was so simple (/etc/rc.conf like BSD only simpler) that it was like "No way!" when I realized it (it was so simple I couldn't find its service configuration as there was only one thing in there at the time and I glossed over it having been in that file). However, I looked them up and they've been silent since 2022. This will not do.

Slackware is unmanageable bloat now for my usage case and it no longer suits my methods. No, I don't want to blast on all of the L package series then try to extract teeth later. He caved on a lot of stupid shit like PAM, switched to the forked systemd versions of things like logind, udevd because Plasma components required them. It had to happen, but it doesn't much suit the old school nature of Slackware anymore. It's still a great system if that's what you're going to do, though (install all packages and update them with slackpkg etc.) but I am sorry to feel that it isn't "good old Slackware" anymore.

I'd rather not have something "Arch based" for my secondary system. No systemd bollocks either.

None of that redshart or ubuntubian shit (I don't like rpm or deb distros, they make package building very awkward on purpose). I don't like what their ilk is doing with software either, the biggest funded are the ones always pushing to reduce the amount of work they have to do and reduce the users' freedom of choice that makes this whole ecosystem so wonderful. Containers are a kludge (for running software), not miraculous like some people seem to think.

So I think I'm going to look at Gentoo again, with OpenRC+sysvinit (default) for a bollock free init system. They have binary packages now, even x86_64-v3 repos, but I'm likely to just install a base system and compile everything. It's going to be 64 bit only (not for games). I am reading the Handbook now to see if I want to do this or not. It has pissed me off in the past (drove me to LFS... if I want things my way I'm going to have to do them my way) but it's time to give it a look again.

[Grogan]

I think this method suits me best. This is how I'm going to get exactly what I want (I'll just drop in my own kernel and use Arch's grub) and get a system with minimal dependencies. I'll have to be careful with use flags to not to let shit creep in though.

https://wiki.gentoo.org/wiki/Installati ... stribution

Installing Gentoo from an existing Linux distribution
Important
The only fully supported method for installing Gentoo is with the Minimal Install CD. That said, installing from another, recent, live environment will usually work just as well. Gentoo support will often still be forthcoming using this method, but be ready to revert to the Minimal Install CD, if needed. Of course, in case of issues with other distributions, users will be referred to other channels for help.
Requirements

In order to install Gentoo from an existing Linux distribution it needs to have the chroot command installed, and have a copy of the Gentoo installation or ISO that's desired to install. A network connection is needed to download files during the installation.
Overview

First allocate a partition to Gentoo by resizing an existing Linux partition.
Mount the partition.
Choose an appropriate stage tarball and unpack it to the partition that is mounted.
Configure compile options for Portage.
Mount the necessary filesystems and chroot inside the pseudo-system.
After entering the new environment, follow Gentoo Handbook from Mounting the boot partition to the end.

[Zema Bus]

Sounds simple enough

That was surprising to hear about Crux though, I wasn't aware they had discontinued it.

[Grogan]

I got a base system set up and booting using that manual procedure with chroot. I already have my kernel image on the UEFI, so I just copied over my modules tree (already depmod'ed). The grub entry was the same (as the LFS kernel), all I had to do was change the name it would display. I just manually created my fstab.

The only thing I forgot was to create the root account, so I had a system that booted but no way to log on. (back to Arch to bind mount and chroot again and run "passwd root" lol)

So now the rest will be a labour of love.

[Grogan]

Network setup couldn't be easier, with OpenRC and "netifrc". Get this... the example config in the Gentoo Handbook just happens to be EXACTLY my machine's IP address and network. Paste...

/etc/conf.d/net

Code: Select all

config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"

(Network was actually working with dhcp out of the box, I didn't configure anything... but I don't do dhcp for permanent, hard wired machines)

I also made my own udev rule for eth0 with the MAC address to make sure it's always going to be eth0 and not the enp5s0 shit or anything.

[Zema Bus]

That's pretty slick

[Grogan]

Moving portage has changed (I don't compile on my fucking root filesystem). In the old days I used to just symlink /usr/portage elsewhere, but they are too clever to stick with that bsd-like convention, it's all /var/db and shit now. Why can't anybody ever just keep things simple. Now you have to move a bunch of environment variables and a profile symlink in /etc/portage (Luckily I happened to notice the symlink before moving the data)

Old:

Code: Select all

repo_basedir="/var/db/repos"
repo_name="gentoo"
distdir="/var/cache/distfiles"
portdir="/var/db/repos/gentoo"
target_distdir="/var/cache/distfiles"
target_pkgdir="/var/cache/binpkgs"

/etc/portage/make.profile -> ../../var/db/repos/gentoo/profiles/default/linux/amd64/23.0/no-multilib

New:

Code: Select all

repo_basedir="/storage2/portage/db/repos"
repo_name="gentoo"
distdir="/storage2/portage/cache/distfiles"
portdir="/storage2/portage/db/repos/gentoo"
target_distdir="/storage2/portage/cache/distfiles"
target_pkgdir="/storage2/portage/cache/binpkgs"

/etc/portage/make.profile -> /storage2/portage/db/repos/gentoo/profiles/default/linux/amd64/23.0/no-multilib

The variables go in /etc/portage/make.conf

I'm still finding silly shit that's not right after doing this:

In /usr/share/portage/config/repos.conf

So copied to /etc/portage and relevant line edited to:

Code: Select all

[gentoo]
location = /storage2/portage/db/repos/gentoo

(was /var/db/repos/gentoo)

[Grogan]

Updates. What I've got now is a binary base system, but I'm only going to use ports from now on. It seems that if I keep doing this, eventually everything in the base system will get recompiled when the distro updates it. This will be my update command.

Code: Select all

emerge --ask --verbose --update --deep --newuse @world

It seems though, I'm still in the same boat and actually worse off than I was before with my LFS system. I say I'm worse off, because on my LFS system I know how to fix it (without breaking package management that I don't have).

Gentoo is still gcc 13 and glibc 2.39, the very things that I need to upgrade for binary compatibility... I'm going to have to go off-distro to fix those things. On gentoo I'll have to figure out how to make/edit my own ebuilds if I don't want to break it.

[Grogan]

I'm not sure I did this exactly as I was "supposed to", but I figured something out. I grabbed "gentoo.git" (the entire ebuild repo) and changed my repo to it in repos.conf. Then, despite warnings that "emerge by path is broken and doesn't always work" I was able to explicitly emerge kernel-headers 6.9, glibc-2.40, gcc 14.1.1 from .ebuilds in the directories. That didn't replace my gcc, but installed it along side and I had to switch gcc with an eselect command. I then did another world update command and then "emerge --depclean" removed gcc 13.

However, the system is not happy with this. When I do a world update command, it tries to downgrade these things, so I masked them. I guess since they aren't part of my "profile", that's what I have to do. I masked them such that they can be upgraded but not downgraded, with less than or equal syntax in /etc/portage/package.mask. I think it's because they are system packages or something, it seemed to upgrade other stuff from that repo.

<=sys-libs/glibc-2.40
<=sys-kernel/kernel-headers-6.9
<=sys-devel/gcc-14.1.1_p20240723

I think I'm good to go with my toolchains now, I can start building the rest of the system (Xorg and everything). I had company today, so I haven't gotten much done.

[Grogan]

This distro is fucking silly. In order to build certain packages, USE flags sometimes have to be changed. There's an auto mechanism for writing them to an /etc/portage/package.use/zz-autounmask file (this is "unmasking" USE flags, not packages), but it absolutely refuses to do this if there are masked packages. So with my kernel-headers, glibc, gcc etc. upgraded I can't build packages without it failing on that annoyance. I have to manually add the USE flags (either to that zz-autounmask file that's there, or some other, or globally in make.conf) and then it proceeds. How silly.

The syntax for all this shit is all clever bullshit too, it's not something you'd intuitively guess on your own.

I've finally got xorg all built and XFCE is compiling now, but we'll see about this system. I'm not sure I'm actually going to use it if it's going to fight me every step of the way like it always has. I might be better off to go back to my LFS system and upgrade GNU (It's a lot easier to do that stuff by hand than to fuck with this emerge shit to be honest)

[Grogan]

Finally sitting at my own machine (was working on it with ssh)... though I still have some kinks to work out with XFCE. I seem to not have jpg support (only PNG) or xcursor support (needs a recompile?) and I can't find my pulseaudio volume control plugin (though I compiled and installed it, it doesn't show up to add to the panel)

P.S. Got the pulseaudio sorted, but looks like I have to recompile xfce4 yet again, it seems I may need use flags.

[Grogan]

Fuck... the xcursor thing sorted itself after I installed Xcursor and recompiled XFCE (I just had to redo the cursor setting in XFCE that got disabled because I didn't have Xcursor), but for the jpeg support it wasn't enough to set the USE flag and recompile XFCE, I had to rebuild world with the jpeg USE flag. Not everything, the @world command just built all the things that needed to be rebuilt with the jpeg flag.

Now I have a fully functional XFCE.

For pulseaudio, since I don't have systemd sockets, I dropped a .desktop file in /etc/xdg/autostart that does pulseaudio --start for my user session.

[Grogan]

This distro really isn't very flexible (their way or the highway) and doesn't allow you much room to customize. Having to use these USE flags is more of a hindrance than a help.

I have some youtube videos that won't play because of missing codecs. (It's my firefox, not crippled by gentoo or anything). I probably have to pass "proprietary-codecs" to a bunch of shit and do an @world command of some sort. How much do you want to bet that it's going to refuse to do it because I don't have the right string in my license acceptance variable (another example of the kind of niggling bullshit that wastes your time in gentoo)

P.S. Actually I forgot about ffmpeg... that's probably why Firefox won't play those codecs. Firefox dlopens that (it compiles with provisions to use several versions). That's what I'll need to build with non-free codecs.

YES, it was ffmpeg. I can play the videos I couldn't this morning.

I get the proprietary codec thing (but NOT in a source based distro of all things), but that libjpeg shit is bollocks. Why would I ever NOT want jpeg support such that it has to be explicitly turned on. Moreover, it's the wrong libjpeg for nowadays, it's jpeg-turbo which is .so.6. The only real benefit to that is breaking binaries that expect .so.8. I had to build one and drop it in /usr/local, by itself so nothing will link to it, to avoid having to immediately re-compile every knick-knack in /usr/local (which I'll get to eventually... for now I copied some essential stuff). It is the wrong ABI too, so you can't symlink or drop in wrong libraries. That was the point of binary compatibility, so I can run (some, if compiled my way... and stuff in /usr/local is) binaries compiled on Arch.

Their documentation never seems to tell you exactly what you want to do, because they don't want you doing it. Admonishments and warnings in red text for everything you try to override.

For example, this ACCEPT_LICENSE variable they tell you this and that, the default is only @FREE and you can add @BINARY-REDISTRIBUTABLE for firmware, or you can revert to the old behaviour of accepting licenses and prompting for EULAs. However, from their syntax of "-*" preceding the licenses in the string, I deduced that ACCEPT_LICENSE="*" will STFU and not bother me at all. They couldn't just come out and say that, no.

[Grogan]

Some of their own shit doesn't seem to work as advertised. The two distdir variables in make.conf are not working, it insists on using /var.

distdir="/storage2/portage/cache/distfiles"

Also, it insists on building in /var/tmp

So I symlinked /var/cache/distfiles there and also symlinked /var/tmp off to another drive (I don't compile on my root filesystem!)

Now, for doing that, I get a nice red error on my root console when I boot up because it can't create /var/tmp (/tmp and /var/tmp are real directories, not tmpfs mounts like a systemd system, but they are nuked at startup. "volatile directories"). It says that /var/tmp exists and is not a directory, in red. That's not really an error, it might as well say "good for you". I don't like errors on my root console, it hurts my pride. I hack on systemd's core library to get it to stop complaining about things on my root console, that I don't want it to have, or do. So now I'm going down the rabbit hole of editing init scripts that I'm not supposed to (they'll get overwritten). I don't actually need anything pre-populated in /var/tmp, it's just a directory where anything that wants to write there, will.

P.S. Worse than that, it's a binary. systemd-tempfiles (with --create parameter). Jesus SHITTING Christ! Oh well, I guess I'll have to find the ebuild that belongs to and patch the source (it'll be a project for a bit later). Fucking systemd, it's everywhere, even on non-systemd systems because of the forked components. Note that Gentoo did most of that work so we could have systems without systemd and still run software that depends on it. I'm not even actually using that, while my PAM has been rebuilt with elogind support, I don't think I'm actually using that shit for X. (I ignored some note about a use flag and said "heheh good", I'll chmod 4755 like I've always done on non-systemd systems)

Anything you want to do is no, no, no, you have to use "eselect" or something to change that, or it will get overwritten. We'll see if it lets me keep my "vi" symlink (I hate vim!! I use elvis in /usr/local/bin... you know, good old Slackware's old default. Changed now because it doesn't support all unicode language chars, but that's not something I need to care about). I've been using elvis on my systems for 24 years, on all linux setups. It's as dear as X File Explorer/Fox toolkit apps and Sylpheed etc. to me. From my stiff, dead fingers.

P.S. I don't mind nano, I had to use that until I got toolchains etc. sorted (Gentoo doesn't come with vi in the base system). Still though, I'm so used to vi that I start doing vi things in nano and it fucks me up (It certainly is an easier editor, but "easier" is what you're used to)

[Zema Bus]

A while back I was curious what became of Sabayon, the Gentoo based distro we played with years ago. I had heard that they had rebased on Funtoo because they didn't like the direction Gentoo was going..I also read that that's the reason Funtoo was created. Sabayon is no more, they discontinued development about 5 years ago, but came back in 2020 as MocaccinoOS based on Funtoo. From what I read they have a very small user base, nothing like what Sabayon had.

[Grogan]

"Funtoo is led by Daniel Robbins"

The original creator of gentoo, it was really cool back then. I heard of Funtoo, but didn't realize he was involved. (Last I heard of him was when he left Gentoo and went to work at Microsoft)

I'm looking into Funtoo right fucking now. I might just stop right now and use that instead if I like what I read.

P.S. Nope

Posted Friday at 05:39 PM

All good things must come to an end. I've decided to end the Funtoo Linux project. Funtoo started as a philosophy to create a fun community of contributors building something great together. For me, it's no longer that so I need to move on to other things. There is not a successor BDFL for Funtoo nor am I interested in trying to find one, or hand the project off to someone else. You can expect the project to wind down through August. If you have a Funtoo container, it will continue to be online through the end of August so you have time to find another hosting solution if you need one.

LOL, just my luck. Friday.

[Zema Bus]

Wow, what timing lol! Oh well. In case Gentoo doesn't workout here's a couple Crux alternatives I read about - KISS and Venom (sounds like a rock group).

Kiss Linux is a meta-distribution for the x86_64 architecture with a focus on
simplicity, sustainability and user freedom. The project was created by
Dylan Araps who also acts as its sole developer and BDFL [0].
The distribution is designed to be maintainable by a single person and to this
end has no infrastructure, backend or monetary running costs. Further, all
installations of KISS contain everything needed to continue its development.
The user is provided with three things.
1. The Official Repositories - An extensible base including a fully X11-less
Wayland environment, modern web browser, media player and everything needed
for this system to rebuild (and update) itself (in under 120 packages).
2. The Package Management System - A pleasant to work with and concise
package format powered by a small, portable and self-contained package
manager (written in POSIX shell).
3. The Freedom To Go It Alone - Users can choose to maintain their system
themselves thus freeing them from all external influence. The system then
belongs to the user and they become totally self-reliant.

Venom:

Minimal as possible

Highly customizable

No systemd (elogind or any part from it)

Centered Around smaller software

That means the lack of huge software like Gnome

Community Driven

The Community is part of the process of building Venom

Support sysvinit and runit

Its user's choice which init to use

One thing about KISS is that it uses musl instead of glibc, but there's a fork called GKISS that uses glibc.

[Grogan]

Well, I think I've pretty much beaten this into submission now. I'll have to see how sustainable it's going to be now with updates from source, with what I've done to the system. With this, my life is always going to be overrides and workarounds.

I've got all the essentials for now, and recompiled everything in /usr/local linked against that libjpeg.so.8 (I think... I'm going to leave it there until I'm sure). I've got good builds of mpv and my smplayer, with a non-kde qt5 built and qt5ct for configuration outside of KDE (and the configuration copied from arch grogan). Audacious was broken because of glib 2, of all things. It was compiled against a newer libglib-2.0 on Arch and needed a recompile. Of all the dumb things, that's got to be the first time I've seen ABI breakage with that library (same sonames, missing symbol). Gentoo isn't actually all that current. Even though the 23.0 release is recent, the shit is a bit behind. I've had to go to my gentoo git directory with more current ebuilds of a few things (doing that causes problems though... makes things a little less automated with masked packages)

I picked up a new X File Explorer out of the deal. I was going to build the same sources to be sure my patch adding .tar.zst(d) support would still be appropriate. Well, it turns out he's been busy and added that a few versions ago so I don't need to worry about that anymore

I'm mostly done here, I don't expect to be installing too much more in the distro, I don't need much here (that's the point). Maybe a few networking utilities I've probably forgotten. I'm about 5.8 Gb on disk now (no build dirs or significant storage on the rootfs!) including browser cache etc. junk in the home dir.

Nice sane df output too, without all those stupid fucking systemd tmpfs mounts, just the necessary ones. Ridiculous now, that and it has made that output more confusing and annoying to look at.

Code: Select all

grogan@nicetry ~ $ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       98G  5.8G   88G   7% /
devtmpfs       devtmpfs   10M     0   10M   0% /dev
tmpfs          tmpfs      13G  1.3M   13G   1% /run
efivarfs       efivarfs  256K  124K  128K  50% /sys/firmware/efi/efivars
shm            tmpfs      32G     0   32G   0% /dev/shm
/dev/nvme1n1p5 ext4      295G   95G  185G  34% /storage
/dev/nvme1n1p6 ext4      1.3T  540G  632G  47% /storage2
/dev/nvme0n1p1 ext4      1.8T  1.7T  110G  95% /storage3

[Zema Bus]

I may have to give Gentoo a try

[Grogan]

You can do a musl system with Gentoo. An all LLVM system too (I debated trying that, but what for... I know it's not going to end well) with Musl or not. I certainly wouldn't like a musl system, too much software would need to be patched for that etc.

I don't like the sound of that KISS very much (they lost me at things like X11-less... don't use the word freedom in the same sentences), but that Venom sounds pretty good.

Indeed, quite a horrible rock group from the 80's (it's so bad it's good lol)

I still have this record in the closet with the rest that my niece didn't take. This was the best song on it

Venom - Women Leather and Hell
https://www.youtube.com/watch?v=5emBB7psh-A

(decided to deactivate the URL... not sure someone would appreciate loading up a youtube player frivolously if a search led them to some Linux info or something. If it was relevant that would be different)

[Grogan]

I'm happy with the end result, but I tried to keep it minimal. If you want to try Gentoo, you'd probably want to do it by the book if you want steam and stuff to work. Also, you need to decide on multi-arch ahead of time, because it's difficult to change gentoo to it later (a lot of chicken-before-egg and layout considerations). You would also want to use an X enabled stage 3. I didn't, because I deliberately wanted a base system without all those USE flags turned on so I could enable dependencies and hooks only as necessary. It will cause things to need recompiling with USE flags enabled, but that's what I'm doing anyway... I want everything locally compiled.

Even a binary Gentoo install would probably be more performant than Arch, they don't use silly compiler flags, they are pretty plain jane. The default compile flags for Gentoo are... "-O2 -pipe", even a generic build (-march=x86-64 is the default for... x86-64) is much better than hardening flags, stack canaries and now frame pointers. (Of course binary packages would have more dependencies than how I did things though)

P.S. Forgot about this! If you configure a binary repo, Gentoo has x86-64-v3 binaries. I don't have a binary repo so I don't have that configured, but that'd be what you'd want.

[Zema Bus]

Thanks Grogan. I was thinking of putting it on my main machine, but putting on my gaming machine is an idea, it could replace the Fedora install I haven't booted into in at least a year.

Just now listened to Venom lol!

[Grogan]

I think Gentoo would be a pretty capable system for gaming if configured that way. It provides a full 32 bit complement and all.

[Grogan]

LOL... now this is silly. I was sync'ing my repo and got a manifest checksum failure at the end of the operation, with exit status 1. I ran the operation again ("emaint --auto sync" which does the same operation as "emerge --sync") and it worked that time. I then wanted to see how common that was... quite. I found out that the sync operations aren't atomic, no locking, it's just rsync. So if you sync and the tree gets updated while you're doing it, checksums are going to fail at the end

We use smarter tools than that nowadays (e.g. git). That's how I'm maintaining my other repo (gentoo git master), going in and using "git pull origin" to update the tree. I'm not actually using that as a "repo" though, I'm just switching to it so it allows me to explicitly build ebuilds from it and then switching back again. I don't build/update @world from that repo. That would probably garner admonishments, but all I expect from the distro is not to get in my way. It shouldn't with the way I'm doing things. I'm properly masking the packages, though the portage system doesn't like when you do that.

P.S. Oh! That's just the default method. You can actually use git to sync the repos now.

https://wiki.gentoo.org/wiki/Portage_with_Git

Code: Select all

eselect repository disable gentoo
eselect repository enable gentoo
portageq repos_config / 

(That last one is a verification step... examine output to make sure it's correct)

Code: Select all

rm -r /var/db/repos/gentoo
emaint sync -r gentoo

Of course I'll be using my path to the repo (I moved mine). I'm likely to have to merge things for my repos.conf file (that I copied to /etc/portage and edited)

The distro is set up to use rsync, but if you disable it and enable it like this, it uses git by default. Gentoo is weird

I'm going to set that up. Git makes much more sense for syncing repos. It's using github by default too, so I can remorselessly sync as many times as I want.

P.S. One thing not mentioned, is that you need to have the eselect module "repository"

Code: Select all

emerge app-eselect/eselect-repository

One unfriendly thing in gentoo is that you have to know what app category (directory) something is in and it's not always intuitive. Often I have to do a recursive find in the portage tree to know what ebuild I need. For example, it took me a bit to figure out that eselect-repository module. I figured it should be in app-admin like eselect is, but noooo... the eselect modules are in app-eselect. I thought maybe I didn't have it (need different eselect version or something) but no, it was that.

It seems fairly arbitrary and whimsical as to why something is in media-video or media-this or -that.

Some of them seem to have pointers, where "emerge pkgname" or "equery list pkgname" works, but most don't. That's silly, if there are multiple locations for a different package basename, present a list of possible providers for that or something like most "package managers" would. Don't make the user know which directory out of hundreds that this package is in. Jeeze.

[Grogan]

Ok, when it said to make sure the configuration was correct, they meant manually reconfigure it from defaults, not that they were going to use your existing variables (silly me for thinking it might be otherwise ). The regeneration also seemed to put an unwanted binary pkg repo in /var/db (this was on the eselect repository enable/disable step). I deleted it before proceeding to delete and pull the new repo. It did not repopulate (good). I don't mean it downloaded packages, just the category directories and files to install them (I think... I didn't actually look, I just nuked about 103 Mb of directories and files).

Anyway, the first operation was a clone:

This is the command I am to use now:

Code: Select all

emaint sync -r gentoo

However, subsequent syncing is instant if there isn't much (or anything) to do. It doesn't have to download and go through a bunch of stupid manifests and run through an operation in every directory like an rsync

Code: Select all

nicetry ~ # emaint sync -r gentoo
>>> Syncing repository 'gentoo' into '/storage2/portage/db/repos/gentoo'...
/usr/bin/git fetch origin --depth 1
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
/usr/bin/git reset --merge refs/remotes/origin/stable
=== Sync completed for gentoo

Action: sync for repo: gentoo, returned code = 0

That's all fine and dandy, but of course, this changed something else that has fucked me up. Now it won't let me proceed at all to update @world because it refuses to accept that I have binutils masked. I built the latest version in the tree, not the one it wanted to build for me (I boostrapped gnu... kernel headers, glibc-2.40, binutils-2.42-r2, gcc-14.1.1 with appropriate rebuilds before I started, so I can compile correctly and I don't want those touched until it's time). Now it's complaining like a simpleton.

Code: Select all

nicetry ~ # emerge --ask --verbose --update --deep --newuse @world

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 0.13 s (backtrack: 0/20).


!!! All ebuilds that could satisfy "sys-devel/binutils" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-devel/binutils-9999::gentoo (masked by: missing keyword)
- sys-devel/binutils-2.42-r2::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-devel/binutils-2.42-r1::gentoo (masked by: package.mask)
- sys-devel/binutils-2.41-r5::gentoo (masked by: package.mask)
- sys-devel/binutils-2.40-r9::gentoo (masked by: package.mask)
- sys-devel/binutils-2.39-r5::gentoo (masked by: package.mask)
/storage2/portage/db/repos/gentoo/profiles/package.mask:

(and a bunch of other stuff listing old versions that are no longer usable). I have r2 and I don't want it downgraded. If it was going to upgrade it, my mask would allow it ( <= ). As it is, what it says there is that it's masked in my profile. My (stable) amd64 profile has it masked.

Alright, I guess I have to start doing things the other way. I need to start using package.unmask to unmask >= versions to override that.

Gentoo

Well, I'm going to edit that to "Gentoo " because package.unmask doesn't... unmask packages that are masked by keywords.

Of course, they don't tell you "how" to do these taboo things (you'll have to go find it in some other wiki), they say "Most masked packages will not accept generic keywords, so specific keywords may need to be granted for the masked package."

OK, so to get through that, I have to have entries in the /etc/portage/package.unmask directory (individual files are parsed in there) for binutils, glibc, linux-headers and binutils. Like this:

Code: Select all

>=sys-devel/binutils-2.42-r2
>=sys-libs/glibc-2.40
>=sys-devel/gcc-14.1.1
>=sys-kernel/linux-headers-6.9

(If I don't specify >= here they will be invalid atoms because they don't actually exist in my profile. I first wanted to specify them only by version so they can't be upgraded but alas, no, I'll have to live with that)

Then, I had to create a directory, /etc/portage/package.accept_keywords and populate it with files containing these directives

Code: Select all

sys-devel/binutils ~amd64
sys-libs/glibc ~amd64
sys-devel/gcc ~amd64
sys-kernel/linux-headers ~amd64

Those don't take versions, what it's doing is allowing "unstable" (~amd64) to override stable (amd64). Rather, more correctly, allows "untested" packages for that architecture.

However, with this new portage setup, I now have some circular dependencies to resolve and it looks like it's going to do a massive @world rebuild. "553 packages"

Code: Select all

 * Error: circular dependencies:

(app-portage/elt-patches-20240512:0/0::gentoo, ebuild scheduled for merge) depends on
 (app-arch/xz-utils-5.6.2-r1:0/0::gentoo, ebuild scheduled for merge) (buildtime)
  (app-portage/elt-patches-20240512:0/0::gentoo, ebuild scheduled for merge) (buildtime)

I b0rked that by deleting /var/db/pkg. That wasn't a "binary package repo", but my package database. The system is fucked now, thanks to that mistake. I didn't think ANY of that shit was supposed to be in /var/db anymore and it looked like it was just created, because it probably was written through and touched.

Ahh well, I don't like this system. I was getting very, very tired of fighting with it (in fact that keyword horseshit was the last straw)

[Grogan]

To summarize this whole thread, fuck Gentoo. It's too silly for me. (sillier than ever... even the things I used to do aren't viable anymore)

I own the package database deletion, but that's just the incentive to blow it away and use something else (I don't have much choice... it doesn't even know what packages I want installed, it's trying to emerge everything and it can't actually run any emerge commands)

I'm just going back to Linux from Scratch. It's easier

For now all I have to actually do is upgrade glibc on it to be able to run the things I build in common on Arch, my gcc is actually 14.1.1 (libstdc++ won't be broken). That will take me about 5 minutes in total. If I keep the same linux headers (Linux 6.8.8 is what I used last time I think) I won't really need to rebuild toolchains right away (I'll probably do the rest tomorrow anyway). That system has all the old goodies I want, I was just looking for a new base for my minimal secondary system and looking for a shortcut. But it's not easier when it's a cast iron bitch of a build system. What good is automation when I have to fight with it.

... and just like that everything is back to normal. A couple minutes to format partition and unpack archived tarball of my LFS, 1m29s to compile glibc, and however many seconds it took me to boot to Arch to manually replace it. Guess what? Nothing admonished me in red

[Grogan]

I've decided that I'm going to give Gentoo another go, this time it will be faster and cleaner (since I already know exactly what I want to do). I'll simply re-archive that LFS with the upgraded glibc now in case I want to blast that back yet again

I did back up /etc/portage with all my changes before I blew it away, in case there was ever going to be a next time. So I'll have those files already prepared. I already have my repos on /storage2 too (I'm glad I didn't delete those yet) and if I get at this right away, that will save time too.

[Grogan]

Well, I'm sitting at the machine again now, with everything done. I'm back to what I had (I just have to recompile a few things in /usr/local again but nothing urgent) all built the same way.

It went a lot more quickly this time with all the portage stuff already figured out.

[Grogan]

Wow, did I ever get my fonts looking nice here, even better than Arch or my LFS. It kind of looked like shit, with Gentoo's defaults so I ran

Code: Select all

eselect fontconfig list

You have to use that to configure your symlinks in /etc/fonts otherwise gentoo will overwrite them.

I disabled 10-subpixel-none and enabled 10-subpixel-rgb and 10-hinting-slight and that's all I did. 11-lcdfilter-default was already enabled.

I'm going to have to see about duplicating this exactly on Arch (I thought it was)

I'll have to use PNG for this, hope it looks this good in the image on this display

gentoofonts.png (338.9 KiB) Viewed 103288 times

Note that the picture is showing 3 different mechanisms at the front end. The FOX gui toolkit (which uses XFT directly) in my file manager, QT in my SMPlayer, and GTK with Pangoft in Gimp all running under XFCE's font settings overrides. It all looks sharp.

[Grogan]

Gentoo is indeed a rolling release, but it's versioned at 23.0 and eventually there would be an "upgrade" to a new Gentoo system (unlike Arch). Right now there are two versions, v17 and v23 so I presume it's a long time between them (that'll be some sort of LTS or something though).

Daily flow of updates is a bit behind Arch, but I'm getting what I need.

I'm still trying to understand all the USE flags, and things like that VIDEO_CARDS variable. I tried to use that for Mesa on my first Gentoo install and ended up building a completely broken Mesa. One would think VIDEO_CARDS="amdgpu" (as the wiki also led me to believe) would be it for me, but no. So I'm just letting it build all the junk with Mesa for now. That's fine for the stable, 24.1.x, but come 24.2 there's going to be a lot more crap that I won't want to build (won't want the crap I'll need to do it). For example nouveau vulkan. I already had to install some intel_clc junk for Mesa 24.1.5 (I was wondering why that was masked!). Stuff like this is way harder on Gentoo, because you can only change what the use flags provide. Eventually I'm going to have to work on my own ebuilds (and the system will fight me every step of the way lol)

("emaint sync -r gentoo" to update ports first or there shouldn't be anything unless you have changed some global use flags or something)

Code: Select all

nicetry ~ # emerge --ask --verbose --update --deep --newuse @world

 * IMPORTANT: 20 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 4.36 s (backtrack: 0/20).

[ebuild     U  ] x11-libs/libdrm-2.4.122::gentoo [2.4.121::gentoo] USE="-test -tools -udev -valgrind" VIDEO_CARDS="amdgpu intel nouveau radeon (-exynos) (-freedreno) (-omap) (-tegra) (-vc4) (-vivante) -vmware" 470 KiB
[ebuild     U  ] dev-libs/libinput-1.26.1:0/10::gentoo [1.25.0:0/10::gentoo] USE="-doc -test" INPUT_DEVICES="-wacom" 805 KiB
[ebuild  N     ] sys-devel/lld-18.1.8:18/18.1::gentoo  USE="zstd -debug -test -verify-sig" 0 KiB
[ebuild  N     ] sys-devel/lld-toolchain-symlinks-18:18::gentoo  USE="native-symlinks -multilib-symlinks" 0 KiB

Total: 4 packages (2 upgrades, 2 new), Size of downloads: 1,274 KiB

!!! The following installed packages are masked:
- sys-devel/gcc-14.1.1_p20240729::gentoo (masked by: package.mask)
- sys-devel/binutils-2.42-r2::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.


Would you like to merge these packages? [Yes/No]

It still fights me trying to downgrade my toolchains, so I had to mask them after all. Even though I had package.unmask entries and allowed ~amd64 keyword override for them. Oh well, I'll have to work around that until Gentoo catches up (or until I figure out a better way to manage alternate builds). That seemed to work for glibc and linux-headers, but all the same I blocked those too. Those all have to be done in an orderly manner, together, on my systems.

By the book this would be easy enough, but to get what you want is harder. It's still a lot faster to get a system built from source, with automated builds a lot of work gets done, fast. I didn't even have to tell it to use -j24 for the builds, it just does. What you can't have is complete control on a system like this though. You have to do things their way or you're fucked. Even masking those packages causes problems.