I recently added the FireBurn overlay via layman. Both FireBurn and gentoo contain media-libs/libsdl-1.2.15-r5. I have unmasked 'media-libs/libsdl' and also added ~amd64 as accepted keyword for 'media-libs/libsdl' to the portage config files. When running 'emerge -uDN world' portage wants to install FireBurn's version of the package. When I mask FireBurn's ebuild with 'media-libs/libsdl::FireBurn' and restrict unmasking to 'media-libs/libsdl::gentoo' emerge still wants to rebuild 'media-libs/libsdl-1.2.15-r5::FireBurn'. To really mask this ebuild I need to restrict the ~amd64 keyword to 'media-libs/libsdl::gentoo' Reproducible: Always Steps to Reproduce: 1. layman -a FireBurn 2. echo "media-libs/libsdl::FireBurn" >> /etc/portage/package.mask 3. echo "media-libs/libsdl::gentoo" >> /etc/portage/package.unmask 4. echo "media-libs/libsdl ~amd64" >> /etc/portage/package.accept_keywords 5. emerge media-libs/libsdl Actual Results: emerge wants to (re)build media-libs/libsdl::FireBurn. Expected Results: emerge should rebuild media-libs/libsdl::gentoo.
Created attachment 376140 [details] emerge --info emerge --info is too large. Added as attachment
What happens if you use --autounmask-keep-masks?
Also wants to install the libsdl::FireBurn
(In reply to farmboy0 from comment #0) > I have unmasked 'media-libs/libsdl' and also added ~amd64 as accepted > keyword for 'media-libs/libsdl' to the portage config files. Does this mean you have 'media-libs/libsdl' in p.unmask? If that's the case then this overrids your repo specific masks. (In reply to farmboy0 from comment #3) > Also wants to install the libsdl::FireBurn Is there a "mask change" for message? If not, then the package is not masked. Post the output of grep -r libsdl /etc/portage in this case.
See Step 3
grep -r libsdl /etc/portage /etc/portage/package.unmask:media-libs/libsdl::gentoo /etc/portage/package.accept_keywords:media-libs/libsdl2 ~amd64 /etc/portage/package.accept_keywords:media-libs/libsdl ~amd64 /etc/portage/package.mask:media-libs/libsdl::FireBurn
Are you using wildcard atoms in package.unmask? Please attach the debug.log created by: emerge -pd media-libs/libsdl &> debug.log
Created attachment 376168 [details] my package.unmask
I have also unmasked abi_x86_32 in /etc/portage/profile/use.mask
Created attachment 376174 [details] emerge -pd media-libs/libsdl &> debug.log
(In reply to farmboy0 from comment #10) > Created attachment 376174 [details] > emerge -pd media-libs/libsdl &> debug.log The output shows that emerge knows that the package was masked at some point, but it thinks that it somehow got unmasked. The FireBurn repository contains a profiles/package.unmask file. Please delete or rename it and try again. It shouldn't override your mask, but I'm out of ideas what else could cause the package to be unmasked.
(In reply to Sebastian Luther (few) from comment #11) seems like our debugging output should track config file loads too ? being able to surface that info even in the non-debugging output would be useful to users. i've helped many people trace package.* files to figure out why something is the way it is.
(In reply to SpanKY from comment #12) > (In reply to Sebastian Luther (few) from comment #11) > > seems like our debugging output should track config file loads too ? > > being able to surface that info even in the non-debugging output would be > useful to users. I've helped many people trace package.* files to figure > out why something is the way it is. A possible solution would be to list all config file lines that affect a given package in emerge --info <pkg>. Listing everything with --debug is probably too much spam. I fear that our current system is not up to the task though. It wouldn't be enough to just list what has been read, but you'd also need to trace what happens in the algorithms that merge files from different locations.
(In reply to Sebastian Luther (few) from comment #13) right, i'm thinking something that'd keep track of all the masks/unmasks, and the files (w/linenos) that added those. for bugzilla purposes, simply listing the files it read (even from overlays) would help triaging in the --info output.