[gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Hello everybody,

I have already said this before, but it looks like nobody cared. We have
a problem for what concerns Gentoo-generated distfiles.

This includes custom snapshots, custom packages, patches, patchsets, and
so on so forth. While it was infra that (back when I joined at least)
asked not to use dev.gentoo.org for hosting said fails and rather prefer
to use mirror://gentoo/, they already stated that it's not a problem to
do so until we have a proper system in place (system that has been
considered and worked on for quite a bit already and yet is not
available).

Unfortunately, as long as the mirror://gentoo/ option is still
maintained, we'll end up with situations like today's gnuconfig that
couldn't be fetched, causing all ~arch users to see the same failure,
because the distfile wasn't uploaded to the staging area. Of course the
same could happen with a stable SRC_URI, but then it would fail after
hitting that, rather than going through half the gentoo mirrors trying
to find a file that is not there.

So, anybody has reasons beside laziness, or concern for infra's disk
usage (that argument is allowed to come only from infra members!), to
not go this route?

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Patrick Lauer]

On 08/18/11 10:50, Diego Elio Pettenò wrote:
> Hello everybody,
> 
> I have already said this before, but it looks like nobody cared. We have
> a problem for what concerns Gentoo-generated distfiles.

People being quiet doesn't imply they don't care - just that it gets
really frustrating to repeat the same thing every week ;)

> This includes custom snapshots, custom packages, patches, patchsets, and
> so on so forth. While it was infra that (back when I joined at least)
> asked not to use dev.gentoo.org for hosting said fails and rather prefer
> to use mirror://gentoo/, they already stated that it's not a problem to
> do so until we have a proper system in place (system that has been
> considered and worked on for quite a bit already and yet is not
> available).

So - what needs to be done to finally make it happen?

> Unfortunately, as long as the mirror://gentoo/ option is still
> maintained, we'll end up with situations like today's gnuconfig that
> couldn't be fetched, 

That's not the only one - if you want to recreate a year-old system
you'll have trouble finding those patches because the ebuilds were
removed and the distfiles removed from the mirrors

> causing all ~arch users to see the same failure,
> because the distfile wasn't uploaded to the staging area. Of course the
> same could happen with a stable SRC_URI, but then it would fail after
> hitting that, rather than going through half the gentoo mirrors trying
> to find a file that is not there.
> 
> So, anybody has reasons beside laziness, or concern for infra's disk
> usage (that argument is allowed to come only from infra members!), to
> not go this route?

I'll even donate two 2TB disks to kill the disk space argument ;)
Hardware is cheap, the maintenance and planning is most likely more of a
bottleneck - but then there's enough smart people around if anyone needs
help.

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Ulrich Mueller]

> On Thu, 18 Aug 2011, Patrick Lauer wrote:

> On 08/18/11 10:50, Diego Elio Pettenò wrote:
>> This includes custom snapshots, custom packages, patches,
>> patchsets, and so on so forth. While it was infra that (back when I
>> joined at least) asked not to use dev.gentoo.org for hosting said
>> fails and rather prefer to use mirror://gentoo/, they already
>> stated that it's not a problem to do so until we have a proper
>> system in place (system that has been considered and worked on for
>> quite a bit already and yet is not available).

> So - what needs to be done to finally make it happen?

It's outlined in bug 176186.


Ulrich

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Thomas Sachau]

Diego Elio Pettenò schrieb:
> Hello everybody,
> 
> I have already said this before, but it looks like nobody cared. We have
> a problem for what concerns Gentoo-generated distfiles.
> 
> This includes custom snapshots, custom packages, patches, patchsets, and
> so on so forth. While it was infra that (back when I joined at least)
> asked not to use dev.gentoo.org for hosting said fails and rather prefer
> to use mirror://gentoo/, they already stated that it's not a problem to
> do so until we have a proper system in place (system that has been
> considered and worked on for quite a bit already and yet is not
> available).
> 
> Unfortunately, as long as the mirror://gentoo/ option is still
> maintained, we'll end up with situations like today's gnuconfig that
> couldn't be fetched, causing all ~arch users to see the same failure,
> because the distfile wasn't uploaded to the staging area. Of course the
> same could happen with a stable SRC_URI, but then it would fail after
> hitting that, rather than going through half the gentoo mirrors trying
> to find a file that is not there.
> 
> So, anybody has reasons beside laziness, or concern for infra's disk
> usage (that argument is allowed to come only from infra members!), to
> not go this route?
> 

I see no improvement from this proposal. If a tarball is not uploaded, the 
users will always fail to
get it, independent from the place, where it should be going to. And even if 
you put the
dev.gentoo.org address in SRC_URI, portage will first check the mirrors before 
it checks SRC_URI, so
this would in the end result in even 1 more download try without success.

The argument about dropped tarballs, once the ebuilds gets removed might weight 
a bit more, but you
cannot depend on other upstream keeping their tarballs around forever, so i see 
no requirement for
us preserving only specific tarballs (those created by our devs), while 
upstream tarballs could
already be gone and are not preserved, once the ebuild for it is gone.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Anthony G. Basile]

On 08/18/2011 05:15 AM, Thomas Sachau wrote:
> Diego Elio Pettenò schrieb:
>> Hello everybody,
>>
>> I have already said this before, but it looks like nobody cared. We have
>> a problem for what concerns Gentoo-generated distfiles.
>>
>> This includes custom snapshots, custom packages, patches, patchsets, and
>> so on so forth. While it was infra that (back when I joined at least)
>> asked not to use dev.gentoo.org for hosting said fails and rather prefer
>> to use mirror://gentoo/, they already stated that it's not a problem to
>> do so until we have a proper system in place (system that has been
>> considered and worked on for quite a bit already and yet is not
>> available).
>>
>> Unfortunately, as long as the mirror://gentoo/ option is still
>> maintained, we'll end up with situations like today's gnuconfig that
>> couldn't be fetched, causing all ~arch users to see the same failure,
>> because the distfile wasn't uploaded to the staging area. Of course the
>> same could happen with a stable SRC_URI, but then it would fail after
>> hitting that, rather than going through half the gentoo mirrors trying
>> to find a file that is not there.
>>
>> So, anybody has reasons beside laziness, or concern for infra's disk
>> usage (that argument is allowed to come only from infra members!), to
>> not go this route?
>>
> 
> I see no improvement from this proposal. If a tarball is not uploaded, the 
> users will always fail to
> get it, independent from the place, where it should be going to. And even if 
> you put the
> dev.gentoo.org address in SRC_URI, portage will first check the mirrors 
> before it checks SRC_URI, so
> this would in the end result in even 1 more download try without success.
> 
> The argument about dropped tarballs, once the ebuilds gets removed might 
> weight a bit more, but you
> cannot depend on other upstream keeping their tarballs around forever, so i 
> see no requirement for
> us preserving only specific tarballs (those created by our devs), while 
> upstream tarballs could
> already be gone and are not preserved, once the ebuild for it is gone.
> 

What alternative are you proposing to mirror://gentoo/ if upstream
doesn't provide a tarball, eg with large patchsets the maintainer
constructs?  Anticipating your answer might be "keep them in your dev
space", then what would be the deprecation policy for distfiles that are
no longer used by ebuilds?  If foresee a tension between keeping all the
distfiles vs disk space, although Patrick's point of cheap hardware is
well taken.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 05.46 -0400, Anthony G. Basile ha
scritto:
> 
> What alternative are you proposing to mirror://gentoo/ if upstream
> doesn't provide a tarball, eg with large patchsets the maintainer
> constructs?  Anticipating your answer might be "keep them in your dev
> space", then what would be the deprecation policy for distfiles that
> are
> no longer used by ebuilds?  If foresee a tension between keeping all
> the
> distfiles vs disk space, although Patrick's point of cheap hardware is
> well taken. 

Keep it in your dev space. As I said, the resources argument is only
available for infra to complain about, and since last I knew from them
was that it was not a problem right now...

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 11.15 +0200, Thomas Sachau ha scritto:
> 
> The argument about dropped tarballs, once the ebuilds gets removed
> might weight a bit more, but you
> cannot depend on other upstream keeping their tarballs around forever,
> so i see no requirement for
> us preserving only specific tarballs (those created by our devs),
> while upstream tarballs could
> already be gone and are not preserved, once the ebuild for it is gone.

Perfect is the enemy of good.

_Most_ upstream projects keep tarballs available of all historic
releases; okay maybe not _all_ projects, but most, especially those
using services such as SourceForge, Google Code, RubyForge,
Rubygems, ...

For _our_ projects, snapshots, or packages, let's try to apply a sane
policy. And that starts by not arguing that we shouldn't be doing so
because others might not be doing so themselves.

Heck, let's try to look up for the projects doing things right, not
justify our failures with those doing things wrong.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Anthony G. Basile]

On 08/18/2011 05:53 AM, Diego Elio Pettenò wrote:
> Il giorno gio, 18/08/2011 alle 05.46 -0400, Anthony G. Basile ha
> scritto:
>>
>> What alternative are you proposing to mirror://gentoo/ if upstream
>> doesn't provide a tarball, eg with large patchsets the maintainer
>> constructs?  Anticipating your answer might be "keep them in your dev
>> space", then what would be the deprecation policy for distfiles that
>> are
>> no longer used by ebuilds?  If foresee a tension between keeping all
>> the
>> distfiles vs disk space, although Patrick's point of cheap hardware is
>> well taken. 
> 
> Keep it in your dev space. As I said, the resources argument is only
> available for infra to complain about, and since last I knew from them
> was that it was not a problem right now...
> 

Understood that infra gets to complain, but that still doesn't tell me
what the deprecation policy is.  Keep all my large patchsets
indefinitely? Or remove them when an ebuild no longer needs them?  Or 1
year after an ebuild no longer needs them?

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

[gentoo-dev] Tinderboxing (was Re: package graveyard)

[Diego Elio Pettenò]

Il giorno mer, 17/08/2011 alle 23.20 +0200, Rémi Cardona ha scritto:
> 
> If anything, working on tinderboxes to catch build issues early and
> file
> bugs against packages, _that_ would help to clean up cruft from
> portage. 

Maintainers can help that by making sure that src_test is not wasting
useless time running non-tests, false positives, or code deemed to
failure.

Also, make sure that packages do not collide/block just for the sake of
doing so. If they provide binaries with the same name and functionality,
consider making them eselectable, or rename one of them.. if they have
the same name and do different stuff, get one (or both) upstream to
understand that the name is too generic, or already taken, and rename
the file once and for all.

Thank you all,

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Chí-Thanh Christopher Nguyễn]

Diego Elio Pettenò schrieb:
> Keep it in your dev space. As I said, the resources argument is only
> available for infra to complain about, and since last I knew from them
> was that it was not a problem right now...

I think robbat2 complained on IRC recently to devs which had their home
directories full of some stuff.

Regarding the problem of the developer neglecting (happened to me too,
ahem) to upload distfiles, maybe repoman could check for this?


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Tinderboxing (was Re: package graveyard)

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 12.01 +0200, Diego Elio Pettenò ha
scritto:
> 
> Thank you all,

Oh and please remember that if your package is not a kernel module, your
CONFIG_CHECK variable should have ~-tests (i.e., notify if not
configured properly but do not die in the ebuild if so).

It is epically bothersome to change a fake kernel configuration just
because a package _needs it to run_.

Dying/failing tests if the features are not available might make a bit
more sense, but even that is borderline, given that in a container
(which is what _I_ use for tinderboxing) the kernel configuration does
not correspond at all with the one the host is running, and that's the
one that is meaningful.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 12.09 +0200, Chí-Thanh Christopher Nguyễn
ha scritto:
> 
> Regarding the problem of the developer neglecting (happened to me too,
> ahem) to upload distfiles, maybe repoman could check for this? 

https://bugs.gentoo.org/show_bug.cgi?id=315243

I know I'm not as useful by just reporting wishlist features for
repoman, but I'm afraid my Python skills are nowhere near what I'd be
needing, and either I report the tinderbox stuff or I try hacking
something within repoman... the former is probably more useful right
now.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Thomas Sachau]

Chí-Thanh Christopher Nguyễn schrieb:
> Diego Elio Pettenò schrieb:
>> Keep it in your dev space. As I said, the resources argument is only
>> available for infra to complain about, and since last I knew from them
>> was that it was not a problem right now...
> 
> I think robbat2 complained on IRC recently to devs which had their home
> directories full of some stuff.

He did and this means, that while it would be ok to have patchsets or smaller 
tarballs in your
homedir, this is no longer ok for big tarballs or many bigger tarballs (e.g. 
proper tarball for
upstream sources or many tarballs due to many upstream releases), so homedir on 
dev.gentoo.org
cannot be the only answer.

This means, that the space for dev-created tarballs should be ready before we 
can deprecate direct
uploads to our mirrors via mirror://gentoo.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18-08-2011 08:50, Diego Elio Pettenò wrote:
> Hello everybody,
> 
> I have already said this before, but it looks like nobody cared. We 
> have a problem for what concerns Gentoo-generated distfiles.
> 
> This includes custom snapshots, custom packages, patches, patchsets, 
> and so on so forth. While it was infra that (back when I joined at 
> least) asked not to use dev.gentoo.org for hosting said fails and 
> rather prefer to use mirror://gentoo/, they already stated that it's 
> not a problem to do so until we have a proper system in place
> (system that has been considered and worked on for quite a bit
> already and yet is not available).
> 
> Unfortunately, as long as the mirror://gentoo/ option is still 
> maintained, we'll end up with situations like today's gnuconfig that
>  couldn't be fetched, causing all ~arch users to see the same 
> failure, because the distfile wasn't uploaded to the staging area.
> Of course the same could happen with a stable SRC_URI, but then it
> would fail after hitting that, rather than going through half the
> gentoo mirrors trying to find a file that is not there.
> 
> So, anybody has reasons beside laziness, or concern for infra's disk
>  usage (that argument is allowed to come only from infra members!), 
> to not go this route?

Diego,

I understand the concern, but instead of banning the use of
mirror://gentoo, why not make it mandatory to have a dev.gentoo.org link
in SRC_URI when there's a mirror://gentoo link?

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOTP2OAAoJEC8ZTXQF1qEPWnoP/jpHJAonBiWm7p6xp1AjuAaE
t2vkFYFpxQRJ0IOYSaXh1Qrynhzc7ky5sT3G6/sLZPARfbCKinjWEXqGJMyvEsHU
tkk4cRdTeoi1iCa8tDtMVgXCEVofhwYJZQvbm+rVRzwuGgks4kNxsVOlAcmPZ3iU
tj9mfgFqKmhuNbFHe/fcPTkEFmCfyMFQdbt0btdk9PKOZK4MK39lEd6kifkNFRKp
Xtzud3uttud+5bOJIQ4er2OthNQhQGEA2SUnS8M5TL0qZyQDfHNrxZGMwbCu/qqz
vsldI6H6d0mCpuBDJ0WeFTcwwgSRCrM2+WiHsseJCUQODcSNkAikSvtaSNyx1LZg
PDQt05m4cX4bQ1I2obwJUvvss7LrDUH9P0JRE+4SHQsPAPwUMNMl3wfPg+PTXXF+
EI1QVEySaMsbJE3czQ7x8stt7Ogzh54eswwKn7Z40yjByX95gH+Oy75ouZmNV5AX
FEnnvpOCyOorc+K1ye+q26rwYHOndtuI/geGRHaF4HDpY+DKyzkq5Pj4v+m7/njP
V1QzYbMu+CYeBlnpnvpQ690Kxayn9e2+5n6DDzoJw1SjBMfJcZ9RnqXJvi0+6uJ3
fuH/FR9iczxambDEgafACKLGXfaNUuIfDeeXK3Xf1qXp2JYfDNmR68HWN8a0hjBm
SDk6u/zlsSpq6oYuUgAg
=96T7
-END PGP SIGNATURE-

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18-08-2011 08:50, Diego Elio Pettenò wrote:


Diego,

I understand the concern, but instead of banning the use of
mirror://gentoo, why not make it mandatory to have a dev.gentoo.org link
in SRC_URI when there's a mirror://gentoo link?

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOTP1+AAoJEC8ZTXQF1qEP/EQQAKMv5JQsj6dH9ry2+Pukf6oh
PqXJkcJJBe2b3vIHRdaj50qiXvpZDYSsRX4U5juCG9nwlYSx0UyZkBVZl9IQHmpB
8XRXZAsjtku100mejuOm8RffINXWvy1pefvN1Qdofnu1US/l8SXSZCQf9VikRvLI
HEcrCAHETSjm4ZbuChc9o2ZH2qbkeRZCctZvmVSOWcTRMdkBoNAwYTDnCYzly36m
OfMLWCwpNBhIT3z4mK7BEMYx8kGAr7xM5tzBnBXaLu3XJ6Q2iX/yFsrdxJLoaxnx
OxMk3DxG/8zdD41u1UPh2oSDaYIfDl1JAGv2etvNPmatCv3RqL4vKRp8J1buZmJw
/IK8C7mzj0HU7sOaIkIAZDP0fi/9QG0RPYSh6bi2mVF+mQ3lOWLdXdzDtT9X7aUW
zvBgVUvmNLgn52jvGK0fzaqtfQ9rL+RYuM46ziTPg2eJOK7adrlAHcyE7RVIl4ks
z07qV4EqzFWmDXriRo8C556XUkCUO16X0QQFKmm6TrM58PEqjP1mviCxMKj6RTYI
4pkNKyFnIDI7z2i6NaCVwi+V3OvB1BthiMMVt0TgM8zjV/99sZw7LVpX3WIaiFdR
yUz/f8OPTPmZfQNtXz2MGmoX6CNSOIUyH6uo6GPIY/dtsh/jLiOlOOUQB9FWpsq9
5UFiY6VYzkDd1wkMA1hb
=KKq4
-END PGP SIGNATURE-

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 11.54 +, Jorge Manuel B. S. Vicetto
ha scritto:
> 
> I understand the concern, but instead of banning the use of
> mirror://gentoo, why not make it mandatory to have a dev.gentoo.org
> link
> in SRC_URI when there's a mirror://gentoo link? 

Because they are functionally equivalent.

If you do have a SRC_URI pointing to dev.g.o, then portage _will_ look
for the file in the gentoo mirrors by default unless you explicitly
RESTRICT it.

Having two SRC_URI entries is not really going to make a difference, and
it's easier to catch: you just remove the gentoo entry from
thirdpartymirrors.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Ulrich Mueller]

> On Thu, 18 Aug 2011, Diego Elio Pettenò wrote:

>> I understand the concern, but instead of banning the use of
>> mirror://gentoo, why not make it mandatory to have a dev.gentoo.org
>> link
>> in SRC_URI when there's a mirror://gentoo link? 

> Because they are functionally equivalent.

They are not, in fact.

> If you do have a SRC_URI pointing to dev.g.o, then portage _will_
> look for the file in the gentoo mirrors by default unless you
> explicitly RESTRICT it.

And if you have an SRC_URI pointing to mirror://gentoo/ then Portage
will look for the file on Gentoo mirrors, regardless of any fetch or
mirror restriction. This can be useful, e.g., if you need the mirror
restriction only for one file in SRC_URI.

Ulrich

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 16.11 +0200, Ulrich Mueller ha scritto:
> 
> And if you have an SRC_URI pointing to mirror://gentoo/ then Portage
> will look for the file on Gentoo mirrors, regardless of any fetch or
> mirror restriction. This can be useful, e.g., if you need the mirror
> restriction only for one file in SRC_URI. 

Right, I was avoiding that point, because as far as I can tell, it's not
what Jorge was thinking of.

SRC_URI="http://dev.gentoo.org/~flameeyes/${PN}/${P}.tar.xz";

and

SRC_URI="mirror://gentoo/${P}.tar.xz
http://dev.gentoo.org/~flameeyes/${PN}/${P}.tar.xz";

are functionally equivalent though, as long as there is no mirror
restriction.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Mike Frysinger]

On Thursday, August 18, 2011 04:50:23 Diego Elio Pettenò wrote:
> Unfortunately, as long as the mirror://gentoo/ option is still
> maintained, we'll end up with situations like today's gnuconfig that
> couldn't be fetched, causing all ~arch users to see the same failure,
> because the distfile wasn't uploaded to the staging area.

you're understanding of this particular bug is completely off.  i forgot to 
upload the pkg -- the only place it existed was on my desktop.  it had nothing 
to do with SRC_URI.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Michał Górny]

On Thu, 18 Aug 2011 14:38:01 +0400
Maxim Koltsov  wrote:

> We've fixed all the problems with eclass. Please review it and give OK
> for commit, i plan to do it this night.

>   0|1) die "EAPI not supported, bug ebuild mantainer" ;;
>   *) die "Unknown EAPI, Bug eclass maintainers." ;;

I think I already mentioned that. Keep consistent case, and in this
case lowercase 'bug' is correct'.

> # @ECLASS-VARIABLE: LC_PCAT
> # @DESCRIPTION:
> # Set this to the category of the plugin, if any.
> : ${LC_PCAT:=}

Please use verbose variable names, and prefix them with eclass
filename; e.g. LEECHCRAFT_PLUGIN_CATEGORY.

And I think @DEFAULT_UNSET may be of interest too.

> 
> if [ "${LC_PCAT+x}" != "x" ]; then
>   CMAKE_USE_DIR="${S}/src/plugins/${LC_PCAT}/${PN#leechcraft-}"
> else
>   if [[ ${PN} != "leechcraft-core" ]]; then
>   CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"
>   else
>   CMAKE_USE_DIR="${S}/src"
>   fi
> fi

if-elif-else-fi.

And I think you dropped gentoo-dev@ from recipients a few mails ago.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 10.54 -0400, Mike Frysinger ha scritto:
> 
> you're understanding of this particular bug is completely off.  i
> forgot to 
> upload the pkg -- the only place it existed was on my desktop.  it had
> nothing 
> to do with SRC_URI. 

I understand the problem pretty well, thank you very much.

But I, and others besides me I'd be ready to bet, didn't act on it much
sooner because the first reaction to a similar fetch failure on
mirror://gentoo/ is "oh the mirrors haven't synced, it'll be okay by
next hour".

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Michał Górny]

On Thu, 18 Aug 2011 12:09:39 +0200
Chí-Thanh Christopher Nguyễn  wrote:

> Diego Elio Pettenò schrieb:
> > Keep it in your dev space. As I said, the resources argument is only
> > available for infra to complain about, and since last I knew from
> > them was that it was not a problem right now...
> 
> I think robbat2 complained on IRC recently to devs which had their
> home directories full of some stuff.

Wasn't that more because of space supposedly wasted for no good reason?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Michał Górny]

On Thu, 18 Aug 2011 11:57:01 +0200
Diego Elio Pettenò  wrote:

> Il giorno gio, 18/08/2011 alle 11.15 +0200, Thomas Sachau ha scritto:
> > 
> > The argument about dropped tarballs, once the ebuilds gets removed
> > might weight a bit more, but you
> > cannot depend on other upstream keeping their tarballs around
> > forever, so i see no requirement for
> > us preserving only specific tarballs (those created by our devs),
> > while upstream tarballs could
> > already be gone and are not preserved, once the ebuild for it is
> > gone.
> 
> _Most_ upstream projects keep tarballs available of all historic
> releases; okay maybe not _all_ projects, but most, especially those
> using services such as SourceForge, Google Code, RubyForge,
> Rubygems, ...
> 
> For _our_ projects, snapshots, or packages, let's try to apply a sane
> policy. And that starts by not arguing that we shouldn't be doing so
> because others might not be doing so themselves.

I'd say do it like that:

1) for our projects -- keep all historical releases (be a good
upstream),

2) for snapshots -- keep them as long as they're used (considering that
a snapshot could be recreated at any point),

3) for patches -- it would be great if we could keep them as long as
upstream keeps the relevant tarballs.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Mike Frysinger]

On Thursday, August 18, 2011 11:02:55 Diego Elio Pettenò wrote:
> Il giorno gio, 18/08/2011 alle 10.54 -0400, Mike Frysinger ha scritto:
> > you're understanding of this particular bug is completely off.  i
> > forgot to
> > upload the pkg -- the only place it existed was on my desktop.  it had
> > nothing
> > to do with SRC_URI.
> 
> I understand the problem pretty well, thank you very much.

the context you snipped from my reply implied differently.  ~arch failing to 
fetch the file had nothing to do with mirror://gentoo/.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Fabian Groffen]

On 18-08-2011 16:57:59 +0200, Michał Górny wrote:
> > # @ECLASS-VARIABLE: LC_PCAT
> > # @DESCRIPTION:
> > # Set this to the category of the plugin, if any.
> > : ${LC_PCAT:=}
> 
> Please use verbose variable names, and prefix them with eclass
> filename; e.g. LEECHCRAFT_PLUGIN_CATEGORY.

Really?  The python eclass is full of such awkward overly verbose names.
One can also exaggerate...

> > if [ "${LC_PCAT+x}" != "x" ]; then
> > CMAKE_USE_DIR="${S}/src/plugins/${LC_PCAT}/${PN#leechcraft-}"
> > else
> > if [[ ${PN} != "leechcraft-core" ]]; then
> > CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"
> > else
> > CMAKE_USE_DIR="${S}/src"
> > fi
> > fi
> 
> if-elif-else-fi.

This sounds like a kind of bogus suggestion to me.  Mixing use of [ and
[[, on the other hand, is more what deserves attention here.



-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Alec Warner]

On Thu, Aug 18, 2011 at 8:27 AM, Fabian Groffen  wrote:
> On 18-08-2011 16:57:59 +0200, Michał Górny wrote:
>> > # @ECLASS-VARIABLE: LC_PCAT
>> > # @DESCRIPTION:
>> > # Set this to the category of the plugin, if any.
>> > : ${LC_PCAT:=}
>>
>> Please use verbose variable names, and prefix them with eclass
>> filename; e.g. LEECHCRAFT_PLUGIN_CATEGORY.
>
> Really?  The python eclass is full of such awkward overly verbose names.
> One can also exaggerate...

python.eclass, perhaps not the best style to use as a defense ;)

-A

>
>> > if [ "${LC_PCAT+x}" != "x" ]; then
>> >     CMAKE_USE_DIR="${S}/src/plugins/${LC_PCAT}/${PN#leechcraft-}"
>> > else
>> >     if [[ ${PN} != "leechcraft-core" ]]; then
>> >             CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"
>> >     else
>> >             CMAKE_USE_DIR="${S}/src"
>> >     fi
>> > fi
>>
>> if-elif-else-fi.
>
> This sounds like a kind of bogus suggestion to me.  Mixing use of [ and
> [[, on the other hand, is more what deserves attention here.
>
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Maxim Koltsov]

2011/8/18 Michał Górny :
> On Thu, 18 Aug 2011 14:38:01 +0400
> Maxim Koltsov  wrote:
>
>
>>       0|1) die "EAPI not supported, bug ebuild mantainer" ;;
>>       *) die "Unknown EAPI, Bug eclass maintainers." ;;
>
> I think I already mentioned that. Keep consistent case, and in this
> case lowercase 'bug' is correct'.

Sorry, i lost fixed version and forgot to correct this in new one :(

>> # @ECLASS-VARIABLE: LC_PCAT
>> # @DESCRIPTION:
>> # Set this to the category of the plugin, if any.
>> : ${LC_PCAT:=}
>
> Please use verbose variable names, and prefix them with eclass
> filename; e.g. LEECHCRAFT_PLUGIN_CATEGORY.
>
> And I think @DEFAULT_UNSET may be of interest too.
done

> if-elif-else-fi.
done

> And I think you dropped gentoo-dev@ from recipients a few mails ago.
Yes, added it now.

-- 
Regards, Maxim.


leechcraft.eclass
Description: Binary data

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Maxim Koltsov]

2011/8/18 Fabian Groffen :
>> > if [ "${LC_PCAT+x}" != "x" ]; then
>> >     CMAKE_USE_DIR="${S}/src/plugins/${LC_PCAT}/${PN#leechcraft-}"
>> > else
>> >     if [[ ${PN} != "leechcraft-core" ]]; then
>> >             CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"
>> >     else
>> >             CMAKE_USE_DIR="${S}/src"
>> >     fi
>> > fi
>>
>> if-elif-else-fi.
>
> This sounds like a kind of bogus suggestion to me.  Mixing use of [ and
> [[, on the other hand, is more what deserves attention here.

'elif' seems more convenient here, i just forgot about it :)

-- 
Regards, Maxim.

[gentoo-dev] Re: Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 11.20 -0400, Mike Frysinger ha scritto:
> 
> the context you snipped from my reply implied differently.  ~arch
> failing to 
> fetch the file had nothing to do with mirror://gentoo/. 

~arch failing to fetch for more than a couple of hours, though, had to
do with it.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Michał Górny]

On Thu, 18 Aug 2011 19:30:29 +0400
Maxim Koltsov  wrote:

> if [ "${LEECHCRAFT_PACKAGE_CATEGORY+x}" != "x" ]; then
>   
> CMAKE_USE_DIR="${S}/src/plugins/${LEECHCRAFT_PACKAGE_CATEGORY}/${PN#leechcraft-}"
> elif [ ${PN} != "leechcraft-core" ]; then
>   CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"

[[ ]] is better here because it's a bash builtin. And you don't need
quotes there.

What should happen if LEECHCRAFT_PACKAGE_CATEGORY is set to ''?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Re: Proposal: ban mirror://gentoo/ from ebuilds

[Mike Frysinger]

On Thursday, August 18, 2011 11:34:49 Diego Elio Pettenò wrote:
> Il giorno gio, 18/08/2011 alle 11.20 -0400, Mike Frysinger ha scritto:
> > the context you snipped from my reply implied differently.  ~arch
> > failing to
> > fetch the file had nothing to do with mirror://gentoo/.
> 
> ~arch failing to fetch for more than a couple of hours, though, had to
> do with it.

i think you've inverted this statement from what you meant.  ~arch failing to 
fetch for more than a couple of hours was because i went to sleep.  SRC_URI 
wouldnt have woken me up.
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: Re: Re: Proposal: ban mirror://gentoo/ from ebuilds

[Diego Elio Pettenò]

Il giorno gio, 18/08/2011 alle 11.55 -0400, Mike Frysinger ha scritto:
> 
> i think you've inverted this statement from what you meant.  ~arch
> failing to 
> fetch for more than a couple of hours was because i went to sleep.
> SRC_URI 
> wouldnt have woken me up. 

Not you, but it would have masked much earlier, by me or someone else.

Seriously, can you stop making this about you and look at the big
picture?

Ulrich did provide a good reason not to simply ban mirror://gentoo/ —
now can you make up any good reason why you shouldn't be uploading this
to _your devspace_ rather than the distfiles directly?

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Roy Bamford]

On 2011.08.18 10:59, Anthony G. Basile wrote:
[snip]
 
> Understood that infra gets to complain, but that still doesn't tell 
> me
> what the deprecation policy is.  Keep all my large patchsets
> indefinitely? Or remove them when an ebuild no longer needs them?  Or
> 1
> year after an ebuild no longer needs them?
> 
> -- 
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
> 
> 
Just as long as we can provide the patch sets for a period of at least 
three years, in case someone asks.  Thats a GPL requirement.

Thats not to say the files need to be online but Gentoo needs to be 
able to provide them on request.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpLniAICC5Gs.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: Re: Proposal: ban mirror://gentoo/ from ebuilds

[Mike Frysinger]

On Thursday, August 18, 2011 12:13:44 Diego Elio Pettenò wrote:
> Il giorno gio, 18/08/2011 alle 11.55 -0400, Mike Frysinger ha scritto:
> > i think you've inverted this statement from what you meant.  ~arch
> > failing to
> > fetch for more than a couple of hours was because i went to sleep.
> > SRC_URI
> > wouldnt have woken me up.
> 
> Not you, but it would have masked much earlier, by me or someone else.
> 
> Seriously, can you stop making this about you and look at the big
> picture?

i corrected your wrong statements wrt gnuconfig.  i dont know why you're 
getting upset over nothing.

as for "the big picture", that would involve an infra solution, not devspace

> Ulrich did provide a good reason not to simply ban mirror://gentoo/ —
> now can you make up any good reason why you shouldn't be uploading this
> to _your devspace_ rather than the distfiles directly?

all of my archives have been mirrored in my personal devspace.  if you're 
implying that i dont do that, you're mistaken.  i am however not a fan of 
listing dev.g.o in SRC_URI for the same reasons infra is.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Maxim Koltsov]

2011/8/18 Michał Górny :
> On Thu, 18 Aug 2011 19:30:29 +0400
> Maxim Koltsov  wrote:
>
>> if [ "${LEECHCRAFT_PACKAGE_CATEGORY+x}" != "x" ]; then
>>       
>> CMAKE_USE_DIR="${S}/src/plugins/${LEECHCRAFT_PACKAGE_CATEGORY}/${PN#leechcraft-}"
>> elif [ ${PN} != "leechcraft-core" ]; then
>>               CMAKE_USE_DIR="${S}/src/plugins/${PN#leechcraft-}"
>
> [[ ]] is better here because it's a bash builtin. And you don't need
> quotes there.
>
> What should happen if LEECHCRAFT_PACKAGE_CATEGORY is set to ''?

Fixed, i think. In this version empty variable will be handled correctly.

-- 
Regards, Maxim.


leechcraft.eclass
Description: Binary data

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Michał Górny]

On Thu, 18 Aug 2011 22:33:15 +0400
Maxim Koltsov  wrote:

> if [[ -z "${LEECHCRAFT_PACKAGE_CATEGORY}" ]]; then
>   
> CMAKE_USE_DIR="${S}"/src/plugins/${LEECHCRAFT_PACKAGE_CATEGORY}/${PN#leechcraft-}

Dude, that's the opposite.

> elif [[ ${PN} != "leechcraft-core" ]]; then
>   CAKE_USE_DIR="${S}"/src/plugins/${PN#leechcraft-}

Don't quote that. It looks bad that the left-side is unquoted and right
side is quoted.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Robin H. Johnson]

On Thu, Aug 18, 2011 at 05:08:43PM +0200, Michał Górny wrote:
> On Thu, 18 Aug 2011 12:09:39 +0200
> Chí-Thanh Christopher Nguyễn  wrote:
> 
> > Diego Elio Pettenò schrieb:
> > > Keep it in your dev space. As I said, the resources argument is only
> > > available for infra to complain about, and since last I knew from
> > > them was that it was not a problem right now...
> > 
> > home directories full of some stuff.
> 
> 
Yes, to clarify, I said distfiles were fine. It was other junk that
needed cleanup, somebody had a pile of old stages that he was comparing
a tmpdir, somebody else had temp KDE distfiles, that sort of cleanup.
-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Fabian Groffen]

On 18-08-2011 20:42:23 +0200, Michał Górny wrote:
> > elif [[ ${PN} != "leechcraft-core" ]]; then
> > CAKE_USE_DIR="${S}"/src/plugins/${PN#leechcraft-}
> 
> Don't quote that. It looks bad that the left-side is unquoted and right
> side is quoted.

it's a string, what's the problem?



-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Michał Górny]

On Thu, 18 Aug 2011 20:43:59 +0200
Fabian Groffen  wrote:

> On 18-08-2011 20:42:23 +0200, Michał Górny wrote:
> > > elif [[ ${PN} != "leechcraft-core" ]]; then
> > >   CAKE_USE_DIR="${S}"/src/plugins/${PN#leechcraft-}
> > 
> > Don't quote that. It looks bad that the left-side is unquoted and
> > right side is quoted.
> 
> it's a string, what's the problem?

It's just a matter of taste. I think it looks better if both sides are
quoted, or neither is.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Ulrich Mueller]

> On Thu, 18 Aug 2011, Michał Górny wrote:

> On Thu, 18 Aug 2011 20:43:59 +0200
> Fabian Groffen  wrote:

>> > > elif [[ ${PN} != "leechcraft-core" ]]; then
>> > >  CAKE_USE_DIR="${S}"/src/plugins/${PN#leechcraft-}
>> > 
>> > Don't quote that. It looks bad that the left-side is unquoted and
>> > right side is quoted.
>> 
>> it's a string, what's the problem?

> It's just a matter of taste. I think it looks better if both sides
> are quoted, or neither is.

But both sides of [[ ]] aren't symmetric, in the first place:

# When the == and != operators are used, the string to the right of
# the operator is considered a pattern and matched according to the
# rules described below under Pattern Matching.

So there's almost never a reason for quoting the left-hand side, while
on the right-hand side quotes will suppress pattern matching.

(Of course, in the example above it doesn't matter, because the string
doesn't contain any special characters.)

Ulrich

Re: [gentoo-dev] Re: RFC: leechcraft.eclass

[Fabian Groffen]

On 18-08-2011 21:41:47 +0200, Michał Górny wrote:
> On Thu, 18 Aug 2011 20:43:59 +0200
> Fabian Groffen  wrote:
> 
> > On 18-08-2011 20:42:23 +0200, Michał Górny wrote:
> > > > elif [[ ${PN} != "leechcraft-core" ]]; then
> > > > CAKE_USE_DIR="${S}"/src/plugins/${PN#leechcraft-}
> > > 
> > > Don't quote that. It looks bad that the left-side is unquoted and
> > > right side is quoted.
> > 
> > it's a string, what's the problem?
> 
> It's just a matter of taste. I think it looks better if both sides are
> quoted, or neither is.

Right, it's a matter of taste, so the snippet is fine as-is.

Commenting on code is fine, Just don't present your taste as if it is
the only right thing to do.


-- 
Fabian Groffen
Gentoo on a different level

[gentoo-dev] Re: Re: RFC: leechcraft.eclass

[Steven J Long]

Ulrich Mueller wrote:

> But both sides of [[ ]] aren't symmetric, in the first place:
> 
> # When the == and != operators are used, the string to the right of
> # the operator is considered a pattern and matched according to the
> # rules described below under Pattern Matching.
> 
> So there's almost never a reason for quoting the left-hand side, while
> on the right-hand side quotes will suppress pattern matching.
> 
> (Of course, in the example above it doesn't matter, because the string
> doesn't contain any special characters.)
> 
Indeed; minor addition: the above applies to [[ foo = bar* ]] as well,
ie you don't have to use == (and most BASH scripters don't.) It's the fact 
that you're in [[ which triggers fnmatch() behaviour.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

[Duncan]

Roy Bamford posted on Thu, 18 Aug 2011 17:41:15 +0100 as excerpted:

> On 2011.08.18 10:59, Anthony G. Basile wrote:
> [snip]
>  
>> Understood that infra gets to complain, but that still doesn't tell me
>> what the deprecation policy is.  Keep all my large patchsets
>> indefinitely? Or remove them when an ebuild no longer needs them?  Or 1
>> year after an ebuild no longer needs them?
>> 
> Just as long as we can provide the patch sets for a period of at least
> three years, in case someone asks.  Thats a GPL requirement.
> 
> Thats not to say the files need to be online but Gentoo needs to be able
> to provide them on request.

That's a very good point and "legal matters, and potentially it matters a 
lot!", but AFAIK it's not exactly correct (and "legal matters, and 
potentially it matters a lot!").

I am not a lawyer, etc, but as I understand it...

1) Generally, the GPL source-provision rules *ONLY* apply if you're 
shipping binaries in the first place, not for sources-only, which fulfill 
the source-provision by definition.

Since in *MOST* cases, Gentoo is shipping source, not binaries, where 
that is the case, we don't need to worry about the GPL source provision 
rules.

However, we DO ship SOME binaries, both in the packages images and in the 
stages and live-images.  Here, we DO need to worry about the GPL's source-
provision rules.  The below point applies to this case.

2) For those shipping binaries, the GPLv2 (I'm not particularly familiar 
with the GPLv3 in this regard so can't say, for it) offers two 
independent ways to fill the source-provision requirements.

2a) The provider can make sources available at the same time/place and by 
the same method as the binaries.  There's some precise definitional 
detail to same time/place and method requirements designed to ensure that 
if a user finds the binaries, they at least should be aware of the 
availability of the sources, but the point is, AS LONG AS the sources are 
made available similarly, that fulfills the sources-provision 
requirement, NO THREE YEAR RULE APPLIES!

2b) If the provider chooses NOT to make sources available at the same 
time/place and by the same method, AN ALTERNATIVE is to be able to 
provide them on demand FOR THREE YEARS AFTER THE BINARY IS NO LONGER 
PROVIDED.  *THIS* is where the three-year rule comes in.  It ONLY applies 
if the binary provider chose not to go with the same time/place/method 
alternative.  An additional requirement here is that sources must be 
available to ALL (not just customers/those-who-originally-downloaded-the-
binaries) who make the request, but again, it only applies if the same 
time/place/method alternative wasn't chosen.

It's worth noting that this discussion has come up before on this list 
and is archived.  At that time, it was noted that Gentoo was still making 
available downloads of the 1.4 and earlier install media, "for historical 
interest", and that because we were still shipping them (and because they 
contained GPLv2 content), that obligated Gentoo to providing exact 
sources (including but not limited to the original tarballs, and all 
patches, plus scripts, etc, as necessary) until three years after Gentoo 
quit making them available.

IIRC, the (first) decision then, since providing those sources was going 
to be very difficult if anyone DID ask, was to take down those "for 
historical interest" images ASAP, so at least the clock would be ticking 
on that three-year requirement.

I know I didn't follow up to ensure it was done.  I hope someone did.  
FWIW, the legal responsibility would (AFAIK) fall on the foundation, so 
it would presumably be their job to ensure this was done, and from that 
point, that previous media were taken down in a timely manner so as not 
to get Gentoo in that situation once again.

The second decision then (again, IIRC, but it's in the archives if anyone 
feels the need to look it up), and I've seen it made elsewhere as well 
(Gentoo's not the first to conclude it's by *FAR* the least hassle), was 
to have and enforce a Gentoo policy that we ALWAYS complied with the same 
time/place/method option, so we never had to worry about the three-year-
clock on the by-request option at all.

Again, I believe it's the Foundation's responsibility here, so they're 
the ones that should be ensuring this is enforced.  FWIW, while I do have 
an interest in software freedom, thus my reasonably close following of 
the discussion at the time (and the degree to which I understand the 
distinction between the two sources-provision options in the first 
place), my personal legal butt isn't in the sling here, so I've felt no 
need to personally follow-up and ensure this policy is being followed.

Thus my point in the context of this thread.  As long as Gentoo is 
continuing to follow the policy decided then, that of always ensuring 
that sources are made available at the same time and place, and by the 
same method, as the binaries we are shipping, we've done our du