Created attachment 368532 [details] build log for dev-python/prettytable The following failure of portage is absolutely reproducible. I have unmerged and re-emerged sci-visualization/paraview-4.1.0 several times on several machines with 4 versions of portage (2.2.8-r1 and 9999, each with python3 use flag on and off). If and only if sci-visualization/paraview-4.1.0 is installed: (Probably) Many packages from dev-python/ fail to install (verified for dev-python/prettytable and dev-python/sphinx) with a sandbox violation like F: mkdir S: deny P: /usr/lib64/paraview-4.1/site-packages/zope/__pycache__ A: /usr/lib64/paraview-4.1/site-packages/zope/__pycache__ R: /usr/lib64/paraview-4.1/site-packages/zope/__pycache__ C: /usr/bin/python3.3 setup.py install --compile -O2 --root=/var/tmp/portage/dev-python/prettytable-0.7.1-r1/image//_python3.3 --install-scripts=/usr/lib/python-exec/python3.3 I see /usr/lib64/paraview-4.1/site-packages/zope/__pycache__ for prettytable as well as for sphinx (both having no connection to paraview) Even if this is triggered by some bug in paraview, a single package should not be able to damage portage as a whole.
I'd like to stress that if one package is able to cause sandbox violations in several totally unrelated other packages, this has to be considered as a bug of portage itself.
*** Bug 499022 has been marked as a duplicate of this bug. ***
(In reply to Helmut Jarausch from comment #1) > I'd like to stress that if one package is able to cause sandbox violations > in several totally unrelated other packages, this has to be considered as a > bug of > portage itself. Sandbox violations are a safety/security feature and not a bug.
yeah, that's pretty weird
it seems paraview has bundled zope-interface since 4.1.0 the question is why other apps pick up that path. I will look into unbundling, but it still seems fishy
*** Bug 499222 has been marked as a duplicate of this bug. ***
*** Bug 499206 has been marked as a duplicate of this bug. ***
+ 25 Jan 2014; Julian Ospald <hasufell@gentoo.org> package.mask: + hardmask >=sci-visualization/paraview-4.1.0 wrt #499020 until I know more or have time to unbundle zope-interface
(In reply to Julian Ospald (hasufell) from comment #5) > the question is why other apps pick up that path. I will look into > unbundling, but it still seems fishy Yeah, that seems odd. Maybe paraview installs something that messes with sys.path or PYTHONPATH?
Yeah, there it is, plain as day in the ebuild: echo "PYTHONPATH="${EPREFIX}"/usr/${PVLIBDIR}:/usr/${PVLIBDIR}/site-packages" >> "${T}"/40${PN} Adding things to PYTHONPATH like this is probably a bad idea.
(In reply to Mike Gilbert from comment #10) > Yeah, there it is, plain as day in the ebuild: > > echo > "PYTHONPATH="${EPREFIX}"/usr/${PVLIBDIR}:/usr/${PVLIBDIR}/site-packages" >> > "${T}"/40${PN} > > Adding things to PYTHONPATH like this is probably a bad idea. The reason of this bug is that I mistyped a config option that should unbundle all python libraries. I am in progress of fixing that. Paraview installs a lot of it's own modules that are not anywhere else. I can look into moving those python files to the regular site-packages, but it won't be easy to do properly. The build system is really over-complex.
(In reply to Julian Ospald (hasufell) from comment #11) > Paraview installs a lot of it's own modules that are not anywhere else. I > can look into moving those python files to the regular site-packages, but it > won't be easy to do properly. The build system is really over-complex. Right, but is paraview meant to be used a library in other packages? If not, then it would probably be better to create/change any necessary wrapper scripts and do the PYTHONPATH or sys.path manipulation there, rather than setting PYTHONPATH globally.
(In reply to Mike Gilbert from comment #12) > (In reply to Julian Ospald (hasufell) from comment #11) > > Paraview installs a lot of it's own modules that are not anywhere else. I > > can look into moving those python files to the regular site-packages, but it > > won't be easy to do properly. The build system is really over-complex. > > Right, but is paraview meant to be used a library in other packages? > > If not, then it would probably be better to create/change any necessary > wrapper scripts and do the PYTHONPATH or sys.path manipulation there, rather > than setting PYTHONPATH globally. hm, that won't be easy either, but doable another problem is that if we fix up the install paths we might hit file collisions with sci-libs/vtk (which is bundled in paraview... although it's the same upstream... and unbundling will be non-trivial as well) I think I will just fix the current issue for now and then have a look on how to improve this long-term. Would you open a new bug for that?
+*paraview-4.1.0-r1 (25 Jan 2014) + + 25 Jan 2014; Julian Ospald <hasufell@gentoo.org> -paraview-4.1.0.ebuild, + +paraview-4.1.0-r1.ebuild: + fix random sandbox violations wrt #499020
