Brian Dessent wrote: > > Charles Wilson wrote: > > > As no one was actually able to install this file, is it OK to replace it > > on sourceware (perhaps deleting the .md5sum file) without bumping the > > version number? > > Yes, I considered doing that myself. Sounds like a good idea.
Crap. It looks like there are a lot of these on sourceware: [EMAIL PROTECTED] release]$ find . -name \*.tar.bz2 -size -45c -printf "%s %P\n" 14 GNOME/libbonobo2/libbonobo20/libbonobo20-2.10.1-1.tar.bz2 14 GNOME/libbonobo2/libbonobo20/libbonobo20-2.14.0-1.tar.bz2 14 GNOME/gnome-libs/gnome-libs-1.4.2-2.tar.bz2 14 jpeg/libjpeg-devel/libjpeg-devel-6b-11.tar.bz2 14 autoconf/autoconf-devel/autoconf-devel-2.59-2.tar.bz2 14 autoconf/autoconf-devel/autoconf-devel-2.59-2-src.tar.bz2 14 autoconf/autoconf-stable/autoconf-stable-2.13-6-src.tar.bz2 14 autoconf/autoconf-stable/autoconf-stable-2.13-6.tar.bz2 14 pkgconfig/pkgconfig-0.17.2-3-src.tar.bz2 14 pkgconfig/pkgconfig-0.17.2-3.tar.bz2 14 automake/automake-devel/automake-devel-1.9.2-2-src.tar.bz2 14 automake/automake-devel/automake-devel-1.9.2-2.tar.bz2 14 automake/automake-1.7.9-2.tar.bz2 14 automake/automake-stable/automake-stable-1.4p6-3-src.tar.bz2 14 automake/automake-stable/automake-stable-1.4p6-3.tar.bz2 14 automake/automake-1.7.9-2-src.tar.bz2 14 _obsolete/more/more-2.11o-3.tar.bz2 14 _obsolete/more/more-2.11o-3-src.tar.bz2 14 _obsolete/agetty/agetty-2.1-2.tar.bz2 14 _obsolete/agetty/agetty-2.1-2-src.tar.bz2 14 _obsolete/libtool/libtool-devel/libtool-devel-1.5.10-2-src.tar.bz2 14 _obsolete/libtool/libtool-devel/libtool-devel-1.5.10-2.tar.bz2 14 _obsolete/libtool/libtool-1.5b-2.tar.bz2 14 _obsolete/libtool/libtool-stable/libtool-stable-1.4.3-3-src.tar.bz2 14 _obsolete/libtool/libtool-stable/libtool-stable-1.4.3-3.tar.bz2 14 _obsolete/libtool/libtool-1.5b-2-src.tar.bz2 14 _obsolete/setsid/setsid-0.0-4.tar.bz2 14 _obsolete/setsid/setsid-0.0-4-src.tar.bz2 14 _obsolete/fftw3-dev/fftw3-dev-3.1.2-2.tar.bz2 The reason this hasn't been a widely reported problem is that the message box for invalid tar files only exists in the setup snapshot versions, not the released version. But it will be after the next release, whenever that is. The feature was added because someone reported that a package was mysteriously not installing, and after some debugging the reason turned out to be that it had been created with some alternative tar-program that used a different magic. So setup was taught to recognize that new magic, as well as report future failures explicitly rather than silently ignoring the package. However, setup cannot distinguish the difference between EOF (i.e. 0 byte file) and magic mismatch. I think it would be prudent to teach setup not to complain about bzipped 0-byte files, but I still feel that on principle if you call something ".tar.bz2" it had ought to be a valid tar file. I'll work on a patch. Brian