| View previous topic :: View next topic |
| Author |
Message |
outtay
n00b
Joined: 11 Jun 2015
Posts: 17
|
 Posted: Tue Jun 18, 2024 7:34 pm Post subject: [solved] Xfce4 and binary package problems |
 |
|
During my last system upgrade I encountered a problem that was a pain to fix, especially since I never really used --resume (and somehow didn't look for it) and therefore just restarted from scratch with the empty-tree each and every time 
Anyway, I encountered a couple of problems where I am not entirely sure where to ask/get them fixed.
- When I install xfce-base/libxfce4ui as a binary and then emerge xfce-base/garcon (also: xfce-base/xfce4-panel) without binary then the emerge fails with
| Code: | /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/libxfce4ui-2.so: undefined reference to `gdk_wayland_display_get_type'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:530: test-display-menu-gtk3] Error 1
make[2]: Leaving directory '/var/tmp/portage/xfce-base/garcon-4.18.2/work/garcon-4.18.2/tests'
make[1]: *** [Makefile:527: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/xfce-base/garcon-4.18.2/work/garcon-4.18.2'
make: *** [Makefile:459: all] Error 2
* ERROR: xfce-base/garcon-4.18.2::gentoo failed (compile phase):
* emake failed
|
If I emerge libxfce4ui not as a binary package and then the rest everything works out.
This was the main problem through which I found the other problem, that I could not find any way that allows me to exclude certain packages from not emerging as a binary if I do a @world command where I by default want binary packages. I was surprised that I couldn't find one, but I can't imagine that there is actually not a way.
Following from that I tried to work around it and tried a couple of things, among which was adding my own patch. I thought that surely when the system detects that I have my own patch to be applied to the package that it won't be emerging the binary. But that was not the case and it was simply ignored. Correct me if I'm wrong but I can't believe that this is intended behavior. If so, then there must be a way to set certain packages from not being emerged as a binary one even though the flag is supplied
In the end I solved this by adding a non-standard use flag to libxfce4ui so that there isn't a binary package for that yet. Not a great solution, but for now it works.
Any help would be greatly appreciated in getting more context or finding out who to ask (because for point number 1 I'm guessing xfce4 developers/maintainers have nothing to do with it)
Last edited by outtay on Fri Jun 21, 2024 2:40 pm; edited 1 time in total |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1921
|
| Posted: Tue Jun 18, 2024 7:47 pm Post subject: |
|
|
| This is Bug 873520 |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Tue Jun 18, 2024 8:26 pm Post subject: Re: Xfce4 and binary package problems |
|
|
| outtay wrote: | | Any help would be greatly appreciated in getting more context or finding out who to ask (because for point number 1 I'm guessing xfce4 developers/maintainers have nothing to do with it) |
Well really xfce4 package maintainers do have everything to do with it, since it's a bug in the ebuild.
However there is some disagreement about whether fixing this for binary package users is beneficial for non-binary users and as a result we are sort of stuck in a holding pattern of nothing is getting done.
I wrote a fix for it: https://github.com/eli-schwartz/gentoo/commit/c47510097254abeb9d73aa3324e74dd908f472f7
Note that it is fixed upstream in the alpha releases of xfce 4.20 (that's the 4.19 series since xfce does even/odd numbering for development cycles). So if we wait long enough the issue will disappear. |
|
| Back to top |
|
|
outtay
n00b
Joined: 11 Jun 2015
Posts: 17
|
| Posted: Wed Jun 19, 2024 6:00 am Post subject: Re: Xfce4 and binary package problems |
|
|
| eschwartz wrote: | | Well really xfce4 package maintainers do have everything to do with it, since it's a bug in the ebuild. |
Apparently, I just wasn't aware of how the binary packages work. I had though that this was a process that is mostly independent of what a package maintainer might do and is just basically emerging a package like on my desktop and repackaging that as a binary and uploading it. But apparently not. Thank you!
Any thoughts/ideas about point 2 and 3? Should I open a separate thread about that?
Just randomly also noticed that unless I build polkit from source I also can't use my shutdown/reboot buttons. If that is now for the package maintainers to fix, I'll just create a bug there. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Wed Jun 19, 2024 11:46 am Post subject: Re: Xfce4 and binary package problems |
|
|
| outtay wrote: | | eschwartz wrote: | | Well really xfce4 package maintainers do have everything to do with it, since it's a bug in the ebuild. |
Apparently, I just wasn't aware of how the binary packages work. I had though that this was a process that is mostly independent of what a package maintainer might do and is just basically emerging a package like on my desktop and repackaging that as a binary and uploading it. But apparently not. Thank you!
|
The same issue would happen for you if you built gtk from source with Wayland support, then built libxfce4ui from source, then removed Wayland from package.use and did "emerge -uDU @world".
You would end up rebuilding gtk without Wayland symbols and since libxfce4ui contains an automagic dependency, it would break libxfce4ui since libxfce4ui would not get automatically rebuilt by that "emerge -uDU @world".
The binhost packages automate this process because they happen to be built on a server where gtk is compiled with USE=wayland.
In general, if a package does something different depending on whether you emerged from source or emerged a binhost prebuilt binary, it's most likely some kind of automagic dependency. And almost per definition, that's a bug in the ebuild. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Wed Jun 19, 2024 11:55 am Post subject: Re: Xfce4 and binary package problems |
|
|
| outtay wrote: |
Any thoughts/ideas about point 2 and 3? Should I open a separate thread about that?
Just randomly also noticed that unless I build polkit from source I also can't use my shutdown/reboot buttons. If that is now for the package maintainers to fix, I'll just create a bug there. |
Specifying getbinpkg on a per package basis: https://bugs.gentoo.org/463964
The /etc/portage/patches thing is mentioned there too. It's actually complicated because how do you know the binpkg isn't built with the same patches? You'd have to hash the patches used and add the hash as a header for the binpackage, probably. |
|
| Back to top |
|
|
toofastforyahuh
Apprentice
Joined: 18 May 2004
Posts: 172
|
| Posted: Wed Jun 19, 2024 7:40 pm Post subject: |
|
|
Firstly, thank you for pursuing fixes for this. My earlier forum thread didn't get any traction.
https://forums.gentoo.org/viewtopic-t-1168976-start-0-postdays-0-postorder-asc-highlight-.html
<somewhat offtopic> Regarding outtay's aforementioned shutdown/reboot button functionality, I first encountered it in May during the 23.0 profile transition and required emerge -e world, which I attempted to shortcut with getbinpg. Recompiling elogind from source (instead of getbinpkg) fixed it at that time. I wasn't sure why the binary was different.
I ran into similar problems in June (on LXDE) and these were indeed caused by the new polkit/124-r1 regardless of source or binary. I'm sticking with polkit/123 for now.
https://bugs.gentoo.org/934314
</somewhat offtopic>
| Quote: | | fixing this for binary package users is beneficial for non-binary users |
The danger is the assumption that you are either one or the other. I think the primary crux of the getbinpkg is to act as a shortcut for otherwise non-binary users to save time, but we still want a functional end result. 
My fear was getbinpkg would be the tempting carrot to force particular unwanted USE flags on people. Example: ignoring for the moment firefox-bin, the regular firefox doesn't have a binary for people without wayland and pulseaudio. And certainly the comments about forcing wayland on everyone in
https://bugs.gentoo.org/873520
almost feel dictatorial. (There's that "legacy" word again.) |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1921
|
| Posted: Wed Jun 19, 2024 7:48 pm Post subject: |
|
|
| toofastforyahuh wrote: | And certainly the comments about forcing wayland on everyone in
https://bugs.gentoo.org/873520
almost feel dictatorial. (There's that "legacy" word again.) |
Just to be clear, the discussion was for x11-libs/gtk+:3 specifically to force enable wayland (the protocol) support to not break ABI. This is not for the entire system. (media-libs/mesa would need to follow as a dependency). This would not force anyone to use Wayland or one of its compositors.
The point becomes moot in future XFCE versions and is only relevant in <4.19 |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Wed Jun 19, 2024 8:52 pm Post subject: |
|
|
| grknight wrote: | | toofastforyahuh wrote: | And certainly the comments about forcing wayland on everyone in
https://bugs.gentoo.org/873520
almost feel dictatorial. (There's that "legacy" word again.) |
Just to be clear, the discussion was for x11-libs/gtk+:3 specifically to force enable wayland (the protocol) support to not break ABI. This is not for the entire system. (media-libs/mesa would need to follow as a dependency). This would not force anyone to use Wayland or one of its compositors. |
Indeed. No one is planning to force people to use wayland compositors. There is some thought to forcing libwayland.so (support library from dev-libs/wayland) to be installed, and for x11-libs/gtk+:3 and its dependency media-libs/mesa to be built against the wayland support libs.
(I oppose this resolution because I still believe it is wrong: forcing a USE flag is not the technically correct solution for xfce and similar packages that have under-specified dependencies.)
| grknight wrote: | | The point becomes moot in future XFCE versions and is only relevant in <4.19 |
It's not solely about xfce. It's about lots of (somewhat carelessly written) software.
| Code: |
$ cd ~/git/gentoo && git log --oneline
dfe44ecddbc3 xfce-base/libxfce4ui: bind tightly to whether gtk was built with wayland
a64aa1ee79e5 x11-libs/wxGTK: bind tightly to whether gtk was built with wayland
1134ff8e7bbb net-libs/gtk-vnc: bind tightly to whether gtk was built with wayland
|
That's three packages where I know it's a problem and have seen reports that the package performs compile-time checks to see if ABI symbols in gtk exist, rather than using buildsystem flags such as "./configure --enable-wayland". There may be more, I haven't examined every gtk project in the world.
xfce fixed this upstream. They added a configure option for it. Once there's a configure option, the ebuild can pass that in a "use_enable". Without a configure option, the only remaining thing an ebuild can do is require that every package have the exact same value of USE.
Just because xfce was fixed, doesn't mean other packages aren't still a problem.
The only fix that will make *everyone* happy would involve adding new EAPI 9 functionality that hasn't yet been agreed on. In the meantime, it's still under discussion, which of several "hacky workaround for EAPI 8" is the least bad. |
|
| Back to top |
|
|
outtay
n00b
Joined: 11 Jun 2015
Posts: 17
|
| Posted: Fri Jun 21, 2024 2:40 pm Post subject: |
|
|
Thank you very much for that explanation and the info everyone has provided.
That addressed all my concerns and I now know which reports to follow.
| toofastforyahuh wrote: |
<somewhat offtopic> Regarding outtay's aforementioned shutdown/reboot button functionality, I first encountered it in May during the 23.0 profile transition and required emerge -e world, which I attempted to shortcut with getbinpg. Recompiling elogind from source (instead of getbinpkg) fixed it at that time. I wasn't sure why the binary was different.
I ran into similar problems in June (on LXDE) and these were indeed caused by the new polkit/124-r1 regardless of source or binary. I'm sticking with polkit/123 for now.
https://bugs.gentoo.org/934314
</somewhat offtopic>
|
Thank you for that as well. I was confused as I distinctly recall having tested it, but now it didn't work anymore at all no matter what I did. Downgrading, however, did work so thank you for solving my off-topic problem as well. |
|
| Back to top |
|
|
|
Portage & Programming
