Re: [gentoo-dev] CGA Web™ graphics standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/04/2015 20:29, Joshua Kinard wrote: Arguably the best 04/01 gag I've seen today. Can we keep this? It'll make browsing the site on old SGI machines so much easier... +1, very good job guys it made my day. Thank you ! -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlUc/BwACgkQKiQSS7ZY+hPvFgEAuOa1EZlahkb+9ebtgcBhJHm0 /lEf2jiALipYN0xapE4BAJazaOX0qvzzUwBPyVO7aLUzkMkcfXaiaq+dKCthXf/E =FDq5 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Dynamic USE dependencies
On Thu, Apr 2, 2015 at 2:03 PM, Kent Fredric kentfred...@gmail.com wrote: So I'm basically having trouble with groking the logic you're proposing of add a new use flag - implied change of useflag - rebuild when useflags change - but don't rebuild for this useflag change using some kind of magic I'm fine with rebuilding a package anytime the IUSE changes. I just don't want to see a package built with +a -b rebuilt as -a +b because either configuration works, so it gets rebuilt every time you run emerge. If multiple configurations work, just use the one that is already installed. emerge --newuse is already going to rebuild any package that has IUSE change anyway. -- Rich
[gentoo-dev] last rites: dev-perl/Eidetic app-admin/rackview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Andreas K. Huettel dilfri...@gentoo.org (2 Apr 2015) # Ancient, dead upstream. File collisions (bug 535700) # and build failures (bug 277670). Masked for removal in # 30 days. dev-perl/Eidetic app-admin/rackview - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVHbknXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5Zz8P/0vbQvEQU/6jszMrNql66ku4 AQtcwr1AcOmYk/51CJC8LglqM7jJhfw21YEQvBfAI7d16CAAC1JgzqPSYGarmcRx 3u7OtoWsAlZaoxaAnsN4+68EvE8YCQcqsIl+9oCyjoFvQvSOwZv1ws/iN5cOQ3aP Phr0a4dLXmfai2P8RHHkUbdPrDMFQr05XlV6VtRvVXVDEU8Px+JfOV3yBlLlwuVJ t3bwDaVltB0Xj7hUbcAds6ZgNzAB2AsZZQngxPMlJzQQyJ/e3a/bTZjGsyaemWwo pdvT5nNVIDlW03qCP8Bm66TVPrpwCzlbmc5/s6GEQk0cOLWHZTKR+3G7DaLipmFa qhxK+RGHHiYaIqxtsrd2QgLfshXFvCqugQca7L6MH4yzwlHQ0xDvoeSmstbRvk7z IduLegYPZEheKMum6fq2V77UOZsW0jPX+oaMMJK26OuU2FYSDzdD/zWf7VzS5iZw r2z6mysr2doUyNydEw4gyAmvTKSIBLpXE4t7MzjzeaG22kN4pl9zAMKX88GZFuGF 7WEL33c2DJe+KNPq2KcFAxEUGm4uwbla6uNfpqeGeakh+TINLo9wFoKBika55wwV 7x6Rj773NjYIOti4mv7beO+FbE7SPDCSKDaQPFtaGpJkETt3VK2AlpW8VzNdzNzG V83pzI2pDk5LCSnBfb8y =r6GB -END PGP SIGNATURE-
Re: [gentoo-dev] libressl status
On Thu, 2 Apr 2015 16:49:20 -0700 Paul B. Henson hen...@acm.org wrote: What is the current status/thoughts regarding libressl? Reviewing the bug and some past threads, it sounds like the initial plan was to make openssl a virtual and let either classic openssl or libressl fulfull it? I'm not sure if things have changed from that viewpoint, but it really doesn't seem they're going to be plug and play compatible 8-/. libressl offers functionality openssl doesn't and vice versa, and playing nicely with each other doesn't seem to be on the agenda of either. The latest state is that there is an overlay, but making the portage tree compatible with libressl is not that trivial. A large number of core packages are upstream-incompatible with libressl. Most of them are actually programming languages (python, php, ruby) that contain bindings to functions libressl has removed. This could be fixed by the upstreams with some ifdefs, but right now you can't just switch out libressl. It seems it might make more sense to treat them more like openssl and gnutls, where they both provide similar ssl functionality but a given package might use one, the other, or either? Tricky thing here, because then you'd need to rename the libs. E.g. libssl to liblibressl or something. But then every program with a build environment to link to libssl would first have to be patched to link to our specialized libressl variant. The specific reason for my current inquiry is that the latest openntpd release includes the new support from openbsd for constraints, where basically you can verify ntp time sources by checking their time relative to a trusted TLS server (which provides the time in HTTP headers). This functionality requires libtls, part of libressl. openssl provides no compatible functionality, so this is a case where they're not plug-and-play, openntpd requires libressl specifically. I'm eager to use that, too, and was disappointed to read it requires libressl :-) Is there a way to split libtls off libressl? Because that might be at least for this case an option: Continue to use openssl, but have libtls laying around. Not sure if it is possible to have libtls using libcrypt/libssl functions from openssl. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-portage-dev] [PATCH v2] repoman: fix dependency.unknown to ignore USE deps (bug 525376)
The surrounding code is ignorant of USE flags, because it calls use_reduce(matchall=True), therefore it makes sense for the dependency.unknown code to ignore USE deps. X-Gentoo-Bug: 525376 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=525376 --- [PATCH v2] only changes the bug references from bug 545294 to bug 525376 bin/repoman | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bin/repoman b/bin/repoman index 7101a00..4a21e37 100755 --- a/bin/repoman +++ b/bin/repoman @@ -2049,9 +2049,10 @@ for x in effective_scanlist: # Skip dependency.unknown for blockers, so that we # don't encourage people to remove necessary blockers, - # as discussed in bug #382407. + # as discussed in bug 382407. We use atom.without_use + # due to bug 525376. if not is_blocker and \ - not portdb.xmatch(match-all, atom) and \ + not portdb.xmatch(match-all, atom.without_use) and \ not atom.cp.startswith(virtual/): unknown_pkgs.add((mytype, atom.unevaluated_atom)) -- 2.3.1
Re: [gentoo-portage-dev] Re: Dynamic USE dependencies
On Thu, Apr 2, 2015 at 10:10 PM, Duncan 1i5t5.dun...@cox.net wrote: Rich Freeman posted on Thu, 02 Apr 2015 12:32:41 -0400 as excerpted: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? Because USE flags are binary, with not-yes implying no, while world set listings are binary, with not-yes implying do it anyway if needed? That doesn't need to be true. Not listing a flag in your config can just mean do it anyway if needed. Package USE dependencies already work this way - you can depend on a flag being set, on it being unset, or not mention the flag at all which means the package doesn't care. Changing the implied meaning of not-yes to match in both cases could certainly be done, but while I'm not opposed if the justification really is there, I think there's the potential here for a rather massive change in base assumptions, and if that is indeed what's involved, I believe it'd call for equally massive justifications. There is no question that it would be a change in behavior. However, I wouldn't anticipate a lot of changes. If you stuck -* in your make.conf then this change would have no affect at all, since you've explicitly set the configuration of every use flag. Anything already in package.use would still stick, since that is also configuration. If you wiped your package.use clean then there would be a possible change, but that is something the user has control over, and presumably for them it is a change for the better if they're making it. Things would still default to their profile/package defaults as they already do if you don't stick anything in your config files. However, future package installs that require a USE change would just make the change if you didn't explicitly bar that configuration. It wouldn't modify your config files. And I'm worried that the suggestion here is going further down that emerge writing its own config path, without (IMO) appropriate safeguards. I think this is exactly the opposite. It would get rid of the need to have portage go modifying package.use at all in many cases. You'd still need to modify configuration (perhaps with automatic help) if you had explicitly set something which conflicts with what you want to install (such as USE=-* globally). However, for users who just go with the profile defaults they wouldn't have to stick nearly as much stuff in package.use just to change a flag setting they never expressed a personal preference for one way or the other. The current configuration forces you to use config files to capture settings you care about, and also ones you don't actually care about, and unless you're careful you'll have trouble telling these settings apart later. It is like sticking every installed package in your world file. -- Rich
[gentoo-dev] libressl status
What is the current status/thoughts regarding libressl? Reviewing the bug and some past threads, it sounds like the initial plan was to make openssl a virtual and let either classic openssl or libressl fulfull it? I'm not sure if things have changed from that viewpoint, but it really doesn't seem they're going to be plug and play compatible 8-/. libressl offers functionality openssl doesn't and vice versa, and playing nicely with each other doesn't seem to be on the agenda of either. It seems it might make more sense to treat them more like openssl and gnutls, where they both provide similar ssl functionality but a given package might use one, the other, or either? The specific reason for my current inquiry is that the latest openntpd release includes the new support from openbsd for constraints, where basically you can verify ntp time sources by checking their time relative to a trusted TLS server (which provides the time in HTTP headers). This functionality requires libtls, part of libressl. openssl provides no compatible functionality, so this is a case where they're not plug-and-play, openntpd requires libressl specifically. Thanks...
[gentoo-portage-dev] Re: Dynamic USE dependencies
Rich Freeman posted on Thu, 02 Apr 2015 12:32:41 -0400 as excerpted: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? Because USE flags are binary, with not-yes implying no, while world set listings are binary, with not-yes implying do it anyway if needed? OK, so the USE flag not-yes implied no /is/ a bit weak, packages omit the USE flag if they (or their maintainer) actually require the feature and simply hard-require what would otherwise be toggled by the USE flag, but by that same token, the very fact that the USE flag exists makes it an option for the admin that would toggle the flag, strengthening the USE flag's implied-no of the not-yes, and in any case, it's still *far* stronger than the do-it-anyway-if-needed of simply not listing a package in the world set. Meanwhile, there is of course a way to have no for a world listing, put it in package.mask. Similarly, there'a a way to enforce an explicit no for that implied by a USE not-yes, by setting USE=-* at the beginning, and users who eventually get tired of having to worry about profile changes meaning implied USE flag changes, etc, may well eventually set it, as I did. But that doesn't change the basic difference in what not- yes is implied to mean in the two cases. Changing the implied meaning of not-yes to match in both cases could certainly be done, but while I'm not opposed if the justification really is there, I think there's the potential here for a rather massive change in base assumptions, and if that is indeed what's involved, I believe it'd call for equally massive justifications. OTOH, maybe you're thinking something a bit more incremental, which would accordingly require lower justification. I'm just a bit worried... ... And I /still/ don't like that --ask, implies that I think it's OK for portage to write to my package.* files (even with config-protection), if I accidentally hit enter. When the danger was simply that a package merge that would take some time and thus could easily be aborted, that was IMO reasonable. The new situation is IMO far more borderline. I'd be a whole lot more comfortable if some EMERGE_DEFAULTs parameter could be set to turn off portage's writing to package.* entirely, while keeping the old --ask package-merging /and/ use-flag/mask/keywording SUGGESTION behavior. And I'm worried that the suggestion here is going further down that emerge writing its own config path, without (IMO) appropriate safeguards. -- 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
[gentoo-portage-dev] Dynamic USE dependencies
Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? I was concerned that it might be more work in calculating the dependencies, but then I was thinking that portage probably already does all this work just to validate that the current configuration is still consistent. I fully appreciate that there could be USE blocks, just as there can be package blocks, and that resolving these could require hints such as adding some USE settings to config files, or doing oneshot installs (perhaps the dynamic configuration would be set up to preserve whatever is installed unless it conflicts - just as is done with virtuals today). -- Rich
Re: [gentoo-portage-dev] Dynamic USE dependencies
On 3 April 2015 at 05:32, Rich Freeman ri...@gentoo.org wrote: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? I'd say its more a concept issue than an application issue. USE flags often signify a need for code to be recompiled to grant the feature. How do you disambiguate between USE flags that *do* need a recompile to enable their power, and those that *dont* need a recompile to enable their power. Or even clarify to portage that, The older version of X that didn't have IUSE=foo, actually had feature foo, but just didn't have the use flag vs The older version of X that didn't have IUSE=foo, didnt have feature foo or the IUSE. Splitting this logic into an explicit bump kinda avoids the need for some of these questions. That last one however I'd like to see improved, because I often see new USE flags turn up on packages, and I have no idea of knowing Is this useflag adding a feature, or exposing an existing one Is this new useflag defaulted on because it already existed, or is it defaulted on because its a new feature and its awesome Is this new useflag defaulted off because it didnt already exist, or did it exist and were disabling the feature because its bad Ad Infinitum. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-portage-dev] Dynamic USE dependencies
On Thu, Apr 2, 2015 at 12:56 PM, Kent Fredric kentfred...@gmail.com wrote: On 3 April 2015 at 05:32, Rich Freeman ri...@gentoo.org wrote: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in /var/lib/portage/world, why can't it figure out that I need it built with USE=icu even if I don't put that in /etc/portage/package.use? I'd say its more a concept issue than an application issue. USE flags often signify a need for code to be recompiled to grant the feature. How do you disambiguate between USE flags that *do* need a recompile to enable their power, and those that *dont* need a recompile to enable their power. Why is this necessary? If a USE flag changes, just rebuild the application. Or even clarify to portage that, The older version of X that didn't have IUSE=foo, actually had feature foo, but just didn't have the use flag vs The older version of X that didn't have IUSE=foo, didnt have feature foo or the IUSE. Do what --newuse does. If a flag is added/removed, then rebuild the application. Is this new useflag defaulted on because it already existed, or is it defaulted on because its a new feature and its awesome Is this new useflag defaulted off because it didnt already exist, or did it exist and were disabling the feature because its bad I'd suggest that the algorithm is: 1. When installing a new or updated package: 1a. set all the flags in accordance with configuration (explicit set/unset in profiles, make.conf, package.use) 1b. if these explicitly conflict with package dependencies then fail with an immediate error (that is, config says USE=foo, and package dep says atom[-foo] and so on 1c. additionally set flags as needed to satisfy package dependencies when they don't conflict with explicit configuration 2. When evaluating the dep tree to see if a package needs to be rebuilt, just keep the existing USE configuration unless it conflicts with explicit configuration or a package dependency. So, the goal would be to avoid rebuilding stuff just because we can. However, we would rebuild things if a user wants a flag to be set differently, or if there is now a dependency problem. -- Rich
Re: [gentoo-portage-dev] Dynamic USE dependencies
On 3 April 2015 at 06:32, Rich Freeman ri...@gentoo.org wrote: Why is this necessary? If a USE flag changes, just rebuild the application. Isn't the nature of your proposal,( that is, dynamic deps for USE flags ) inherently Use flags change, _dont_ rebuild the application ? :) It may help to think in terms of : Any ebuild without IUSE=foo , once installed, actually has a property of USE_foo=undef Once an ebuild has IUSE=foo, the installed package then can subsequently get USE_foo=y USE_foo=n So under that logic, adding a new IUSE implies Use flag changes ( either from state undef to y , or state undef to n ). We have mechanisms for other ebuilds to declare what USE_foo=undef means in dependency defaults: =X[foo(+)] # Assume USE_foo = undef to mean USE_foo = y =X[foo(-)] # Assume USE_foo = undef to mean USE_foo = n There's just no mechanism similar to that for an ebuild with CVS revision 02 to declare what USE_foo = undef meant on ebuild with CVS revision 01 Nor is there a way to express what USE_foo=undef meant on X$PV ( And subsequently, there is no user visible way /in portage/ for portage to express the meaning of a new USE flag becoming visible ) So I'm basically having trouble with groking the logic you're proposing of add a new use flag - implied change of useflag - rebuild when useflags change - but don't rebuild for this useflag change using some kind of magic ( Mostly due to the implied-change via addition I can't seem to ignore ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
[gentoo-portage-dev] [PATCH] repoman: fix dependency.unknown to ignore USE deps (bug 545294)
The surrounding code is ignorant of USE flags, because it calls use_reduce(matchall=True), therefore it makes sense for the dependency.unknown code to ignore USE deps. X-Gentoo-Bug: 545294 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545294 --- bin/repoman | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bin/repoman b/bin/repoman index 7101a00..64f1ec5 100755 --- a/bin/repoman +++ b/bin/repoman @@ -2049,9 +2049,10 @@ for x in effective_scanlist: # Skip dependency.unknown for blockers, so that we # don't encourage people to remove necessary blockers, - # as discussed in bug #382407. + # as discussed in bug 382407. We use atom.without_use + # due to bug 545294. if not is_blocker and \ - not portdb.xmatch(match-all, atom) and \ + not portdb.xmatch(match-all, atom.without_use) and \ not atom.cp.startswith(virtual/): unknown_pkgs.add((mytype, atom.unevaluated_atom)) -- 2.3.1
