[gentoo-dev] Re: Making user patches globally available
On Wed, 25 Apr 2012 22:03:18 -0700 Zac Medico zmed...@gentoo.org wrote: On 04/25/2012 09:44 PM, Ryan Hill wrote: Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. Using the apply_user_patches_here approach [1] that Ciaran suggested, the ebuild wouldn't need any modification unless it overrides default_src_prepare. Which is a very large number of ebuilds. :) But it's a step in the right direction. There is not necessarily any eclass dependence, though the ebuild may call eclass functions such as eautoreconf when necessary. [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
Ryan Hill posted on Wed, 25 Apr 2012 22:44:33 -0600 as excerpted: On Wed, 18 Apr 2012 22:41:39 +0100 David Leverton levert...@googlemail.com wrote: The point I was trying to get at was that it seems a bit heavyweight to rely on a whole eclass for a minor use-case, as well as a bit error-prone to expect people to remember it every time, but maybe that's the least bad option after all Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. Being a user of this functionality since name forgotten, unfortunately first introduced it with his bashrc hooks and the additional FEATURES=userpatch he used, and currently using a nasty hack to ensure that it gets run for every package, even those not calling base.eclass... IMO we're over-thinking this. Keep in mind that while being able to simply drop a patch in /etc/portage/patches/cat/pkg/ is very useful indeed, ultimately, all it does is eliminate the necessity of manually copying the ebuild to a personal overlay and setting up the patch to be applied via the ebuild itself. 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. Just having the patches applied consistently will be a HUGE improvement from what we have at the moment, and it doesn't prevent people from falling back to the old copy-ebuild-to-overlay-and-modify method, should anything fancy, including eautoreconf, but of course also including all the other things people modify ebuilds for OTHER than simple patching, be needed. IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. I know from experience that this eliminates a good 80-90% of what would otherwise be personal overlay ebuilds, here, and it's not as if it's an EITHER overlay OR patches dir thing, so let's just do it, and people who need anything fancier can still do the overlay thing they're doing now, while those just applying a simple patch no longer have to worry about whether dropping it in patches is enough or not. -- 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] Re: Making user patches globally available
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). -- Thanks, Zac
Re: [gentoo-dev] [RFC] New third party mirrors
On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary corentin.ch...@gmail.com wrote: On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 24 Apr 2012 16:19:11 + Robin H. Johnson robb...@gentoo.org 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 mgo...@gentoo.org wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary corentin.ch...@gmail.com wrote: On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 24 Apr 2012 16:19:11 + Robin H. Johnson robb...@gentoo.org 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 zmed...@gentoo.org wrote: On 04/26/2012 12:30 AM, Corentin Chary wrote: On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary corentin.ch...@gmail.com wrote: On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 24 Apr 2012 16:19:11 + Robin H. Johnson robb...@gentoo.org 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 zmed...@gentoo.org wrote: On 04/26/2012 12:30 AM, Corentin Chary wrote: On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary corentin.ch...@gmail.com wrote: On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 24 Apr 2012 16:19:11 + Robin H. Johnson robb...@gentoo.org 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 zmed...@gentoo.org wrote: On 04/26/2012 01:03 AM, Corentin Chary wrote: On Thu, Apr 26, 2012 at 9:57 AM, Zac Medico zmed...@gentoo.org wrote: On 04/26/2012 12:30 AM, Corentin Chary wrote: On Wed, Apr 25, 2012 at 6:41 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 25 Apr 2012 09:16:05 +0200 Corentin Chary corentin.ch...@gmail.com wrote: On Tue, Apr 24, 2012 at 6:38 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 24 Apr 2012 16:19:11 + Robin H. Johnson robb...@gentoo.org 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 pso...@gentoo.org (26 Apr 2012) # No longer maintained. # Masked for removal in 30 days wrt #412189 sys-kernel/mm-sources -- Stratos Psomadakis pso...@gentoo.org 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 dirtye...@gentoo.org 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 dirtye...@gentoo.org 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 corentin.ch...@gmail.com 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 zmed...@gentoo.org 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 mgo...@gentoo.org 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 id...@gentoo.org 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, Apr 26, 2012 at 4:06 PM, Alexis Ballier aball...@gentoo.org 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 aball...@gentoo.org wrote: On Thu, 26 Apr 2012 15:15:34 -0400 Matt Turner matts...@gentoo.org wrote: On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert id...@gentoo.org 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 j...@gentoo.org wrote: On Wed, 25 Apr 2012 23:04:08 -0600 Ryan Hill dirtye...@gentoo.org 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
