[SOLVED] Did I misuse gentoo or is it a bug?

[alexander-n8hgeg5e]

I emerged x11-base/xwayland-23.2.2 and my system fetched it as signed
binpkg from some official mirror.
It installed the binpkg xwayland-23.2.2-6.gpkg.tar.
I think the "-6" at the end is because it fits my use flags.
But the binary can not run because it wants systemd.

Code: Select all

ldd image/usr/bin/Xwayland

gives

Code: Select all

libsystemd.so.0 => not found

But the dependencies don't list systemd,...
My old binary that portage kept for me is made from the same official gentoo ebuild
and doesn't require systemd.
The ebuild is x11-base/xwayland/xwayland-23.2.2.ebuild
and git is 8bb7721f7d22

Am I supposed to use the "systemd" profile with the binpkgs ?
Shouldn't it be in the dependencies ?

[sMueggli]

I think the packages are compiled for OpenRC and SystemD usage. At least it is written in the wiki https://wiki.gentoo.org/wiki/Binary_package_quickstart.

Why do you think that Xwayland cannot run? Is there an error message? How do you invoke it?

[alexander-n8hgeg5e]

I ran it with

Code: Select all

Xwayland --help

and it spit out the complain about the missing systemd lib.
I don't want to reinstall it because my terminal emulators need Xwayland with my configuration.
But I could run the extracted binary. There is essentially only the binary in the package. And the dependencies don't change, so this method would be ok I guess.
I'm in a "unpack dir" in /tmp and I run the extracted binary:

Code: Select all

image/usr/bin/Xwayland --help

result is

Code: Select all

image/usr/bin/Xwayland: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory

Actually the package is still installed except the binary.
So there is no worry about the dependencies.
I fixed it with manually extracting the binary from the old (self compiled) package and overwriting the one from the fetched binpkg.
I extraced it like so(the failing one):

Code: Select all

 tar -xOf /var/cache/binpkgs/dusteater/x11-base/xwayland/xwayland-23.2.2-6.gpkg.tar.partial xwayland-23.2.2-5/image.tar.bz2 |tar -jx image/usr/bin/Xwayland

the partial is because it's essentially fetched (I deleted it and I needed to refetch it) but it waits for another program.

[sMueggli]

I do not think that Xwayland has an "--help" flag. Do you see the error also if you execute

Code: Select all

image/usr/bin/Xwayland -help # one dash only!

[Phoenix591]

You ran into [bug=908254]Bug 908254[/bug] unfortunately. Xwayland links to libsystemd if it's installed without being explicitly told to, so it wasn't a proper use conditional dependency that would have been guarded against being selected.

[alexander-n8hgeg5e]

I do not think that Xwayland has an "--help" flag. Do you see the error also if you execute

Code: Select all

image/usr/bin/Xwayland -help # one dash only!

Yes with -help it's exactly the same message.
I also thought that programs like "X" want only one dash even for their
long options. But maybe with "--help" they introduced an exception.

[alexander-n8hgeg5e]

You ran into [bug=908254]Bug 908254[/bug] unfortunately. Xwayland links to libsystemd if it's installed without being explicitly told to, so it wasn't a proper use conditional dependency that would have been guarded against being selected.

Cool thanks, for this thread , I think you solved this thread, I can rename it as solved.
How to solve the bug is another question. It somehow is open since june.
At the moment I don't understand the bug but as soon as there are some
ugly hacks in my /etc/portage/patches directory I start to consider
posting them.

[Hu]

I do not think that Xwayland has an "--help" flag. Do you see the error also if you execute

Code: Select all

image/usr/bin/Xwayland -help # one dash only!

This is a dynamic loader error, so the command line arguments are irrelevant. The code that should parse them never gets executed, so even grossly invalid inputs would produce the same error.

Cool thanks, for this thread , I think you solved this thread, I can rename it as solved.
How to solve the bug is another question. It somehow is open since june.

The bug appears to be a basic automagic dependency:

• When x11-base/xwayland is built, it will try to detect libsystemd.so.
• If successful, it will enable systemd-specific logic and the resulting file will have a load-time dependency on libsystemd.so.
• If not successful, it will not depend on systemd.

Since the ebuild does not direct the package to use or not use systemd, Portage does not record in the ebuild that systemd support was enabled or disabled, so the USE flag matching cannot avoid picking this unusable (to non-systemd systems) package.

Your [bug=908254#c2]comment #2[/bug] and [bug=908254#c3]comment #3[/bug] on the bug look to me to be an incorrect solution, though it might (or might not) be accepted as a stopgap. For your patch to the ebuild, flags in IUSE do not need an explicit -. Conditionally patching source is supported, but I seem to recall that Gentoo developers discourage that where possible, because it makes maintenance more difficult. As a practical matter, I question the value of patching meson.build after running meson_src_configure. For your patch to the source files, I question the correctness of emptying out include/systemd-logind.h. The header appears to be written to provide macro-based stubs when systemd is disabled. I expect files that include this header need those stubs in order to build properly. Did you test these patches before posting them?

[alexander-n8hgeg5e]

Did you test these patches before posting them?

Actually, I only compiled it and did not even restart the window system,...
It seems my package is installed and can print out the help,...
That's not a proper test and I admit I don't even remember doing the "--help" test.
Sorry, I should at least work a bit on a patch before posting it.

Anyway, thank you for your tips, these are really valuable!

[alexander-n8hgeg5e]

As a practical matter, I question the value of patching meson.build after running meson_src_configure

I should make a single patch that patches the source/input meson file.
Now I know what to look out for.
Probably there is something to copy (a lot of meson packages) that , if added via patch, would enable the ebuild to send a configure argument like enable/disable in an ebuilds configure phase.
With this approach, I also don't have to mess with random header files.

Do you think it would be appropriate to add a systemd use flag,
(that switches the configure arguments not the patch)
and also let it depend on systemd if the flag is activated ?

[Hu]

Yes, that is the typical approach for patches that are adopted into the main tree.