[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-kernel/linux-headers: ChangeLog linux-headers-2.6.26.ebuild
On Wed, Aug 20, 2008 at 02:57:03AM +, Mike Frysinger (vapier) wrote:
> 1.1 sys-kernel/linux-headers/linux-headers-2.6.26.ebuild
...
> src_install() {
> kernel-2_src_install
> cd "${D}"
> egrep -r \
> -e '[[:space:]](asm|volatile|inline)[[:space:](]' \
> -e '\<([us](8|16|32|64))\>' \
> .
> headers___fix $(find -type f)
> }
...
Are you missing a pipe after the egrep statement? What's the point of
just spitting to stdout?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?
On Thu, Aug 21, 2008 at 8:35 AM, Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > >> On Tue, 19 Aug 2008 21:27:03 +0100 >> Steve Long <[EMAIL PROTECTED]> wrote: >>> > On Tue, 19 Aug 2008 23:31:17 +0530 >>> > Arun Raghavan <[EMAIL PROTECTED]> wrote: >>> >> Ciaran McCreesh wrote: >>> >> > The benefit is that it's a logically separate action, and will >>> >> > avoid all the silliness of people repeatedly changing their >>> >> > minds about which phase should do the eautoreconf calls and so >>> >> > on. >>> Er, that would be the new src_configure? >> >> Oh really? >> > Hmm fun as it isn't playing these games with you.. > If he doesn't respond with anything useful; just act like he conceded the point and move on. >>> > In the grand scheme of things, no. In the grand scheme of things, >>> > you only *need* a single src_ function. From a maintainer >>> > convenience perspective, however, src_prepare is marginally more >>> > useful than having a split src_configure. >>> > >>> How so? >>> >>> From a user point of view, and from a maintenance point of view, >>> src_configure is very useful. >> >> Any reason you can provide for src_configure being useful can be used >> with slight modification for src_prepare. >> > Which is no reason to add a new phase. OFC if zac wants to provide it that's > entirely up to him. > You are saying src_configure is useful; he is saying src_prepare is useful. both of you are arguments as to why you think that way; that is all he is saying. >>> > It's a better mapping of the things ebuilds do than the current set >>> > of functions. >>> > >>> > The logic is this: lots of ebuilds end up duplicating src_unpack >>> > (or, in future EAPIs, calling 'default') and then adding things to >>> > do preparation work. Experience suggests that the most common >>> > reason for overriding src_unpack is to do preparation work, not to >>> > change how things are unpacked. >>> > >>> Yeah I've always seen src_unpack as being more cogent to preparation >>> of src files, than to actually untarring stuff. >> >> Yes, the 'unpack' in the name really does go along with the phase being >> used to prepare things. >> > Oh so this is about correct nomenclature rather than anything else? I see. > >>> So what? Why make a new phase which every new dev has to know about, >>> and we have to provide pre_ and post_ hooks for, when the existing >>> phase covers the usage fine? >> >> Make a phase for each common logically distinct operation. Which, with >> src_prepare being added, we almost have. >> > Yes, I see, because it's really needed; real functionality our users have > been crying out for. > At least one has...do you want to vote for each feature? What will it take to convince you? >> (The one missing is a src_fetch_extra or somesuch, for use by the scm >> eclasses. But that wants special handling, and is probably best left to >> another EAPI...) >> > Yes, a defined, configurable API for dealing with any version control would > be useful, though your minion seemed to argue against it in #-portage. I > can think of a couple of things that would be more useful to end-users: > pkg_check for interactive ebuilds (eg license acceptance or media access), > proper support for cross-compiling, integration of prefix, better handling > of overlays, and of binpkgs.. > Your comment is arguably about feature prioritization; not about whether a given feature is necessary. If we have two orthogonal features A and B; you can't argue that A is necessary and B is not because A is more important to work on; the only thing you have succeeded in doing is arguing that A should be done first. >>> > (Number-wise... For Exherbo, where the split's already been made, >>> > custom src_prepare functions are three times more common than custom >>> > src_unpack functions. And that figure's significantly lower than >>> > what Gentoo would see, because with exheres-0 'default' functions >>> > you don't need to write a src_prepare if you're merely applying >>> > patches.) >>> > >>> Well it's easy enough to auto-apply patches, given a declaration in >>> the ebuild (since files for all versions are in the same dir.) It >>> certainly doesn't need a new phase. >> >> Well, if you're proposing that Gentoo also adopts the more complicated >> default_* functions from exheres-0, you're more than welcome to write >> up a proposal... >> > Tsk of course not. default functions are in the pipeline in any case, but > glad to see you're still using this list for proselytising your pet project > while avoiding true discussion. In any event, it wouldn't be needed. > >>> >> The *only* potential "benefit" I see here is that at some point of >>> >> time in the nebulous future, it might be possible to tell the PM to >>> >> always skip src_prepare in order to give a system where everything >>> >> is "vanilla". >>> > >>> > Such a system wouldn't be usable... Not all of Gentoo's patches are >>> > non-essential. >>> > >>> So the real, fully-defined, ex
Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
On Tue, Aug 19, 2008 at 11:31:17PM +0530, Arun Raghavan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ciaran McCreesh wrote: > [...] > > The benefit is that it's a logically separate action, and will avoid > > all the silliness of people repeatedly changing their minds about > > which phase should do the eautoreconf calls and so on. > > a) Is this really an issue for maintainers? As someone who has worked with exheres, I very much want this phase for EAPI 2. It makes things simpler and more logical. Why should patching be done in _unpack? It shouldn't, and that's a reason why _prepare should be added. > b) Does it really matter? To me, yes pgpaXQSYQmSiY.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?
On Thu, 21 Aug 2008 16:35:18 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Hmm fun as it isn't playing these games with you.. What? Deliberately arguing against an idea because it comes from the wrong people, even though they're the only ones with the practical experience on the issue? > > Any reason you can provide for src_configure being useful can be > > used with slight modification for src_prepare. > > > Which is no reason to add a new phase. OFC if zac wants to provide it > that's entirely up to him. Are you saying it is entirely up to him or that it should be entirely up to him? > >> Yeah I've always seen src_unpack as being more cogent to > >> preparation of src files, than to actually untarring stuff. > > > > Yes, the 'unpack' in the name really does go along with the phase > > being used to prepare things. > > > Oh so this is about correct nomenclature rather than anything else? I > see. It's about making the ebuild language fit what most ebuilds do. > > Make a phase for each common logically distinct operation. Which, > > with src_prepare being added, we almost have. > > > Yes, I see, because it's really needed; real functionality our users > have been crying out for. This one's a developer-targeted feature. The benefit to users is that a) developers have a nicer package format to work with, and b) when they want to add patches to an ebuild locally, they don't have to know how to reimplement src_unpack correctly. > > (The one missing is a src_fetch_extra or somesuch, for use by the > > scm eclasses. But that wants special handling, and is probably best > > left to another EAPI...) > > > Yes, a defined, configurable API for dealing with any version control > would be useful, though your minion seemed to argue against it in > #-portage. I can think of a couple of things that would be more > useful to end-users: pkg_check for interactive ebuilds (eg license > acceptance or media access), proper support for cross-compiling, > integration of prefix, better handling of overlays, and of binpkgs.. And all of those are complicated features that can't be delivered with ten minutes work, which would mean delaying EAPI 2. > > Well, if you're proposing that Gentoo also adopts the more > > complicated default_* functions from exheres-0, you're more than > > welcome to write up a proposal... > > > Tsk of course not. default functions are in the pipeline in any case, > but glad to see you're still using this list for proselytising your > pet project while avoiding true discussion. You misunderstand, again. Exheres has two improvements on default functions: the default_*/default mechanism, and better default_ implementations. Portage is taking only the former for EAPI 2. > In any event, it wouldn't be needed. Sure. You can do away with all the helpers and all the default functions in a future EAPI if you want. But all that'd do is make writing correct ebuilds much more tedious. Or, you can go the other way, as Exheres has, and improve the current lot of defaults to make writing ebuilds even easier. > The reasoning others have given (yes it is possible to explain why > without making people read thru 20 one line emails) is that this > would be useful for live ebuilds. Neither src_configure nor src_prepare makes much difference to live ebuilds. > Call the function what you like (or add a new phase with the hooks) > it's still logically one point in time. For a live ebuild it's to > prepare the src, for a normal one to (possibly) unpack and prepare. Uhm. I think you're completely misunderstanding src_prepare. Go back and read the original email. If that's not clear enough for you, also have a look at how it's being used in Exherbo -- you can see plenty of practical examples. Then, once you've done so, please explain how the added simplicity and clarity is not a benefit. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote: > On Tue, 19 Aug 2008 21:27:03 +0100 > Steve Long <[EMAIL PROTECTED]> wrote: >> > On Tue, 19 Aug 2008 23:31:17 +0530 >> > Arun Raghavan <[EMAIL PROTECTED]> wrote: >> >> Ciaran McCreesh wrote: >> >> > The benefit is that it's a logically separate action, and will >> >> > avoid all the silliness of people repeatedly changing their >> >> > minds about which phase should do the eautoreconf calls and so >> >> > on. >> Er, that would be the new src_configure? > > Oh really? > Hmm fun as it isn't playing these games with you.. >> > In the grand scheme of things, no. In the grand scheme of things, >> > you only *need* a single src_ function. From a maintainer >> > convenience perspective, however, src_prepare is marginally more >> > useful than having a split src_configure. >> > >> How so? >> >> From a user point of view, and from a maintenance point of view, >> src_configure is very useful. > > Any reason you can provide for src_configure being useful can be used > with slight modification for src_prepare. > Which is no reason to add a new phase. OFC if zac wants to provide it that's entirely up to him. >> > It's a better mapping of the things ebuilds do than the current set >> > of functions. >> > >> > The logic is this: lots of ebuilds end up duplicating src_unpack >> > (or, in future EAPIs, calling 'default') and then adding things to >> > do preparation work. Experience suggests that the most common >> > reason for overriding src_unpack is to do preparation work, not to >> > change how things are unpacked. >> > >> Yeah I've always seen src_unpack as being more cogent to preparation >> of src files, than to actually untarring stuff. > > Yes, the 'unpack' in the name really does go along with the phase being > used to prepare things. > Oh so this is about correct nomenclature rather than anything else? I see. >> So what? Why make a new phase which every new dev has to know about, >> and we have to provide pre_ and post_ hooks for, when the existing >> phase covers the usage fine? > > Make a phase for each common logically distinct operation. Which, with > src_prepare being added, we almost have. > Yes, I see, because it's really needed; real functionality our users have been crying out for. > (The one missing is a src_fetch_extra or somesuch, for use by the scm > eclasses. But that wants special handling, and is probably best left to > another EAPI...) > Yes, a defined, configurable API for dealing with any version control would be useful, though your minion seemed to argue against it in #-portage. I can think of a couple of things that would be more useful to end-users: pkg_check for interactive ebuilds (eg license acceptance or media access), proper support for cross-compiling, integration of prefix, better handling of overlays, and of binpkgs.. >> > (Number-wise... For Exherbo, where the split's already been made, >> > custom src_prepare functions are three times more common than custom >> > src_unpack functions. And that figure's significantly lower than >> > what Gentoo would see, because with exheres-0 'default' functions >> > you don't need to write a src_prepare if you're merely applying >> > patches.) >> > >> Well it's easy enough to auto-apply patches, given a declaration in >> the ebuild (since files for all versions are in the same dir.) It >> certainly doesn't need a new phase. > > Well, if you're proposing that Gentoo also adopts the more complicated > default_* functions from exheres-0, you're more than welcome to write > up a proposal... > Tsk of course not. default functions are in the pipeline in any case, but glad to see you're still using this list for proselytising your pet project while avoiding true discussion. In any event, it wouldn't be needed. >> >> The *only* potential "benefit" I see here is that at some point of >> >> time in the nebulous future, it might be possible to tell the PM to >> >> always skip src_prepare in order to give a system where everything >> >> is "vanilla". >> > >> > Such a system wouldn't be usable... Not all of Gentoo's patches are >> > non-essential. >> > >> So the real, fully-defined, explicit benefit is.. > > The same as the benefit of splitting src_compile into src_configure and > src_compile, except that it'll be of use to a slightly larger > proportion of ebuilds. > As ever, you fail to argue the actual case, preferring to hide behind "the same reasons as.." which is a variant on the "if you don't understand some one line comment, you're not qualified to discuss anything (plus you're ugly.)" The reasoning others have given (yes it is possible to explain why without making people read thru 20 one line emails) is that this would be useful for live ebuilds. In maintenance terms (when looking at the lifecycle of an ebuild) I don't see the need, since there is no unpacking required from a vcs pull. Once it's made into a normal ebuild, any preparation would necessarily require review and might not be needed at all
Re: [gentoo-dev] License Interpretation
On Wed, Aug 20, 2008 at 9:10 PM, Jim Ramsay <[EMAIL PROTECTED]> wrote: > 2.5.1 You may not modify, adapt, translate or create derivative works > based upon the Software. You may not reverse engineer, decompile, > disassemble or otherwise attempt to discover the source code of the > Software except to the extent you may be expressly permitted to > decompile under applicable law, it is essential to do so in order to > achieve operability of the Software with another software program, and > you have first requested Adobe to provide the information necessary to > achieve such operability and Adobe has not made such information > available. > > I *think* I would be okay using this binary patch since: > > 1) This is specifically to make it operable with libcurl.so.4 > 2) I have (and others have) asked Adobe to recompile it with support > for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or > responded to any of these requests, as far as I am aware). Actually (and I'm no lawyer either), I think a binary patch isn't allowed: > You may not modify, adapt, translate or create derivative works > based upon the Software. The rest of the paragraph is about obtaining (or trying to obtain) its source code or application behavior, i.e. learn the program, not modify it. Wkr, Sven Vermeulen
