El mar, 06-08-2024 a las 13:27 -0400, Mike Gilbert escribió: > On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos <pa...@gentoo.org> wrote: > > > > Hello, > > > > This is a follow up from an older thread by leio in the mailing > > list: > > https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9 > > > > The problem is that, at present time, we are getting more and more > > bugs > > coming from flatpak users that get build failures due to having > > those > > variables "polluted". > > > > Personally, I would opt for unsetting them too and properly set > > them to > > known values for packages needing it. But I am unsure if we could > > probably do a tinderbox run to find&fix packages needing them to be > > set > > :-/ > > I'm not really familiar with the packages that require these > variables. I agree with the idea in principle though. > > It seems like x11-libs/gtk+ is one example given by leio. How would > we > fix that one? Can the same strategy be applied to similar ebuilds? > > Another possible idea would be to source /etc/profile.env in a > subshell and pick out the relevant XDG variables in > xdg_environment_reset.
Hi! I have locally tried to append XDG_DATA_DIRS & XDG_CONFIG_DIRS to ENV_UNSET and x11-libs/gtk+-3.24.42-r1 looks to compile properly. I would then try to do a tinderbox run with they unset, if few packages are affected, we can set them to their expected values in relevant ebuilds. If there are many, maybe we can try to rely on xdg_environment_reset for more standardization. Regards
signature.asc
Description: This is a digitally signed message part
