Bugzilla Bug 186715

The distribution file is no longer available at the apache mirrors, as 3.2.2 is
latest version.

Reproducible: Always




I've found the file here
(http://dl.ambiweb.de/mirrors/ftp.cpan.org/modules/by-category/19_Mail_and_Usenet_News/Mail/JMASON/Mail-SpamAssassin-3.2.1.tar.bz2)
and downloaded it to /usr/portage/distfiles - that worked. Probably it should
temporarily backed up into portage, because we shouldn't use a
third-party-server for this ;-)

Why's this missing on Gentoo mirrors?!

AFAIK, most dist files are downloaded from their original servers/mirrors.
However, in this case, the file has been removed from the Apache mirrors, so
it's necessary to either provide the dist file on a Gentoo server or to provide
an upgraded ebuild.

(In reply to comment #2)
> AFAIK, most dist files are downloaded from their original servers/mirrors.

Nope, unless you have GENTOO_MIRRORS unset or unless there's RESTRICT="mirror"
in the ebuild.

Renaming the ebuild is sufficient for compiling spamassassin. Just tried it and
it works fine on amd64.

(In reply to comment #2)
> AFAIK, most dist files are downloaded from their original servers/mirrors.
> However, in this case, the file has been removed from the Apache mirrors, so
> it's necessary to either provide the dist file on a Gentoo server or to provide
> an upgraded ebuild.

This has nothing to do with mirror-admins. As epdv pointed out, upstream
decided to remove it from the mirrors. Thus I changed the SRC_URI to point to
archives.apache.org which still has the DISTFILE.

OK, I'm just committing the fix. Should be on the mirrors in about 45 minutes.

(In reply to comment #5)
> This has nothing to do with mirror-admins. As epdv pointed out, upstream
> decided to remove it from the mirrors. Thus I changed the SRC_URI to point to
> archives.apache.org which still has the DISTFILE.

That's nice, but it was available on Gentoo mirrors before and shouldn't just
vanish from there no matter how much upstream shuffles with their stuff.
Completely defeats one of the main purposes of mirroring the tarballs in the
first place.

*** Bug 189077 has been marked as a duplicate of this bug. ***

Same issue with 3.2.2, nowhere to be found on our mirrors. Re-assigning to
mirror admins, because we have mirrors for a reason. 

The file is supposed to get mirrored from SRC_URI (unless there's a
RESTRICT=mirror) and *stay* on the Gentoo mirrors until the ebuild gets
*removed* from the tree, no matter what upstream does, where it shuffles the
tarball or whether it gets removed even by upstream. This will prevent exactly
such crap as in this bug, but it doesn't work ATM.

Hi,

please don't reassign this bug every two comments :)

either the mirror team decides to find a 3.2.2 tarball from...
i-dont-know-where, either the Perl team decides to p.mask or delete the
ebuild... 

Honestly, i'm not sure anybody could be able to find a 3.2.2 tarball on the net
now. It seems to have completely vanished, even google fails to find it.
Perhaps on some random user hard drives? If a Perl developer had such a tarball
then he could drop it to our distfiles-local to make everybody happy.

AFAIK, the delete procedure on the Gentoo distfiles mirrors is entirely
automatic. I was told one day that the mirrors don't care whether the ebuild
exists or not, they only care about the last access time. If the file is not
acceded anymore within a few days, it is dropped.

I think just deleting the ebuild (and introducing spamassassin-3.2.3 which
provides several bug fixes) is the best thing to do, in the present case.
Perhaps the mirror policy could be improved or changed, but that's not the
objective of this bug.

(In reply to comment #10)
> Honestly, i'm not sure anybody could be able to find a 3.2.2 tarball on the net
> now. It seems to have completely vanished, even google fails to find it.
> Perhaps on some random user hard drives? If a Perl developer had such a tarball
> then he could drop it to our distfiles-local to make everybody happy.

The point of Comment #9 is to prevent this from happening over and over again.
Why do the tarballs plain vanish from our mirrors? Surely it must have been
available upstream until lately, otherwise noone would have been able to bump
the ebuild in the first place. Once it gets mirrored, it's supposed to sit
there until there's no ebuild using the tarball, not just randomly disappear
when upstream moves/nukes the file. What'd be the point of mirroring tarballs
then?

(In reply to comment #11)
> The point of Comment #9 is to prevent this from happening over and over again.
> Why do the tarballs plain vanish from our mirrors?

As i said sooner, the tarballs are dropped when they are not accessed anymore
within a given period of time  --  mirrors admins certainly know the exact
delay. As far as i can tell, it has nothing to do with upstream removal. It is
not a voluntary action. I am not saying that it is the only good choice, but it
has worked until now.



What i consider more harmfull is a behaviour like http://apache.secsup.org/,
which doesn't send a 404 error but a 302 redirect to a plain text page, and
obviously:

bzip2:
/var/tmp/portage/mail-filter/spamassassin-3.2.2/distdir/Mail-SpamAssassin-3.2.2.tar.bz2
is not a bzip2 file.

(This might worth another bug)

Pushed older packages on gentoo-mirrors manually.