In order to let distutils compile installed Python modules, we enable writing bytecode. Sadly, with some broken packages installed it may result in distutils trying to compile bytecode outside of installation root. http://forums.gentoo.org/viewtopic.php?p=7202762#7202762 http://bpaste.net/show/64181/ (grep for DENIED) Possible solutions: 1) withdraw from letting distutils compile installed modules and do it by hand -- reinvent the wheel, 2) use 'addpredict' to safely ignore this kind of compilation. Your thoughts?
I've committed a simple 'addpredict' to avoid more users from hitting this. However, I can't reproduce it to be honest. It may take some random conditions (or Python versions?) to get this issue triggered.
(In reply to Michał Górny from comment #1) > I've committed a simple 'addpredict' to avoid more users from hitting this. > > However, I can't reproduce it to be honest. It may take some random > conditions (or Python versions?) to get this issue triggered. I can reproduce this very easily in a MIPS stage run with catalyst for some reason, on two different SGI machines. It happens when catalyst tried to re-merge portage-2.2.15 in a stage2 build. Haven't found a workaround so far. Previous stage runs I did over the late summer ran flawlessly.
Created attachment 394692 [details] Sandbox violations from MIPS catalyst run Created via a atsage1 -> stage2 attempt.
So this happens with stage1 python? Could you tell me if it has .pyc files around at all?
Well, the long history is, I was having the problem building a stage1 from my stage3 done in August of 2014. That was with catalyst-2.0.17. I tried avoiding an upgrade to 2.0.18 due to some unsubmitted changes for MIPS. But I finally relented, updated, re-applied my changes, and that catalyst built the stage1 just fine on both machines (One machine built o32 stage1, other machine built n32 stage1). Moved onto building stage2, and that's when the problems began (again). I just compiled Python-3.4 in the seed stage3, repacked it on both systems, and am going to try building the stage1 again, using pkgcache as much as possible, then try the stage2 again. IF that stage2 fails, I will blow all caches away and rebuild stage1 completely under the Python-3.4, and see if that has an effect. I did check the old stage1/stage2 build dirs for any *.pyc files, and nothing turns up in stage1, but stage2 has python-2.7 pyc files. No pyc's for Python 3.x. The access violations all appear to happen only on 3.3, so we'll see what 3.4 does.
Same problem using python-3.4, so it's definitely a sandbox problem. MIPS has historically had off-and-on problems with sandbox. I can't find a "proper" way to disable it in catalyst, but I found out how to edit the make.conf inside the chroot before it starts executing portage, and disabled sandbox in FEATURES. That looks to have worked around the bug for now....
(In reply to Michał Górny from comment #4) > So this happens with stage1 python? Could you tell me if it has .pyc files > around at all? You'll be interested to know that I finally got around to finishing the migration of data for one of my SGI machines from old hard drives to new hard drives -- a process which I put off for several months. The install on the drives hasn't been updated since about October of 2014. Upon migrating and booting into it, then attempting to update portage, I triggered the sandbox errors. This isn't catalyst, but a live filesystem. So scan all changes to distutils and python from October till now and that might help pinpoint the problem. Meanwhile, I'll quickpkg python, portage, distutils, and a few other apps as forensics, then I need to disable sandbox, update portage, then update the rest of the machine.
I don't think there's anything to be done here. If anyone has a better idea what to do, feel free to reopen.
