Re: [gentoo-dev] [RFC] New third party mirrors
On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny wrote: > On Wed, 25 Apr 2012 09:16:05 +0200 > Corentin Chary wrote: > >> On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny >> wrote: >> > On Tue, 24 Apr 2012 16:19:11 + >> > "Robin H. Johnson" wrote: >> > >> >> On Tue, Apr 24, 2012 at 04:50:49PM +0200, Corentin Chary wrote: >> >> > >> $ ./mirrors.py --all --count >> >> > >> 297 ?? ?? http://pear.php.net >> >> > >> 297 ?? ?? http://pear.php.net/get >> >> > >> 88 ?? ?? ??http://pecl.php.net >> >> > >> 88 ?? ?? ??http://pecl.php.net/get >> >> > > These are already mirror bouncers. If you visit the above, >> >> > > you'll get the closest mirror for downloading. >> >> > And since there is already ~10 "mirrors" with only one actual >> >> > backend, should they go to thirdpartymirrors or not ? If not, >> >> > what about this pseudo-mirrors already present in >> >> > thirdpartymirrors ? >> >> I think we should add the pseudo-mirrors, but explicitly mark them >> >> as such in the file, so that they don't get duplicate entries >> >> added (eg adding us.pear, de.pear and the pear bouncer is bad. >> >> Should have just the bouncer). >> > >> > It'd be great if we could add some kind of additional mirror >> > entries, which would be used by repoman to signal missing mirror:// >> > entries but won't be used for downloads. >> >> Yep, we could put that in it too: >> github http://github.com/downloads/ >> https://github.com/downloads/ > > Per spec, portage can choose a random mirror of the list. If we put > entries like that, these two will be equally possible as the preferred > cloud. URL -- while they redirect one to another. > > We might decide on some common syntax like preceding all extra entries > with '-' but I don't want to be the one deciding here. I checked, and current portage code already handle entries starting with a - gracefully thanks to stack_dictlist (removing them from the list of mirrors). -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] [RFC] New third party mirrors
On 04/26/2012 12:30 AM, Corentin Chary wrote: > On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny wrote: >> On Wed, 25 Apr 2012 09:16:05 +0200 >> Corentin Chary wrote: >> >>> On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny >>> wrote: On Tue, 24 Apr 2012 16:19:11 + "Robin H. Johnson" wrote: > On Tue, Apr 24, 2012 at 04:50:49PM +0200, Corentin Chary wrote: $ ./mirrors.py --all --count 297 ?? ?? http://pear.php.net 297 ?? ?? http://pear.php.net/get 88 ?? ?? ??http://pecl.php.net 88 ?? ?? ??http://pecl.php.net/get >>> These are already mirror bouncers. If you visit the above, >>> you'll get the closest mirror for downloading. >> And since there is already ~10 "mirrors" with only one actual >> backend, should they go to thirdpartymirrors or not ? If not, >> what about this pseudo-mirrors already present in >> thirdpartymirrors ? > I think we should add the pseudo-mirrors, but explicitly mark them > as such in the file, so that they don't get duplicate entries > added (eg adding us.pear, de.pear and the pear bouncer is bad. > Should have just the bouncer). It'd be great if we could add some kind of additional mirror entries, which would be used by repoman to signal missing mirror:// entries but won't be used for downloads. >>> >>> Yep, we could put that in it too: >>> githubhttp://github.com/downloads/ >>> https://github.com/downloads/ >> >> Per spec, portage can choose a random mirror of the list. If we put >> entries like that, these two will be equally possible as the preferred >> cloud. URL -- while they redirect one to another. >> >> We might decide on some common syntax like preceding all extra entries >> with '-' but I don't want to be the one deciding here. > > I checked, and current portage code already handle entries starting > with a - gracefully thanks to stack_dictlist (removing them from the > list of mirrors). That means repoman will ignore them too. If you want existing versions of repoman to check for those paths in SRC_URI, you can add a line like this to thirdpartymirrors: github-bad-urls http://github.com/downloads/ https://github.com/downloads/ -- Thanks, Zac
Re: [gentoo-dev] [RFC] New third party mirrors
On Thu, Apr 26, 2012 at 9:57 AM, Zac Medico wrote: > On 04/26/2012 12:30 AM, Corentin Chary wrote: >> On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny wrote: >>> On Wed, 25 Apr 2012 09:16:05 +0200 >>> Corentin Chary wrote: >>> On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny wrote: > On Tue, 24 Apr 2012 16:19:11 + > "Robin H. Johnson" wrote: > >> On Tue, Apr 24, 2012 at 04:50:49PM +0200, Corentin Chary wrote: > $ ./mirrors.py --all --count > 297 ?? ?? http://pear.php.net > 297 ?? ?? http://pear.php.net/get > 88 ?? ?? ??http://pecl.php.net > 88 ?? ?? ??http://pecl.php.net/get These are already mirror bouncers. If you visit the above, you'll get the closest mirror for downloading. >>> And since there is already ~10 "mirrors" with only one actual >>> backend, should they go to thirdpartymirrors or not ? If not, >>> what about this pseudo-mirrors already present in >>> thirdpartymirrors ? >> I think we should add the pseudo-mirrors, but explicitly mark them >> as such in the file, so that they don't get duplicate entries >> added (eg adding us.pear, de.pear and the pear bouncer is bad. >> Should have just the bouncer). > > It'd be great if we could add some kind of additional mirror > entries, which would be used by repoman to signal missing mirror:// > entries but won't be used for downloads. Yep, we could put that in it too: github http://github.com/downloads/ https://github.com/downloads/ >>> >>> Per spec, portage can choose a random mirror of the list. If we put >>> entries like that, these two will be equally possible as the preferred >>> cloud. URL -- while they redirect one to another. >>> >>> We might decide on some common syntax like preceding all extra entries >>> with '-' but I don't want to be the one deciding here. >> >> I checked, and current portage code already handle entries starting >> with a - gracefully thanks to stack_dictlist (removing them from the >> list of mirrors). > > That means repoman will ignore them too. If you want existing versions > of repoman to check for those paths in SRC_URI, you can add a line like > this to thirdpartymirrors: > > github-bad-urls http://github.com/downloads/ https://github.com/downloads/ Hum, I checked repoman source code, and I didn't find where it checks if SRC_URI matches something in thirdpartymirror. Any hint ? -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] [RFC] New third party mirrors
On 04/26/2012 01:03 AM, Corentin Chary wrote: > On Thu, Apr 26, 2012 at 9:57 AM, Zac Medico wrote: >> On 04/26/2012 12:30 AM, Corentin Chary wrote: >>> On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary wrote: > On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny > wrote: >> On Tue, 24 Apr 2012 16:19:11 + >> "Robin H. Johnson" wrote: >> >>> On Tue, Apr 24, 2012 at 04:50:49PM +0200, Corentin Chary wrote: >> $ ./mirrors.py --all --count >> 297 ?? ?? http://pear.php.net >> 297 ?? ?? http://pear.php.net/get >> 88 ?? ?? ??http://pecl.php.net >> 88 ?? ?? ??http://pecl.php.net/get > These are already mirror bouncers. If you visit the above, > you'll get the closest mirror for downloading. And since there is already ~10 "mirrors" with only one actual backend, should they go to thirdpartymirrors or not ? If not, what about this pseudo-mirrors already present in thirdpartymirrors ? >>> I think we should add the pseudo-mirrors, but explicitly mark them >>> as such in the file, so that they don't get duplicate entries >>> added (eg adding us.pear, de.pear and the pear bouncer is bad. >>> Should have just the bouncer). >> >> It'd be great if we could add some kind of additional mirror >> entries, which would be used by repoman to signal missing mirror:// >> entries but won't be used for downloads. > > Yep, we could put that in it too: > githubhttp://github.com/downloads/ > https://github.com/downloads/ Per spec, portage can choose a random mirror of the list. If we put entries like that, these two will be equally possible as the preferred cloud. URL -- while they redirect one to another. We might decide on some common syntax like preceding all extra entries with '-' but I don't want to be the one deciding here. >>> >>> I checked, and current portage code already handle entries starting >>> with a - gracefully thanks to stack_dictlist (removing them from the >>> list of mirrors). >> >> That means repoman will ignore them too. If you want existing versions >> of repoman to check for those paths in SRC_URI, you can add a line like >> this to thirdpartymirrors: >> >> github-bad-urls http://github.com/downloads/ https://github.com/downloads/ > > Hum, I checked repoman source code, and I didn't find where it checks > if SRC_URI matches something in thirdpartymirror. Any hint ? Search for SRC_URI.mirror in /usr/bin/repoman. -- Thanks, Zac
Re: [gentoo-dev] [RFC] New third party mirrors
On Thu, Apr 26, 2012 at 10:07 AM, Zac Medico wrote: > On 04/26/2012 01:03 AM, Corentin Chary wrote: >> On Thu, Apr 26, 2012 at 9:57 AM, Zac Medico wrote: >>> On 04/26/2012 12:30 AM, Corentin Chary wrote: On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny wrote: > On Wed, 25 Apr 2012 09:16:05 +0200 > Corentin Chary wrote: > >> On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny >> wrote: >>> On Tue, 24 Apr 2012 16:19:11 + >>> "Robin H. Johnson" wrote: >>> On Tue, Apr 24, 2012 at 04:50:49PM +0200, Corentin Chary wrote: >>> $ ./mirrors.py --all --count >>> 297 ?? ?? http://pear.php.net >>> 297 ?? ?? http://pear.php.net/get >>> 88 ?? ?? ??http://pecl.php.net >>> 88 ?? ?? ??http://pecl.php.net/get >> These are already mirror bouncers. If you visit the above, >> you'll get the closest mirror for downloading. > And since there is already ~10 "mirrors" with only one actual > backend, should they go to thirdpartymirrors or not ? If not, > what about this pseudo-mirrors already present in > thirdpartymirrors ? I think we should add the pseudo-mirrors, but explicitly mark them as such in the file, so that they don't get duplicate entries added (eg adding us.pear, de.pear and the pear bouncer is bad. Should have just the bouncer). >>> >>> It'd be great if we could add some kind of additional mirror >>> entries, which would be used by repoman to signal missing mirror:// >>> entries but won't be used for downloads. >> >> Yep, we could put that in it too: >> github http://github.com/downloads/ >> https://github.com/downloads/ > > Per spec, portage can choose a random mirror of the list. If we put > entries like that, these two will be equally possible as the preferred > cloud. URL -- while they redirect one to another. > > We might decide on some common syntax like preceding all extra entries > with '-' but I don't want to be the one deciding here. I checked, and current portage code already handle entries starting with a - gracefully thanks to stack_dictlist (removing them from the list of mirrors). >>> >>> That means repoman will ignore them too. If you want existing versions >>> of repoman to check for those paths in SRC_URI, you can add a line like >>> this to thirdpartymirrors: >>> >>> github-bad-urls http://github.com/downloads/ https://github.com/downloads/ >> >> Hum, I checked repoman source code, and I didn't find where it checks >> if SRC_URI matches something in thirdpartymirror. Any hint ? > > Search for SRC_URI.mirror in /usr/bin/repoman. Arg.. ok, I only looked in pym/repoman/. So two solutions here: First one: github http://cloud.github.com/downloads -http://github.com/downloads/ -https://github.com/downloads/ + a small patch that would allow repoman to do something like settings.thirdpartymirrors(keep_bad_uris=True) in order to keep uris starting with a - in the list. Second solution: github http://cloud.github.com/downloads github-bad-uris -http://github.com/downloads/ -https://github.com/downloads/ The good thing with the first one is that it would allow repoman to outputs something like "you should use 'mirror://github'". -- Corentin Chary http://xf.iksaif.net
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: > On 04/25/2012 11:18 PM, Duncan wrote: >> IOW, let's quit letting the perfect be the enemy of the good, and just >> get on with it, already. > > If that means settling on something that's fragile and prone to lots of > bug reports, then it's not really practical, because it wastes peoples > time (and time is our most valuable resource). IMO it's trying to do too much with it that's the fragile bit. If all it does is the patching, but it /always/ does the patching (unlike the hit- and-miss we get now), and people know they need to use the overlay-ebuild method to do anything beyond patching, including if they need to re- invoke eautoreconf, then it should "just work". Right now we're talking about all this fancy stuff, detecting when we need to automatically run eautoreconf, etc, and /that/ seems to me to be the fragile bit. Of course that's why I have preserve-libs turned off here as well. IMO it's a too complex solution to a simple problem, and cleaning up when it breaks is worse than simply dealing with the problem using current proven technology. But at least epatch-user doesn't break the modified ebuild in overlay method, like preserved-libs breaks the normal revdep-rebuild scans so they report no packages to rebuild. -- 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-dev] eselect git repo
Hi all, Just a heads up, lu_zero has discovered that the eselect git repository contains some commits with invalid author lines. This is a holdover from the conversion from svn to git (basically, the real name is missing for devs who changed their Gentoo username). I'm going to fix this within the next few days, but I believe this means that the history will change. So, please don't push to the eselect repo until I give the all-clear. Ulrich
[gentoo-dev] Last rites: sys-kernel/mm-sources
# Stratos Psomadakis (26 Apr 2012) # No longer maintained. # Masked for removal in 30 days wrt #412189 sys-kernel/mm-sources -- Stratos Psomadakis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 02:55 AM, Duncan wrote: Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. If that means settling on something that's fragile and prone to lots of bug reports, then it's not really practical, because it wastes peoples time (and time is our most valuable resource). IMO it's trying to do too much with it that's the fragile bit. If all it does is the patching, but it /always/ does the patching (unlike the hit- and-miss we get now), and people know they need to use the overlay-ebuild method to do anything beyond patching, including if they need to re- invoke eautoreconf, then it should "just work". Right now we're talking about all this fancy stuff, detecting when we need to automatically run eautoreconf, etc, and /that/ seems to me to be the fragile bit. Ignoring the problem doesn't make it go away. If we ignore the problem, then we end up dealing with bug reports of the form "FEATURES=userpatch doesn't work with this particular patch set" until the end of time. Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). Overall, the "apply_user_patches_here" approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Wed, 25 Apr 2012 23:04:08 -0600 Ryan Hill wrote: > Arg, no. Please just print the warning if the host doesn't do SSE2. > There's no reason to have a USE flag here (and _really_ no reason to > make it fatal) I entirely agree there. :) > , especially for an instruction set that every system has supported > for over a decade. Er, some of my teenage systems run desktops just fine here, thanks. And one of them is just nine years old right now but still doesn't support SSE2 (merely SSE[1]). Regards, jer [1] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Barton_and_Thorton - see [2] right above that for the actual specs. [2] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Thoroughbred_.28T-Bred.29
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On 04/26/12 at 06:00PM +0200, Jeroen Roovers wrote: > On Wed, 25 Apr 2012 23:04:08 -0600 > Ryan Hill wrote: > > > Arg, no. Please just print the warning if the host doesn't do SSE2. > > There's no reason to have a USE flag here (and _really_ no reason to > > make it fatal) > > I entirely agree there. :) > I haven't followed the prev. conversation but what's wrong with a USE flag for SSE2? We already have SSE2 flags, even global.. > > , especially for an instruction set that every system has supported > > for over a decade. > > Er, some of my teenage systems run desktops just fine here, thanks. And > one of them is just nine years old right now but still doesn't support > SSE2 (merely SSE[1]). > > > Regards, > jer > > > [1] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Barton_and_Thorton - see > [2] right above that for the actual specs. > [2] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Thoroughbred_.28T-Bred.29 > -- Regards, Christian Ruppert Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 pgpXFvDvRmpl3.pgp Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 06:18:32 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > My suggestion is therefore to do the simple thing, just apply any > patches found in the patches dir, and punt on the complicated > do-we-eautoreconf- or-not thing. Agreed. Just make sure the feature will be only used for ebuilds not calling epatch_user manually or through the eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New third party mirrors
On Thu, 26 Apr 2012 10:21:36 +0200 Corentin Chary wrote: > Second solution: > github http://cloud.github.com/downloads > github-bad-uris -http://github.com/downloads/ -https://github.com/downloads/ > > The good thing with the first one is that it would allow repoman to > outputs something like "you should use 'mirror://github'". Well, we could decide on something common and special like: github:bad-uris http://. And then let repoman suggest using mirror with ':bad-uris' stripped. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 11:27 AM, Michał Górny wrote: > On Thu, 26 Apr 2012 06:18:32 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> My suggestion is therefore to do the simple thing, just apply any >> patches found in the patches dir, and punt on the complicated >> do-we-eautoreconf- or-not thing. > > Agreed. Just make sure the feature will be only used for ebuilds not > calling epatch_user manually or through the eclass. So the package manager is supposed to interact with an eclass function? That's pretty ugly. Why not just roll out a quick EAPI 5 that adds support for the "apply_user_patches_here" approach [1]? http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 11:43:37 -0700 Zac Medico wrote: > On 04/26/2012 11:27 AM, Michał Górny wrote: > > On Thu, 26 Apr 2012 06:18:32 + (UTC) > > Duncan <1i5t5.dun...@cox.net> wrote: > > > >> My suggestion is therefore to do the simple thing, just apply any > >> patches found in the patches dir, and punt on the complicated > >> do-we-eautoreconf- or-not thing. > > > > Agreed. Just make sure the feature will be only used for ebuilds not > > calling epatch_user manually or through the eclass. > > So the package manager is supposed to interact with an eclass > function? That's pretty ugly. Why not just roll out a quick EAPI 5 > that adds support for the "apply_user_patches_here" approach [1]? > > http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml 1) Because it's ugly hack, 2) it will have to interact with epatch_user anyway (at least to avoid applying patches twice), 3) it will work only for new/modified ebuilds so won't differ at all from using epatch_user(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 20:50:02 +0200 Michał Górny wrote: > > So the package manager is supposed to interact with an eclass > > function? That's pretty ugly. Why not just roll out a quick EAPI 5 > > that adds support for the "apply_user_patches_here" approach [1]? > > > > http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml > > 1) Because it's ugly hack, Awww. You say that about everything with my name on it. > 2) it will have to interact with epatch_user anyway (at least to avoid > applying patches twice), > 3) it will work only for new/modified ebuilds so won't differ at all > from using epatch_user(). Not if we kill epatch_user... Not like it works properly anyway, and it's better to have a "works properly or not at all" feature than one that breaks randomly. The package mangler could even make it fatal (at pretend time, no less) if someone wants to apply user patches to an ebuild whose EAPI doesn't support it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert wrote: > I haven't followed the prev. conversation but what's wrong with a USE flag for > SSE2? We already have SSE2 flags, even global.. That's not it. The flash binary uses SSE2 instructions without checking for their presence, which causes bad things on systems without SSE2. The purpose of the 'sse2check' flag was to die if the system doesn't have SSE2 and print a message telling the user to use an older version of flash. The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, 26 Apr 2012 15:15:34 -0400 Matt Turner wrote: > On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert > wrote: > > I haven't followed the prev. conversation but what's wrong with a > > USE flag for SSE2? We already have SSE2 flags, even global.. > > That's not it. The flash binary uses SSE2 instructions without > checking for their presence, which causes bad things on systems > without SSE2. The purpose of the 'sse2check' flag was to die if the > system doesn't have SSE2 and print a message telling the user to use > an older version of flash. > > The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547 > wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the problem ? afaik portage wont even try to upgrade if people have -sse2 A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, Apr 26, 2012 at 4:06 PM, Alexis Ballier wrote: > wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the > problem ? > > afaik portage wont even try to upgrade if people have -sse2 If that works, which I think it will, that does sound like the best thing to do.
[gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Dear all, I'd like to suggest we introduce the following very useful feature, as soon as possible (which likely means in the next EAPI?): * two new files in profile directories supported, package.use.stable.mask and package.use.stable.force * syntax is identical to package.use.mask and package.use.force * meaning is identical to package.use.mask and package.use.force, except that the resulting rules are ONLY applied iff a stable keyword is in use Rationale: Often single features are "not ready for production yet", but the remaining package with that feature disabled would be a perfect candidate for stabilization. Right now this can be solved by * masking the useflag, which then makes the feature inaccessible even for ~arch * masking the useflag for exactly one package revision, which is hell to maintain * or introducing different package revisions with/without the useflag, which is also a mess. Where this would (have been|be) useful: * we had for a long time different revisions of subversion with/without kde useflag * cups-1.4 had the infamous libusb backend triggered by USE=usb * cups-1.5 has optional systemd support via a systemd useflag, which pulls in non-stabilized systemd as dependency... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: > On 04/26/2012 02:55 AM, Duncan wrote: >> Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: >> >>> On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good >>> If that means settling on something that's fragile and prone to lots >>> of bug reports, then it's not really practical >> IMO[,] If all it does is the patching, but it /always/ does the >> patching[,] and people know they need to use the overlay-ebuild >> method to do anything beyond patching, [including eautoreconf,] >> then it should "just work". > Ignoring the problem doesn't make it go away. If we ignore the problem, > then we end up dealing with bug reports of the form "FEATURES=userpatch > doesn't work with this particular patch set" until the end of time. Standard boilerplate resolved/DUP, pointing to the first one, resolved like this: NOTABUG/INVALID. The feature does what it says on the label and is working as designed. The files are patched and the build bails out if the patch fails. The userpatch feature is deliberately limited to patching, thus keeping the problem manageable and the code transparent and maintainable. For anything fancy, including patches that need eautoreconf called afterward, the userpatch feature isn't the right tool. Copy the ebuild to an overlay and edit it as necessary to both apply the patch and eautoreconf or whatever else needs done afterward. > Also, don't forget to consider the possibility of interference between > FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Test for the existence of a file and punt if it's found; touch the file on first invocation. The only caveat is that the existing eclass solution has changed the filename before. Once the corresponding feature exists, both the eclass and the feature will have to use the same filename so as not to conflict with each other, thereby effectively locking down the name and preventing further changes to it. > Overall, the "apply_user_patches_here" approach [1] seems pretty > reasonable to me. > > [1] > http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run immediately after source_prepare, thus ensuring that it gets called, AND that calling either autoreconf or eautoreconf without calling apply-user- patches first is a repoman-checked error, it looks like it should work, agreed. But I'm a bit wary as to the robustness. And without a mechanism to apply the patches at a particular point (arguably, post-src-prepare) even in the absence of a specific apply-user-patches-here call, we're back where we were without a global solution, but if the hard-invocation is done, then we're back to either inefficiently running eautoreconf twice or forced into doing likely failure-prone detection, thus the worry over robustness. But of course he who codes, decides. We have existing and already proven code for the simple case, but if someone actually codes that complex approach, and it actually does both get us global coverage and avoid duplicated autoreconf runs, without hard to track down failures, I for one will certainly bless them! =:^) I just don't want to have to wait until kingdom come for the "perfect" solution, when we already have a demonstrated "good enough 80-90% of the time" solution ready to roll out globally, if we'd just do it. It's also worth pointing out that nothing prevents rolling out the "good enough" solution right away, then growing the complexity to cover the harder autoreconf cases when a solution for them actually gets coded. -- 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] Feature request: package.use.stable.mask and package.use.stable.force
On Thursday 26 April 2012 18:03:54 Andreas K. Huettel wrote: > * two new files in profile directories supported, package.use.stable.mask > and package.use.stable.force > * syntax is identical to package.use.mask and package.use.force > * meaning is identical to package.use.mask and package.use.force, except > that the resulting rules are ONLY applied iff a stable keyword is in use i'd love to see this as i'm tangling with pretty much the same problem: on ia64, we want java in ~arch, but never in stable (just don't have the resources for it). this causes problems for packages that have USE=java and are stable, but work fine when they're unstable. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 03:08 PM, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Test for the existence of a file and punt if it's found; touch the file on first invocation. The only caveat is that the existing eclass solution has changed the filename before. Once the corresponding feature exists, both the eclass and the feature will have to use the same filename so as not to conflict with each other, thereby effectively locking down the name and preventing further changes to it. Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi Overall, the "apply_user_patches_here" approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run immediately after source_prepare, thus ensuring that it gets called, AND that calling either autoreconf or eautoreconf without calling apply-user- patches first is a repoman-checked error, it looks like it should work, agreed. I think it might be better to die if it's not called in src_prepare, like Ciaran originally suggested. This ensures that people don't forget to call it when they are supposed to. But I'm a bit wary as to the robustness. And without a mechanism to apply the patches at a particular point (arguably, post-src-prepare) even in the absence of a specific apply-user-patches-here call, we're back where we were without a global solution, but if the hard-invocation is done, then we're back to either inefficiently running eautoreconf twice or forced into doing likely failure-prone detection, thus the worry over robustness. It's no worse than epatch_user currently is. It's the responsibility of the person who overrides src_prepare to call eautoreconf or whatever else when necessary, so the package manager will not have the burden. -- Thanks, Zac
[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/26/2012 06:03 PM, Andreas K. Huettel wrote: > I'd like to suggest we introduce the following very useful > feature, as soon as possible (which likely means in the next > EAPI?): > > * two new files in profile directories supported, > package.use.stable.mask and package.use.stable.force * syntax is > identical to package.use.mask and package.use.force * meaning is > identical to package.use.mask and package.use.force, except that > the resulting rules are ONLY applied iff a stable keyword is in > use As "a stable keyword is in use" is either ambiguous or outright wrong (depending on exactly what was meant by that), I would propose that one of the following cases replace that: * At least one keyword beginning with "~" or the value "**" is in the global ACCEPT_KEYWORDS. * At least one keyword beginning with "~" or the value "**" is in the ACCEPT_KEYWORDS used for the package in question. This is required because on a typical ~amd64 system, the effective value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered under "a stable keyword is in use" (the same applies for other arches as well). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPmiPhAAoJELHSF2kinlg4BRkP/2vxN8Wq9+tTdk54XifMm4T8 Q3p01uowvTYhTx2mIh2qLPMemtJ1ABCe7ZxpTkconE1Qw9VtgKsjuRX63glnsKDh wU6hzMH8RUFIA9BNDb4ZHstp35Okthtju67jPRiN2hp1DuYjTQ4kTKm9IIp14/8T hb9u7l2VEoyIuhYSAm1b1VjkIS5OO16tCkwiWF0HqaWCfw0z65/HncARf+D35cfZ giHV9qwTvHoXCh2PBq7XyJaCs3XYcNfmAV7o8tBpXxAvzqWRbh2hMLgSpmIxFjXM 3MvqdjVmNJowovAiLatHMby4ogO9Gq1A4svoYXsOuTC9lC4XQDp6md9zCcAPBD8w qBEnixWb2p4xfqpzk0zP6JxmvQkKmPPzWVoBuV8lYni8jN/GFRntnT35GEwiA/si 04/wg3+w/cG4q5vglExrFpT3cNG8nkMPmqQIN8XrtdhGnOCyLYrAd4lvymEVf4/8 ymD36BZwQ6xW3yjbWEl/CmvpdbRjrFBp5pzebFGzZxnWrrnGQtVBYYA4o7GoPvhu hsNtCM/C8afynflTvaiX+9/bzbwrKSN5+4VmTT+9m+sQBwbnFy6iby1X5HlmE/Ie L6k2iTxT0hrNxwZaf6eYR2zxjzV6FiDkO6eBEgYFNcOd+JgZ5/+dKJ/1CHy753d/ 2zXMNmzVLT6fXLHrAH6m =pmWk -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, 26 Apr 2012 17:06:45 -0300 Alexis Ballier wrote: > On Thu, 26 Apr 2012 15:15:34 -0400 > Matt Turner wrote: > > > On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert > > wrote: > > > I haven't followed the prev. conversation but what's wrong with a > > > USE flag for SSE2? We already have SSE2 flags, even global.. > > > > That's not it. The flash binary uses SSE2 instructions without > > checking for their presence, which causes bad things on systems > > without SSE2. The purpose of the 'sse2check' flag was to die if the > > system doesn't have SSE2 and print a message telling the user to use > > an older version of flash. > > > > The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547 > > > > wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the > problem ? > > afaik portage wont even try to upgrade if people have -sse2 I like that, but it doesn't address building on a host not supporting SSE2 for a target that does. That's the reason the USE flag was added - to provide a workaround for the die. I'm saying just don't die at all. It doesn't provide anything but another way for the ebuild to fail. An ewarn for the very few people that will actually encounter this should be enough. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, 26 Apr 2012 18:00:04 +0200 Jeroen Roovers wrote: > On Wed, 25 Apr 2012 23:04:08 -0600 > Ryan Hill wrote: > > > especially for an instruction set that every system has supported > > for over a decade. > > Er, some of my teenage systems run desktops just fine here, thanks. And > one of them is just nine years old right now but still doesn't support > SSE2 (merely SSE[1]). I knew I'd get called on that. s/every/almost every -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On Friday 27 April 2012 00:43:15 Jonathan Callen wrote: > On 04/26/2012 06:03 PM, Andreas K. Huettel wrote: > > I'd like to suggest we introduce the following very useful > > feature, as soon as possible (which likely means in the next > > EAPI?): > > > > * two new files in profile directories supported, > > package.use.stable.mask and package.use.stable.force * syntax is > > identical to package.use.mask and package.use.force * meaning is > > identical to package.use.mask and package.use.force, except that > > the resulting rules are ONLY applied iff a stable keyword is in > > use > > As "a stable keyword is in use" is either ambiguous or outright wrong > (depending on exactly what was meant by that), I would propose that > one of the following cases replace that: > > * At least one keyword beginning with "~" or the value "**" is in the > global ACCEPT_KEYWORDS. > * At least one keyword beginning with "~" or the value "**" is in the > ACCEPT_KEYWORDS used for the package in question. > > This is required because on a typical ~amd64 system, the effective > value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered > under "a stable keyword is in use" (the same applies for other arches > as well). i don't think that wording is correct and misses the point. simple example of how this should work: if package.use.stable.force has: cat/pkg foo and then cat/pkg/pkg-0.ebuild has: KEYWORDS="~amd64 x86" the forcing of "foo" would apply to people who are ARCH=x86 (regardless of their ACCEPT_KEYWORDS containing ~x86), but not apply to people who are ARCH=amd64. once the ebuild changes to KEYWORDS="amd64 x86", then it would apply to both. i.e. the keyword matching is to the ebuild, not to the user's ACCEPT_KEYWORDS. or Andreas can clarify. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On 04/26/2012 11:28 PM, Mike Frysinger wrote:
> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
>>> I'd like to suggest we introduce the following very useful
>>> feature, as soon as possible (which likely means in the next
>>> EAPI?):
>>>
>>> * two new files in profile directories supported,
>>> package.use.stable.mask and package.use.stable.force * syntax is
>>> identical to package.use.mask and package.use.force * meaning is
>>> identical to package.use.mask and package.use.force, except that
>>> the resulting rules are ONLY applied iff a stable keyword is in
>>> use
>>
>> As "a stable keyword is in use" is either ambiguous or outright wrong
>> (depending on exactly what was meant by that), I would propose that
>> one of the following cases replace that:
>>
>> * At least one keyword beginning with "~" or the value "**" is in the
>> global ACCEPT_KEYWORDS.
>> * At least one keyword beginning with "~" or the value "**" is in the
>> ACCEPT_KEYWORDS used for the package in question.
>>
>> This is required because on a typical ~amd64 system, the effective
>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
>> under "a stable keyword is in use" (the same applies for other arches
>> as well).
>
> i don't think that wording is correct and misses the point. simple example
> of
> how this should work:
>
> if package.use.stable.force has:
> cat/pkg foo
>
> and then cat/pkg/pkg-0.ebuild has:
> KEYWORDS="~amd64 x86"
>
> the forcing of "foo" would apply to people who are ARCH=x86 (regardless of
> their ACCEPT_KEYWORDS containing ~x86), but not apply to people who are
> ARCH=amd64. once the ebuild changes to KEYWORDS="amd64 x86", then it would
> apply to both.
>
> i.e. the keyword matching is to the ebuild, not to the user's ACCEPT_KEYWORDS.
That makes sense in the context of trying to keep repoman from
complaining. Since repoman complains about stable keywords for packages
with unstable dependencies, package.use.stable.{force,mask} will serve
to mask off conditional dependencies that would otherwise trigger
*DEPEND.bad complaints from repoman.
--
Thanks,
Zac
