Back to gentoo after 20++ years, some questions on setup

[bea]

Hi, yes i had left Gentoo many years ago when i ended up into a non recoverable system upon a necessary profile change.
Now i am considering coming back. Background is that the "mainstream" distros appear to get more and more embraced by some developments i do not like. Even distros like devuan. Or Alpine.

My idea is to set up an "old fashioned" and as simple as possible machine for every day use. Which means i would like to avoid everything connected to systemd:

systemd, elogind, udev/eudev

in addition

avahi
dbus
pam
polkit
udisks2
selinux
pulseaudio
pipewire

At least for now i would entirely avoid any support of wayland,
try XLibre

Use case:
new hardware, static ip, X11/wdm/windowmaker/some dockapps.

Of course recent web browsers like firefox or librewolf

Which probably means i'll need to fine tune the use flags during initial installation.

What i would like to know is which of the flags are related to the abovementioned services and where i would possibly run into setup problems

[NeddySeagoon]

bea,

Welcome back. We knew you would come but we didn't know when :)

I've been running pretty much the system you describe since 2013.
I wrote it up reasonably well in 2013, Old Fashioned Gentoo Install then started again on new hardware with YeOldeGentoo 2021 Edition but never finished that page.

Support for wayland cannot be totally excluded. Some packages depend on libwayland to be able to detect if wayland support is available. It's a small library.

The kernel uses dynamic major device numbers for some things, like NVMe.
They don't change often but when they do, your NVMe is not where /dev says it is. Needless to say, that makes booting difficult.

I use MATE and Xorg for a desktop. In my opinion XLibre needs to prove itself for a year or two before I would try it.
There is an overlay for it if you want to try.

[bea]

bea,

Welcome back. We knew you would come but we didn't know when

Well, i actually gave the musl build a try a few years ago, but that installation failed pretty early. That's why i went to Alpine for that machine.

Thanks for You links, i'll read that soon. At present i am struggling with the tiny fonts on my monitor (luckily it is not a HiDPI display, i would almost need my 6-fold stereo loupes to read that )

[bea]

Well, after some struggling (grub does not install from XFS file systems although docs suggest otherwise ... took me some days to find out and repeat the installation).

Meanwhile i have something bootable, even a GUI (good old windommaker... still my favorite)

Installing some tools mandatatory for that machine:

media-sound qastools:

Code: Select all

!!! All ebuilds that could satisfy "dev-qt/qtbase:6[dbus,gui,network,widgets]" have been masked.

hydrogen

Code: Select all

there are no ebuilds to satisfy "~dev-qt/qtbase-6.10.2:6[dbus,xml]".

qterminal

Code: Select all

!!! All ebuilds that could satisfy ">=dev-qt/qtbase-6.6:6=[dbus,gui,widgets,X]" have been masked.  

same for qjackctl


lxterminal

Code: Select all

All ebuilds that could satisfy "lxterminal" have been masked.

Well, the latter ... upon closer checking, lxde to which lxterminal belongs is masked because it needs a new maintainer

All the others: according to https://packages.gentoo.org/packages/dev-qt/qtbase
qtbase 6.2.10.x is (still?) supported on the target architecture (amd64).

What's going on there?
Why do i have to unlock everything qt?
Is that a sign of X support being dropped in the near future?
And is unlocking qt stuff safe for the forthcoming years?

When i left gentoo years ago that was because i could not handle the regular maintenance efforts anymore - in addition to the demands of my business. Like any other rolling distro. Now the situation is different but the amount of work to handle gentoo so that it satisfies my needs looks to have increased drastically.

Anyway: at present it appears to me that gentoo is not "production ready", at least not for my use case. The effort is really short before doing all from scatch instead through the help of ebuilds. Or hacking dependencies in source files of something like devuan or BSDs.

I am sincerely considering to tar up the installation and replace it by a copy of my current old devuan setup onto the new machine (and then maybe install the gentoo setup on the old box just for playing around with it).

mhmm

i actually would have hoped that gentoo was still a lot more flexible, but if the result of building all by myself will end up with just the functionality of any arbitrary mainstream distro i wonder if the effort is worth the result.

[grknight]

Without knowing the reasons from below your quoted sections, it is impossible to help.

What's going on there?
Why do i have to unlock everything qt?

You are asking for qt based programs so it is normal to have it pulled in. The flags listed there are required for those apps to build (on Gentoo or any other distro).

[Hu]

Portage is generally quite good at explaining the problem, but the quoted snippets omit too much of that information for us to analyze the problem. Per [post=1901]Guidelines[/post] item #4, you should show us the full output, starting at the command line you entered, and going through to when your shell prompt appeared again.

Even if grub cannot read from XFS[1], there is no need to reinstall the whole system for that. You would only need the kernel to be on a filesystem that grub can read.

[1]: I don't know whether or not grub can read XFS. I am only reacting to OP's claim that it cannot.

[bea]

First of all my goal was to issue frustration and not to ask for support.

Anyway another snippet from the output which probably makes the situation clear:

Code: Select all

# Ionen Wolkens <ionen@gentoo.org> (2026-03-23)
# Masked for testing the new .0 version and leave time for packages
# to catch up on support. Will likely be kept masked until 6.11.1
# is released unless there is a notable reason to need this earlier.

In case of all the examples above, qt 6.11 is not demanded at all, some older release (6.6.x or sometimes 6.10.x, on my devuan, 6.8.2 is installed) are sufficient - same api. according to the docs, 6.10.2 is available but the problem is that the ebuilds try to pull in 6.11 which is not (yet) available. Which to me appears that the whole stable production tree is being blocked due to the testing of the latest version.

[bea]

Even if grub cannot read from XFS[1], there is no need to reinstall the whole system for that. You would only need the kernel to be on a filesystem that grub can read.

But that obviously requires a separate boot partition which i did not have set up.

[pingtoo]

Even if grub cannot read from XFS[1], there is no need to reinstall the whole system for that. You would only need the kernel to be on a filesystem that grub can read.

But that obviously requires a separate boot partition which i did not have set up.

No, Grub not necessary need a separated partition, May be a /boot directory is all you need. (this /boot again is customizale)

However this is why additional information required. Without knowing how you system boot (BIOS or UEFI) it is hard to tell what more required in order to support.

From your posts, it seems you retain binary distros mentality, you are expecting Gentoo is just select packages and compile them from source code then it will just work. This is not true. Gentoo is not (even with binary packages) design to work out of box. It have been always require some level of knowledge of own hardware and some degree of will for customize to make it work to ones like. It will now work out of box.

[grknight]

All of the apps that need qt above also need qt with dbus support. Portage is saying as such but at the same time it is getting confused trying to unmask a version instead of asking for the flag.

[GDH-gentoo]

As far as I can tell, GRUB does support XFS filesystems. The corresponding GRUB module is named xfs (unsurprisingly ).

[bea]

Even if grub cannot read from XFS[1], there is no need to reinstall the whole system for that. You would only need the kernel to be on a filesystem that grub can read.

But that obviously requires a separate boot partition which i did not have set up.

No, Grub not necessary need a separated partition, May be a /boot directory is all you need. (this /boot again is customizale)

I know. That's what caused the problem when i was using the XFS file system. But anyway, upon reinstall i switched to ext4. And that expectedly solved the problem.

From your posts, it seems you retain binary distros mentality, you are expecting Gentoo is just select packages and compile them from source code then it will just work. This is not true. Gentoo is not (even with binary packages) design to work out of box. It have been always require some level of knowledge of own hardware and some degree of will for customize to make it work to ones like. It will now work out of box.

Not quite: my feeling is that gentoo still emposes many of the restrictions i wanted to avoid. Example is the current situation where the qt demands for dbus to compile.
A while ago i set up an Alpine machine without dbus, but those qt apps did work. That might have been QT5, and i have yet to figure out if QT6 can still be built without dbus support, which btw is not necessarily present on BSD machines as well.

And the qterminal ebuild tries to pull in some stuff from KDE which it won't do on my devuan6 machine.

So in fact i feel pretty limited by the demands of the package maintainer.
In a similar way i do in the binary distros. And that makes me think wether the source fully source based distro is really the right choice for my main working machine.

[Hu]

You can build qt without dbus support. However, if you want to install a package that requires qt's dbus support, then you must enable qt's dbus support. The full Portage output should indicate if this is happening. To take one example from your earlier post, qterminal hard-requires dbus support in qt. If you want to turn off qt support for dbus, then you cannot install qterminal. Switch to a lighter-weight terminal. It's possible, although very unlikely, that this dependency statement is in error. You could try building qt without dbus, then forcing Portage to install qterminal without checking dependencies. This may well result in a broken package, though.

[sam_]

Just as a concrete example, the "KDE" pulled in by qterminal is not optional at all per https://github.com/lxqt/qterminal/blob/ ... ts.txt#L34 and it indeed requires Qt w/ dbus support at https://github.com/lxqt/qterminal/blob/ ... ts.txt#L36

Anyway, venting may do you good, but it won't do anyone else any good. If you want to be helped, facilitate that. If not, go use Devuan and be happy. But you're definitely mistaken either way. I'm confident we could help you get the setup the way you want, but only if you're in a state of mind to get things sorted.

[grknight]

Well, after some struggling (grub does not install from XFS file systems although docs suggest otherwise ... took me some days to find out and repeat the installation).

Out of curiosity, was mkfs.xfs invoked with the extra configuration option I added last month? Grub doesn't like file system features it doesn't know about (hopefully GRUB 2.14 is stabled soon). It may need to go back one more step if it failed. I really need to test that at some point personally.

[sam_]

It's stable now: [bug=971533]bug 971533[/bug]