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.
