El mar, 06-08-2024 a las 13:27 -0400, Mike Gilbert escribió:

On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos <pacho@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

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEE808Ng0g83FMNupoifLEMIH/AfbwFAmcvG+kACgkQfLEMIH/A fbzt+Af/apJxhsDEUrszEgRCYn6sLTR7b8p/8yTndywjo1PszMzdUVYXs5D+r+7w B2J28j05gRTTv3YPZDt6JF5sKaOKcZ5V1FgLDk2KCKmGn1tWxqwrenteBX7JbjN5 0chw8LDtG46bc8Bs83pN3lYAQE4h/RxO5MbWmqlz4caM6+R5Fo882/g+WyMFyKXH ncVUtbv1KrEv5pvAwZ0BxhQoawYiHczpFBXAj+e5PH/zZ9qi1BH81GS9pR/askRP 566TKHF4gtf3DeD6F1c/36xSdO4vTpwxmUcAtGUrN7W2Z/CEUxrB5tXdv7i//liC V1pQVsGFBJxEwagbR1HywgqhYIvWRQ==
=87MF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)