Gentoo 2024

[Grogan]

So I no longer have to have symlinks in /var to get portage to behave where I want it to.

Firstly, there was a PORTAGE_TMPDIR variable I was unaware of. I grabbed settings from some wiki showing old and new locations of the files. If I'd have read the actual Portage wiki, I'd have known some things, including the location of the package database that's always going to be /var/db/pkg.

Secondly, some of those variables need to be upper case it seems. Some of them were working, while at least DISTDIR and TARGET_DISTDIR weren't as lower case. Where I grabbed them they were all lower case. So I changed all my make.conf variables to upper case. It's weird that any of them can be case insensitive (it would have to check for both).

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"
PORTAGE_TMPDIR="/storage2/portage/tmp"

Now none of that shit is happening in /var (except for /var/cache/edb which simply caches some info to save portage from gathering it and can be deleted any time... it's about 1.4 Mb. Stuff like that is the purpose of /var/cache)

[Grogan]

I'm getting closer to figuring out the differences in font rendering in Gentoo. On Arch, I removed a bunch of dejavu configuration symlinks that Gentoo didn't have enabled. I use that font family almost exclusively for TTF. I only install Dejavu and Liberation TTF fonts. Font matching rules sometimes need Liberation it seems. (the rest of my fonts are old X11 fonts for terminals and stuff). This did not change my fonts in XFCE, but I noticed a bit later that it did in X11 (e.g. IceWM). I always noticed a difference outside of XFCE, but now the fonts look better again in IceWM.

There is nothing in my fontconfig or freetype configuration now that should affect this. So it could be something different with XFCE. (Both have the same font settings). So I'm going to start looking at commits/patching, use flags... maybe it was built differently. It could also be GTK/Pango machinery itself, that's probably even more likely.

My fonts just look sharper and better. That PNG wasn't perfect, it blurred them a little (I'd have to use some unencoded bitmap format or something) but even so, in Arch, I opened my XFE file manager to the exact same place and compared them side-by-each and the PNG still looked better than the real thing in Arch.

P.S. Also note that my LFS system wasn't much better than Arch for font rendering on the new box (it actually was a bit better on the old box than Manjaro and Arch). My font rendering in Gentoo is better than that was on this rig too.

[Grogan]

Ahh, here we go. This is what I wanted to see happening. (It helps to see it in action to verify my understanding of how it should work)

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 4.55 s (backtrack: 0/20).

[ebuild     U ~] sys-devel/gcc-14.2.0:14::gentoo [14.1.1_p20240729:14::gentoo] USE="cet (cxx) (default-stack-clash-protection) (default-znow) fortran nls openmp (pie) sanitize ssp zstd -ada (-custom-cflags) -d -debug -doc (-fixed-point) -go -graphite -hardened (-ieee-long-double) -jit (-libssp) -lto -modula2 (-multilib) -objc -objc++ -objc-gc (-pch) -pgo -rust -systemtap -test -valgrind -vanilla -vtv" 90,144 KiB

Total: 1 package (1 upgrade), Size of downloads: 90,144 KiB

!!! The following installed packages are masked:
- 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] 

NOW it's time to upgrade gcc (my 14.1.1_p20240729 ebuild was actually the 14.2 branch, I saw what it was pulling. It's the stable upstream gcc now. Well, mainline I guess, they don't call them stable until .1 now).

I set the package mask as: " <=sys-devel/gcc-14.1.2 "

so that when the upstream version bumped in any way, portage would try to upgrade it, but not before. This is now happening because I have accepted the keyword "~amd64" and the latest "untested" for that arch is now this. Now it's time to upgrade gcc (but not glibc yet, and it's after that I'll want to recompile glibc-2.40 and binutils-2.42-r2 with this new gcc, not before).

Also, since my first gentoo install, these things are now in the main portage tree as alternatives if ~amd64 is enabled, I don't have to switch to the gentoo git master/main repo to build them, in fact I can ditch that tree now as nothing on the system will be built from it anymore. That eliminates one headache on my system.

Also, again, when installing gcc like this I get to see all the effective use flags getting added to the build. I see they build gcc with some options I don't like, but I'm not going to change that just yet (until I'm a bit more comfortable with the gentoo environment/ideology). Assuming it actually lives that long.

This is still an experiment to me, I still haven't formed a strong enough opinion on whether or not I can use this for the way I like to do things. I did back things up this time though, so only I will be the one to cut the experiment short.

[Zema Bus]

I have my partitions created, formatted and mounted, stage 3 downloaded and untarred. I'll continue with it tomorrow.

[Grogan]

Did you start it yet, and are you installing it from, and alongside an installed setup like I did? I always feel safer doing that than booting with an installer and wondering whether or not it's going to let me skip installing a boot loader and stuff. (Those live distro installers are bad for that, because they install from an image)

[Zema Bus]

Yeah, I'm doing it from Slackware. I was going to do from their live installer and SSH in like I've done when installing Arch, but thought this way would be just as good.

[Grogan]

Once you get the base system up and booting, and network working it's easy to start sshd. I'd edit /etc/ssh/sshd_config and uncomment and set "PermitRootLogin yes" (by default it's only allowed with key files)

I'd do as little as possible in the chroot, as there is the risk of environment leakage compiling things that way. For example on my first gentoo build I ended up compiling some things with the host system's environment because /etc/profile got sourced in the wrong order of operations. It shouldn't have, but did because I pasted the commands and I guess the next command executed too quickly. I knew it because I didn't have things in my path that were supposed to be. Sourcing /etc/profile again fixed that, but I still had the environment of the host system. When I realized it I just started over with the stage 3 tarball (only a few minutes of actual work at that point)

From my notes that I made for myself:

Code: Select all

# Don't just paste these as a block together, do them individually... I got the wrong env that way.

env -i HOME=$HOME TERM=$TERM chroot /mnt/gentoo /bin/bash

/usr/sbin/env-update

source /etc/profile

Note: I mean just that, it's usually OK to paste commands in a block. They'll be executed in sequence but in this case env-update is a sequence of commands itself. For example all the bind mount commands are fine to paste that way.

To enable and a service on Gentoo (I'm assuming you're using OpenRC with init, because you can). This enables it for the default runlevel, which is all you should need to worry about in this distro. Other runlevels aren't used for normal use like 3, 4 and 5 used to be etc. OpenRC will use the default runlevel unless given on the kernel commandline, but like everything in Gentoo, it's weird (but nice). It's a "softlevel=" parameter, and it's things like "softlevel=nonetwork" (which would then not start a bunch of services that would depend on that etc.)

Code: Select all

rc-update add sshd default
rc-service sshd start

(I think I rebooted at that point so I didn't bother to start it, it started on boot)

The runlevels are defined in /etc/runlevels and they have symlinks to the appropriate init scripts. The runlevels may build on each other, for example the "default" runlevel also runs "local".

Yeah fuck, it's a bit different than other init systems. I still have to get used to it

[Zema Bus]

Thanks Grogan.

[Grogan]

I made an edit about pasting commands in a block. It's ONLY the chroot setup I mean. (The whole point of working like this, or from another box is so you can do things like paste commands in a block lol)

I'm trying to think of ANY other scenario where I've been bitten by pasting commands like that and I can't. Just that this is the reason in this case.

Note: I mean just that, it's usually OK to paste commands in a block. They'll be executed in sequence but in this case env-update is a sequence of commands itself. For example all the bind mount commands are fine to paste that way.

P.S. It would still be the same shell invocation while the pasted commands are executing. That's probably the real reason it fucks up.

[Zema Bus]

I got the base system up and working, my network interfaces changed from eth0 and eth1 to enp9s0 and enp10s0 so I have to fix that, but no time to sort that out tonight. I think I remember now that you dealt with this so I'll go back and review what you posted. But at least I ended up with a working system on the first try

[Grogan]

What I do is make a udev rule in /etc/udev/rules.d to override the distro's rule. On Gentoo (and Arch) the filename you have to use is

/etc/udev/rules.d/80-net-setup-link.rules

Code: Select all

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d8:bb:c2:d1:4b:1c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*" NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d8:bb:c2:d1:4b:1d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*" NAME="eth1"

Obviously use the correct MAC addresses for eth0 and eth1

[Zema Bus]

Thanks!

[Grogan]

My pleasure as always. (and it's pretty much my reason to exist)

To understand why that happened, the DHCP in Gentoo uses that nomenclature by default. Set up eth0 and eth1 statically, add those udev rules and you'll be grooving.

https://wiki.gentoo.org/wiki/Handbook:A ... Networking

I find the Gentoo wikis go blahdee blahdaa blahdoo, but don't make it clear exactly what you want to do (and/or make what you want to do clear). So I'll summarize what I did.

Using OpenRC's Netifrc, I think, is the simplest, most old school method. I am assuming that you are using OpenRC and not systemd (It would depend on what stage3 tarball you chose). This is probably the same rc mechanism you're already using with OpenRC, only with DHCP.

Here's something pissing me off. I can't even find the exact wiki page I used to configure mine. Remember where I said the example was the exact settings for this box (192.168.0.2 etc.). Well I can't find that page again

This is actually more complete and probably more modern. It takes both syntax for subnet, either 255.255.255.0 or /24 syntax and I doubt you'd really need to specify broadcast (brd) for a simple network like a home class 3.
https://wiki.gentoo.org/wiki/Netifrc

I just have one NIC, but we can easily extend this shit to eth0 and eth1. However, that does mean that this dual config is untested by me. Logically, this is how it should work. I don't know what your eth1 network is (perhaps different IP network and route) but you will.

You're going to say things like this in /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"
config_eth1="192.168.0.3 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth1="default via 192.168.0.1"

That's what I used from an example, but more succinctly:

Code: Select all

config_eth0="192.168.0.2/24"
routes_eth0="default via 192.168.0.1"
config_eth1="192.168.0.3/24"
routes_eth1="default via 192.168.0.1"

I didn't specify DNS servers there, I just use a standard, old school, static /etc/resolv.conf (there's nothing to touch that on my setup) with NO bullshit but the nameservers in it.

Code: Select all

nameserver 208.67.222.222
nameserver 208.67.220.220

No comments, no search domains (I find those just cause internet lookup delays and why would I want to search my ISP's domain first?!?), just my OpenDNS servers. I could also just use my router's dnsmasq ("nameserver 192.168.0.1") but the router also gets the ISP's DNS servers from DHCP and while I have three configured in there (2 OpenDNS, 1 google) I don't ever want my lookups going through the ISP's nameservers (shouldn't, but a static resolv.conf on Linux means there will simply be no other nameservers to query). Why? Because they'll do things like redirect name lookup failures and shit. I don't trust ISPs' to return accurate, honest current enough results. ISPs are notorious for ignoring TTL, too.

Anyway, with that done, it should be like this. Yes, this looks funny, but net.lo is the actual network init script that brings the interfaces up and you symlink to it

Code: Select all

cd /etc/init.d
ln -s net.lo net.eth0
ln -s net.lo net.eth1
rc-update add net.eth0 default
rc-update add net.eth1 default

That's if you want a simple, permanent static network config. They'll direct you to more complex shit first.

P.S. That is indeed what you'd be using by default on a non-systemd stage3. From the Netifrc wiki:

Basic examples
DHCP

Although it's not necessary to explicitly configure it, here's an example to make use of DHCP on an interface.
FILE /etc/conf.d/net Example DHCP configuration

# Note: DHCP is the default behavior if /etc/conf.d/net is empty or missing
config_eth0="dhcp"

So when you create your static netifrc configuration, you ARE configuring it. If you WANT to use dhcp and you want eth* nomenclature (which you must, if you added those udev rules), you're going to have to configure config_eth0 and 1 = "dhcp" as shown in /etc/conf.d/net. If you want to stick with DHCP it's as simple as THAT (and the init.d symlinks) and the udev rules

That was the perfect tidbit (in bold) to help understand this.

[Grogan]

If you have read any of that last post since you said "Thanks", read the P.S. at the bottom. It occurred to me that you may just want DHCP with eth0 and eth1 interfaces instead of the bollocks nomenclature and that would make your life dead-nuts simple without having to wade through as much info. A post edit never bumps a thread.

[Grogan]

I just figured something out that's actually been pissing me off about gentoo over the course of 20 fucking years (any time I've taken another look at it)

Whenever I go into a portage directory and explicitly build filename.ebuild, it always screams at me in red "emerging by path is broken and may not always work!!!". Well, how else do I do it then? Trying "emerge binutils-2.42-r2" doesn't work. Ahh, it needs the category (directory). Nope, "emerge sys-devel/binutils-2.42-r2" says invalid package atom. Oh well, entering into the dir and emerging the filename always has worked (I think the warning is more if you're doing it from out of tree, but even that worked at least back then).

What I'm actually supposed to be doing is specify the category and version, but it also needs an operator. ANY portage version comparison atom needs an operator (package.mask, package.use) including "emerge" commands and in that case that's "="

Code: Select all

emerge =sys-devel/binutils-2.42-r2

(this does not, however, override masks like explicity emerging a .ebuild does... maybe that's the reason they have kept that ambiguous warning forever)



P.S. The "proper" way to do things on Gentoo can be quite irritating. That's all fine and dandy, I've got package.accept_keywords flags and everything to allow me to use packages in testing. I've had no problem explicitly emerging these, but now that I want to do things "properly" it's a pain in the ass to build something like gcc-14.2.1_p20240803 that's present in my category not even in "testing" and it's masked by some missing keyword and I don't think there is one, it means you have to override the ~arch keyword altogether)

So now my /etc/portage/package.accept_keywords/gcc is:

Code: Select all

sys-devel/gcc **

Which essentially means ignore all keywords (or "just fuck off" in my dictionary). I could limit that to version like this, but I have a package.mask entry that prevents anything lower than 14.2.1 at this time anyway (and when I'm done I'll bump those critical packages' mask entries so they can't be upgraded out from under foot)

Code: Select all

>=sys-devel/gcc-14.2.1 **

What's funny is, if they are going to make me do that (ignore keywords because it's not even in testing) to get that package, what's the point? I might as well have just gone in there and built it explicitly. I do want gcc 14.2.1 now... Arch has switched to that)

P.S. Actually all that to allow that package to merge, and I can't leave it like that with those wildcards, because now it's trying to upgrade to gcc-15 (which isn't even close to me wanting to have) with @world. I give up, those packages simply have to be masked and their keywords masked (the keywords override my package.mask actually it seems). I think it's better to just mask and do those ebuilds explicitly.

Aren't you glad that you aren't going to be having problems like this, because you're going to behave better than I do

[Zema Bus]

lol!

That'll definitely help, I did go with OpenRC.

[Zema Bus]

I checked and I already have config_eth0 and config_eth1 = "dhcp" in /etc/conf.d/net but the issue remains (I have connectivity though):

PXL_20240807_084326662.jpg (251.75 KiB) Viewed 45639 times

PXL_20240807_084458776.jpg (207.43 KiB) Viewed 45639 times

Something going on with non-existent modules too. It was getting late at the time so I just installed the binary kernel figuring I'd address that later, but that's why the LTS kernel.

[Grogan]

You have the correct module, that other shit looks more like skipping loading modules because you don't have the front ends installed to use them. (That's WEIRD but this is Gentoo lol) Those aren't all kernel modules being listed, it's a bunch of module aliases and it looks like they are loading them based on installed helper programs. I don't use their kernel, and no initramfs of course so I don't see anything like that.

So the /etc/udev/rules.d/80-net-setup-link.rules lines didn't work on that kernel? That's the way I've been doing them for a long time on Slackware, Manjaroo, Arch, my LFS etc., but maybe that's not right for the Gentoo modular kernel with what they do in their initramfs or something. It's probably already initialized or something by the time those rules are processed.

I'm looking into it... if I can find info that isn't 15 years old.

Maybe you need to generate a new initramfs with a module alias in place or something. For that matter, how are you booting? Did you install Grub in Gentoo or did you add your kernel to another boot loader? The parameters may not be right for the Gentoo kernel (e.g. if you generated one with slackware's grub-mkconfig or something)

[Grogan]

See if adding this to your kernel command line helps:

Code: Select all

net.ifnames=0

That's not actually a "kernel parameter", it's udev that listens for that. Well, systemd, but Gentoo uses the actual systemd udev now (sys-apps/systemd-utils) for OpenRC as well, not their old eudev fork.

[Grogan]

Easy to just try that kernel parameter, but Bloody Hell... the info you find in Gentoo wikis and stuff is not always correct or current.

Code: Select all

udev from the sys-apps/systemd-utils package is used as the default device manager for Gentoo systems using the OpenRC init system, independently of systemd.

That's not true that Gentoo uses "systemd-utils" udev for OpenRC now (though I think it can work with OpenRC)... that's not the udev I have installed

Code: Select all

grogan@nicetry /storage2/portage/db/repos/gentoo $ find . -name '*udev*'
...
...
./virtual/udev
./virtual/udev/udev-217-r7.ebuild
./virtual/libudev
./virtual/libudev/libudev-251-r2.ebuild

grogan@nicetry ~ $ equery list virtual/udev
 * Searching for udev in virtual ...
[IP-] [  ] virtual/udev-217-r7:0

grogan@nicetry /storage2/portage/db/repos/gentoo $ equery list libudev
 * Searching for libudev ...
[IP-] [  ] virtual/libudev-251-r2:0/1

Location field in brackets... The "I means installed, the "P" means available in Portage. The second field is the Mask field, which is empty because there is no masking activity involved with that package.

That looks like old school udev (not even eudev which is deprecated) like I had on my LFS system.

Let's see what udev you have installed. Recall that I chose the most minimal stage 3, without the use flags to build an "X" enabled system and then worked that up by compiling/recompiling. With your stage3, you might have the other because crap tied to systemd like Gnome and Plasma might need that one.

Yet I also have systemd-utils installed.

------------------------ Edit ----------------------------

Mayonnaise diarrhoea!

Forget that. We do have the same udev using OpenRC.

virtual/udev is not an actual package, it's more like a dependency satisfying pointer, essentially. Something like, virtual/dev-manager is satisfied by virtual/udev which is satisfied by sys-apps/systemd-utils on a NON-systemd system. On a systemd system that dependency chain would simply be satisfied by systemd for the result. This would all be governed by the stage3 we used (i.e. without the systemd USE flag anywhere)

Gentoo is clever, but strange

[Zema Bus]

Thanks, I'll try that after work tonight. I'm booting it with Gentoo's Grub.

I'm in Arch so I mounted the Gentoo drive mounted to search for udev [Oops, I ran this before seeing your edit, I'll post it anyway]

Code: Select all

[root@Raza drive]# cd ./var/db/repos/gentoo
[root@Raza gentoo]# find . -name '*udev*'
./app-crypt/ekeyd/files/ekeyd-1.1.5-udev-rule.patch
./app-emulation/libvirt/files/libvirt-10.1.0-Fix-off-by-one-error-in-udevListInterfacesByStatus.patch
./app-emulation/qemu-guest-agent/files/qemu-ga-systemd.udev
./app-emulation/xen-tools/files/xenqemudev.confd
./app-emulation/xen-tools/files/xenqemudev.initd
./app-misc/openrgb/files/OpenRGB-0.7-r1-udev.patch
./app-misc/openrgb/files/OpenRGB-0.9-udev-check.patch
./app-text/uudeview
./app-text/uudeview/files/uudeview-0.5.20-CVE-2004-2265.patch
./app-text/uudeview/files/uudeview-0.5.20-CVE-2008-2266.patch
./app-text/uudeview/files/uudeview-0.5.20-bugfixes.patch
./app-text/uudeview/files/uudeview-0.5.20-fix-append_signature.patch
./app-text/uudeview/files/uudeview-0.5.20-fix-function-definitions-clang16.patch
./app-text/uudeview/files/uudeview-0.5.20-fix-implicit.diff
./app-text/uudeview/files/uudeview-0.5.20-format-string-warning-inews.patch
./app-text/uudeview/files/uudeview-0.5.20-makefile.patch
./app-text/uudeview/files/uudeview-0.5.20-man.patch
./app-text/uudeview/files/uudeview-0.5.20-rename.patch
./app-text/uudeview/files/uudeview-0.5.20-string_format_issue.patch
./app-text/uudeview/uudeview-0.5.20-r2.ebuild
./app-text/uudeview/uudeview-0.5.20-r3.ebuild
./app-text/uudeview/uudeview-0.5.20-r4.ebuild
./app-vim/udev-syntax
./app-vim/udev-syntax/files/udev-syntax-20051016-ftdetect.patch
./app-vim/udev-syntax/udev-syntax-20051016-r3.ebuild
./dev-libs/cyberjack/files/libifd-cyberjack6.udev-r1
./dev-libs/libcec/files/libcec-4.0.7-no-override-udev.patch
./dev-libs/libgudev
./dev-libs/libgudev/libgudev-238-r1.ebuild
./dev-libs/libgudev/libgudev-238-r2.ebuild
./dev-python/pyudev
./dev-python/pyudev/pyudev-0.24.1.ebuild
./dev-util/android-udev-rules
./dev-util/android-udev-rules/android-udev-rules-20240221.ebuild
./dev-util/android-udev-rules/android-udev-rules-20240625.ebuild
./eclass/udev.eclass
./games-util/game-device-udev-rules
./games-util/game-device-udev-rules/game-device-udev-rules-20220311.ebuild
./games-util/game-device-udev-rules/game-device-udev-rules-20230603.ebuild
./games-util/xboxdrv/files/xboxdrv.udev-rules
./media-libs/svgalib/files/svgalib.udev.rules.d.2
./metadata/install-qa-check.d/60udev-eclass
./metadata/md5-cache/app-text/uudeview-0.5.20-r2
./metadata/md5-cache/app-text/uudeview-0.5.20-r3
./metadata/md5-cache/app-text/uudeview-0.5.20-r4
./metadata/md5-cache/app-vim/udev-syntax-20051016-r3
./metadata/md5-cache/dev-libs/libgudev-238-r1
./metadata/md5-cache/dev-libs/libgudev-238-r2
./metadata/md5-cache/dev-python/pyudev-0.24.1
./metadata/md5-cache/dev-util/android-udev-rules-20240221
./metadata/md5-cache/dev-util/android-udev-rules-20240625
./metadata/md5-cache/games-util/game-device-udev-rules-20220311
./metadata/md5-cache/games-util/game-device-udev-rules-20230603
./metadata/md5-cache/sys-apps/udevil-0.4.4-r5
./metadata/md5-cache/sys-block/io-scheduler-udev-rules-2
./metadata/md5-cache/sys-fs/udev-init-scripts-35
./metadata/md5-cache/sys-fs/udev-init-scripts-9999
./metadata/md5-cache/sys-libs/libudev-compat-186-r1
./metadata/md5-cache/virtual/libudev-251-r2
./metadata/md5-cache/virtual/udev-217-r7
./metadata/news/2021-08-24-eudev-retirement
./metadata/news/2021-08-24-eudev-retirement/2021-08-24-eudev-retirement.en.txt
./net-fs/nfs-utils/files/nfs-utils-udev-sysctl.patch
./net-print/foo2zjs/files/foo2zjs-udev.patch
./net-wireless/bluez/files/bluez-udevadm-path-r1.patch
./sys-apps/pcsc-lite/files/pcscd-udev
./sys-apps/udevil
./sys-apps/udevil/files/udevil-0.4.3-flags.patch
./sys-apps/udevil/files/udevil-0.4.4-include-sysmacros.patch
./sys-apps/udevil/files/udevil-0.4.4-no-libtool.patch
./sys-apps/udevil/files/udevil-0.4.4-stat.patch
./sys-apps/udevil/udevil-0.4.4-r5.ebuild
./sys-block/io-scheduler-udev-rules
./sys-block/io-scheduler-udev-rules/io-scheduler-udev-rules-2.ebuild
./sys-fs/mdadm/files/mdadm-4.3-no-udev.patch
./sys-fs/udev-init-scripts
./sys-fs/udev-init-scripts/udev-init-scripts-35.ebuild
./sys-fs/udev-init-scripts/udev-init-scripts-9999.ebuild
./sys-kernel/dracut/files/dracut-103-systemd-udev-256-kmod.patch
./sys-libs/libudev-compat
./sys-libs/libudev-compat/files/udev_old.c
./sys-libs/libudev-compat/libudev-compat-186-r1.ebuild
./sys-power/apcupsd/files/apcupsd-udev.rules
./virtual/libudev
./virtual/libudev/libudev-251-r2.ebuild
./virtual/udev
./virtual/udev/udev-217-r7.ebuild

Gotta get ready for work now...

[Grogan]

You don't specifically need to query this anymore, but you probably have to actually install gentoolkit to have "equery" to be able to see what's installed and stuff. I did, in both installs, there's nothing to pull that in. (How silly to not install the query tool for the distro's package management)

Code: Select all

emerge app-portage/gentoolkit

----------------------------------------

That change to systemd-utils happened in 2022

https://www.gentoo.org/support/news-ite ... utils.html

The sys-apps/systemd-utils package was recently added to the gentoo
repository. This replaces sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, and sys-fs/udev with a single package, and is
for OpenRC users. It does not depend on sys-apps/systemd and contains
the same exact components as the split packages.

That systemd-tmpfiles program (compiled, not script) was the poxy thing that didn't like me having /var/tmp symlinked off previously

[Grogan]

I think I may now understand the reason for that "emerge by path is broken and may not always work!" warning that I've encountered forever when explicitly emerging .ebuilds. Emerging by path implies a "one-shot", which makes perfect sense, but I wasn't aware of the implications.

From "man emerge"

Code: Select all

--oneshot, -1
              Emerge as normal, but do not add the packages to the world file for later updating.

              WARNING: This option should only be used for packages that are reachable from the @world package set (those that would not be removed by --depclean), since dependencies of unreachable packages are
              allowed to be broken when satisfying dependencies of other packages.  Broken dependencies of this sort will invalidate assumptions that make it possible for --deep to be disabled by default.

I'm good though, I'm doing things that I know will work. The packages I actually fuck with (kernel-headers, glibc, binutils, gcc) are done correctly, in an orderly manner together and they are mostly their dependencies and I use masks so they can't be touched automatically. I'm not going so far out of scope that the distro versions of gcc's supporting libraries (e.g. libisl, mpc, gmp, mpfr) won't be usable. Hell, those compiled years ago on my LFS were still usable (stable interfaces) for gcc 14 builds. I recall upgrading those once in the lifetime of that system and it was voluntary.

[Grogan]

Finally... I got rootless X working with just startx and startxfce4 (I never use login managers... hate them)

The profile for an X enabled stage3 will already have these USE flags.

I decided to be a good boy and unsabotage that so I wouldn't have to set /usr/bin/Xorg SUID root anymore. I didn't want the dependency on elogind so I deliberately didn't add the USE flags when working up my minimal stage3, but that's silly to defeat that out of stubbornness. I set the elogind and dbus USE flags globally and let it recompile the packages that need it (I already had PAM compiled with it through a package specific USE flag as other things were dependent on it and it was just easier to let it rebuild PAM but I was not actually using it). I'd say probably a dozen or so packages, it didn't take long.

Gentoo doesn't have a USE flag for xorg-server to enable building the suid-wrapper binary (Xorg.wrap) either since they want you to use either elogind or systemd-logind. You can't just supply your own ./configure or meson setup options with Gentoo, you'd have to make your own .ebuild and use a portage overlay (location= in repos.conf) so that's a pain in the ass and would send me further down the rabbit hole. (Arch builds the suid-wrapper, so does Slackware)

When I have trouble, I do go consult wikis. What I didn't know, and the Xorg wiki didn't actually have (I finally found what I was doing wrong in a separate "Non-root X" wiki) was that the elogind service needed to be added to the boot runlevel. It isn't something passive, like "login" (the d for daemon should have been a clue and I should have remembered that Gentoo doesn't enable services automatically)

Code: Select all

rc-update add elogind boot

Ferfucksakes

[Grogan]

With OpenRC, my system boots up faster than my monitor can mode switch. Hit enter on kernel, and next thing I see is the green bulleted init and the login prompt already there in about 1 second. It makes me LIKE rebooting, it's so cool. I could get used to this

[Grogan]

I said somewhere above that I tried to customize Mesa with the VIDEO_CARDS= variable. I built a non-functional Mesa that didn't have the drivers I needed. Fucking nowhere in any wiki did it tell me about RADEON_CARDS= (that gets included in the VIDEO_CARDS variable, where I would have needed "radeonsi" (which is our gallium driver for amdgpu). I would have thought that VIDEO_CARDS="amdgpu" as directed would turn that on. Moreover, in the actual Mesa configuration, you don't say "amdgpu" anywhere, the driver IS "radeonsi" and "amd" for vulkan-drivers. That's silly, why do things like that... I didn't get that until I started going through the .ebuild (making an overlay to build my own, my way... what good is Gentoo if I have to eat dogfood)

Code: Select all

RADEON_CARDS="r300 r600 radeon radeonsi"
VIDEO_CARDS="${RADEON_CARDS} d3d12 freedreno intel lavapipe lima nouveau nvk panfrost v3d vc4 virgl vivante vmware zink"
for card in ${VIDEO_CARDS}; do
	IUSE_VIDEO_CARDS+=" video_cards_${card}"
done

This is what's wrong with Gentoo, it's a wonderful system, but you have to figure out their arbitrary methods and decisions. I think the wikis are deliberately ambiguous so that if you can't figure it out, you can't do anything other than defaults. They never tell you exactly what you need.

Look, here, it showed me this

https://wiki.gentoo.org/wiki/AMDGPU

VIDEO_CARDS="amdgpu radeonsi"

That's not even valid for mesa, amdgpu. I thought they were doing something clever with that, but no, that's not for mesa. If that same VIDEO_CARDS= variable is used for building graphics drivers in the kernel package, then that's pretty wrong headed to use the same variable with a string with inapplicable parameters for other things its used for.

I can also see that the VIDEO_CARDS variable is used for Vulkan too. They are doing "clever" shit with that, automatically adding "amd" to vulkan drivers based on the radeonsi choice, "if use vulkan; then"... and then using "vulkan_enable video_cards_radeonsi amd" to map their shit to set "amd" for the vulkan driver. You just can't predict what they are going to do, it won't be consistent logic.

I'm just going to force my own config by ignoring all their gymnastics in the .ebuild. Just hard code my meson setup options, my way. For example, instead of things like this:

Code: Select all

-Dgallium-drivers=$(driver_list "${GALLIUM_DRIVERS[*]}")

Do (normal) things like THIS

Code: Select all

-Dgallium-drivers=radeonsi,zink,softpipe

[Grogan]

So... I have not been successful with that. I don't think I can build Mesa my way on this system. There's a whole house of cards of USE flags on the system that I will break, with the Mesa package, even if I successfully finagle it. What's frustrating is I could rip that out and replace it by hand in 2 minutes flat (I'm very familiar with Mesa... LFS etc.) but I would break package management completely (emerge).

I created a repo for myself (properly, using "eselect repository create") for a portage overlay, but you can't just drop in stuff from the portage tree without correct manifests and stuff. You'd have to create your own .ebuild and work it up. I could do a simple one, but that's not what I need. (if it was that simple I'd do it by hand in /usr/local and not emerge it from the distro at all lol). That's another thing I could do... link Mesa off to a non-system prefix. When I go to play a game, simply prepend the environment with LD_LIBRARY_PATH and PATH etc. for that invocation so the alternate prefix is searched first, thus not touching the system's boring old stable with LLVM back end. I do intend to play some 64 bit native games here occasionally. I have some from GoG, as well as old shit like UT2004. Open source games like RBDoom3BFG too. I could run stuff like that right now if I were to do sdl2 and openal, I just don't care about that yet. I'm more interested in my Mesa first.

Anyway, I sought to just leave all the USE flags intact and just gut the meson setup and replace it with mine. Nope... you can't do that, I presume because it validates the USE flags. It will just tell you that the syntax is incorrect (ebuild) or go in a loop of exiting on signal 2 (emerge) and starting the red warning countdown again (merging a masked package) if you force it. I was testing it with --pretend first, since this is compiling and installing things as root, where you're not just going to build a bad package, but insta-b0rk if it goes through.

So no... I don't think I will be using Gentoo as my main squeeze, I'll keep it as my minimal, serious system.

Every time I get mad at Arch... I realize that it's highly flexible and friendly to my methods. I can do any fucking thing I want in those PKGBUILDs as long as I set provides=, replaces= and conflicts= parameters correctly. I build glibc and both GNU and LLVM based toolchains my own way (so they output things my way), Mesa my own way, anything else that pisses me off my own way and in some cases even packaged my own way (e.g. monolithic packages instead of umpteen split). I just have to keep up, and compile a lot of the system because their build flags bite the weenie.

[Grogan]

Oh man, these USE flags are such a pain in the ass. I added "wayland" to my global USE flags to make sure everything is compiled with Wayland support (whether I intend to use it or not, it's a build dependency for a lot of things and I want to make sure that everything is properly linked). That would have been in the profile, had I started out with an "X" enabled stage3. That's the whole point, so I could control some dependencies.

Of course, the old sdl2 stuff doesn't have Wayland support. Fine, it therefore would have nothing to do with Wayland at compile time. Instead of just ignoring that then, emerge won't do it because it's an invalid USE flag. Easily overridden by prefacing the emerge command with USE="-wayland". However, it was also wanting to rebuild my freetype with harfbuzz. I don't like that circular dependency and don't care about those fonts or the changes to the hinting for TTF fonts. Freetype doesn't need to use harfbuzz, and harfbuzz itself is linked to freetype. I quite frankly don't want to change my freetype at all, my fonts are perfect (better than anywhere else in this house!). I also don't have to contend with things like Wine here, which handles fonts. So...

Code: Select all

USE="-wayland -harfbuzz" emerge --ask media-libs/libsdl2 media-libs/sdl2-gfx media-libs/sdl2-image media-libs/sdl2-mixer media-libs/sdl2-net media-libs/sdl2-pango media-libs/sdl2-ttf

Here's something stupid about this. It will be fine and dandy, until there's something in the @world update command that needs "wayland" and coincidentally, if sdl2 needs updating at the same time, the world emerge command will fail and/or try to rebuild my freetype with harfbuzz and I'll have to do that thing separately

(to be safe I should probably have some package specific use flag masks in some package.* scheme to prevent the harfbuzz/freetype thing)

[Grogan]

I decided to do just that with my Mesa (install mine in another location), only I might as well use it in my global environment, not just at invocation time.

I built one my way and without using glvnd (the dispatch) so I'd have real opengl libraries in my prefix, /opt/mesa/

I deleted /opt/mesa/include and /opt/mesa/lib64/pkgconfig so nothing on the system could possibly find those (it shouldn't, but I want ensure gentoo builds use the headers etc. in /usr) and link to that mesa.

I set /opt/mesa/lib64 first in /etc/ld.so.conf

I exported VK_DRIVER_FILES="/opt/mesa/share/vulkan/icd.d/radeon_icd.x86_64.json" (that has the full path to libvulkan_radeon.so)

So unto .ebuilds, I say pffft

[Grogan]

I'm all set for 64 bit native games now. I tested Soma (opengl) from GoG and RBDoom3BFG (vulkan). My old RBDoom3 build still ran (built on the old computer on my LFS lol) but it was time for a new one. I got the latest git and found I needed dxc, the "directx shader compiler" for the build, for translating intermediate shader languages. That was never needed previously. Gentoo didn't seem to provide that (nor a build for VulkanSDK which would also have it) so rather than fuck about, I just went to Arch to compile RBDoom3BFG where I already have that for other builds. (I'll probably not need that for anything in Gentoo ever again)

I'm running the game in Gentoo, is the new RBDoom3BFG ever nice. I had to cap it at 120 FPS for nice smooth gameplay though.

It sure is stupid that Steam needs 32 bit userspace. I could be playing my native games that I never play anymore (e.g. those tomb raider games, DiRT racing games). Oh well... Steam isn't the whole world. I have all my GoG games. I could even do a 64 bit Wine with some limited 32 bit support with wow64 (I say limited because I'm not sure exactly how much that provides, and how much is still the lib32 back end on the system) and that would cover some of the Windows GoG games)

I like a minimal system though, so that's the price to pay. I have Arch if I want bloat. This system is so nice and fast, and I'd hate to ruin it.