Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Dnia 2015-01-21, o godz. 12:12:21 Alexis Ballier aball...@gentoo.org napisał(a): On Wed, 21 Jan 2015 11:15:04 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-21, o godz. 11:05:01 Alexis Ballier aball...@gentoo.org napisał(a): 2. Subslots work correctly. Rebuilds are forced when the chosen library is upgraded. Moreover, USE flag change causes a rebuild when user decides to change the ffmpeg provider. No offense, but this argument is complete crap. You should rather fix portage bugs than propose to introduce tree-wide changes to hide them... More precisely: || ( a:= b c:= d ) is perfectly defined (in the what it means sense, not in PMS sense). When the package is built, if 'a' is satisfied then a (and its subslot) is added to the subslot list of the package; ditto for c. You end up with a list of subslot deps, that you can store in vdb or whatever, and use that to decide when to rebuild the package. Following a specification is not a bug. I could argue here a lot but... just implement it. And return to us when you do. We had an item for this for EAPI 6, and it was removed because nobody volunteered to implement it. In fact, nobody even were able to fully specify what it should do... but if you want to discuss that, please start a new thread, possibly at the -pms list. Above is a simple algorithm that works in all cases. What you're asking me to do is go beg pms list to allow something they don't want because the subslot/:= spec was poorly written and thought of. I already gave you the solution, don't count on me for the administrative work :=) (NB: everytime I tried to improve/fix something in pms I failed miserably, so that I have no other choice but giving up on this, check bgo) No, it works in the one case you thought of. Two quick issues: Ok, so first thing: You are the one writing about putting || in effective deps (whatever that means), for me := deps that apply when the package is installed is just a list created when the package is built: no ||, no use conditional, and with subslots instantiated. I'm just describing the current Portage behavior. By 'effective deps' I mean 'what Portage puts in depgraph' when it sees || ( a:= b:= ). 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots. This makes sense only when in DEPEND+RDEPEND (because of the :=), so apply this (mostly copy/paste) for all such deps: for a in 'a' 'b' 'c': When the package is built, if 'a' is satisfied and has a := dep then 'a' and its subslot is added to := deps list for the installed package As for the meaning, it uses all of a, b and c that are available at buildtime and at least one of them must be present. for 'b' and 'c', the := dep description/meaning from pms applies. 2. What does || ( a:= b:= ) mean when a and b can be both installed? Ditto. A fair bit inconsistent but I guess it is the safe solution. Of course, it is ugly for making || () behave completely different from the original meaning when := is used inside. You add subslot, you get completely different behavior. You remove it, you get completely different behavior... Adding a very specific PMS rule for two packages doesn't sound like a very good idea to me. I agree but I don't think it is that specific. Moreover, when I bumped ffmpeg subslot, portage did rebuild all those packages with || ( := := ) deps properly for me. So, you'll have to be a bit more specific on what goes wrong than 'broken || ( libav:= ffmpeg:= )'... I already told you that before. Try switching from ffmpeg to libav, and see what mess it causes. I'll summarize it for you: 1. if you have dynamic-deps enabled, portage will want to install both ffmpeg (because of :=) and libav (because of ||). The effective deps will look like: || ( ffmpeg:0/51= libav ) ffmpeg:0/51= with a separate := deps list, you have 'ffmpeg:0/51=' in the list; you notice ffmpeg subslot has changed from '0/51' to '' (since it is not installed anymore) so trigger the package for rebuild and use the || ( ffmpeg:= libav:= ) dep (which I assume works fine since that's what happens when you install the package). the bug here is that portage uses a crafted (r)depend string for reinstall, instead of the ones from the stock ebuild from either vdb or the portage tree. 2. If you have dynamic-deps disabled, portage will happily switch impl without rebuilding revdeps (breakage). Afterwards, it will allow upgrading the other dep (libav) without rebuilds. The effective deps will look like: || ( ffmpeg:0/51= libav ) this is also solved by having a separate := dep list in vdb It is easy to write others how to do stuff without looking at the code, isn't it? -- Best regards, Michał Górny pgp7seKLVuJap.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Dnia 2015-01-21, o godz. 16:00:55 Alexis Ballier aball...@gentoo.org napisał(a): On Wed, 21 Jan 2015 11:05:34 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. I see two generic approaches possible here: 1. proxying distcc from within the build environment, or 2. moving distcc-spawned processes back to parent's namespace. [...] Any other ideas? I haven't followed this at all, so this might be very stupid: Isn't it possible to whitelist distcc hosts ? No because the child process is completely disconnected from parent's network stack. It has only a brand new loopback that's even separate from host's loopback. -- Best regards, Michał Górny pgp2m3XoDv9ky.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier aball...@gentoo.org wrote: On Wed, 21 Jan 2015 11:05:34 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. I see two generic approaches possible here: 1. proxying distcc from within the build environment, or 2. moving distcc-spawned processes back to parent's namespace. I haven't followed this at all, so this might be very stupid: Isn't it possible to whitelist distcc hosts ? That would only work with a proxy of some kind. A process running in a separate network namespace doesn't see any network interfaces. It can't even get as far as iptables/etc for some kind of filtering. Now, you could define an interface in the new namespace, and then bridge that to the host network, and then apply iptables rules to it. I will second Michael's comment that distcc support shouldn't really be required for making this feature a mainstream one. I'm all for getting distcc working with this, but there is no reason the 98% of Gentoo users who don't use distcc can't benefit from network isolation while we wait to get it working for everybody else. -- Rich
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Dnia 2015-01-21, o godz. 09:40:41 Michael Orlitzky m...@gentoo.org napisał(a): On 01/21/2015 05:05 AM, Michał Górny wrote: Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. ... Any other ideas? We probably won't avoid the fact that some features are incompatible forever. Why not just let the combination be broken? Distcc isn't enabled by default, so having network-sandbox enabled won't immediately cause problems. But *I* want to use both! -- Best regards, Michał Górny pgp_4y9jYT8fr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Things one could be upset about
On Wed, 21 Jan 2015 01:57:27 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Róbert Čerňanský posted on Tue, 20 Jan 2015 06:51:01 +0100 as excerpted: On Mon, 19 Jan 2015 20:51:31 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský ope...@tightmail.com wrote: From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). This is only possible in carefully selected circumstances, and to get it to work more generally would require a lot of hinting from package maintainers. But portage already knows that. It tells the user which USE flags needs to be changed in order to emerge a package. It should just go one step further - to make the proposed change happen by itself. Actually, current portage (2.2.15 is what I have installed here ATM) does exactly that, making changes to the appropriate package.* files as necessary, mediated only by the usual CONFIG_PROTECT variables. No, no, no that is not the right solution. Portage should _not_ touch my precious config files crafted for many years. It should store the USE related dependencies info in its _internal_ structures (somewhere in /var/db/pkg I presume). Sorry I was not clear previously. Moreover it should be able to depclean them - revert the USE changes once the dependency is no longer needed (for example with new emerge option --use-depclean). Just like with standard package dependencies. Since /etc/portage is CONFIG_PROTECTed by default, these changes normally first appear in that feature's .* files, to be merged by the [...] tolerable. As others in-thread have stated, we don't believe that's something portage should be messing with. Totally agree, it should mess only with /var/db/pkg or so, not /etc. [... sniped great explanation of current testing portage behaviour in this regard; thanks for that, even though it is not what I crave for] Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] Things one could be upset about
On 01/17/2015 08:21, Pacho Ramos wrote: El sáb, 17-01-2015 a las 13:44 +0100, Dirkjan Ochtman escribió: [...] Also, I hate something like ['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]']. What the hell kind of warning is that? I guess maybe these are the results of USE_EXPAND trickery and what not, but it would sure be nice to have something more readable. Yeah, sometimes the output are really fat, not sure if some heuristic could be done to, for example, collate the exact same errors that are coming from every single subprofile. I've been spending the better half of the last two days trying to kickstart catalyst runs on two of my SGI systems, one doing o32 and the other n32. Using seed stage3 stages I built 6 months ago (but never released due to getting sidetracked), I run into errors like this: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/perl:0 (dev-lang/perl-5.20.1-r4:0/5.20::gentoo, ebuild scheduled for merge) pulled in by =dev-lang/perl-5.20* required by (virtual/perl-ExtUtils-ParseXS-3.240.0:0/0::gentoo, ebuild scheduled for merge) ^ ^ (and 16 more with the same problem) (dev-lang/perl-5.18.2-r2:0/5.18::gentoo, ebuild scheduled for merge) pulled in by dev-lang/perl:0/5.18=[-build(-)] required by (dev-perl/libintl-perl-1.230.0:0/0::gentoo, installed) =dev-lang/perl-5.18* required by (virtual/perl-ExtUtils-Manifest-1.630.0-r1:0/0::gentoo, installed) ^ ^ (and 2 more with the same problems) It's hard to read mess like that and trace down the offending package, fix it, and make catalyst happy. Got bit by the splitting of libltdl and libtool as well. Several packages included a block on =libtool-2.4.2, which was in my stage3 builds from last summer. Not an easy way to work around those in catalyst. Eventually just unpacked the seed stage3 on both systems, updated libtool/libltdl, repacked them, and used those as the as seed stages. Kinda defeats the purpose of catalyst in the first place. Looks like I have to repeat for perl now, which seems to do this every major update. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
On Wed, 21 Jan 2015 10:38:20 -0500
Rich Freeman ri...@gentoo.org wrote:
On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier
aball...@gentoo.org wrote:
On Wed, 21 Jan 2015 11:05:34 +0100
Michał Górny mgo...@gentoo.org wrote:
Hello, developers.
As you may recall, the main blocker for wide-establishment of
FEATURES=network-sandbox prohibiting network access within the
build environment is distcc. Since all connectivity is disabled,
distcc can no longer reach other distcc servers and build
efficiently. I therefore find it important to figure out a
solution.
I see two generic approaches possible here:
1. proxying distcc from within the build environment, or
2. moving distcc-spawned processes back to parent's namespace.
I haven't followed this at all, so this might be very stupid:
Isn't it possible to whitelist distcc hosts ?
That would only work with a proxy of some kind.
A process running in a separate network namespace doesn't see any
network interfaces. It can't even get as far as iptables/etc for some
kind of filtering. Now, you could define an interface in the new
namespace, and then bridge that to the host network, and then apply
iptables rules to it.
Your last sentence mentions a nice possibility:
1) Connect the sandbox network namespace to the global namespace (using
a veth pair?)
2) Enable forwarding (if I understand it right, it's even possible to
do this for individual interfaces instead of globally, using
/proc/sys/net/ipv{4,6}/conf/veth0 )
3) Set up suitable rules in the netfiler FORWARD chain to ensure only
distcc gets through
4) Set up SNAT or MASQUERADE in netfilter's nat table
5) There you go!
This is beautiful because is doesn't require any userland proxies, but
of course, it would be difficult to set up in an automated fashion. So
my proposal would be just to stay with the status quo, and document the
above in the wiki for those who really want to use both network-sandbox
and distcc despite the hassle.
Regards,
Luis Ressel
Re: [gentoo-dev] keywording gcc-4.9 branch
On 01/20/15 19:49, Luca Barbato wrote: On 17/01/15 18:43, Anthony G. Basile wrote: Hi everyone, It looks like there aren't too many bugs against gcc-4.9 (bug #495124). There are a couple having to do with lto and one which is hardened specific, but its probably a good idea to start keywording on the various arches so we can get more bug reports and not trail behind. So I opened bug #536874. I've followed Ryan's workflow where he has one bug for gcc 4.9 porting and another for keywording/stabilization. I'm not sure why he did it this way, but it may be less confusing in the future to have just one which track the state of the ebuild from keyword masked, to keyworded to stabilization. @rhill, any advice here :) Word of warning, asan was still terminally broken on nontrivial code last time I tested it. lu Its masked by default and only unmasked on amd64, arm, powerpc, sparc and x86 with glibc. Its pretty much broken on other arches, on other libc's and on PaX hardened kernels. See the following bugs: [1] https://bugs.gentoo.org/show_bug.cgi?id=504200 [2] https://bugs.gentoo.org/show_bug.cgi?id=458706 -- 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: Moving CPU flags into USE_EXPAND
On Wed, 21 Jan 2015 01:13:08 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: (a lot) Thank you, Duncan. You explained by position perfectly. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Wed, 21 Jan 2015 19:21:28 +0100 Michał Górny mgo...@gentoo.org wrote: [...] 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots. This makes sense only when in DEPEND+RDEPEND (because of the :=), so apply this (mostly copy/paste) for all such deps: for a in 'a' 'b' 'c': When the package is built, if 'a' is satisfied and has a := dep then 'a' and its subslot is added to := deps list for the installed package As for the meaning, it uses all of a, b and c that are available at buildtime and at least one of them must be present. for 'b' and 'c', the := dep description/meaning from pms applies. 2. What does || ( a:= b:= ) mean when a and b can be both installed? Ditto. A fair bit inconsistent but I guess it is the safe solution. Of course, it is ugly for making || () behave completely different from the original meaning when := is used inside. You add subslot, you get completely different behavior. You remove it, you get completely different behavior... Can you answer the same question removing ':=' ? I might have missed something but, as I see it, it is the same meaning with and without :=, and this just provides an algorithm on how to trigger the rebuilds. [...] It is easy to write others how to do stuff without looking at the code, isn't it? It is, indeed. But two things: 1. If portage uses crafted depstrings in its depgraph when rebuilding a package and nobody is able to give me a good reason _why_ this is needed, I really do not want to look at the code :) 2. From my experience, such input is very useful: Yes, it often annoys me and sometimes even pisses me off that some external guy comes and tells me I have to trash all that code I wrote, that costed me a lot, and even I have problems understanding it. But, in the end, more often than not, I realize that I was too much into the code and not enough into understanding and simplifying the global picture and that this external input allows me to make the code simpler, less buggy and much more maintainable. Alexis.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Tue, 20 Jan 2015 22:43:52 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-20, o godz. 09:13:19 Alexis Ballier aball...@gentoo.org napisał(a): For this reason, I would like to employ the solution used by Exherbo. More specifically, use: libav? ( media-libs/libav:= ) !libav? ( media-libs/ffmpeg:= ) This has two advantages: 1. gives users more explicit control over whether they want to use libav or ffmpeg. Since the two have mutual blockers, right now random packages could have tried to force you to switch from one to the other. However, most often Portage would just give you terribly unreadable blockers. This sounds good to me; there are a few things to consider though: - Whatever default useflag is enabled, people will have terribly unreadable blockers if they use the other implementation. It is even worse if you want to follow upstreams in their preferred implementation: some want libav, others ffmpeg... It's no better than it is now. I don't see any obvious solution, except maybe for fake flags that would shout loudly at users, like USE=libav with matching pkg_pretend() telling to change the global flag. As I see it, this problem has no solution unless we're going to make the two co-installable. There is indeed no solution I can think of but it is a bit worse than what it is now at first: People that wanted to chose put their implementation in world and were done. With this solution, such people will have to adapt their useflags in make.conf. Don't get me wrong: I'm all for changing it as you suggest (or remi suggests), I'm just saying users might have a hard time finding out what those portage blockers mean and how to fix it. In the long term your proposal is a better solution but the first time will be painful IMHO. - This is hidden by the proposal but it enforces that a package has equal visibility of both implementations (while the || requires only one); libav tends to have a faster code cleaning rate and thus a slower unmasking rate in gentoo. I agree with that requirement but this might end-up being unpractical since this means packages keywording and stabilization will have the slowest pace: mpv has been masked for 4 months and counting for this reason. It will *at least* make those issues explicit and visible to repoman. Rather than discovered via users hitting impossible dep trees. They're usually not impossible, but my point was rather: Is this something everyone wants ? - What to do with packages like mplayer that haven't been building against libav for a year or so ? I don't know. pkg_pretend() like suggested above? Me neither. pkg_pretend will be too intrusive into packages I think (and there are quite a few). I remember something that enabled useflags based on if you had a given package installed. /me runs 2. Subslots work correctly. Rebuilds are forced when the chosen library is upgraded. Moreover, USE flag change causes a rebuild when user decides to change the ffmpeg provider. No offense, but this argument is complete crap. You should rather fix portage bugs than propose to introduce tree-wide changes to hide them... More precisely: || ( a:= b c:= d ) is perfectly defined (in the what it means sense, not in PMS sense). When the package is built, if 'a' is satisfied then a (and its subslot) is added to the subslot list of the package; ditto for c. You end up with a list of subslot deps, that you can store in vdb or whatever, and use that to decide when to rebuild the package. Following a specification is not a bug. I could argue here a lot but... just implement it. And return to us when you do. We had an item for this for EAPI 6, and it was removed because nobody volunteered to implement it. In fact, nobody even were able to fully specify what it should do... but if you want to discuss that, please start a new thread, possibly at the -pms list. Above is a simple algorithm that works in all cases. What you're asking me to do is go beg pms list to allow something they don't want because the subslot/:= spec was poorly written and thought of. I already gave you the solution, don't count on me for the administrative work :=) (NB: everytime I tried to improve/fix something in pms I failed miserably, so that I have no other choice but giving up on this, check bgo) Moreover, when I bumped ffmpeg subslot, portage did rebuild all those packages with || ( := := ) deps properly for me. So, you'll have to be a bit more specific on what goes wrong than 'broken || ( libav:= ffmpeg:= )'... Alexis.
[gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. I see two generic approaches possible here: 1. proxying distcc from within the build environment, or 2. moving distcc-spawned processes back to parent's namespace. distcc client/server solution - The most obvious solution to me is to employ a client/server model where a system-wide daemon is running, parsing /etc/distcc/hosts and doing all the network activity. Clients can only connect to it via a UNIX socket. While at it, we also make it responsible for task scheduling so that parallel builds don't go over the task limits, and maybe even integrate into distccd so that it is both aware of local and remote builds. Of course, that's a pipe dream assuming there will be somewhere to do all the work, upstream will accept it and users will accept some limitations (like no easy per-process overrides of DISTCC_HOSTS). So better to look into something more realistic. Generic proxy solution -- The simplest solution so far seems to be setting a generic SOCKS proxy inside the build environment, and wrapping distcc so that it will use it for network access. Unless we do some extra magic which don't want to do, this means that other apps can also abuse the proxy to reach outside sandbox. However, network-sandbox is not really a security feature, so I don't think that is important. At least as long as we don't export it globally :). Of course, software is a problem. We'd need at least some SOCKS server for Portage (at least a very simple one), and as far as I'm aware distcc does not support SOCKS directly, so tsocks in addition to that. Parent namespace solution - The alternative is to wrap distcc so that parent network namespace is regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to parent's /proc entry (so root privileges). We obviously don't want to lose userpriv, so we have to do with setuid wrapper. Of course, setuid wrappers need to be written in C, so we need to introduce C compiled executable in Portage. Then we need to take some special care for it not to be abused, e.g. to access restricted network namespaces of other processes. Any other ideas? -- Best regards, Michał Górny pgpqn42Mh1Tax.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Wed, 21 Jan 2015 11:15:04 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-21, o godz. 11:05:01 Alexis Ballier aball...@gentoo.org napisał(a): 2. Subslots work correctly. Rebuilds are forced when the chosen library is upgraded. Moreover, USE flag change causes a rebuild when user decides to change the ffmpeg provider. No offense, but this argument is complete crap. You should rather fix portage bugs than propose to introduce tree-wide changes to hide them... More precisely: || ( a:= b c:= d ) is perfectly defined (in the what it means sense, not in PMS sense). When the package is built, if 'a' is satisfied then a (and its subslot) is added to the subslot list of the package; ditto for c. You end up with a list of subslot deps, that you can store in vdb or whatever, and use that to decide when to rebuild the package. Following a specification is not a bug. I could argue here a lot but... just implement it. And return to us when you do. We had an item for this for EAPI 6, and it was removed because nobody volunteered to implement it. In fact, nobody even were able to fully specify what it should do... but if you want to discuss that, please start a new thread, possibly at the -pms list. Above is a simple algorithm that works in all cases. What you're asking me to do is go beg pms list to allow something they don't want because the subslot/:= spec was poorly written and thought of. I already gave you the solution, don't count on me for the administrative work :=) (NB: everytime I tried to improve/fix something in pms I failed miserably, so that I have no other choice but giving up on this, check bgo) No, it works in the one case you thought of. Two quick issues: Ok, so first thing: You are the one writing about putting || in effective deps (whatever that means), for me := deps that apply when the package is installed is just a list created when the package is built: no ||, no use conditional, and with subslots instantiated. 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots. This makes sense only when in DEPEND+RDEPEND (because of the :=), so apply this (mostly copy/paste) for all such deps: for a in 'a' 'b' 'c': When the package is built, if 'a' is satisfied and has a := dep then 'a' and its subslot is added to := deps list for the installed package As for the meaning, it uses all of a, b and c that are available at buildtime and at least one of them must be present. for 'b' and 'c', the := dep description/meaning from pms applies. 2. What does || ( a:= b:= ) mean when a and b can be both installed? Ditto. Adding a very specific PMS rule for two packages doesn't sound like a very good idea to me. I agree but I don't think it is that specific. Moreover, when I bumped ffmpeg subslot, portage did rebuild all those packages with || ( := := ) deps properly for me. So, you'll have to be a bit more specific on what goes wrong than 'broken || ( libav:= ffmpeg:= )'... I already told you that before. Try switching from ffmpeg to libav, and see what mess it causes. I'll summarize it for you: 1. if you have dynamic-deps enabled, portage will want to install both ffmpeg (because of :=) and libav (because of ||). The effective deps will look like: || ( ffmpeg:0/51= libav ) ffmpeg:0/51= with a separate := deps list, you have 'ffmpeg:0/51=' in the list; you notice ffmpeg subslot has changed from '0/51' to '' (since it is not installed anymore) so trigger the package for rebuild and use the || ( ffmpeg:= libav:= ) dep (which I assume works fine since that's what happens when you install the package). the bug here is that portage uses a crafted (r)depend string for reinstall, instead of the ones from the stock ebuild from either vdb or the portage tree. 2. If you have dynamic-deps disabled, portage will happily switch impl without rebuilding revdeps (breakage). Afterwards, it will allow upgrading the other dep (libav) without rebuilds. The effective deps will look like: || ( ffmpeg:0/51= libav ) this is also solved by having a separate := dep list in vdb Alexis.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Dnia 2015-01-21, o godz. 11:05:01 Alexis Ballier aball...@gentoo.org napisał(a): 2. Subslots work correctly. Rebuilds are forced when the chosen library is upgraded. Moreover, USE flag change causes a rebuild when user decides to change the ffmpeg provider. No offense, but this argument is complete crap. You should rather fix portage bugs than propose to introduce tree-wide changes to hide them... More precisely: || ( a:= b c:= d ) is perfectly defined (in the what it means sense, not in PMS sense). When the package is built, if 'a' is satisfied then a (and its subslot) is added to the subslot list of the package; ditto for c. You end up with a list of subslot deps, that you can store in vdb or whatever, and use that to decide when to rebuild the package. Following a specification is not a bug. I could argue here a lot but... just implement it. And return to us when you do. We had an item for this for EAPI 6, and it was removed because nobody volunteered to implement it. In fact, nobody even were able to fully specify what it should do... but if you want to discuss that, please start a new thread, possibly at the -pms list. Above is a simple algorithm that works in all cases. What you're asking me to do is go beg pms list to allow something they don't want because the subslot/:= spec was poorly written and thought of. I already gave you the solution, don't count on me for the administrative work :=) (NB: everytime I tried to improve/fix something in pms I failed miserably, so that I have no other choice but giving up on this, check bgo) No, it works in the one case you thought of. Two quick issues: 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots. 2. What does || ( a:= b:= ) mean when a and b can be both installed? Adding a very specific PMS rule for two packages doesn't sound like a very good idea to me. Moreover, when I bumped ffmpeg subslot, portage did rebuild all those packages with || ( := := ) deps properly for me. So, you'll have to be a bit more specific on what goes wrong than 'broken || ( libav:= ffmpeg:= )'... I already told you that before. Try switching from ffmpeg to libav, and see what mess it causes. I'll summarize it for you: 1. if you have dynamic-deps enabled, portage will want to install both ffmpeg (because of :=) and libav (because of ||). The effective deps will look like: || ( ffmpeg:0/51= libav ) ffmpeg:0/51= 2. If you have dynamic-deps disabled, portage will happily switch impl without rebuilding revdeps (breakage). Afterwards, it will allow upgrading the other dep (libav) without rebuilds. The effective deps will look like: || ( ffmpeg:0/51= libav ) -- Best regards, Michał Górny pgpXyKkWYNzeN.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Tue, 20 Jan 2015 10:33:49 -0800 Zac Medico zmed...@gentoo.org wrote: On 01/20/2015 10:20 AM, Alexis Ballier wrote: On Tue, 20 Jan 2015 09:28:21 -0800 Zac Medico zmed...@gentoo.org wrote: On 01/20/2015 01:11 AM, Alexis Ballier wrote: I think we can only make the safest assumption. Even without subslot, if you consider this: || ( a b c d ), with a and c installed but package automagically deciding to use only a, how can a PM decide whether it is safe to remove a or not after the package has been merged ? Right, this demonstrates that || deps are ambiguous. So, maybe we should look at alternatives that are not so ambiguous, such as USE conditionals and REQUIRED_USE constraints. if you assume there are no automagic deps, what is wrong and/or ambiguous with '|| ( a b c d ) means any of them, and at least all that were available when the package was merged' ? in the above example this avoids PM breaking people systems by removing 'a' (e.g. if another packages pulls in 'd' that has a blocker against 'a') and as a side effect makes := deps work... Sure, but when you start using words like at least all that were available when the package was merged, it shows a lack of precision in your model. all that were available when the package was merged is perfectly defined. The at least is to allow room for dynamic deps but can be dropped. Simple words don't make things less precise, just more readable :) [...]
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
On Wed, 21 Jan 2015 11:05:34 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. I see two generic approaches possible here: 1. proxying distcc from within the build environment, or 2. moving distcc-spawned processes back to parent's namespace. [...] Any other ideas? I haven't followed this at all, so this might be very stupid: Isn't it possible to whitelist distcc hosts ? Alexis.
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
On 01/21/2015 05:05 AM, Michał Górny wrote: Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution. ... Any other ideas? We probably won't avoid the fact that some features are incompatible forever. Why not just let the combination be broken? Distcc isn't enabled by default, so having network-sandbox enabled won't immediately cause problems. We can document that, when enabling distcc, you have to set FEATURES=-network-sandbox. No one will read it, so that leaves the question of what to do when both are enabled. 1. Break normally. We can point people to the man page. 2. Disable network-sandbox and emit a warning. 3. Disable distcc and emit a warning. The third is my favorite, since it's the non-default feature and the warning will be more helpful: to enable distcc, you must add -network-sandbox to your FEATURES in make.conf... If the point of network-sandbox is to catch mistakes, having it enabled for 95% of users is just as good as 100%.
