Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On 04/26/2012 11:48 PM, Zac Medico wrote:
> 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.
Actually, I don't think the specification should involve ARCH. In order
to determine whether package.use.stable.{force,mask} apply, I would
intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
package.use.stable.{force,mask} if this intersection contains only
stable keywords. So, I think that I mostly agree with Jonathan's
statements, though I describe the behavior slightly differently than how
he did.
--
Thanks,
Zac
Re: [gentoo-dev] [RFC] New third party mirrors
On Thu, Apr 26, 2012 at 8:41 PM, Michał Górny wrote: > 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. Works for me. What would be the next step to push this ? -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
On 04/27/12 00:03, Andreas K. Huettel wrote: 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 Wouldn't it be more obvious/simple to have an extra profile subdirectory containing package.use.mask and package.use.force? Maybe in combination with 'eselect profile' to be able to select multiple profiles [1], selecting both what /etc/make.profile pointed to as symlink as well as some /usr/portage/profile/unstable/$arch - to avoid the need for having an extra unstable/ subdir within each (selectable) profile dir. Actually, I do have an extra unstable/ subdir for each selectable profile here, besides an extra buildbot/ subdir too... As a side effect, this wouldn't affect EAPI in any way. [1] http://archives.gentoo.org/gentoo-dev/msg_a69bee8bfa00146ee05e49adf722e791.xml my .02 /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] New license: yEd Software License Agreement
Hi, I'd like to add attached license to portage/licenses/. Any objections? -- Amadeusz Żołnowski yEd Description: Binary data 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 Fri, Apr 27, 2012 at 08:23, Ryan Hill wrote: > On Thu, 26 Apr 2012 18:00:04 +0200, Jeroen Roovers wrote: >> 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 I suspect that you are missing the point; see https://en.wikipedia.org/wiki/List_of_AMD_Athlon_XP_microprocessors. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
On Fri, 27 Apr 2012 00:03:54 +0200 "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 This means that an ebuild will effectively change when moved from ~arch to arch. The point of ~arch is to test ebuilds before they're moved to arch. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
This license would go to EULA group. Is this correct? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Ciaran McCreesh schrieb: >> * 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 > This means that an ebuild will effectively change when moved from ~arch > to arch. The point of ~arch is to test ebuilds before they're moved to > arch. I agree that the ~arch ebuilds should be tested in the same configuration in which they will end up in arch. However in this case, the possible configurations for arch are a subset of those in ~arch, so the testing covers those too. I see a problem where a significant proportion of ~arch users will have this flag enabled (which is obviously the point of package.use.stable.mask) so the arch configurations will see fewer testers. This issue may need to be addressed, e.g. by extending stabilization period or disallowing package.use.stable.mask in default or desktop profile. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] New third party mirrors
On Fri, 27 Apr 2012 10:06:38 +0200 Corentin Chary wrote: > On Thu, Apr 26, 2012 at 8:41 PM, Michał Górny > wrote: > > 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. > > Works for me. What would be the next step to push this ? Next step would be to find a good name :P. I suggest going the Perl way and prepending '~' ;P. -- Best regards, Michał Górny 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, 26 Apr 2012 23:19:04 -0600 Ryan Hill wrote: > 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. Why? Enable sse2 when cross-"building" and be done. Note: There's no more check via /proc/cpuinfo that way. A.
[gentoo-dev] Re: New license: yEd Software License Agreement
Amadeusz Żołnowski posted on Fri, 27 Apr 2012 13:30:32 +0200 as excerpted: > This license would go to EULA group. Is this correct? That appears to be correct to me, yes. No distribution allowed. You're going to be doing restrict=mirror, correct? -- 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: New license: yEd Software License Agreement
Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: > No distribution allowed. You're going to be doing restrict=mirror, > correct? Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
> On Fri, 27 Apr 2012, Chí-Thanh Christopher Nguyễn wrote: > Ciaran McCreesh schrieb: >>> * 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 >> This means that an ebuild will effectively change when moved from >> ~arch to arch. The point of ~arch is to test ebuilds before they're >> moved to arch. > I agree that the ~arch ebuilds should be tested in the same > configuration in which they will end up in arch. However in this > case, the possible configurations for arch are a subset of those in > ~arch, so the testing covers those too. Maybe I'm missing something, but what would happen when the newest version of a package is marked stable? The masked USE flags would become unavailable for everyone? Ulrich
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: > 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. > 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 But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. Tho I guess one solution to that would be to change the name of the patches dir for the new version, calling it /etc/portage/patches2/ or some such. Another solution could be to make the existing epatch_user call a no-op, and force post-src-prepare invocation on EAPIs 1-4. But both of these have problems in that they nullify the work done in existing ebuilds to locate the call correctly, before eautoreconf or whatever. > >>> 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 fit 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. That can work for EAPI-5, but what about existing ebuilds? Remember, the goal is global coverage without forcing an edit to every existing ebuild that doesn't yet call it either directly or via eclass. >> 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. Except that in ordered to make it global without touching existing ebuilds, the PM MUST shoulder the burden. THAT is where the robustness issues appear. The require-it-in-EAPI-5-plus-only solution will help longer term, but given that many core packages are to remain EAPI-0 for the foreseeable future, that could be a VERY long term indeed. Additionally, it only makes user confusion WORSE, since a user still won't know for sure whether his patches will apply to a particular ebuild without looking. Making it "just work" is the goal, and just doing it for EAPI-5+ is nice, but not really sufficient. -- 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 Fri, 27 Apr 2012 14:15:35 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: > > > 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. > > > 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 > > But that doesn't solve the problem of making it globally available, > since it only applies to packages/eclasses that already call > epatch_user for EAPIs thru current EAPI-4. > > In ordered to make it globally available, it cannot simply be an > EAPI-5 thing, it must apply to all current ebuilds whether they (or > an inherited eclass) call epatch_user or not. Which means that > conflict with the existing epatch_user is unavoidable, since it will > either try to run twice where it's already called, or it won't run at > all where it's not. > > Tho I guess one solution to that would be to change the name of the > patches dir for the new version, calling it /etc/portage/patches2/ or > some such. Another solution could be to make the existing > epatch_user call a no-op, and force post-src-prepare invocation on > EAPIs 1-4. > > But both of these have problems in that they nullify the work done in > existing ebuilds to locate the call correctly, before eautoreconf or > whatever. We could finally decide it'll be a Portage internal feature, and modify epatch_user() to export some Portage-specific indication that user patches were applied. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
Amadeusz Żołnowski posted on Fri, 27 Apr 2012 15:45:36 +0200 as excerpted: > Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: >> No distribution allowed. You're going to be doing restrict=mirror, >> correct? > > Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. That works. RESTRICT=fetch is stricter so works, but I'm not sure whether it's necessary as I've not paid attention to the legal distinctions since both are out of the question here, but certainly, gentoo can't distribute, so restrict=mirror for sure. Whether it merits restrict=fetch or not I'll let someone else worry about. -- 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 Fri, 27 Apr 2012 14:15:35 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > In ordered to make it globally available, it cannot simply be an > EAPI-5 thing, it must apply to all current ebuilds whether they (or > an inherited eclass) call epatch_user or not. Which means that > conflict with the existing epatch_user is unavoidable, since it will > either try to run twice where it's already called, or it won't run at > all where it's not. In order to make it globally available, you put it in EAPI 5, and make the package mangler die at pretend time if the user has patches specified for a package that isn't EAPI 5. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/04/12 06:03 PM, Andreas K. Huettel wrote: > > 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. I would think, personally, that masking the useflag on a per-package basis would be better than this new feature -- it is more work as it needs to be done for all the different ~arch packages the use flag applies to, but it would mean that when a given ~arch version bump has that feature ready one wouldn't lose the mask on the previous ~arch versions. It would also mean (i assume) that this flag would be masked if that version went stable too (although in reality I would expect this wouldn't ever occur). There are potentially a lot of package entries to manage if this were, say, a flag like 'introspection'.. however, i'm sure maintaining this could be scriptable couldn't it? > > 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... > I'm not sure that I'm following the cups examples here. For cups-1.5 even if it were stable, if someone actually wanted to use systemd on their system and unmasked/keyworded it (while running stable everything else) I don't see why this would be an issue that would need this new masking feature (unless IUSE="+systemd", which probably shouldn't be the case anyways). Ian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk+ara4ACgkQ2ugaI38ACPALZwD/bIk3GzOThs6P/2EkWn2DxvEY XHQZVUvmc1dJBERmSiIA/3saDFCoK79S8fw+2Q9Myf9Lt6PdEc4u1j48QcDf+sKW =XQ3/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 9:45 AM, Amadeusz Żołnowski wrote: > Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: >> No distribution allowed. You're going to be doing restrict=mirror, >> correct? > > Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. > I don't see much point in using RESTRICT=fetch unless there is no URL available to fetch. I think RESTRICT=mirror should be sufficient in most cases to cover situations where we are not allowed to redistribute, and is consistent with what we do across the tree. Consistency is very important where there are legal concerns. Otherwise our actions with one ebuild will be used to argue that our actions on another ebuild are wrong. Rich
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 02:26:07PM +, Duncan wrote: > Amadeusz Żołnowski posted on Fri, 27 Apr 2012 15:45:36 +0200 as excerpted: > > > Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: > >> No distribution allowed. You're going to be doing restrict=mirror, > >> correct? > > > > Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. > > That works. RESTRICT=fetch is stricter so works, but I'm not sure > whether it's necessary as I've not paid attention to the legal > distinctions since both are out of the question here, but certainly, > gentoo can't distribute, so restrict=mirror for sure. Whether it merits > restrict=fetch or not I'll let someone else worry about. Definitely you should use restrict=mirror. Restrict=fetch is used when a user has to go to a web site and register or accept a license on the web site before they download the file the way I understand it. William pgpFqGmuYcBtm.pgp Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
William Hubbs posted on Fri, 27 Apr 2012 09:34:05 -0500 as excerpted: > Restrict=fetch is used when a user has to go to a web site and register > or accept a license on the web site before they download the file the > way I understand it. Thanks. I thought restrict=fetch was for when a website acceptance was required, but upon being pressed, I realized I wasn't sure enough about it to be comfortable trying to explain it. Tho FWIW I think restrict=fetch applies to stuff like cd/dvd-based game data as well, where the agreement is on the cd not a website, but still requires specific click-thru. IOW, manual click-thru and fetch, regardless of whether it's from local device, or from the net. If we're just forbidden from distributing but can still script an auto-fetch (they just want to be sure they control distribution, mainly), then it's restrict=mirror. If we can't script an auto-fetch either, generally due to direct click-thru agreement required, it's restrict=fetch. My definitely non-professional legal understanding, of course. -- 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 Fri, Apr 27, 2012 at 7:35 AM, Chí-Thanh Christopher Nguyễn wrote: > I agree that the ~arch ebuilds should be tested in the same > configuration in which they will end up in arch. However in this case, > the possible configurations for arch are a subset of those in ~arch, so > the testing covers those too. Just because a stable system brings in fewer use flags doesn't necessarily mean that it is less likely to break. Use flags can have all kinds of effects, some applied when they are present, and others applied when they are absent. The value of testing comes from testing things in the anticipated future production environment. Of course, the fact that we stabilize individual packages and not all their libraries/etc at the same time already weakens this. Rich
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 10:54 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Tho FWIW I think restrict=fetch applies to stuff like cd/dvd-based game > data as well, where the agreement is on the cd not a website, but still > requires specific click-thru. I think the real determiner should almost always be whether there is a URL that you can reliably fetch or not. If you're talking about a CD there is nothing to fetch. If you want somebody to copy a file off of a CD and stick it in distfiles then RESTRICT=fetch makes perfect sense, but it has nothing to do with licensing, but the fact that no consistent URL exists. Legally the basic issue is whether linking to something is the same as distributing it. I'm open to a lawyer's summary, but my sense is that the case law around this is very messy, especially on an international scale. Rich
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
On 04/27/2012 06:49 AM, Ulrich Mueller wrote:
>> On Fri, 27 Apr 2012, Chí-Thanh Christopher Nguyễn wrote:
>
>> Ciaran McCreesh schrieb:
* 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
>>> This means that an ebuild will effectively change when moved from
>>> ~arch to arch. The point of ~arch is to test ebuilds before they're
>>> moved to arch.
>
>> I agree that the ~arch ebuilds should be tested in the same
>> configuration in which they will end up in arch. However in this
>> case, the possible configurations for arch are a subset of those in
>> ~arch, so the testing covers those too.
>
> Maybe I'm missing something, but what would happen when the newest
> version of a package is marked stable? The masked USE flags would
> become unavailable for everyone?
In order to be practical, I guess we'd have to add a constraint which
says that if KEYWORDS contains the stable variant of a particular
keyword, then it should also be considered to implicitly contain the
unstable variant when the package manager is deciding whether or not to
apply package.use.{mask,force}.
So, here's a description of the whole algorithm that I'd use:
1) Let EFFECTIVE_KEYWORDS equal the set of values contained in KEYWORDS,
plus ** and all the unstable variants of the stable values contained in
KEYWORDS. For example:
KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS, where
effective ACCEPT_KEYWORDS includes any relevant values from
package.accept_keywords. For example, here is a table of intersections
of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with various effective
ACCEPT_KEYWORDS values:
ACCEPT_KEYWORDS | INTERSECTION | package.stable
-
x86 | x86 | yes
x86 ~x86 | x86 ~x86 | no
** | **| no
amd64 ~amd64 | ~amd64| no
3) Apply package.stable settings if INTERSECTION contains only stable
keywords. For example, see the package.stable column in the table above.
--
Thanks,
Zac
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
Excerpts from William Hubbs's message of 2012-04-27 16:34:05 +0200: > On Fri, Apr 27, 2012 at 02:26:07PM +, Duncan wrote: > > Amadeusz Żołnowski posted on Fri, 27 Apr 2012 15:45:36 +0200 as > > excerpted: > > > > > Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200: > > >> No distribution allowed. You're going to be doing > > >> restrict=mirror, correct? > > > > > > Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually. > > > > That works. RESTRICT=fetch is stricter so works, but I'm not sure > > whether it's necessary as I've not paid attention to the legal > > distinctions since both are out of the question here, but certainly, > > gentoo can't distribute, so restrict=mirror for sure. Whether it > > merits restrict=fetch or not I'll let someone else worry about. > > Definitely you should use restrict=mirror. > > Restrict=fetch is used when a user has to go to a web site and > register or accept a license on the web site before they download the > file the way I understand it. And this is probably the case when user has to accept a license on the website. This is URL for zip archive of yEd-3.9.1: http://www.yworks.com/en/products_download.php?file=yEd-3.9.1.zip It directs to website with license text, check-box for accept and download button. If check-box is not set, following message is shown: "In order to download yEd, it is necessary that you first accept the license terms." If check-box is set, client is redirected to the page with actual link to zip archive. Moreover, I have had email conversation with yWorks representative and he says that installation files need to be obtained manually by the end users from their website. -- Amadeusz Żołnowski signature.asc Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
> I'd like to add attached license to portage/licenses/. Any objections? Because there seem to be no objection wrt license itself, I've just committed it. I'll wait with adding ebuild until we get some consensus wrt RESTRICT=fetch/mirror. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 07:27 AM, Ciaran McCreesh wrote: > On Fri, 27 Apr 2012 14:15:35 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> In ordered to make it globally available, it cannot simply be an >> EAPI-5 thing, it must apply to all current ebuilds whether they (or >> an inherited eclass) call epatch_user or not. Which means that >> conflict with the existing epatch_user is unavoidable, since it will >> either try to run twice where it's already called, or it won't run at >> all where it's not. > > In order to make it globally available, you put it in EAPI 5, and make > the package mangler die at pretend time if the user has patches > specified for a package that isn't EAPI 5. Or, have repoman assert that src_prepare contains an epatch_user call if EAPI is less than 5. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 08:41:35 -0700 Zac Medico wrote: > > In order to make it globally available, you put it in EAPI 5, and > > make the package mangler die at pretend time if the user has patches > > specified for a package that isn't EAPI 5. > > Or, have repoman assert that src_prepare contains an epatch_user call > if EAPI is less than 5. Why bother? That's hideously error prone. We have a simple way that's guaranteed to work, and that is able to inform the user if their expectations can't be met. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 08:45 AM, Ciaran McCreesh wrote: > On Fri, 27 Apr 2012 08:41:35 -0700 > Zac Medico wrote: >>> In order to make it globally available, you put it in EAPI 5, and >>> make the package mangler die at pretend time if the user has patches >>> specified for a package that isn't EAPI 5. >> >> Or, have repoman assert that src_prepare contains an epatch_user call >> if EAPI is less than 5. > > Why bother? That's hideously error prone. We have a simple way that's > guaranteed to work, and that is able to inform the user if their > expectations can't be met. I suppose that we could do it both ways. The repoman check would be for people who want a practical approach that doesn't require all ebuilds to be converted to EAPI 5, and your strict die approach would be for people who want strictness and can afford to wait for the relevant ebuilds to be converted to EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 08:55:49 -0700 Zac Medico wrote: > I suppose that we could do it both ways. The repoman check would be > for people who want a practical approach that doesn't require all > ebuilds to be converted to EAPI 5, and your strict die approach would > be for people who want strictness and can afford to wait for the > relevant ebuilds to be converted to EAPI 5. But there's no way the repoman check is going to give anything like reliable answers if you're involving eclasses... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 09:00 AM, Ciaran McCreesh wrote: > On Fri, 27 Apr 2012 08:55:49 -0700 > Zac Medico wrote: >> I suppose that we could do it both ways. The repoman check would be >> for people who want a practical approach that doesn't require all >> ebuilds to be converted to EAPI 5, and your strict die approach would >> be for people who want strictness and can afford to wait for the >> relevant ebuilds to be converted to EAPI 5. > > But there's no way the repoman check is going to give anything like > reliable answers if you're involving eclasses... Okay, so people who need "reliable answers" can go with your strict approach. Meanwhile, it's relatively easy to to a manual audit of the src_prepare function of each eclass. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 09:08:06 -0700 Zac Medico wrote: > > But there's no way the repoman check is going to give anything like > > reliable answers if you're involving eclasses... > > Okay, so people who need "reliable answers" can go with your strict > approach. Meanwhile, it's relatively easy to to a manual audit of the > src_prepare function of each eclass. Providing unreliable functionality just leads to whining and contortions when it doesn't work. This isn't a situation where compromise is necessary, so there's no reason not to just do it properly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 09:11 AM, Ciaran McCreesh wrote: > On Fri, 27 Apr 2012 09:08:06 -0700 > Zac Medico wrote: >>> But there's no way the repoman check is going to give anything like >>> reliable answers if you're involving eclasses... >> >> Okay, so people who need "reliable answers" can go with your strict >> approach. Meanwhile, it's relatively easy to to a manual audit of the >> src_prepare function of each eclass. > > Providing unreliable functionality just leads to whining and > contortions when it doesn't work. This isn't a situation where > compromise is necessary, so there's no reason not to just do it > properly. Yeah, I guess you're right. ;-) -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
On 27/04/12 17:15, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: 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 But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. According to the source, calling it twice is perfectly safe.
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 07:20 AM, Michał Górny wrote: > We could finally decide it'll be a Portage internal feature, and modify > epatch_user() to export some Portage-specific indication that user > patches were applied. Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. -- Thanks, Zac
[gentoo-dev] [RFC] Changing default serial-console definition in inittab
Since I've been configuring a couple of systems lately for remote access, which include configuring the serial console, I'm wondering if it would be a good idea to change our inittab so that the default (commented out) definition of the serial consoles is a bit more.. modern. The current definition sets the console at 9600 baud, using vt100 emulation; I think most of us who configure it, do so at 115200 baud, and some prefer vt-utf8 over vt100 (the two are partially compatible as far as I can tell). Of the two systems I've configured – a SuperMicro server which is the new tinderbox host, and an HP for work – both have the default IPMI configuration for Serial-over-LAN set at 115200, and the HP also had VT-UTF8 by default for emulation (SuperMicro defaulted to vt100 but still allows utf8). Comments? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Gentoostats, SoC 2011
On 23/08/11 00:20, Vikraman wrote: Hi all, Gentoostats[0] is a GSoC 2011 project to collect package statistics from gentoo machines. Please check it out. Bug reports and feature suggestions are welcome. To submit your stats, use the app-portage/gentoostats ebuild from betagarden overlay[1]. [0] https://soc.dev.gentoo.org/gentoostats/ [1] https://soc.dev.gentoo.org/gentoostats/about Is this project dead now?
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 11:33 AM, Amadeusz Żołnowski wrote: > > And this is probably the case when user has to accept a license on the > website. This is URL for zip archive of yEd-3.9.1: > > http://www.yworks.com/en/products_download.php?file=yEd-3.9.1.zip > > It directs to website with license text, check-box for accept and > download button. If check-box is not set, following message is shown: > > "In order to download yEd, it is necessary that you first accept the > license terms." > > If check-box is set, client is redirected to the page with actual link to > zip archive. It turns out the vendor is lying - you can download it fine without accepting the license from: http://www.yworks.com/products/yed/demo/yEd-3.9.1.zip No doubt the vendor WANTS users to accept the license first, but it is not "necessary" from a technical standpoint. > > Moreover, I have had email conversation with yWorks representative and > he says that installation files need to be obtained manually by the end > users from their website. > Again, they likely intend for them to be obtained in this manner, but the word "need" is not true from a technical perspective. This brings up a debate that was recently held over deep-linking in bugzilla over a math library. The trustees never took a final vote since the maintainer decided to just implement RESTRICT=fetch. The issue there was about more than just copyright, however, and the trade regulations around munitions do not apply in this case. I don't think we have clear policy around this situation. I see our options as: 1. Set RESTRICT=fetch because upstream wants us to and we like to cooperate. 2. Set RESTRICT=fetch because even if legally they're on shaky ground upstream could probably waste a lot of our time and money. 3. Set RESTRICT=mirror because legally we think we have the right to do so, and want to stand for our principles and make life easier for our users. The potential upstream responses to doing #3 might be to do nothing, to not like us, to sue us, or to not use a fixed URL to distribute the file so that we have to restrict fetching for technical reasons. Do we as a matter of policy want to respect broken click-through download implementations? Rich
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
On Fri, Apr 27, 2012 at 10:29:54AM -0700, Diego Elio Pettenò wrote: > Since I've been configuring a couple of systems lately for remote > access, which include configuring the serial console, I'm wondering if > it would be a good idea to change our inittab so that the default > (commented out) definition of the serial consoles is a bit more.. modern. > > The current definition sets the console at 9600 baud, using vt100 > emulation; I think most of us who configure it, do so at 115200 baud, > and some prefer vt-utf8 over vt100 (the two are partially compatible as > far as I can tell). > > Of the two systems I've configured – a SuperMicro server which is the > new tinderbox host, and an HP for work – both have the default IPMI > configuration for Serial-over-LAN set at 115200, and the HP also had > VT-UTF8 by default for emulation (SuperMicro defaulted to vt100 but > still allows utf8). > > Comments? Makes sense to me, nice idea. greg k-h
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 17:26:48 schrieb Zac Medico:
> >
> > Maybe I'm missing something, but what would happen when the newest
> > version of a package is marked stable? The masked USE flags would
> > become unavailable for everyone?
>
> In order to be practical, I guess we'd have to add a constraint which
> says that if KEYWORDS contains the stable variant of a particular
> keyword, then it should also be considered to implicitly contain the
> unstable variant when the package manager is deciding whether or not to
> apply package.use.{mask,force}.
>
> So, here's a description of the whole algorithm that I'd use:
>
> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in KEYWORDS,
> plus ** and all the unstable variants of the stable values contained in
> KEYWORDS. For example:
>
>KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
>
> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS, where
> effective ACCEPT_KEYWORDS includes any relevant values from
> package.accept_keywords. For example, here is a table of intersections
> of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with various effective
> ACCEPT_KEYWORDS values:
>
> ACCEPT_KEYWORDS | INTERSECTION | package.stable
> -
> x86 | x86 | yes
> x86 ~x86 | x86 ~x86 | no
> ** | **| no
> amd64 ~amd64 | ~amd64| no
>
> 3) Apply package.stable settings if INTERSECTION contains only stable
> keywords. For example, see the package.stable column in the table above.
That is the best description I've seen so far, which exactly describes the use
case that I had in mind. +1 :)
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 13:35:21 schrieb Chí-Thanh Christopher Nguyễn: > Ciaran McCreesh schrieb: > >> * 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 > > > > This means that an ebuild will effectively change when moved from ~arch > > to arch. The point of ~arch is to test ebuilds before they're moved to > > arch. > > I agree that the ~arch ebuilds should be tested in the same > configuration in which they will end up in arch. However in this case, > the possible configurations for arch are a subset of those in ~arch, so > the testing covers those too. Right now, it's more likely that just before filing the stablerequest an ebuild is modified such that the useflag disappears and all the conditional codeblocks are set to a fixed value. (Compare cups-1.5.2-r3 and -r4) That includes a much larger danger of mistakes creeping in. Just forcing an useflag on or off poses a fairly minimal intrusion. > I see a problem where a significant proportion of ~arch users will have > this flag enabled (which is obviously the point of > package.use.stable.mask) so the arch configurations will see fewer > testers. This issue may need to be addressed, e.g. by extending > stabilization period or disallowing package.use.stable.mask in default > or desktop profile. Well, at least in some use cases the useflag will have an obvious disadvantage (remember the many libusb-backend bugs in cups-1.4). Then the consensus would have been "you can use this but it's not as bug-free", there may have been even an ewarn about it, ... 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.
Re: [gentoo-dev] Re: Making user patches globally available
> On Fri, 27 Apr 2012, Zac Medico wrote: > Since we've managed to survive up to this point without such a > feature, I think it's worth the wait roll it into EAPI 5 and have a > clean solution that doesn't rely on package manager interaction with > eclasses. If we quickly draft an EAPI 5 spec, there's still have > time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Ulrich
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 16:31:10 schrieb Ian Stakenvicius: > > 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... > > I'm not sure that I'm following the cups examples here. For cups-1.5 > even if it were stable, if someone actually wanted to use systemd on > their system and unmasked/keyworded it (while running stable > everything else) I don't see why this would be an issue that would > need this new masking feature (unless IUSE="+systemd", which probably > shouldn't be the case anyways). The point is that as it is now cups(-1.5.2-r20) could not be stabilized without a stable systemd, because systemd is a dependency (optional on useflag systemd). -- 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: New license: yEd Software License Agreement
On 27/04/12 20:38, Rich Freeman wrote: On Fri, Apr 27, 2012 at 11:33 AM, Amadeusz Żołnowski wrote: And this is probably the case when user has to accept a license on the website. This is URL for zip archive of yEd-3.9.1: http://www.yworks.com/en/products_download.php?file=yEd-3.9.1.zip It directs to website with license text, check-box for accept and download button. If check-box is not set, following message is shown: "In order to download yEd, it is necessary that you first accept the license terms." If check-box is set, client is redirected to the page with actual link to zip archive. It turns out the vendor is lying - you can download it fine without accepting the license from: http://www.yworks.com/products/yed/demo/yEd-3.9.1.zip No doubt the vendor WANTS users to accept the license first, but it is not "necessary" from a technical standpoint. Didn't the user already accept the license by putting it in ACCEPT_LICENSE? If not, portage will not download it.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 11:30:57 schrieb Michael Haubenwallner: > On 04/27/12 00:03, Andreas K. Huettel wrote: > > 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 > > Wouldn't it be more obvious/simple to have an extra profile subdirectory > containing package.use.mask and package.use.force? While this works (kind of), it is like running globally stable or globally testing. So, if you run stable but add one package with ~arch keyword, you are restricted to the "stable useflag set" there as well... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 11:01 AM, Ulrich Mueller wrote: >> On Fri, 27 Apr 2012, Zac Medico wrote: > >> Since we've managed to survive up to this point without such a >> feature, I think it's worth the wait roll it into EAPI 5 and have a >> clean solution that doesn't rely on package manager interaction with >> eclasses. If we quickly draft an EAPI 5 spec, there's still have >> time to have it approved at the next council meeting. > > Did I get it right, you are thinking about a special EAPI only for > user patches? I'd say that the feature is not important enough to > justify that. Let's just say that it's within the realm of possibilities, and I consider it to be preferable to a solution which involves package manager interaction with epatch_user. -- Thanks, Zac
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
On 04/27/2012 07:29 PM, Diego Elio Pettenò wrote:
> Since I've been configuring a couple of systems lately for remote
> access, which include configuring the serial console, I'm wondering if
> it would be a good idea to change our inittab so that the default
> (commented out) definition of the serial consoles is a bit more.. modern.
>
> The current definition sets the console at 9600 baud, using vt100
> emulation; I think most of us who configure it, do so at 115200 baud,
> and some prefer vt-utf8 over vt100 (the two are partially compatible as
> far as I can tell).
>
> Of the two systems I've configured – a SuperMicro server which is the
> new tinderbox host, and an HP for work – both have the default IPMI
> configuration for Serial-over-LAN set at 115200, and the HP also had
> VT-UTF8 by default for emulation (SuperMicro defaulted to vt100 but
> still allows utf8).
>
> Comments?
>
I wouldn't mind for amd64/x86.
There haven't been any new alpha/hppa systems in years, and the default
for them was 9600. All the cheap(and therefore common) sparc hardware
uses 9600 as we're talking about systems 10 years old. On ia64, from
what i've had access to in the last years, it used 9600 as well.
m68k/s390/sh are very exotic arches and 9600 is a safe default.
I'm providing this info as member of the teams of those architectures
i've mentioned(except hppa). I have no clue about mips or ppc* systems.
On the other hand, maybe it could be changed on arm to 115200, as all
the devices i have use that speed. Although some use a non-standard
serial port(ttyO{0,2} for OMAP devices, ttymxc0 for FSL i.mx devices).
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
On 04/27/12 at 10:29AM -0700, Diego Elio Pettenò wrote: > Since I've been configuring a couple of systems lately for remote > access, which include configuring the serial console, I'm wondering if > it would be a good idea to change our inittab so that the default > (commented out) definition of the serial consoles is a bit more.. modern. > > The current definition sets the console at 9600 baud, using vt100 > emulation; I think most of us who configure it, do so at 115200 baud, > and some prefer vt-utf8 over vt100 (the two are partially compatible as > far as I can tell). > > Of the two systems I've configured – a SuperMicro server which is the > new tinderbox host, and an HP for work – both have the default IPMI > configuration for Serial-over-LAN set at 115200, and the HP also had > VT-UTF8 by default for emulation (SuperMicro defaulted to vt100 but > still allows utf8). > > Comments? > > -- > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > +1 on the 115200 baud but I'm not sure about the VT-UTF8 even though I'd prefer it too. -- Regards, Christian Ruppert Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 pgpjVlDpP9dhC.pgp Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, Apr 27, 2012 at 11:01 AM, Ulrich Mueller wrote: >> On Fri, 27 Apr 2012, Zac Medico wrote: > >> Since we've managed to survive up to this point without such a >> feature, I think it's worth the wait roll it into EAPI 5 and have a >> clean solution that doesn't rely on package manager interaction with >> eclasses. If we quickly draft an EAPI 5 spec, there's still have >> time to have it approved at the next council meeting. > > Did I get it right, you are thinking about a special EAPI only for > user patches? I'd say that the feature is not important enough to > justify that. Release early and often :) > > Ulrich >
Re: [gentoo-dev] Re: Gentoostats, SoC 2011
On Fri, Apr 27, 2012 at 10:34 AM, Nikos Chantziaras wrote: > On 23/08/11 00:20, Vikraman wrote: >> >> Hi all, >> >> Gentoostats[0] is a GSoC 2011 project to collect package statistics from >> gentoo >> machines. Please check it out. Bug reports and feature suggestions are >> welcome. >> >> To submit your stats, use the app-portage/gentoostats ebuild from >> betagarden >> overlay[1]. >> >> [0] https://soc.dev.gentoo.org/gentoostats/ >> [1] https://soc.dev.gentoo.org/gentoostats/about > > > Is this project dead now? > > A trivial look at the git repo would indicate no it is not dead. -A
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 20:01:15 +0200 Ulrich Mueller wrote: > > On Fri, 27 Apr 2012, Zac Medico wrote: > > > Since we've managed to survive up to this point without such a > > feature, I think it's worth the wait roll it into EAPI 5 and have a > > clean solution that doesn't rely on package manager interaction with > > eclasses. If we quickly draft an EAPI 5 spec, there's still have > > time to have it approved at the next council meeting. > > Did I get it right, you are thinking about a special EAPI only for > user patches? I'd say that the feature is not important enough to > justify that. +1. Either we use EAPIs with some thinking or just drop that concept and move on to something else. There is a number of features waiting for new EAPI, and noone yet even considered them. But when it comes to marginal feature which many of devs don't even accept, it's enough to quickly release a new EAPI which most of the tree won't support. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 2:04 PM, Nikos Chantziaras wrote: > Didn't the user already accept the license by putting it in ACCEPT_LICENSE? > If not, portage will not download it. > Well, I'd argue that it is impossible to "accept a license" in the first place. It is possible to agree to a contract if there is consideration on both sides and a meeting of the minds. Copyright says you can't copy something. A license says you might be able to. You don't have to "accept" a license to benefit it. A license does not restrict what a user can do, it restricts what the person issuing the license can do (I can't sue you for redistributing my code if I licensed it to you under the GPL). Some licenses are conditional - I only limit my own ability to sue you if you give people a copy of the source for any binary you give them, and if you don't do that I am now free to sue you. Ultimately the foundation for licenses is copyright law, and other forms of IP law. Copyright says we can't distribute anything we don't create except under very specific circumstances. A license says that we can distribute stuff without fear of lawsuit under some conditions. The yEd license says we can't distribute anything, so as far as I can see, we might as well not have any license at all. We're not protected at all from a lawsuit, except to the degree that we don't do anything that we can be sued for (like distributing their software). But yes, from a technical standpoint you can only install a package if its license is contained in ACCEPT_LICENSE. Whether this has any legal meaning is up to you or a court with jurisdiction to decide. Rich
[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/27/2012 11:26 AM, Zac Medico wrote:
> In order to be practical, I guess we'd have to add a constraint
> which says that if KEYWORDS contains the stable variant of a
> particular keyword, then it should also be considered to implicitly
> contain the unstable variant when the package manager is deciding
> whether or not to apply package.use.{mask,force}.
>
> So, here's a description of the whole algorithm that I'd use:
>
> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in
> KEYWORDS, plus ** and all the unstable variants of the stable
> values contained in KEYWORDS. For example:
>
> KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
>
> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS,
> where effective ACCEPT_KEYWORDS includes any relevant values from
> package.accept_keywords. For example, here is a table of
> intersections of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with
> various effective ACCEPT_KEYWORDS values:
>
> ACCEPT_KEYWORDS | INTERSECTION | package.stable
> - x86
> | x86 | yes x86 ~x86 | x86 ~x86 | no **
> | **| no amd64 ~amd64 | ~amd64| no
>
> 3) Apply package.stable settings if INTERSECTION contains only
> stable keywords. For example, see the package.stable column in the
> table above.
This algorithm better matches what I meant in my earlier posting, so
+1 from me. (And if anyone has an ACCEPT_KEYWORDS value of "~amd64
- -amd64", they deserve any issues that may arise).
The only issue I have with it is that EFFECTIVE_KEYWORDS should be
expanded to contain "*" if any stable keyword is present and "~*" if
any unstable keyword is present (or "*" and "~*" in ACCEPT_KEYWORDS
should be pre-expanded).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPmvKPAAoJELHSF2kinlg43ZgP/1F++FzGzmUZxy+2enHeCIRb
47y4hFxZG18ulWijr0qEJTizDGCxE8RCBfanM4I1G4qSdy0Eyg+6yIdT+B1FRZ1F
Wp5p/CPPX/AfxgJ+LTTmY5V3f8AWrk1MfX4sGoy+0DGzgMB+Z87M6f10wAWcLIV5
RHd3591kyL5AOifaaM53/tgFcjvXECz+DfbDaVFaD1XjnSkEsu6aV6k1xaVqGGfF
pK3Dqo672XUKR1laFODYEkknO0JlR8EcU8De4pkdgj8ffbf0g2uVXbpTCEgd+w4I
0eEd+LNVDAnTQntMuSETK5ysfYIVOPOmo1KoaR5XSFVsNL8UzjUKY1Yx7owXrm+N
2OR+2JtdCnjkTveZZbP/Y8M74wiZeptOsgK5PxN+C/3vLWJ0LMrxIsWMugc0Oihv
3ddk1/WQolBtA8+DDBY+mOrJuKa5R7eqLAJQVmFLyDVLGu2dTCO26TaT7IKWnN8J
Kw0RqscOFd93RcsfpgKwM2ij+8N+QlGgvK4qBwR9MAIEEQAPtx5Rxi6dxly/b/7h
6jC2Yt8UqVOCloQ4vjoopIqA7QYGk3JS+yp27HAVR+cXDX1OWntEU+LeVlmm27k9
vuEBRXosD9DpYCQ7OCQOzYa5TefgVs76TY/ygSgpkHlzcCbZ5iRwholKuOuKSvyd
mRi9g8/nctJXFkHn17GV
=LYAv
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 11:57 AM, Michał Górny wrote: > On Fri, 27 Apr 2012 20:01:15 +0200 > Ulrich Mueller wrote: > >>> On Fri, 27 Apr 2012, Zac Medico wrote: >> >>> Since we've managed to survive up to this point without such a >>> feature, I think it's worth the wait roll it into EAPI 5 and have a >>> clean solution that doesn't rely on package manager interaction with >>> eclasses. If we quickly draft an EAPI 5 spec, there's still have >>> time to have it approved at the next council meeting. >> >> Did I get it right, you are thinking about a special EAPI only for >> user patches? I'd say that the feature is not important enough to >> justify that. > > +1. Either we use EAPIs with some thinking or just drop that concept > and move on to something else. > > There is a number of features waiting for new EAPI, and noone yet even > considered them. But when it comes to marginal feature which many of > devs don't even accept, it's enough to quickly release a new EAPI which > most of the tree won't support. The fact that it's a "marginal feature" is exactly why I don't think it justifies adding a quick and dirty hack that introduces an interaction between the package manager an eclass function like epatch_user. On the other hand, if it's important enough to justify a quick and dirty hack in the package manager, then I'd argue that it's also important enough to justify a quick and clean EAPI bump. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 20:01:15 +0200 Ulrich Mueller wrote: > > Since we've managed to survive up to this point without such a > > feature, I think it's worth the wait roll it into EAPI 5 and have a > > clean solution that doesn't rely on package manager interaction with > > eclasses. If we quickly draft an EAPI 5 spec, there's still have > > time to have it approved at the next council meeting. > > Did I get it right, you are thinking about a special EAPI only for > user patches? I'd say that the feature is not important enough to > justify that. Didn't we have a few other cheap things lined up? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On 04/27/2012 12:25 PM, Jonathan Callen wrote:
> On 04/27/2012 11:26 AM, Zac Medico wrote:
>> In order to be practical, I guess we'd have to add a constraint
>> which says that if KEYWORDS contains the stable variant of a
>> particular keyword, then it should also be considered to implicitly
>> contain the unstable variant when the package manager is deciding
>> whether or not to apply package.use.{mask,force}.
>
>> So, here's a description of the whole algorithm that I'd use:
>
>> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in
>> KEYWORDS, plus ** and all the unstable variants of the stable
>> values contained in KEYWORDS. For example:
>
>> KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
>
>> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS,
>> where effective ACCEPT_KEYWORDS includes any relevant values from
>> package.accept_keywords. For example, here is a table of
>> intersections of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with
>> various effective ACCEPT_KEYWORDS values:
>
>> ACCEPT_KEYWORDS | INTERSECTION | package.stable
>> - x86
>> | x86 | yes x86 ~x86 | x86 ~x86 | no **
>> | **| no amd64 ~amd64 | ~amd64| no
>
>> 3) Apply package.stable settings if INTERSECTION contains only
>> stable keywords. For example, see the package.stable column in the
>> table above.
>
> This algorithm better matches what I meant in my earlier posting, so
> +1 from me. (And if anyone has an ACCEPT_KEYWORDS value of "~amd64
> -amd64", they deserve any issues that may arise).
>
> The only issue I have with it is that EFFECTIVE_KEYWORDS should be
> expanded to contain "*" if any stable keyword is present and "~*" if
> any unstable keyword is present (or "*" and "~*" in ACCEPT_KEYWORDS
> should be pre-expanded).
Yeah, I omitted * and ~* for brevity, and you've got the right idea.
--
Thanks,
Zac
Re: [gentoo-dev] Re: Making user patches globally available
> On Fri, 27 Apr 2012, Ciaran McCreesh wrote: >> Did I get it right, you are thinking about a special EAPI only for >> user patches? I'd say that the feature is not important enough to >> justify that. > Didn't we have a few other cheap things lined up? Yes we do, and IMHO it would make much more sense if EAPI 5 would include them. (And of course, there are still the two features that were omitted from EAPI 4, namely slot-operator-deps and profile-iuse-injection.) Ulrich
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Zac Medico wrote: So, here's a description of the whole algorithm that I'd use: > [snip] I think the following is equivalent, but simpler and more general since it doesn't have to mention details like ** and friends that aren't currently in PMS, and doesn't assume that the rule for handling KEYWORDS is simply "does it contain at least one of the accepted values? (plus handling of ** etc)". (For example, I can imagine something like "accept the package if it has amd64, or if it has both ~amd64 and x86" being potentially useful for some people, although I don't think it's implemented anywhere at the moment.) 1) Pretend that all stable keywords in the package's KEYWORDS are replaced with the corresponding ~arch ones 2) If this would result in the package being masked by keywords (I forget the exact terminology Portage uses, but I'm sure you know what I mean), then apply the masks/forces from package.use.stable.*
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 21:43:06 +0200 Ulrich Mueller wrote: > > On Fri, 27 Apr 2012, Ciaran McCreesh wrote: > > >> Did I get it right, you are thinking about a special EAPI only for > >> user patches? I'd say that the feature is not important enough to > >> justify that. > > > Didn't we have a few other cheap things lined up? > > Yes we do, and IMHO it would make much more sense if EAPI 5 would > include them. > > (And of course, there are still the two features that were omitted > from EAPI 4, namely slot-operator-deps and profile-iuse-injection.) Of course, if we take the 'quick EAPI 5 route', it won't include anything useful. In the meantime, do we have a complete list of candidates for EAPI 5? -- Best regards, Michał Górny signature.asc Description: PGP signature
EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Fri, 27 Apr 2012 21:58:24 +0200 Michał Górny wrote: > Of course, if we take the 'quick EAPI 5 route', it won't include > anything useful. In the meantime, do we have a complete list of > candidates for EAPI 5? Let's continue this on the PMS list. * user patches * EAPI parsing * the things that were left out of 4: + slot operator deps + profile IUSE * No -j1 for src_test * Remove deprecated stuff * Zero or one REQUIRED_USE operator These might be cheap now? * New bash version * Get a versionator replacement into the PM -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
We have had a talk about yEd on #gentoo-dev which is worth attaching here: <@ulm> aidecoe: I suspect that yEd is in violation of the GPL :/ <@ulm> their package zip file includes JavaHelp classes but no source code for them <@ulm> and I also don't see it at their site <@ulm> neither do they include the GPL license text <@aidecoe> ulm: they provide links in their license <@ulm> that's not enough <@ulm> read the GPL ;) <@aidecoe> yes, i have read <@aidecoe> some time ago <@ulm> what's probably worse, they pack that GPLed software into their jar <@ulm> and in clause 1 of the yed license they forbid to unjar it <@aidecoe> yes, that's not fair <@ulm> and in clause 6 they forbid distribution <@ulm> I'm pretty sure that this contradicts the GPL <@ulm> aidecoe: that would be another reason for mirror restriction ;) <@aidecoe> ulm: i'll mail them about it I have just sent nice e-mail to yWorks about this. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
On 04/27/2012 12:57 PM, David Leverton wrote: > Zac Medico wrote: >> So, here's a description of the whole algorithm that I'd use: >> [snip] > > I think the following is equivalent, but simpler and more general since > it doesn't have to mention details like ** and friends that aren't > currently in PMS, and doesn't assume that the rule for handling KEYWORDS > is simply "does it contain at least one of the accepted values? (plus > handling of ** etc)". (For example, I can imagine something like > "accept the package if it has amd64, or if it has both ~amd64 and x86" > being potentially useful for some people, although I don't think it's > implemented anywhere at the moment.) > > 1) Pretend that all stable keywords in the package's KEYWORDS are > replaced with the corresponding ~arch ones > 2) If this would result in the package being masked by keywords (I > forget the exact terminology Portage uses, but I'm sure you know what I > mean), then apply the masks/forces from package.use.stable.* Yeah, that appears to be equivalent. -- Thanks, Zac
[gentoo-dev] Re: Re: Making user patches globally available
Zac Medico wrote:
> Steven J Long wrote:
>> It seems there's two major cases, with autotools or without. In either
>> case, epatch_user should be called after Gentoo patches have been
>> applied.
>>
>> Why not make epatch_user set a variable to indicate that patches have
>> been applied, and only apply the patches on the first call?
>>
>> Then eautoreconf could call it before calling autoconf (and the ebuild
>> wouldn't need to worry about it.) And any custom src_prepare function
>> could call it when needed, if it needed to be done during the phase, and
>> not after.
>>
>> After src_prepare, the PM could just call it unconditionally, since it
>> will not apply the patches again, if it's already been called by the
>> ebuild.
>>
>> Does that make sense?
>
> Yeah, sounds roughly equivalent to Ciaran's suggested
> "apply_user_patches_here" approach [1], except that Ciaran suggested to
> make it an error if src_prepare doesn't call apply_user_patches_here (so
> people don't forget to call it when they should).
>
> [1]
> http://archives.gentoo.org/gentoo-
dev/msg_c228be85e0c4e577ad194e6004d59062.xml
Yeah, I saw that, but given that this would be standardisation around an
EAPI bump, I don't see the point in changing the name of the function to
mean exactly the same thing, only to make it much more inconvenient in
usage.
I feel there needs to be more thinking about what you mentioned, ie around
the lines of "user-patches are applied on top of Gentoo-patched sources."
This makes much more sense in process terms, since user-patches are more
likely to be included in Gentoo-patches, and thus easier to handle for
submission upstream. The alternative (user-patches applied to vanilla
sources) has much more likelihood for bad interaction with Gentoo patches or
changes.
If we stipulate that src_prepare transforms upstream sources into Gentoo-
official sources, then it only makes sense to epatch_user thereafter, and
there's no point burdening the ebuild, or its developer, with that task.
It also makes ebuilds much cleaner to read.
Where you have a build-system that requires epatch_user part way through
src_prepare, it's up to the ebuild, or more likely eclass for that build-
system, to call it at the appropriate time. (autoconf ebuilds clearly should
just inherit whatever eclass the team tells them to, and stop messing
around.)
In any event, specifying that the PM only calls epatch_user after
src_prepare if there are user-patches, and it hasn't been called already
(this is easiest done within epatch_user, ofc) allows ebuild or eclass
developers to override the default easily, while still keeping things easy
for most ebuilds.
eg: so far I've heard that: epatch_user && eautoreconf
..is desired behaviour, so I guess you want logic like:
if ((${#USER_PATCHES[*]})); then
((applied_user_patches)) || {
<.. apply the patches || die ..>
applied_user_patches=1
}
return 0
else return 1
fi
Given something like the above, the addition of a simple[1]: epatch_user
..to eautoreconf before the call to autoreconf, and after src_prepare in
ebuild.sh, cannot do any harm, and ensures that sources are patched without
adding any cruft to ebuilds.
I also think there would be merit in optionally including any user-patches
with binpkgs. This would be useful for transparency, ie debugging and
licensing concerns with respect to modified sources.
Regards,
Steve.
PS As you know, ofc, patches against vanilla sources can be done in a
pre_src_prepare bashrc hook, if one really has to for custom builds. I don't
think anyone's talking about implementing them; or should they be on the
table too?
[1] Yes, EAPI-dependent, so might need eg:
case $EAPI in 5|6) epatch_user;; esac
..depending on what else is happening, but simple in the sense that we don't
care about its return value in these contexts.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
On 04/28/12 01:29, Diego Elio Pettenò wrote: > Since I've been configuring a couple of systems lately for remote > access, which include configuring the serial console, I'm wondering if > it would be a good idea to change our inittab so that the default > (commented out) definition of the serial consoles is a bit more.. modern. > > The current definition sets the console at 9600 baud, using vt100 > emulation; I think most of us who configure it, do so at 115200 baud, > and some prefer vt-utf8 over vt100 (the two are partially compatible as > far as I can tell). > > Of the two systems I've configured – a SuperMicro server which is the > new tinderbox host, and an HP for work – both have the default IPMI > configuration for Serial-over-LAN set at 115200, and the HP also had > VT-UTF8 by default for emulation (SuperMicro defaulted to vt100 but > still allows utf8). > > Comments? > Leave the old defaults, add an example with the new options? Since serial consoles are not default the user will have to consciously enable them anyway, so there are no "defaults" Have fun, Patrick
[gentoo-dev] Re: Re: Proposal to move use.local.desc somewhere in /var
Mike Frysinger wrote: > On Wednesday 25 April 2012 02:26:19 Steven J Long wrote: >> Mike Frysinger wrote: >> > Paul Varner wrote: >> >> Robin H. Johnson wrote: >> >> > Why are we keeping it? I move that we remove it. It's been replaced >> >> > by USE flags in metadata.xml for several years now. >> >> >> >> euse from gentoolkit still uses it since it is written in bash and XML >> >> parsing in bash can be problematic. We really need to get euse >> >> rewritten in python so it can use the portage and gentoolkit API's >> >> before we get rid of the file. >> > >> > it's also a bit of a speed issue. i often want to look at what flags >> > get used >> > across the tree. what's faster: loading + parsing 15000 xml files, or >> > loading 1 file ? shifting it to metadata/ as a cache of all the xml >> > files is probably fine, but i'm not sure dropping it completely is an >> > improvement. >> >> Agreed. I don't think it's a good idea to lose the ability to script >> against the tree from bash. > > technically, you can script with xml files just fine from bash. install > app- text/xmlstarlet and use the `xml` tool. Oh, I've been a fan for several years[1] :) I still don't want to require it as a dependency, especially when, as you say, it's quick and easy to access a single file per-repo. There's utility in it, and there isn't any real gain in ditching it, beyond not requiring its generation. And since it's been unnoticed for such a long while, it can't be causing any real troubles. So why lose its usefulness? It certainly counts as a file that should be synchronised as part of the repo, though. So if you're going to move it to /var, better to move /usr/portage itself, imo. (This thread feels like it's really about that, tbh, but users can already set it where they want and often just have a separate partition, or if they're bothered have already configured it to /var/portage, so it's more about new users, and whether a baselayout change is worth the hassle.) Regards, Steve. [1] cf: /msg friendlyToaster xml -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Making user patches globally available
Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted: > On 27/04/12 17:15, Duncan wrote: >> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: >>> 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. >> >> But that doesn't solve the problem of making it globally available, >> since it only applies to packages/eclasses that already call >> epatch_user for EAPIs thru current EAPI-4. >> >> In ordered to make it globally available, it cannot simply be an EAPI-5 >> thing, it must apply to all current ebuilds whether they (or an >> inherited eclass) call epatch_user or not. Which means that conflict >> with the existing epatch_user is unavoidable, since it will either try >> to run twice where it's already called, or it won't run at all where >> it's not. > > According to the source, calling it twice is perfectly safe. That's actually one of the points I've been making, that if we simply force an epatch_user at approximately post_src_prepare, the existing code already deals with multiple calls just fine. The problem appears if we then decide that we're going to do something with eautoreconf immediately thereafter. * if we just call it, we're potentially doing extra work both when the patch didn't require it, and when the ebuild already invoked eautoreconf after doing its own patching. * elif we try to somehow detect that it needs to be run, that's a huge amount of additional complexity we're now talking about adding to what WAS a simple globalization of already tested working code. * elif we try to force developers to call it at some point via repoman check or the like, thus letting them decide, then we're possibly looking at eapi5, and in any case, we just lost the point of the entire exercise, to make it global without forcing a touch of every existing ebuild in the tree that doesn't do it yet. Rock, hard place, with us between them! That's why I proposed up-thread that at least for now we go with the simple option, simply have the PM call epatch_user (either supplying its own internal function or sourcing the eclass to get the existing eclass version), and just punt on the eautoreconf stuff for now. As I said there, based on my experience anyway, that covers the for me at least 80-90% of use-cases where the patch isn't complex enough to require an eautoreconf, using code that's already known to be solid and well tested. For the remaining 10-20%, the old solution, copying the ebuild to an overlay and adding the patch calls and any other necessary modifications manually, still works. I'd rather take the "good solution", the well tested code we have now, and apply it globally, yielding the 80-90% reduction in forced personal overlay ebuilds as a result, and continue to deal with the 10-20% than need eautoreconf or other processing manually, now, instead of waiting possibly forever for a "perfect" solution that might or might not ever come, even if in theory it could raise that 80-90% to 99%+. But Zac and a few others believe that what I called the "good" solution will result in a more or less continuous flood of bugs from people who expect epatch_user (or whatever replaces it) to "just work" for that perhaps 10-20% where eautoreconf is required as well, and don't believe it's an acceptable tradeoff. Since they're the devs dealing with the bugs, not me, that's a trump card I can't counter. They win. Unfortunately that means we're stuck waiting for a "perfect" solution that may never come, once again, or at least with an eapi5 solution that even when adopted won't reach global coverage for many many years to come. Oh, well... Unless you're talking about eautoreconf, not epatch_user. Actually, calling eautoreconf extra times should be safe. It'll just take longer, potentially MUCH longer, relative to the current merge time of some affected packages. (There's the question too, of what happens if eautoreconf is called on a non-autotools package. But at a suitably high level, that simply gets lumped in with the general robustness question on the whole approach.) -- 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
