Emerge fails to work complains about a bad magic number in emergehelp.pyo sorry I lost the error that came up while I fixed it by rolling back using "ebuild portage-2.1.2_rc1-r2 merge"
*** This bug has been marked as a duplicate of 153891 ***
oops resent previous bug by accident but - something went askew this installed even though my /etc/portage/package.mask file contianed: =sys-apps/portage-2.1.2_rc1-r3 results from the fixes re: bugs 153905 153891 Last night the masking worked as I rolled back to portage-2.1.2_rc1-r2 and it held. the "fixed" version of portage-2.1.2_rc1-r3 ignores the /etc/portage/package.mask file entry for it. Thought you should know.
bug title changed to reflect another issue and fix accidental old submission
Please post the output of `grep -r sys-apps/portage /etc/portage`.
grep -r sys-apps/portage /etc/portage /etc/portage/package.unmask:sys-apps/portage /etc/portage/package.mask:#=sys-apps/portage-2.1.2_rc1-r3 /etc/portage/package.keywords:sys-apps/portage Note I've commented the specific package mask out after the install wnet a head anyways. Does the package.unmask over-rule the specific package.mask? Should it? I do know it's risky to work with "masked packages" but I've been following this one for quite some time with only a few hic-cups such as this .. consider me a freelance guinea pig. Do you recommend any changes to these settings or want me to test variations of them?
(In reply to comment #5) > /etc/portage/package.unmask:sys-apps/portage That single package.umask atom overrides any atoms regarding sys-apps/portage that may be listed in package.mask. I don't like this behavior, but that's the way that it has always been. Personally, I use -atom in package.mask in order to unmask atoms, since that approach does not have the problem that package.unmask creates.
Reopen to change status.
package.unmask works as expected.
