Re: [gentoo-dev] Packages up for grabs
On Fri, Nov 14, 2014 at 4:16 AM, Tom Wijsman tom...@gentoo.org wrote: dev-python/markups A wrapper around various text markups The python team can take this one. Cheers, Dirkjan
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/14 21:38, Michael Palimaka wrote: On 14/11/14 11:06, Rich Freeman wrote: On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka kensing...@gentoo.org wrote: Ditching implicit dependencies is an interesting idea but not practical. Nobody wants to the laundry list, and there's little benefit in maintaining a virtual/system clone of @system. Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Naively implemented, this would break my uclibc and musl builds which do exactly that. However, you could build in logic, like `if use elibc_uclibc; then`, or DEPEND=elibc_uclibc? ( ... ) etc. I get the benefits of this approach, but I'm happy enough with the status quo that I'm not in favor of the extra work. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/14 23:15, Zac Medico wrote: On 11/13/2014 08:01 PM, Rich Freeman wrote: On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. Maybe I'm missing something, but if you are using virtuals, then you can make the deps conditional on profile forced/masked flags like userland_BSD and userland_GNU if necessary. These behave like normal USE flags, aside from the fact the they are forced or masked by profiles. Sorry Zac, I posted my reply before I read this. This is essentially the point I was making. However, I think this will be cumbersome. With the current way we do things, its easy to delete packages from @system by just doing '-*sys-apps/man-pages' (for example) in a profile's packages file. It is not so easy to delete from a DEPEND string, so I foresee some tricky if logic here. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: Implicit system dependency
On Fri, Nov 14, 2014 at 7:20 AM, Anthony G. Basile bluen...@gentoo.org wrote: Sorry Zac, I posted my reply before I read this. This is essentially the point I was making. However, I think this will be cumbersome. With the current way we do things, its easy to delete packages from @system by just doing '-*sys-apps/man-pages' (for example) in a profile's packages file. It is not so easy to delete from a DEPEND string, so I foresee some tricky if logic here. Appreciating that we're on a slight tangent, why are these packages typically removed? Were they ever truly dependencies? I can't imagine too many packages breaking if man-pages isn't present. If we went the virtual route I would suggest that we end up having a few meta-virtuals. There would be the lazy dependency virtual that pulls in stuff like gcc/libc/posix/etc. There would be a virtual that pulls in useful-to-user stuff like ssh/man-pages/etc. Then there would be a virtual that pulls in both of the other virtuals. Ebuilds would only pull in the dependency virtual. I agree that this would involve a fair bit of work, though I imagine it could be done without any changes to portage insofar as testing things out goes (just create a virtual, stick it in @system in a profile, and test away). -- Rich
[gentoo-dev] Deps on slotted executables (implicit @system tangent)
On 11/13/2014 10:17 AM, Ian Stakenvicius wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is.. but unfortunately there's no way in DEPEND to ensure it's satisfied, as you can have a gcc installed with that flag enabled but have a second one (that's actually selected in gcc-config) with it disabled. A pkg_pretend check or a pkg_setup check (if you don't want it to just fail in src_configure) is probably the best way to enforce that one at this time. Unless there are other ways I'm not aware of?? Is this a case (as was recently suggested) where we're doing something stupid rather than asking for help from the PMS? This problem shows up in a few places -- off the top of my head: * GCC (see sys-apps/systemd-217.ebuild) * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild) * Python (all over the place) * Ruby (all over the place) Since all of the above are slotted, we can DEPEND on them, but we can't actually be sure that we're using the right slot at build time. The package manager knows that the right version is there, but it's not at the moment prepared to find and use it. Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? At first I thought the PM should respect my selected compiler, but after thinking about it for a few minutes, I've changed my mind. The compiler deps are just like anything else: if I ask portage to install systemd, it should do what it takes to install systemd assuming I approve the build plan. Question2: Is it technically possible to fix this in a new EAPI? I have no idea.
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/2014 01:13 PM, Mike Gilbert wrote: On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? Under the assumption that gcc[cxx] is needed for the package manager, you still only need *one* GCC with C++ support. You could have another slot without C++ for testing or whatever.
Re: [gentoo-dev] Re: Implicit system dependency
Hi, On Fri, 14 Nov 2014 07:20:50 -0500 Anthony G. Basile wrote: On 11/13/14 23:15, Zac Medico wrote: On 11/13/2014 08:01 PM, Rich Freeman wrote: On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. Maybe I'm missing something, but if you are using virtuals, then you can make the deps conditional on profile forced/masked flags like userland_BSD and userland_GNU if necessary. These behave like normal USE flags, aside from the fact the they are forced or masked by profiles. Sorry Zac, I posted my reply before I read this. This is essentially the point I was making. However, I think this will be cumbersome. With the current way we do things, its easy to delete packages from @system by just doing '-*sys-apps/man-pages' (for example) in a profile's packages file. It is not so easy to delete from a DEPEND string, so I foresee some tricky if logic here. There is another drawback of using virtuals instead of @system set. For old systems (in practical terms they are systems not updated @world for more than several month) it is wise to update kernel, @system and only afterwards whole @world. Virtuals will not catch updates in underlying packages if --deep is not used and it can't be used, because some packages from @system may indirectly depend on packages from @world (e.g. cairo, qt or xorg) which will trigger half of the @world update with -D @system which makes it impossible and impractical to use -D @system before full @world update on old setups. We already have this problem with virtua/libc: it is not updated at all, so when I run emerge -uav @system for the purposes described above I have to manually add sys-devel/glibc to the list. If @system will be removed at all, it will be much harder to perform deep and large @world updates. Practically users willing to update old systems will have to write and manage @system set on their own. Best regards, Andrew Savchenko pgpgeWoMmmyh5.pgp Description: PGP signature
Re: [gentoo-dev] Re: Implicit system dependency
On Fri, 14 Nov 2014 09:10:43 -0500 Michael Orlitzky wrote: On 11/13/2014 01:13 PM, Mike Gilbert wrote: On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? Under the assumption that gcc[cxx] is needed for the package manager, you still only need *one* GCC with C++ support. You could have another slot without C++ for testing or whatever. Seconded. Simple practical example (aside from testing) from my system: I need libg2c.so for old crappy fortran software I have to use. That's why I'm keeping sys-devel:3.4[fortran nls] around. I definitely do not need cxx flag here. Best regards, Andrew Savchenko pgp05NnkhPAyB.pgp Description: PGP signature
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
Hi, On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote: On 11/13/2014 10:17 AM, Ian Stakenvicius wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is.. but unfortunately there's no way in DEPEND to ensure it's satisfied, as you can have a gcc installed with that flag enabled but have a second one (that's actually selected in gcc-config) with it disabled. A pkg_pretend check or a pkg_setup check (if you don't want it to just fail in src_configure) is probably the best way to enforce that one at this time. Unless there are other ways I'm not aware of?? Is this a case (as was recently suggested) where we're doing something stupid rather than asking for help from the PMS? This problem shows up in a few places -- off the top of my head: * GCC (see sys-apps/systemd-217.ebuild) * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild) * Python (all over the place) * Ruby (all over the place) Since all of the above are slotted, we can DEPEND on them, but we can't actually be sure that we're using the right slot at build time. The package manager knows that the right version is there, but it's not at the moment prepared to find and use it. Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This is definitely a good idea. Some packages are picky about gcc versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the latest available gcc version by one. By the way we have another problem here: packages using cuda build-time must require the same version of compiler as nvidia-cuda-toolkit, or build will fail (app-crypt/johntheripper [cuda] is a good example). Probably cuda eclass should be updated to reflecth this change as well. ATM I workaround issue with switching compilers to and from during emerge run using app-portage/gcc-switcher from stuff overlay. Best regards, Andrew Savchenko pgpQr6aOmEd60.pgp Description: PGP signature
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
Dnia 2014-11-14, o godz. 09:08:17 Michael Orlitzky m...@gentoo.org napisał(a): On 11/13/2014 10:17 AM, Ian Stakenvicius wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is.. but unfortunately there's no way in DEPEND to ensure it's satisfied, as you can have a gcc installed with that flag enabled but have a second one (that's actually selected in gcc-config) with it disabled. A pkg_pretend check or a pkg_setup check (if you don't want it to just fail in src_configure) is probably the best way to enforce that one at this time. Unless there are other ways I'm not aware of?? Is this a case (as was recently suggested) where we're doing something stupid rather than asking for help from the PMS? This problem shows up in a few places -- off the top of my head: * GCC (see sys-apps/systemd-217.ebuild) * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild) * Python (all over the place) * Ruby (all over the place) Since all of the above are slotted, we can DEPEND on them, but we can't actually be sure that we're using the right slot at build time. The package manager knows that the right version is there, but it's not at the moment prepared to find and use it. Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? At first I thought the PM should respect my selected compiler, but after thinking about it for a few minutes, I've changed my mind. The compiler deps are just like anything else: if I ask portage to install systemd, it should do what it takes to install systemd assuming I approve the build plan. Relying on stuff that can be switched outside the PM scope is always a bad idea. Think of eselect-opengl -- for a long time, people had to switch the OpenGL implementation to xorg to build xorg server, and then back to be able to use anything using OpenGL. Then we fixed xorg-server to use the underlying headers directly. I think we should use the same solution for the gcc issues. We already expect packages to respect CC CXX -- why not set them then? I'm keeping my CC CXX at a specific gcc version for a long time now. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko: Hi, On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This is definitely a good idea. Some packages are picky about gcc versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the latest available gcc version by one. E.g. cmake may fail to run correctly if it is built with a newer compiler than the one currently selected. Or so I remember from a bug some time ago. This is a recipe for major trouble. -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/11/14 10:50 AM, Andreas K. Huettel wrote: Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko: Hi, On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This is definitely a good idea. Some packages are picky about gcc versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the latest available gcc version by one. E.g. cmake may fail to run correctly if it is built with a newer compiler than the one currently selected. Or so I remember from a bug some time ago. This is a recipe for major trouble. It used to be that after a gcc upgrade people were expected to 'emerge - -e @world' to make sure everything would work properly by being rebuilt for the new version. It's always a possibility that we need to go back to that type of policy for a particular subset of the tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRmO2IACgkQ2ugaI38ACPBueAD/StqbdxmsPwbDmSgczVGwLThj mISg96OlEm8TktUONP4A/AnJm0cV7+APPM97YbCg24qC+7Hz4JtSBZnkEUMDghHS =GfSI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Implicit system dependency
On 11/14/2014 06:14 AM, Andrew Savchenko wrote: Hi, On Fri, 14 Nov 2014 07:20:50 -0500 Anthony G. Basile wrote: On 11/13/14 23:15, Zac Medico wrote: On 11/13/2014 08:01 PM, Rich Freeman wrote: On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. Maybe I'm missing something, but if you are using virtuals, then you can make the deps conditional on profile forced/masked flags like userland_BSD and userland_GNU if necessary. These behave like normal USE flags, aside from the fact the they are forced or masked by profiles. Sorry Zac, I posted my reply before I read this. This is essentially the point I was making. However, I think this will be cumbersome. With the current way we do things, its easy to delete packages from @system by just doing '-*sys-apps/man-pages' (for example) in a profile's packages file. It is not so easy to delete from a DEPEND string, so I foresee some tricky if logic here. There is another drawback of using virtuals instead of @system set. For old systems (in practical terms they are systems not updated @world for more than several month) it is wise to update kernel, @system and only afterwards whole @world. Virtuals will not catch updates in underlying packages if --deep is not used and it can't be used, because some packages from @system may indirectly depend on packages from @world (e.g. cairo, qt or xorg) which will trigger half of the @world update with -D @system which makes it impossible and impractical to use -D @system before full @world update on old setups. We already have this problem with virtua/libc: it is not updated at all, so when I run emerge -uav @system for the purposes described above I have to manually add sys-devel/glibc to the list. There was a time long ago when portage actually behaved the way you want here. I implemented the behavior myself, but then I changed it to the way it is now because others complained that virtuals should behave just like normal packages. We could certainly add an emerge option which would trigger the behavior that you want. -- Thanks, Zac
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
On Fri, 14 Nov 2014 16:50:24 +0100 Andreas K. Huettel wrote: Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko: On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This is definitely a good idea. Some packages are picky about gcc versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the latest available gcc version by one. E.g. cmake may fail to run correctly if it is built with a newer compiler than the one currently selected. Or so I remember from a bug some time ago. There are packages (or more precisely combinations of packages and use flags) for which there is no other way to build them. They need older gcc and they build fine with it. So the question is whether users will struggle themselves or PMS will support this in a friendly way. Please note, I'm not talking about gcc dynamic version switch for each package in portage. Only small number of them needs this and if some of this little set will experience gcc-downgrade related bug (e.g. cmake bug mentioned above), IMHO this should be handled separately. Best regards, Andrew Savchenko pgpw4cmsj8noW.pgp Description: PGP signature
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
On 11/14/2014 06:58 AM, Michał Górny wrote: Dnia 2014-11-14, o godz. 09:08:17 Michael Orlitzky m...@gentoo.org napisał(a): On 11/13/2014 10:17 AM, Ian Stakenvicius wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is.. but unfortunately there's no way in DEPEND to ensure it's satisfied, as you can have a gcc installed with that flag enabled but have a second one (that's actually selected in gcc-config) with it disabled. A pkg_pretend check or a pkg_setup check (if you don't want it to just fail in src_configure) is probably the best way to enforce that one at this time. Unless there are other ways I'm not aware of?? Is this a case (as was recently suggested) where we're doing something stupid rather than asking for help from the PMS? This problem shows up in a few places -- off the top of my head: * GCC (see sys-apps/systemd-217.ebuild) * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild) * Python (all over the place) * Ruby (all over the place) Since all of the above are slotted, we can DEPEND on them, but we can't actually be sure that we're using the right slot at build time. The package manager knows that the right version is there, but it's not at the moment prepared to find and use it. Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? At first I thought the PM should respect my selected compiler, but after thinking about it for a few minutes, I've changed my mind. The compiler deps are just like anything else: if I ask portage to install systemd, it should do what it takes to install systemd assuming I approve the build plan. Relying on stuff that can be switched outside the PM scope is always a bad idea. Think of eselect-opengl -- for a long time, people had to switch the OpenGL implementation to xorg to build xorg server, and then back to be able to use anything using OpenGL. Then we fixed xorg-server to use the underlying headers directly. Yeah, having ebuilds switch the global compiler configuration would be completely insane. If they need to select a different local compiler via a mechanism like CC and CXX, as you suggest below, then that's fine. I think we should use the same solution for the gcc issues. We already expect packages to respect CC CXX -- why not set them then? I'm keeping my CC CXX at a specific gcc version for a long time now. -- Thanks, Zac
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky m...@gentoo.org wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This will horrifically break things like Portage's parallel build... Note that on every distribution except Gentoo, there are no problems with running multiple versions of gcc simultaneously. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dropping GCC maintainership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/17/2014 09:43 PM, Anthony G. Basile wrote: On 10/17/14 14:55, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/07/2014 01:00 AM, Patrick McLean wrote: On Mon, 06 Oct 2014 19:25:53 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 10/06/14 13:13, Markos Chandras wrote: Let's face it, this is not a job just anyone can do. I asked a few people I thought could handle it and they said they're too busy. So I'm a bit worried. If someone with the appropriate skills is interested, but currently has no time. We have some open positions at my employer where Gentoo work is part of the job. Work locations are available in Orange County, CA/USA, San Mateo, CA/USA and Berlin, Germany. Contact me off-list if you are interested. Well I think this haven't been addressed yet (or has it?). Shall we start a discussion about this problem since Gentoo is not really functional without an active GCC maintainer. I'm trying to clear blockers to gcc-4.8 and then I'll start working on 4.9. I'm going to formally ask to be part of the toolchain/gcc-porting team and I'll try to help, but this does take lots of skill. Perhaps it makes sense to write something here as well? https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF7BAEBCgBmBQJUZlDCXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZpvYH9iVzRPgJuEHHt4oZ9wBibawP N8x5Dillzd8K1Ypq8RNvNEhlT1uPUQE/RDcKxH6mTvbpxTJwNy6F7MSxkjDU56F9 YRAyXppPdKecHBvi1F5qyrfV2s9idmSWGLCAhhwjvYSo5NbikYdsWW8syVuKg+Wx vMMhnkP4MuFPSFexI/5s7rB6JAtXhNsMsmNNV1SlIkgKBpLPQjx3jWAaEA/Brmrd nkmFzWEJy1oOg0MmUI9XXDG9DfLO7JEKGpZGlHp2lD464W0QWoZWCJa9w84Kawu4 jKFLRoXRp1e0DxUlZV0tpvBVNux9FxJ29ZVaL+5Lqxrw4C8Go0ZWisaanBKwjg== =i7bP -END PGP SIGNATURE-
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
On Fri, Nov 14, 2014 at 1:22 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky m...@gentoo.org wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This will horrifically break things like Portage's parallel build... Note that on every distribution except Gentoo, there are no problems with running multiple versions of gcc simultaneously. Not really an apples to apples. If you exclusively use binary packages I suspect that you won't run into any of these problems on Gentoo either. However, the right way to do this isn't to toggle some global setting - it is to just apply specific settings when building specific packages. -- Rich
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
On Fri, 14 Nov 2014 14:17:12 -0500 Rich Freeman ri...@gentoo.org wrote: On Fri, Nov 14, 2014 at 1:22 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky m...@gentoo.org wrote: Question 1: is it desirable to e.g. switch compilers, compile systemd, and then switch back? This will horrifically break things like Portage's parallel build... Note that on every distribution except Gentoo, there are no problems with running multiple versions of gcc simultaneously. Not really an apples to apples. If you exclusively use binary packages I suspect that you won't run into any of these problems on Gentoo either. It *also* isn't an issue on any other source based distribution. This is entirely down to Gentoo libstdc++ silliness. However, the right way to do this isn't to toggle some global setting - it is to just apply specific settings when building specific packages. Which doesn't work properly on Gentoo due to the weird way libstdc++ is handled. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Implicit system dependency
On Fri, 14 Nov 2014 10:03:27 -0800 Zac Medico wrote: [...] Sorry Zac, I posted my reply before I read this. This is essentially the point I was making. However, I think this will be cumbersome. With the current way we do things, its easy to delete packages from @system by just doing '-*sys-apps/man-pages' (for example) in a profile's packages file. It is not so easy to delete from a DEPEND string, so I foresee some tricky if logic here. There is another drawback of using virtuals instead of @system set. For old systems (in practical terms they are systems not updated @world for more than several month) it is wise to update kernel, @system and only afterwards whole @world. Virtuals will not catch updates in underlying packages if --deep is not used and it can't be used, because some packages from @system may indirectly depend on packages from @world (e.g. cairo, qt or xorg) which will trigger half of the @world update with -D @system which makes it impossible and impractical to use -D @system before full @world update on old setups. We already have this problem with virtua/libc: it is not updated at all, so when I run emerge -uav @system for the purposes described above I have to manually add sys-devel/glibc to the list. There was a time long ago when portage actually behaved the way you want here. I implemented the behavior myself, but then I changed it to the way it is now because others complained that virtuals should behave just like normal packages. We could certainly add an emerge option which would trigger the behavior that you want. If this switch will be available, it would be great! And in such case I don't mind for system-virtual switch for my profiles. Moreover it would be great to have this switch even now to avoid glibc not updated with @system issues. Best regards, Andrew Savchenko pgpgbNSP_qIsH.pgp Description: PGP signature
Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)
El vie, 14-11-2014 a las 19:23 +, Ciaran McCreesh escribió: [...] It *also* isn't an issue on any other source based distribution. This is entirely down to Gentoo libstdc++ silliness. However, the right way to do this isn't to toggle some global setting - it is to just apply specific settings when building specific packages. Which doesn't work properly on Gentoo due to the weird way libstdc++ is handled. Not sure if you could point to some link or bug... or a longer explanation about that silliness for people like me that are not aware of that problem. Thanks :)
Re: [gentoo-dev] Re: Implicit system dependency
On Thu, Nov 13, 2014 at 5:10 PM, Alexander Hof gentoo...@cosmofox.net wrote: Mike Gilbert wrote: On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? There are people that don't want c++ and gcc:4.7 can still bootstrap without. Those people know what they are doing and could un-force the use flag. That would prevent people from accidentally disabling it via USE=-*. I'm not normally one to prevent people from shooting themselves, but in this case the safety would be simple to toggle.
Re: [gentoo-dev] Re: Implicit system dependency
Mike Gilbert wrote: There are people that don't want c++ and gcc:4.7 can still bootstrap without. Those people know what they are doing and could un-force the use flag. That would prevent people from accidentally disabling it via USE=-*. Are we talking about forcing +cxx globally or for gcc (+toolchain)? Has this been a major problem in the past? Shouldn't people who set USE=-* also know what they are doing? I'm not normally one to prevent people from shooting themselves, but in this case the safety would be simple to toggle. What if there was some other reason someone had to set a +cxx for some package in package.use.force, and I'm missing out that reason with my -cxx in profiles/package.use.force that I need to circumvent your safety-measure?
Re: [gentoo-dev] Re: Implicit system dependency
On 11/14/2014 11:42 PM, Alexander Hof wrote: Mike Gilbert wrote: There are people that don't want c++ and gcc:4.7 can still bootstrap without. Those people know what they are doing and could un-force the use flag. That would prevent people from accidentally disabling it via USE=-*. Are we talking about forcing +cxx globally or for gcc (+toolchain)? Has this been a major problem in the past? Shouldn't people who set USE=-* also know what they are doing? * don't ever assume that the user knows what he is doing * still allow him to break things if he really chooses to * don't make excuses for gentoo bugs like not properly checking the toolchain for validity, including necessary package dependencies/requirements
Re: [gentoo-dev] Re: Implicit system dependency
hasufell wrote: Are we talking about forcing +cxx globally or for gcc (+toolchain)? Has this been a major problem in the past? Shouldn't people who set USE=-* also know what they are doing? * don't ever assume that the user knows what he is doing * still allow him to break things if he really chooses to * don't make excuses for gentoo bugs like not properly checking the toolchain for validity, including necessary package dependencies/requirements +1, that's what I wanted to express.
[gentoo-dev] Re: Implicit system dependency
Mike Gilbert posted on Fri, 14 Nov 2014 15:55:10 -0500 as excerpted: On Thu, Nov 13, 2014 at 5:10 PM, Alexander Hof gentoo...@cosmofox.net wrote: Mike Gilbert wrote: On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? There are people that don't want c++ and gcc:4.7 can still bootstrap without. Those people know what they are doing and could un-force the use flag. That would prevent people from accidentally disabling it via USE=-*. I'm not normally one to prevent people from shooting themselves, but in this case the safety would be simple to toggle. The problem is the precedent that sets. (Package.)use.force is the equivalent of going nuke and IMO it should be kept that way. ^^ TL;DR ^^ Overriding use.force (package or otherwise) should be clearly no-man's- land, something done only for stuff like cross-compiling, etc, so far out of gentoo support that normally nobody sane would ask for it under those conditions, and if they did, they'd clearly mention the conditions and explain why they thought the override was necessary and didn't affect whatever bug they were seeing. Use.forcing something isn't even /close/ to default-use, which can be and is routinely overridden by people (including me) who know what they are doing with USE=-*, and as soon as use.forcing something, and then overriding it, becomes normal and routine, then we'll need a really force option to override use.force, much like use.force was the really force option to override use-defaults. So I'd suggest (package.)use.forcing isn't appropriate with c++, because there /are/ legitimate reasons to unset it, as already discussed, and as soon as people start having to do that with the one flag, nobody user or dev in gentoo is going to be able to assume (package.)use.force isn't routinely overridden ever again. Again, then we'll need a (package.)use.force.really option, and the race will be on to (package.)use.force.yes.I.really.really.really.really.mean.it! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Packages up for grabs
i'm interested on sys-apps/epoch, if no one takes it On Fri, Nov 14, 2014 at 12:16 PM, Tom Wijsman tom...@gentoo.org wrote: Hello all Due to lack of time I'm giving up some packages. Feel free to take them: app-admin/ec2-ami-tools app-admin/ec2-api-tools These command-line tools serve as the client interface to the Amazon EC2 web service app-admin/logmon Split-screen terminal/ncurses based log viewer app-admin/usermin A web-based user administration interface app-admin/yaala Yet Another Log Analyzer app-editors/retext A Qt-based text editor for Markdown and reStructuredText app-misc/fslint A utility to find various forms of lint on a filesystem app-text/logmerge Merge multiple logs such that multilined entries appear in chronological order without breaks dev-games/aseprite Animated sprite editor and pixel art tool dev-python/markups A wrapper around various text markups dev-util/cdiff Colored, side-by-side diff terminal viewer dev-util/oprofile A transparent low-overhead system-wide profiler media-libs/libmkv Lightweight Matroska muxer written for HandBrake media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin TeamSpeak Client / Server (Voice Communication Software) media-video/openshot Free, open-source, non-linear video editor to create and edit videos and movies sys-apps/epoch An init system (analogous to systemd or upstart) for Linux by Subsentient; it is intended as a lightweight solution for lightweight distributions that don't want a huge mess just to boot up; it has one unified configuration file, is very small in size, and it has no external dependencies besides glibc or similar; installing a shell for /bin/sh is strongly recommended sys-process/ftop Monitor open files and filesystems www-misc/monitorix A lightweight system monitoring tool x11-misc/growl-for-linux A Linux-compatible version of Growl, a notification system for Mac OS X Thanks, Tom Wijsman -- アリス フェッラッシィ Alice Ferrazzi Gentoo, If it moves, compile it! My_overlay: https://github.com/aliceinwire/overlay Gentoo Euscan: http://goo.gl/JUVyTN Mail: Alice Ferrazzi alice.ferra...@gmail.com PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 15:01, Rich Freeman wrote: On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. The only perfect solution is explicit dependencies across the board. If we want to be lazy and not have to list 50 deps for hello world, then the package manager isn't going to know whether hello world actually works on every arch/profile/etc. Maybe the better solution is some kind of automation around (R)DEPEND. In any case, I agree that it is a bit beyond the original scope of this. Maybe some dependencies (within reason) should always be listed, for example when there's linkage eg. to libbzip2 or liblzma. That would make it easy to find consumers eg. if an alternate implementation appeared, and already appears to be a common practice. The problem is that if it isn't 100% then it isn't all that great a solution. It also isn't really necessary unless you want to remove a package from the system set. If an alternative implementation appears, then you create a virtual, place that virtual in the system set, and all the packages in the tree remain happy to use whatever implementation the user has installed without the risk of it getting depcleaned. In the past when we've considered removing a package from @system there is usually a thread on -dev, and if there is a general sense that we want to move forward then the announcement goes out for everybody to check their packages and add an explicit dependency if needed (often with tinderbox runs and the like). Then after a delay the package is removed from @system and maintainers get to deal with anything they missed. I don't have a problem with devs listing dependencies anytime they're real and they feel it makes sense to do so. I wouldn't make a push to have them go out of their way to do it for any particular package unless we are actively looking to remove it from @system, or there is some other driver. Slot operator deps would be the one case where I would try to push on maintainers to list deps. And I do apologize for piling on a bit - trying to get rid of @system has been one of my soap box issues for a while. It really seems like an ugly, if practical, solution. I think the proposed text in my previous reply is an improvement on the current text. It certainly doesn't attempt to solve the problem of implicit dependencies 100%, but I don't think that's a good reason to avoid improvement. The new text doesn't change the status quo at all. It just attempts to clarify that: * It's up to the developer if they wish to include a system dependency or not (ie. it's not frowned upon, which was the issue raised in the original bug) * It's recommended (but not required) to depend upon a system dependency if it's linked against (this is already common practice and there seems to be support for requiring it, but I don't want to get too controversial :-)
Re: [gentoo-portage-dev] [PATCH] fs_template._ensure_dirs: handle EEXIST (529120)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 LGTM. Go ahead merge. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRlwSAACgkQRtClrXBQc7We7AD+Mu0N+qkL+KDjmVgFa/AZ4VX4 +D2pxqPMHwzAmdqjZ2EBAIMAsk1GFRRo6OvPWKmv/fJv9QATCA6e8ZZMcs/wZrjs =K/rk -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] portageq: fix eroot parameter (bug #529200)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/11/14 08:42, Zac Medico wrote: + eprefix = os.environ.get(EPREFIX, portage.const.EPREFIX) + if eprefix: + eprefix = portage.util.normalize_path(eprefix) Why not just: eprefix = os.environ.get(EPREFIX, portage.const.EPREFIX) and \ portage.util.normalize_path(eprefix) ? I don't care *that* much. Patch looks good otherwise, so go ahead merge, with or without my proposed change. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRlw/gACgkQRtClrXBQc7VfNgEAlDyhLlgp8kagXSfFbLyQFjWS RsE7bGdLkulDbOO4oR4BAIuKxwFKx7yUkregTqiyS7aNX7jdQcY3YhOAdcHte0Cw =7o+I -END PGP SIGNATURE-
[gentoo-portage-dev] Binpackages
Hi all, i think the answer is you can't but i wan to try :) . I setup a builder ( FEATURES=buildpkg ) server to deploy bin packages for other servers ( FEATURES=getbinpkg ) ? For example: mail-mta/postfix with USE=mysql mail-mta/postfix without mysql Sometimes can be useful to have a binpackage with different use flags to deploy to different servers without have two binhosts repository or more. Is it possible to have this situation ? Thanks Marco
Re: [gentoo-portage-dev] Binpackages
On 11/14/2014 05:29 AM, ma...@nucleus.it wrote: Hi all, i think the answer is you can't but i wan to try :) . I setup a builder ( FEATURES=buildpkg ) server to deploy bin packages for other servers ( FEATURES=getbinpkg ) ? For example: mail-mta/postfix with USE=mysql mail-mta/postfix without mysql Sometimes can be useful to have a binpackage with different use flags to deploy to different servers without have two binhosts repository or more. Is it possible to have this situation ? Thanks Marco At this point, no :( -- -- Matthew Thode (prometheanfire)
Re: [gentoo-portage-dev] [PATCH] portageq: fix eroot parameter (bug #529200)
On 11/14/2014 12:57 AM, Alexander Berntsen wrote: On 14/11/14 08:42, Zac Medico wrote: +eprefix = os.environ.get(EPREFIX, portage.const.EPREFIX) +if eprefix: +eprefix = portage.util.normalize_path(eprefix) Why not just: eprefix = os.environ.get(EPREFIX, portage.const.EPREFIX) and \ portage.util.normalize_path(eprefix) ? That won't work, because you can't reference eprefix on the right hand side of the assignment, and the whole right hand side must evaluate before the eprefix reference is initialized. I don't care *that* much. Patch looks good otherwise, so go ahead merge, with or without my proposed change. Merged, thanks. -- Thanks, Zac
Re: [gentoo-portage-dev] Binpackages
On 11/14/2014 03:29 AM, ma...@nucleus.it wrote: Hi all, i think the answer is you can't but i wan to try :) . I setup a builder ( FEATURES=buildpkg ) server to deploy bin packages for other servers ( FEATURES=getbinpkg ) ? For example: mail-mta/postfix with USE=mysql mail-mta/postfix without mysql Sometimes can be useful to have a binpackage with different use flags to deploy to different servers without have two binhosts repository or more. Is it possible to have this situation ? Thanks Marco We have a feature request bug filed for that here: https://bugs.gentoo.org/show_bug.cgi?id=150031 -- Thanks, Zac
[gentoo-portage-dev] [PATCH v2] NewsManager.getUnreadItems: handle EROFS (490732)
When getUnreadItems tries to lock the news.unread file, it's safe to ignore EROFS. This is handled with a ReadOnlyFileSystem exception raised from the portage.locks.lockfile function. X-Gentoo-Bug: 490732 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=490732 --- This updated patch fixes the typo spotted by Brian Dolbec. pym/portage/exception.py | 1 + pym/portage/locks.py | 7 ++- pym/portage/news.py | 7 --- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/pym/portage/exception.py b/pym/portage/exception.py index ef62e7a..857a727 100644 --- a/pym/portage/exception.py +++ b/pym/portage/exception.py @@ -133,6 +133,7 @@ class AlarmSignal(TimeoutException): class ReadOnlyFileSystem(PortageException): Read-only file system + from errno import EROFS as errno class CommandNotFound(PortageException): A required binary was not available or executable diff --git a/pym/portage/locks.py b/pym/portage/locks.py index 0789f89..0b0f74b 100644 --- a/pym/portage/locks.py +++ b/pym/portage/locks.py @@ -16,7 +16,8 @@ import warnings import portage from portage import os, _encodings, _unicode_decode from portage.exception import DirectoryNotFound, FileNotFound, \ - InvalidData, TryAgain, OperationNotPermitted, PermissionDenied + InvalidData, TryAgain, OperationNotPermitted, PermissionDenied, \ + ReadOnlyFileSystem from portage.util import writemsg from portage.localization import _ @@ -110,6 +111,8 @@ def lockfile(mypath, wantnewlockfile=0, unlinkfile=0, raise OperationNotPermitted(func_call) elif e.errno == PermissionDenied.errno: raise PermissionDenied(func_call) + elif e.errno == ReadOnlyFileSystem.errno: + raise ReadOnlyFileSystem(func_call) else: raise @@ -404,6 +407,8 @@ def hardlink_lockfile(lockfilename, max_wait=DeprecationWarning, raise OperationNotPermitted(func_call) elif e.errno == PermissionDenied.errno: raise PermissionDenied(func_call) + elif e.errno == ReadOnlyFileSystem.errno: + raise ReadOnlyFileSystem(func_call) else: raise else: diff --git a/pym/portage/news.py b/pym/portage/news.py index 0d72b00..d90d97a 100644 --- a/pym/portage/news.py +++ b/pym/portage/news.py @@ -1,5 +1,5 @@ # portage: news management code -# Copyright 2006-2013 Gentoo Foundation +# Copyright 2006-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 from __future__ import print_function, unicode_literals @@ -28,7 +28,7 @@ from portage.localization import _ from portage.locks import lockfile, unlockfile from portage.output import colorize from portage.exception import InvalidLocation, OperationNotPermitted, \ - PermissionDenied + PermissionDenied, ReadOnlyFileSystem class NewsManager(object): @@ -180,7 +180,8 @@ class NewsManager(object): unread_lock = None try: unread_lock = lockfile(unread_filename, wantnewlockfile=1) - except (InvalidLocation, OperationNotPermitted, PermissionDenied): + except (InvalidLocation, OperationNotPermitted, PermissionDenied, + ReadOnlyFileSystem): pass try: try: -- 2.0.4
Re: [gentoo-portage-dev] [PATCH] unprivileged mode: generate PORTAGE_DEPCACHEDIR
On 11/11/2014 01:14 AM, Alexander Berntsen wrote: On 11/11/14 01:17, Zac Medico wrote: We could certainly express it in a way that doesn't involve any mutating loop control variables, but ultimately that's going to lead to more lines of code, and it will leave imperative programmers wondering why we didn't choose a simpler and more succinct approach. For example, we could create an class for iterating over the paths from a given path down to the root directory. Then we could create a function which selects the first element from that iterator that exists. Once the class and function are implemented, their usage would be very succinct: first_parent = first_existing(iter_parents(path)) I would greatly prefer this. But I suppose I'm in a minority. v2 of the patch is fine by me. Thanks. I eliminated one more backslash, and pushed it. Now I'm thinking about splitting out a first_existing function so that I can use it in portage.data._unprivileged_mode(), to determine if the unprivileged root can be created. Maybe I'll do it with the iterator approach that we've discussed, and we'll see what the consensus is. -- Thanks, Zac
[gentoo-portage-dev] [PATCH] unprivileged mode: use first_existing helper func
Split out a first_existing function, in order to improve logic related
to the _unprivileged_mode function so that it checks whether it's
possible to create the specified target root (instead of requiring that
the target root already exists).
---
pym/portage/data.py | 20 +--
pym/portage/package/ebuild/config.py | 23 ++---
pym/portage/util/path.py | 48
3 files changed, 67 insertions(+), 24 deletions(-)
create mode 100644 pym/portage/util/path.py
diff --git a/pym/portage/data.py b/pym/portage/data.py
index 3e03eef..d9b36ee 100644
--- a/pym/portage/data.py
+++ b/pym/portage/data.py
@@ -8,6 +8,7 @@ import portage
portage.proxy.lazyimport.lazyimport(globals(),
'portage.output:colorize',
'portage.util:writemsg',
+ 'portage.util.path:first_existing',
'subprocess'
)
from portage.localization import _
@@ -94,14 +95,16 @@ def _get_global(k):
else:
# The config class has equivalent code, but we also
need to
# do it here if _disable_legacy_globals() has been
called.
- eroot = os.path.join(os.environ.get('ROOT', os.sep),
- portage.const.EPREFIX.lstrip(os.sep))
+ eroot_or_parent = first_existing(os.path.join(
+ os.environ.get('ROOT', os.sep),
+ portage.const.EPREFIX.lstrip(os.sep)))
try:
- eroot_st = os.stat(eroot)
+ eroot_st = os.stat(eroot_or_parent)
except OSError:
pass
else:
- unprivileged = _unprivileged_mode(eroot,
eroot_st)
+ unprivileged = _unprivileged_mode(
+ eroot_or_parent, eroot_st)
v = 0
if uid == 0:
@@ -206,14 +209,15 @@ def _get_global(k):
else:
# The config class has equivalent code, but we also
need to
# do it here if _disable_legacy_globals() has been
called.
- eroot = os.path.join(os.environ.get('ROOT', os.sep),
- portage.const.EPREFIX.lstrip(os.sep))
+ eroot_or_parent = first_existing(os.path.join(
+ os.environ.get('ROOT', os.sep),
+ portage.const.EPREFIX.lstrip(os.sep)))
try:
- eroot_st = os.stat(eroot)
+ eroot_st = os.stat(eroot_or_parent)
except OSError:
pass
else:
- if _unprivileged_mode(eroot, eroot_st):
+ if _unprivileged_mode(eroot_or_parent,
eroot_st):
if k == '_portage_grpname':
try:
grp_struct =
grp.getgrgid(eroot_st.st_gid)
diff --git a/pym/portage/package/ebuild/config.py
b/pym/portage/package/ebuild/config.py
index c7308a4..bf39487 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -48,6 +48,7 @@ from portage.util import ensure_dirs, getconfig, grabdict, \
grabdict_package, grabfile, grabfile_package, LazyItemsDict, \
normalize_path, shlex_split, stack_dictlist, stack_dicts, stack_lists, \
writemsg, writemsg_level, _eapi_cache
+from portage.util.path import first_existing
from portage.util._path import exists_raise_eaccess, isdir_raise_eaccess
from portage.versions import catpkgsplit, catsplit, cpv_getkey, _pkg_str
@@ -848,14 +849,16 @@ class config(object):
PORTAGE_INST_UID: 0,
}
+ eroot_or_parent = first_existing(eroot)
unprivileged = False
try:
- eroot_st = os.stat(eroot)
+ eroot_st = os.stat(eroot_or_parent)
except OSError:
pass
else:
- if portage.data._unprivileged_mode(eroot,
eroot_st):
+ if portage.data._unprivileged_mode(
+ eroot_or_parent, eroot_st):
unprivileged = True
default_inst_ids[PORTAGE_INST_GID] =
str(eroot_st.st_gid)
@@ -897,20 +900,8 @@ class config(object):
# In unprivileged mode, automatically
make
