Here's a partial emerge log. Full sandbox log to be attached. checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool !!! Please attach the config.log to your bug report: !!! /tmp/portage/shared-mime-info-0.16/work/shared-mime-info-0.16/config.log !!! ERROR: x11-misc/shared-mime-info-0.16 failed. !!! Function econf, Line 806, Exitcode 0 !!! econf failed !!! If you need support, post the topmost build error, NOT this status message. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-x11-misc_-_shared-mime-info-0.16-976.log" Reproducible: Always Steps to Reproduce: emerge shared-mime-info Actual Results: sandbox violation Expected Results: Completed the emerge normally. Any legit out of sandbox access should be specifically allowed. Any not-legit out of sandbox access should be patched out and bugged upstream or reported if necessary. emerge info to be attached. Do note this is on amd64, altho why that would matter for a sandbox error I don't know. Also note that I have the confcache portage patch installed. FEATURES=userpriv (so no sandbox) fails at the same place, so whatever it wants to do must be done by root: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
Created attachment 54511 [details] emerge info output
Created attachment 54512 [details] sandbox violation log
Did you ran the "perl-cleaner" script after updating perl?
From the perl-5.8.6-r4 emerge log: You have changed versions of perl. It is recommended that you run /tmp/portage-pkg/perl-5.8.6-r4/inf/files/perl-cleaner to assist with this transition. This script is capable of cleaning out old .ph files [...] Obviously, it isn't capable of /anything/ when the location is apparently the package temporary dir (I have FEATURES=buildpkg enabled), and therefore erased by the time I read the message and try to act on it. However, I /did/ check the package to see where it put the script, and it wasn't tarred up into the package, so that didn't work, either, and it's possible it never got to the package tempdir in the first place. I hadn't experienced any ill effects from not running the non-existent script, however (until now, anyway), so I didn't worry much about it. The topic did come up on the devel list, which I follow, recently, tho, and I did reply, saying I had been bit by the bug and didn't have the script, either. I didn't see any further followups, however, and again, hadn't experienced any issues until now, so hadn't worried about it. Thanks for the pointer, tho. I guess I'll go digging in the perl ebuild and see where the script comes from, and see about copying it from there manually, to run. I'll follow up after I do so and see if it fixes things, or if I can't figure out where the script is coming from, after checking the ebuild.
OK, looks like the message in the perl ebuild now points to the script as it exists in the portage tree itself. Cool, I can actually run it! <g> It wanted to remerge a couple packages, including the xmlparser, so I let it. After that, as you hinted it would, shared-mime-info merged without a hitch. Thanks, setting resolved, fixed, as the fix was already there in the perl ebuild, I just didn't know about it. So, today I added one more tool to my troubleshooting toolbox, one I can always find in the perl-files dir of the portage tree... Again, thanks!
