Gentoo 2024

[Grogan]

I had the wrong strategy by disabling glvnd in my alternate mesa. That was fine for GLX, but most desktop shit (XFCE, Firefox) uses EGL now. That's dispatched by a similar json mechanism as Vulkan. I was checking to make sure the libraries were all being used, with lsof and I noticed that the EGL in /usr/lib64 was being used, not my /opt/mesa. So I need to use glvnd's egl_vendor.d dispatch json files.

Another problem is some of the stuff on the system is compiled against the libglvnd libraries, for example libOpenGL.so.0 instead of libGL and that wouldn't dispatch correctly if my mesa wasn't built with library names like libGLX_mesa.so

Since the next Gentoo ebuild of their mesa would blow this away, I made my own egl_vendor.d directory and used this variable to override the directory in /etc/profile.d (I made a file called extrapathsandshit.sh where I'm putting ALL of my own variables so they will be all together). It's one of those stupid things with double underscores to get wrong

Code: Select all

export __EGL_VENDOR_LIBRARY_DIRS=/opt/mesa/share/egl_vendor.d

Then I could drop in my own 50_meson.json file (could be anything.json, numbers are for ordering. I only have one so that's moot). This ensures that it has no choice but to dispatch the correct libEGL.

Code: Select all

{
    "file_format_version" : "1.0.0",
    "ICD" : {
        "library_path" : "/opt/mesa/lib64/libEGL_mesa.so.0"
    }
}

Edit: Oh jeeze. mesa actually does install an egl_vendor.d/50_meson.json file in $PREFIX/share/glvnd when glvnd is enabled (I thought that came from glvnd, but like vulkan, mesa does drop in the .json). I'm using my own location just above it, but I can switch to that one which saves me having to preserve it in /opt/mesa (I can just nuke /opt/mesa). I will still have to edit it so it has the full path to libEGL_mesa.so.0 to make sure it dlopens the right one, at least I'm going to. since those icd.d mechanisms provide for this very thing (overriding distro with vendor of choice). I'm always leery of relying on the environment.

I also realized that silly Gentoo overwrites /etc/ld.so.conf (e.g. when you do a merge it will run env-update and overwrite it... that blows goats!) and my entry was lost. I was wondering why I had no direct rendering when I first started back into Gentoo. I have to use the /etc/ld.so.conf.d directory now. I made a file 00mesa.conf with /opt/mesa/lib64 in it. Those includes are at the top of the ld.so.conf file that is generated, so 00mesa.conf will get processed first.

NOW everything is dispatching correctly, and the libraries in /opt/mesa are being used. (the X server, firefox, XFCE, everything). I had no problem with Vulkan, as I was overriding the json, but EGL was a pain in the ass.

[Grogan]

What did I say was going to happen with that -wayland USE flag for the SDL2 packages? That's right, the very next day. Updates to the old SDL2... probably hasn't been in a long time, but because I did that, there is NOW

Code: Select all

!!! The ebuild selected to satisfy "media-libs/libsdl2" has unmet requirements.
- media-libs/libsdl2-2.28.5-r2::gentoo USE="X dbus haptic joystick pulseaudio sound threads video vulkan wayland -alsa (-aqua) (-custom-cflags) -doc -fcitx4 -gles1 -gles2 -ibus -jack -kms -libsamplerate -nas -opengl -oss -pipewire -sndio -static-libs -test -udev -xscreensaver" CPU_FLAGS_X86="mmx sse sse2 -3dnow" VIDEO_CARDS="(-vc4)"

  The following REQUIRED_USE flag constraints are unsatisfied:
    wayland? ( gles2 )

So I'll just emerge those SDL2 packages again with -wayland -harfbuzz and then the @world update command will work again.

P.S. Actually no, that seems permanently fucked. I tested that yesterday and "emerge --ask --update --deep --newuse @world" didn't complain, but after this last sync it's complaining every time.

This is utterly ridiculous. Alright, fuck Wayland. That's coming out of the USE flags, I don't care if something doesn't get built with wayland support (as long as I don't go -wayland it shouldn't rebuild world without it lol)

Now it wants to rebuild my freetype with harfbuzz again, just because I'm trying to update. (Note that SDL2 packages aren't actually being touched here, that's just silly emerge validating everything)

Code: Select all

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by media-libs/sdl2-ttf-2.22.0::gentoo
# required by @selected
# required by @world (argument)
>=media-libs/freetype-2.13.2 harfbuzz

This shit is just way too rigid to be practical. What a waste of time, I'd have had a new, custom LFS build done exactly my way in far less time than I've been fucking with this. It's Saturday and I have to leave, and I didn't even get this simple update command done today. (Though I did get side tracked helping Dad with his satellite receiver... I had to recalibrate the dish again because we couldn't get a lock)

[Zema Bus]

I can easily say I'm not feeling as enthused about Gentoo as I was before I installed it, but at least I can check installing Gentoo off my bucket list lol!

[Grogan]

Well, you know that these are not difficulties you are going to have with it, unless you want to follow me off a cliff

I still haven't figured this out. It seems that some of these changes only take effect after the next time you sync. Now, it's trying to rebuild everything without Wayland, because I took "wayland" out of the global use flags. I didn't add "-wayland".

So now I'm thinking my only way out is to have hard masks for those packages. I can't seem to get portage to allow those packages to exist with "-wayland" or "-harfbuzz", so they simply have to be blocked, if it will let me still emerge @world. I really need that old SDL2 stuff, it's what most Linux native games use. WTF.

I like this nice, light, snappy system I have (everything compiled smartly, and with as few dependencies as practical) and I'm happy with my Mesa workaround since they can't play ball, but jeeze, does it ever fight me every step of the way.

[Grogan]

So yes, that's how I got out of it. I masked those packages explicitly, and I do mean explicitly (like "media-libs/freetype" and so on for each of the SDL packages. Just. Fuck. Off. and don't try to recompile them. Ever. I'll look after it

I'm back in business, and that's a good thing because I was almost fed up.

These are actual upgrades now ("U")

Code: Select all

nicetry /etc/portage/package.mask # emerge --ask --verbose --update --deep --newuse @world

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

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

[ebuild     U  ] dev-python/setuptools-71.1.0::gentoo [71.0.4::gentoo] USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 2,366 KiB
[ebuild     U  ] dev-python/certifi-3024.7.22::gentoo [3021.3.16-r4::gentoo] USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 13 KiB
[ebuild     U  ] x11-libs/libxkbcommon-1.7.0-r1::gentoo [1.7.0::gentoo] USE="X wayland -doc -static-libs -test -tools" 522 KiB
[ebuild     U  ] x11-libs/gtk+-3.24.41-r1:3::gentoo [3.24.41:3::gentoo] USE="X introspection wayland (-aqua) -broadway -cloudproviders -colord -cups -examples -gtk-doc -sysprof -test -vim-syntax -xinerama" 12,880 KiB
[ebuild     U  ] xfce-base/libxfce4ui-4.18.6-r1::gentoo [4.18.6::gentoo] USE="introspection wayland%* -glade -startup-notification -system-info -vala" 886 KiB

Total: 5 packages (5 upgrades), Size of downloads: 16,664 KiB

!!! The following installed packages are masked:
- media-libs/sdl2-gfx-1.0.4-r1::gentoo (masked by: package.mask)
- media-libs/sdl2-net-2.2.0::gentoo (masked by: package.mask)
- media-libs/libsdl2-2.28.5-r2::gentoo (masked by: package.mask)
- media-libs/sdl2-mixer-2.6.3-r1::gentoo (masked by: package.mask)
- media-libs/sdl2-pango-2.1.5::gentoo (masked by: package.mask)
- media-libs/freetype-2.13.2::gentoo (masked by: package.mask)
- media-libs/sdl2-ttf-2.22.0::gentoo (masked by: package.mask)
- sys-kernel/linux-headers-6.9::gentoo (masked by: package.mask)
- media-libs/sdl2-image-2.8.2::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]

[Grogan]

What sucks about gaming is that it doesn't like "workspace wrapping" behaviour. In XFCE, that's a prime mechanism for me, the way I move around my virtual desktops and I have to turn it off for games or I'll find myself looking at Desktop 2 instead of my game as I move around. I couldn't play RBDoom3BFG like that.

So rather than do that, I decided to just set up icewm for games here too. Already compiled in /usr/local and configured (~/.icewm copied from Arch and menu additions removed for things I'm not going to have) so it was a no-brainer. All I really had to do was install imlib2 for it. I don't like upgrading things like icewm unless absolutely necessary, in case they change something. That build is reliable and doesn't need a recompile. It's all mature libraries.

I also don't care for a compositor while gaming. XFCE's will passthrough an exclusive full screen window, but I mostly use Full Screen Borderless now, it's more recoverable, especially for native games (of course something old like UT2004 won't have that mode though). I don't want to have to turn settings on and off every time I play a game. I was hoping to just use XFCE, but my focus and workspace wrapping configuration, as well as a compositor are too much of a pain in the ass for gaming.

P.S. I'm responsible for starting pulseaudio though. It's not getting loaded through /etc/xdg/autostart here (I don't think icewm is xdg aware), but that's OK. I'm just using pulse in user mode, I didn't compile daemon support. On Arch, systemd loads it through a user socket, but I can start it myself with the start-pulseaudio-x11 wrapper or simply "pulseaudio --start". I used to hate pulseaudio but it's gotten pretty good latency wise and now I actually prefer it because it's so easy to work with. I don't do pipewire. I still hate the way libpulse becomes a dependency for everything (even inherited by linking to toolkits), but it already is.

You can do a lot in the ~/.xinitrc file these days now that there's xrandr, too. Everything before the exec line gets processed after the X server starts, but before the client. Wayland is going to ruin stuff like this

Code: Select all

xrandr --rate 180
/home/grogan/.config/xsetoff
start-pulseaudio-x11
exec icewm-session

(xsetoff does "xset s off" and "xset dpms 0 0 0")

[Grogan]

Oooh, look, Gentoo is getting caught up

Code: Select all

[ebuild     U ~] sys-kernel/linux-headers-6.10::gentoo [6.9::gentoo] USE="-headers-only" 141,743 KiB
[ebuild     U ~] dev-util/intel_clc-24.2.0_rc4::gentoo [24.1.5::gentoo] USE="-debug" LLVM_SLOT="18 -16 -17" 28,638 KiB
[ebuild     U ~] media-libs/mesa-24.2.0_rc4::gentoo [24.1.5::gentoo] USE="X llvm (opengl) proprietary-codecs vulkan wayland zstd -d3d9 -debug -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan-overlay -xa" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="intel nouveau radeon radeonsi -d3d12 (-freedreno) -lavapipe (-lima) (-nvk) (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 369 KiB

That means a GNU rebuild (the reason I mask those packages). I have linux-headers masked for <= 6.10 which is why it has come unmasked for me now that gentoo has a newer .ebuild in the tree for ~amd64. (working how I intended). This time, I'm going to trim that mesa build as well as I can with USE flags, now that I understand why my VIDEO_CARDS variable fucked me up. I'm thinking of building a more crippled one for the distro, with just VIDEO_CARDS="radeonsi" (no swrast, no zink, no osmesa etc.). Mine in /opt/mesa will have the stuff I want. Then --depclean will remove that intel_clc crap. I'm still going to bypass their mesa with my own libraries though. Mine in /opt/mesa is currently 24.2.0-rc4 (maybe today or tomorrowish for a -rc5) but it's my way, or the highway for Mesa. For example, I don't want mine linked against LLVM, as I use ACO for all shaders.

Nothing actually links against Mesa anymore, they link against glvnd and the vulkan loader (these provide the includes and front facing libraries... in the case of vulkan-headers that comes from vulkanSDK as does the Vulkan loader, but supplied separately). I'm starting to see the benefits of glvnd and those icd.d (installable client driver) mechanisms.

I'm starting to understand this USE flag bollocks a bit better, but I still find it miserable to work with.

P.S. I had a nice time with circular dependencies caused by removing USE flags from mesa. I ended up removing all of "xorg-drivers" and remerging and finally got rid of them all with --depclean

VIDEO_CARDS="radeonsi" (only) in /etc/portage/make.conf

I needed to mask libdrm to remove the possibility of older libdrm being in the slot (want to remove legacy drivers... I want to remove it). A package.mask directive:

Code: Select all

<x11-libs/libdrm-2.4.122

Rebuild some xorg packages (drivers, xorg-server)

I needed to add some USE flags for libdrm to package.use directives, otherwise it won't build the back end I need without "amdgpu" in the VIDEO_CARDS variable (I don't want it there because I don't want xf86-video-amdgpu to get built and installed... I just want the generic modesetting driver now because the legacy one is bollocks... doesn't support DRI3)

Code: Select all

>=x11-libs/libdrm-2.4.122 video_cards_amdgpu video_cards_radeon

Then I was able to update @world again and "emerge --depclean" removed the old xorg-drivers packages for me.

Now it all works properly again. Jeeze.

[Grogan]

You know, that's actually a pretty good method I've figured out for overriding a silly distro's Mesa. In the distros I'd normally use, package management is flexible enough, but in things like *buntubian, redhat distros etc. AND evidently Gentoo, you'll break the shit out of package dependencies and stuff if you deviate from their build configurations like I do.

Those mechanisms I used to hate (glvnd, vulkan-icd-loader) actually make it easier to do that cleanly as long as you get your mesa library directory searched first. Builds all link against glvnd and vulkan loader headers and libraries, which dispatch to (dlopen) mine, which then load their dependencies with the dynamic linker.

I was thinking of writing this up in a distro-agnostic way, but the problem is how to handle the 32 bit in different distros. It's not just the directories but how they handle the dynamic linking. I don't think it would be a very useful tut. without that.

[Grogan]

Wow, removing a meta is quite an operation. I wanted to completely remove XFCE and rebuild it without Thunar (might not be easy and I might end up just doing my own install of it instead of the distro .ebuilds)

Firstly:

Code: Select all

emerge --unmerge xfce4-meta

It warned me that I shouldn't do that because it might remove other important packages and to do some other command to check for reverse dependencies first. I don't care... removing dependencies is the point. With these rigid USE flags, how could I remove something that's still a dep?

Anyway, that gyrated for a bit and returned my prompt. It seemed it was done with no complaints.

However, it didn't actually remove anything. I had a funny feeling it didn't "actually" do what I asked, this is Gentoo after all.

So I did "emaint sync -r gentoo" (updates portage tree with git on my system) and my world update command, and then depclean

Code: Select all

emerge sync -r gentoo
emerge --ask --verbose --update --deep --newuse @world
emerge --ask --depclean

THEN it removed a metric shit tonne of packages, 52 of them

Code: Select all

All selected packages: =dev-libs/icu-74.2 =xfce-base/garcon-4.18.2 =x11-libs/libxklavier-5.4-r1 =app-arch/brotli-1.1.0 =xfce-base/xfconf-4.18.3 =sys-block/parted-3.6-r2 =x11-libs/vte-0.74.2 =app-crypt/gcr-3.41.1-r2 =app-crypt/argon2-20190702-r1 =sys-fs/udisks-2.10.1 =gnome-base/gnome-keyring-42.1-r2 =x11-libs/libXinerama-1.1.5 =sys-libs/libnvme-1.9 =app-crypt/libsecret-0.21.1 =sys-fs/lvm2-2.03.22-r5 =x11-libs/libwnck-43.0-r1 =xfce-base/xfce4-appfinder-4.18.1 =xfce-extra/xfce4-pulseaudio-plugin-0.4.8 =virtual/freedesktop-icon-theme-0-r4 =x11-misc/xdg-user-dirs-0.18 =net-libs/libsoup-3.4.4 =virtual/secret-service-0 =dev-libs/libbytesize-2.10 =dev-lang/swig-4.2.1 =gui-libs/gtk-layer-shell-0.8.2 =x11-libs/libXres-1.2.2 =xfce-base/xfwm4-4.18.0 =xfce-base/libxfce4util-4.18.2 =xfce-base/xfce4-settings-4.18.6 =dev-libs/libdbusmenu-16.04.0-r2 =xfce-base/tumbler-4.18.2 =xfce-base/thunar-volman-4.18.0 =app-crypt/p11-kit-0.25.3-r2 =dev-libs/libgudev-238-r1 =sys-fs/cryptsetup-2.7.2 =gui-libs/vte-common-0.74.2 =dev-libs/dbus-glib-0.112 =sys-libs/libblockdev-3.0.4 =xfce-base/exo-4.18.0 =xfce-base/xfce4-session-4.18.4 =app-text/iso-codes-4.16.0 =x11-terms/xfce4-terminal-1.1.3 =gnome-base/gvfs-1.52.2 =xfce-base/xfce4-panel-4.18.6 =sys-apps/gptfdisk-1.0.9-r3 =xfce-extra/xfce4-screensaver-4.18.3 =dev-libs/keybinder-0.3.2-r300 =sys-apps/keyutils-1.6.3-r1 =xfce-base/libxfce4ui-4.18.6-r1 =xfce-base/xfdesktop-4.18.1 =dev-libs/libatasmart-0.19_p5 =xfce-base/thunar-4.18.10

Some of that is going to get put back, but the less of it I can muster, the better. A lot of that junk is because of Thunar, which I hate and I don't normally build. It isn't a dependency for any other XFCE components if it isn't there when building them (there will be a harmless "file not found" when xfce4-session tries to execute it though). There's no USE flag to avoid it, at least not in the meta. If this build system won't let me build XFCE without Thunar, then it's going in /opt by hand. I want to ditch all that gnome gvfs and udisks2 related junk.

The actual, mandatory dependencies for XFCE are not onerous at all, and you don't have to build all components of it

https://docs.xfce.org/xfce/building

For me, that's just this (and without most of those optional deps). I won't be building those things I drew a (messy lol) line through.

xfce4deps.jpg (119.01 KiB) Viewed 77265 times

[Grogan]

So instead of having a duh moment, I decided to just install my own XFCE in /opt/xfce. I just did this in Arch, so I had all the tarballs and already had all the settings worked out in the PKGBUILDS so I could just copy most of the ./configure commands (editing where appropriate). Yes, it's good old fashioned autoconf ./configure, with make install-strip and everything. It is a pleasure to work like this for a change.

Firstly, I explicitly emerged the packages back again that I knew I was going to want/need (from the list I removed). Now they won't be "deps" anymore (won't be removed by --depclean) but entries in the "world file". These things aren't just for XFCE, I'll be needing them for other builds. Moreover, I think it's kind of obnoxious that --depclean removed X11 libraries (though I know it's going to do things like that). I really miss the days when all of X was built together.

Code: Select all

emerge --ask dev-libs/dbus-glib dev-libs/icu x11-libs/vte x11-libs/libwnck gui-libs/vte-common dev-libs/dbus-glib dev-libs/libgudev x11-misc/xdg-user-dirs dev-libs/libdbusmenu virtual/freedesktop-icon-theme x11-libs/libXinerama app-text/iso-codes app-crypt/p11-kit x11-libs/libXres gui-libs/gtk-layer-shell

Then I made sure everything was fine with @world and --depclean

In order for this to work in /opt/xfce, a few variables are needed. I use a file in /etc/profile.d for my stuff.

Firstly /opt/xfce/bin has to be added to the PATH variable somewhere. (I do it like this in /etc/profile.d)

Code: Select all

export PATH="/opt/mesa/bin:/opt/xfce/bin:/opt/firefox/bin:/opt/libreoffice/program:$PATH"

It's also going to need its pkgconfig files found:

Code: Select all

export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/opt/xfce/lib64/pkgconfig"

In order for it to both compile (needs to find gobject-introspection files) and work, it needs to be in the $XDG_DATA_DIRS path. I think the defaults are /usr/share and /usr/local/share but I set them explicitly. This variable won't likely be set by default on a distro and I don't want to find out if it appends or overrides, so

Code: Select all

export XDG_DATA_DIRS="/opt/xfce/share:/usr/local/share:/usr/share"

Last but not least, it needs a ldconfig entry. I made a file /etc/ld.so.conf.d/01xfce.conf with /opt/xfce/lib64 in it.

In my terminal shell I set:

Code: Select all

export CFLAGS="-O2 -pipe -march=alderlake -Wno-error=incompatible-pointer-types -Wno-error=implicit-function-declaration"
export CXXFLAGS="-O2 -pipe -march=alderlake"

After that, ./configure --prefix=/opt/xfce, make, make install-strip for each package, disabling things I don't need in each build. (./configure --help to suss those out... but I already had that sorted). I did use --sysconfdir=/etc so /etc/xdg would work out though.

Now this is a nice snappy XFCE, and it will neither get broken (no dependencies with sonames that are going to break... probably not for years), nor need updating, because it's outside the distro and also XFCE doesn't change much and often not for the better when it does. The current release is already 2 years old, it's robust.

[Grogan]

I just realized, you know what I don't have? A solitaire game! They all need some desktop environment framework, except... pysol (the modern -fc "fanclub" fork of it). That'll just be a bunch of python modules and tk/tcl language and bindings. Nothing that's going to add a bunch of unwanted dependencies (and I should have tk/tcl anyway) or affect anything else.

However, I just don't understand this distro. Why would this package be masked for my architecture? (What they really mean there is that it's masked for "amd64" and I'll have to unmask it with the ~amd64 keyword. I guess because pysolfc is in "testing" but then why doesn't it offer me a previous one? Fine, I can add yet another pointless package.accept_keywords directive.

Code: Select all

nicetry ~ # emerge --ask games-board/pysolfc

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

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


!!! All ebuilds that could satisfy "games-board/pysolfc" have been masked.
!!! One of the following masked packages is required to complete your request:
- games-board/pysolfc-3.0.0::gentoo (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Every day I find something like this that surprises me. This distro is toys in the attic

P.S. Actually, oh shit, in this case I'd have to say it's "pysolfc-3.0.0" that's toys in the attic. I think I see why gentoo has that masked. It seems that some of its libraries are written in fortran now (figures... sci libs) and needs "virtual/fortran-0-r1", an alternate fortran compiler. It just so happens the only reason I have fortran at all is because I was too lazy to find a way to configure gcc without it on this distro. I'm not sure I want another one, for fuck's sake. It's probably got to switch out the gfortran libraries too, from my much newer gcc. (my guess would be that this is an older gfortran)

It's also got to recompile python (and some modules) with tk support, but that's not a show stopper and ought to have been done in the first place.

I guess by my own logic, the fortran compiler doesn't matter (because I don't care about fortran lol). It didn't seem to replace my gfortran anyway, I just have that package, virtual/fortran-0-r1 installed. I honestly don't have a clue what that .ebuild did.

Code: Select all

grogan@nicetry ~ $ equery f virtual/fortran-0-r1
 * Searching for fortran0-r1 in virtual ...
 * Contents of virtual/fortran-0-r1:

and indeed, the CONTENTS file in /var/db/pkg/virtual/fortran-0-r1 is a 0 byte file

It's possible that "virtual" package only does something if it's not already satisfied

I'm back to not understanding why this was masked for me, unless it's because of tk/tcl and python, but that would be an earlier step in the dependency chain. (they'd mask that use flag if that was the reason, I'd think).

[Grogan]

Sometimes, you just have to ask yourself, do I really want this application? The whole point of this system was to keep the dependencies to a minimum. I've not (ever) installed Audacity on Arch because it would pull in too many unwanted dependencies. Gentoo is a bit better, but all the same I don't think I'll do this.

I'll go and grab the Audacity git tree which (hopefully still) has everything necessary bundled for an in-tree (mostly) static build, including appropriate sources for that WxWidgets crap, which Gentoo is MacGyvering with eselect and install it the old fashioned way. I did a build like that on my LFS, so I just used it there when I needed to edit audio. But now I don't have that LFS system on this computer anymore. This build will likely run on my Arch too.

Code: Select all

nicetry ~ # emerge --ask media-sound/audacity

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

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

[ebuild  N     ] dev-libs/serd-0.32.2  USE="tools -doc -test" 
[ebuild  N     ] media-libs/portsmf-239  USE="-test" 
[ebuild  N     ] media-libs/soxr-0.1.3-r1  USE="-examples -test" 
[ebuild  N     ] dev-libs/rapidjson-1.1.0-r4  USE="-doc -examples -test" 
[ebuild  N     ] dev-python/isodate-0.6.1-r1  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] dev-python/pyparsing-3.1.2  USE="-examples -test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] dev-python/fastjsonschema-2.20.0  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] dev-python/lark-1.1.9  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] dev-python/webencodings-0.5.1-r2  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] app-eselect/eselect-wxwidgets-20230114-r1 
[ebuild  N     ] app-text/hunspell-1.7.2  USE="ncurses nls readline -static-libs" L10N="-af -bg -ca -cs -cy -da -de -de-1901 -el -en -eo -es -et -fo -fr -ga -gl -he -hr -hu -ia -id -is -it -kk -km -ku -lt -lv -mi -mk -ms -nb -nl -nn -pl -pt -pt-BR -ro -ru -sk -sl -sq -sv -sw -tn -uk -zu" 
[ebuild  N     ] dev-libs/zix-0.4.2  USE="-doc -test" 
[ebuild  N     ] media-libs/libsoundtouch-2.3.3  USE="openmp -static-libs" CPU_FLAGS_X86="sse" 
[ebuild  N     ] media-libs/portaudio-19.07.00-r2  USE="cxx -alsa -debug -doc -jack -oss -static-libs" 
[ebuild  N     ] dev-python/html5lib-1.1-r2  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] dev-python/poetry-core-1.9.0  USE="-test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)" 
[ebuild  N     ] app-text/enchant-2.6.1  USE="hunspell -aspell -nuspell -test -voikko" 
[ebuild  N     ] dev-libs/sord-0.16.16-r1  USE="-doc -test -tools" 
[ebuild  N     ] dev-python/rdflib-7.0.0  USE="-examples -sqlite -test" PYTHON_TARGETS="python3_12 -python3_10 -python3_11" 
[ebuild  N     ] app-text/gspell-1.12.2  USE="introspection vala -test" 
[ebuild  N     ] media-libs/lv2-1.18.10-r1  USE="-doc -plugins -test" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11" 
[ebuild  N     ] x11-libs/wxGTK-3.2.2.1-r5  USE="X lzma spell wayland -curl -debug -doc -gstreamer -keyring -libnotify -opengl (-pch) -sdl -test -tiff -webkit" 
[ebuild  N     ] media-libs/sratom-0.6.16  USE="-doc -test" 
[ebuild  N     ] media-libs/suil-0.10.20  USE="X -doc -gtk -gtk2 -qt5 -test" 
[ebuild  N     ] media-libs/lilv-0.24.24  USE="-doc -python -test -tools" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11" 
[ebuild  N     ] media-sound/audacity-3.4.2-r1  USE="flac ladspa lv2 ogg portmixer vorbis -alsa -audiocom -ffmpeg -id3tag -mpg123 -opus -sbsms -test -twolame -vamp -wavpack" 

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

Quitting.

[Grogan]

Oho... now here's an example of biting myself in the ass.

Code: Select all

SyntaxError: invalid syntax
CMake Error at cmake-proxies/cmake-modules/AudacityDependencies.cmake:209 (message):
  Conan failed to install dependencies (1) /opt/libreoffice/program/python

This build is finding the WRONG python interpreter because I have /opt/libreoffice/program in the variable string pre-pending $PATH. Bad toad... (slaps hands). It just so happens I built a python interpreter with that LibreOffice build 5 years ago because it couldn't handle Python 3.8. (as a consequence of the bundling and static linking, that build still runs today on much newer systems. I quite like that version, it was before they added annoying date string auto-formatting behaviour that has to be overridden in each cell if you want it to be literal)

I'm going to have to change that variable and reload that shell now (if I just source I'll end up with a mess of duplicate paths if it has $PATH in it). The trouble is, I want some things prepended, so I'll do it like this. The rest can go after.

Code: Select all

export PATH=/opt/mesa/bin:/opt/xfce/bin:$PATH:/opt/firefox/bin:/opt/audacity/bin:/opt/libreoffice/program

This now gives me an effective $PATH of:

Code: Select all

/opt/mesa/bin:/opt/xfce/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/18/bin:/opt/firefox/bin:/opt/audacity/bin:/opt/libreoffice/program

(includes system set dirs in $PATH in that order)

This is what you get when you do things your own way, unanticipated gotchas. If you want to be old school these days, you'll take your paddling in the ass. This build must just look for "python" instead of python3 or something (the reason I've not run afoul of this with other builds or python applications)

[Grogan]

So yeah, it's as simple as that. The build process of Audacity has changed a bit since last time I did this, they now use this "Conan" build tool (automatically, during the cmake command based on preference) to satisfy dependencies before the build.

I'll just paste the notes I made as I was going along, this was super easy to suss out. I did not have to install one single thing on Gentoo (any system set up for dev will already have prerequisites) to pull this build off. The key to this is -Daudacity_lib_preference=local so it uses everything bundled in the git tree instead of system libraries.

Code: Select all

# not sure if --recursive is necessary here, but I do want any submodules if there are any and it doesn't hurt if there aren't, so...

git clone --recursive https://github.com/audacity/audacity.git

# from above audacity source dir

mkdir build
cd build

# build process has changed, it uses this Conan thing to build your deps during the cmake command here:

# Release build already does -O3, so don't add -O to flags. With all the shit this has to build, put the -Wno-errors for gcc 14.x)

cmake -G "Unix Makefiles" ../audacity -DCMAKE_C_FLAGS:STRING="-march=alderlake -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types" -DCMAKE_CXX_FLAGS:STRING="-march=alderlake" -DCMAKE_INSTALL_PREFIX=/opt/audacity -DCMAKE_BUILD_TYPE=Release -Daudacity_lib_preference=local

make -j?? (-j24 is yet to be determined but it only took about 3 minutes with -j4 since the deps were already built)

make install DESTDIR=/storage2/test

find /storage2/test | xargs file | grep -e "executable" -e "shared object" | grep ELF | cut -f 1 -d : | xargs strip -p --strip-unneeded

So then, for continuity... this is how I installed it (as root now). I don't really need to copy through /opt here so I won't.

(examine directory tree, yep, just /storage2/test/opt/audacity and nothing's going to get clobbered, it's going to use lib64 and didn't create a "lib" dir etc.)

Code: Select all

chown -R root:root /storage2/test/opt
cd /storage2/test/opt
cp -a audacity /opt

(I generally don't trust make or ninja installs anymore, always to a DESTDIR first... I want to see what it's going to write and I'll install those results manually with "chown -R root:root" and "cp -a" if not packaging)

This needs only to be found in $PATH (or /opt/audacity/bin/audacity run explicitly... it's actually the only binary... 19.4 Mb stripped for me). You do not even need a ld.so.conf entry for /opt/audacity/lib64 here because it installs all its own bundled libraries in its own lib64/audacity and finds them there)

Moreover, while I don't personally like to do that, I see no reason why this couldn't just be installed to a user owned directory and run like this. (A user can set their own PATH or just run this from location)

In a few minutes... et voila... a fully functional Audacity without installing anything else on the system. It will probably run for years, too. I tested a .flac file first because that's what I'm likely going to be doing next, chopping, tagging, exporting to mp3 for the car. Having some flac I want to chop up and being unable to was what prompted this today.

audacity.jpg (201.29 KiB) Viewed 76590 times

(That's the built in High Contrast style I chose. Except for the mind searing green, it matches my GTK styling the most. Fonts etc. a bit blurry because the image was 1050 px and gets downscaled by the client. They seem to have taken that setting away in current phpbb, probably proportional to client window geometry or something now. At least it doesn't alter the images for viewing in new tab or saving etc. like some boards do)

[Grogan]

Ahhh... the libjpeg discrepancy sabotaged the binary compatibility with Arch. Gentoo uses libjpegturbo, which is libjpeg.so.62 and Arch uses the normal libjpeg, which is linked as libjpeg.so.8. They are not ABI compatible.

So, dropping libjpeg.so.62 in /opt/audacity/lib64/audacity (it sets its own library path there relative to the binary) makes it run on Arch. What I'd best do though is install the corresponding other in /usr/local (library only, no includes, moreover for the turbo one I only need the libjpeg API, not the separate jpegturbo libs) on each distro to fix that discrepancy permanently. At least they'll be compiled for each system that way. This is the second time I've encountered this now with programs I want to run in Gentoo that were compiled on Arch. I recompiled to fix the last one, but I want to run the same build of audacity on both systems.

That's a dumb ass library soname discrepancy, I doubt there is any good enough reason to use libjpegturbo anymore (and our compiler can turn on simd instructions). Certainly not for a bit of jpeg decoding on the desktop, anyway.

[Grogan]

Oh ferfucksake... that libjpeg thing. Arch also uses libjpeg-turbo, but if it's configured with this, -D WITH_JPEG8=ON, then the libjpeg API library will have the newer API and the .so.8 soname instead of the so.62. It actually provides 2 APIs, libjpeg and a more limited libjpegturbo API that applications can use (though they generally don't). It doesn't do both though (it's not just a matter of filename), so it's not something I can change on Gentoo now. I also wouldn't like to change my libjpeg to .so.62 on Arch either, probably even less so. Therefore I'm still relegated to a compat library in /usr/local in each OS. HOWEVER, I can use libjpeg-turbo for both, since they both actually are that on each OS respectively and it's actually the correct library in either case that the software will be linked against, not just one that works. I can certainly live with that

But if I were me, that's how I'd be having libjpeg-turbo on my distribution, to be compatible with most everything else that uses vanilla libjpeg.

[Grogan]

Fuck... what a drama queen this guy is.

https://forums.funtoo.org/topic/5185-fu ... obby-mode/

I've decided to keep Funtoo Linux going in a limited capacity.

Borrowing a phrase from Cameron Kaiser, developer of TenFourFox (a Firefox fork for PowerPC Macs) Funtoo Linux will be entering "Hobby Mode". Here is what that means:

Funtoo Linux will continue as a personal project of mine, maintained for myself. You will still be able to ego sync and get periodic updates. You can still use it if you want to. I use Funtoo in various capacities personally so I might as well allow others to continue to use it too, if they want.

...blah blahfuckin blah...

If you are interested in making a major, meaningful technical contribution to Funtoo Linux, please contact me privately via email to discuss it. I am always open to co-creation and supporting collaboration from serious contributors, but can't spend the time and energy to keep the doors open for this 24/7 as there is significant overhead in running a community project.

So essentially, this was to just take back control and scale it down from a community project to a personal one. I don't think I'd invest any time in Funtoo. He doesn't even really want any comments, he posts these proclamations in a "read-only" forum.

So I'd have to be an asshole to use that... what, next week, is he going to make the repos private too? It doesn't sound like it would be very useful anymore. One guy can't maintain all those ebuilds and keep it current.

[Zema Bus]

And he originally said he was discontinuing it because it wasn't 'fun' anymore. He should have just passed the torch.

[Grogan]

So now that I've fought with everything, configured all the USE flags and Keywords that let me do my thing, and simply took over things I want done my way, there really isn't a lot of work to maintaining this Gentoo system. I check it every day (sync portage repo with git, update world) and it compiles a few updated packages. Things that I have masked I just check myself and explicitly emerge ("by path"... sue me in red) if there's an updated ebuild. For example, something like gcc-14.2.1_p20240824.ebuild which isn't even in any slot.

The only tricky thing was Mesa. Because of the house of cards built around those USE flags, that will break shit. Best thing was to build as minimal a Mesa as I could with available USE flags, and override it with mine. The rest of the stuff meant simply not having the distro ebuilds installed for them.

I'm very happy with this, my no-nonsense, source built, completely optimized, dependency lean system. It shows in startup time of the system, and applications and the general snappy feel of things. I actually get slightly higher Firefox benchmarks with the same build on this system too. (on X11, in XFCE I mean, compared to that. For example 2800'ish vs. 2600'ish for Basemark Web 3.0 scores, consistently.)

I'm happy with OpenRC with init too. That starts up so fast that it's all on the screen before my monitor can mode switch to the amdgpu framebuffer console. All green bullet points with no noise or nonsense like systemd, either.

It's not as good as a custom LFS where I get to plan everything, but almost. I have achieved a similar effect, with something easier to maintain (in the end... I sure didn't think so while I was fighting with it)

[Grogan]

I didn't boot Gentoo at all yesterday, working on video players etc. on Arch. I didn't think I would have missed much, but today was a huge update to everything Perl, dependencies and dependents. 93 ebuilds with updating @world. As a lot of those were perl modules, and with automation the builds didn't take long. I wouldn't have been doing that very often on my LFS (I think I upgraded Perl once in its lifetime... it's pretty mature)

Then I decided to take over mpv and smplayer in the same manner as I did on Arch (I've got that stuff all worked out). I upgraded my /opt/mesa setup to the same git sources as I used last night in Arch, removed Gentoo's linux-firmware (it's not a dependency and it will never bother me again) and deposited my own directory.

Then I removed the smplayer and mpv I installed (emerge --unmerge smplayer mpv)

Now... if you want to be able to use --depclean to get rid of dependencies that are no longer necessary (actually important in some situations, e.g. some things that are switchable with "eselect" if you upgrade) you have to deal with those things that were installed as dependencies for those ebuilds. That was a dozen or so packages.

So I did "emerge --ask --depclean" and said Yes after reviewing what it was going to remove.

Then I simply merged them all back again. I tried to get rid of app-alternative/cpio-0 but the two cpio packages are tied together. The app-alternative cpio IS actually the real GNU cpio, that they rename to gcpio and symlink. The app-arch/cpio is the "bsdcpio" from libarchive, similar to the "bsdtar" it provides. So I guess that's something selectable with eselect. Cpio is not actually important on my system, such that it can be removed with --depclean but I need to have it for handling cpio archives lol

Now these packages are explicitly installed (and recorded to the "world file") and won't get removed by --depclean again. I need them for the smplayer and mpv builds I'm going to send to /usr/local. I suppose I could have added them to the world file so they wouldn't get removed by depclean, but honestly, that would probably take as long as compiling them on this system anyway, so...

Code: Select all

emerge --ask x11-libs/libXpresent x11-libs/libXScrnSaver media-libs/libplacebo media-libs/libass dev-qt/qtsingleapplication dev-lang/luajit media-libs/shaderc dev-qt/qtlockedfile dev-libs/xxhash app-arch/cpio app-alternatives/cpio-0

(by the way, that libplacebo is part of how the "gpu-next" video output driver in MPV interfaces. I always thought "hmm, libplacebo. It sounds like something I don't really need, it's not going to do anything for me" )

[Grogan]

Pretty soon we'll be using Vulkan for everything. Vulkan for games, vulkan for desktop acceleration, vulkan for video. You could almost use Vulkan for OpenGL with Zink, but that's not advantageous if you have a good OpenGL implementation like amdgpu or proprietary nvidia etc. Of course, Microsoft bought out all the game studios to keep their APIs mandatory.

I've got vulkan video now in Gentoo, with my SMPlayer and directly with the mpv command in the file manager. I'm pretty happy with it. The only thing is, SMPlayer would detach the video under Wayland. If I was actually watching movies or shows, I would likely be booted to my "clean" system if not gaming so this is really where I most want this anyway. I don't anticipate using Wayland soon on this system.

[Grogan]

I'd have cobwebs on my ass crack waiting on Gentoo, to get new Mesa features. They are still on the old 24.1.6 stable, and there is still just mesa-24.2.0 in testing (~amd64 keyword) even though the stable 24.2.1 is out. I don't really have to care, as I'm overriding theirs, but that would be a drag if I had to eat their dogfood (and they make mesa difficult with so much tied to its USE flags such that I can't replace it with my desired configuration).

Hell, I LIVE for upgrading mesa