When I try to do the following: $ emerge /usr/portage/app-admin/ufed/ufed-0.31.ebuild portage goes through its full range of mirrors, fetches the file but continues on to the rest of the mirrors with the following intermittent error messages. -------- The file is already fully retrieved; nothing to do. Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/usr/portage/distfiles/ufed-0.31.tar.bz2'. !!! Couldn't download ufed-0.31.tar.bz2. Aborting. !!! Fetch for /usr/portage/app-admin/ufed/ufed-0.31.ebuild failed, continuing... !!! Some fetch errors were encountered. Please see above for details. -------- These errors alternate with portage eventually giving up with the last few messages prefixed with exclamation marks. I have tried deleting the downloaded tarball and reemerging but the same happens. Here is my emerge info. Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz GENTOO_MIRRORS="http://gentoo.linux.no/ http://ftp.tu- clausthal.de/pub/linux/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo/ " CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/shar e/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow avi cups encode gif jpeg mikmod mmx mpeg ncurses pdflib png quicktime truetype xml2 xmms xv zlib directfb gtkhtml alsa slang readline aalib svga java X sdl tcpd pam libwww ssl python imlib oggvorbis gtk qt motif opengl mozilla cdr acpi dvd fbcon gtk2 imap sse tiff usb xml -oss -apm -crypt - libg++ -nls -spell -gdbm -berkdb -arts -tetex -nas -bonobo -tcltk -guile -gpm - perl -esd -gnome -kde" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays - falign-functions=4 -funroll-loops -ffast-math -fforce-addr" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -fprefetch-loop- arrays -falign-functions=4 -funroll-loops -ffast-math -fforce-addr" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.uk.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
When I attempt it i get: 416 Requested Range Not Satisfiable which means: Your Web server thinks that the HTTP data stream sent by the client contains a 'Range' request which specifies a range of bytes which can not be satisfied - because the resource being accessed does not cover this byte range. For example if the resource - an image file for example - has 1000 bytes and the Range requested is 500-1500, then it can not be satisfied. What It means I dont know I apologize to the bug wranglers, I didnt mean to reassign this on to myself so I am giving it back to you.
I have reproduced the bug. And I think I have found why it happens as well, and I've fixed it my side, but I think it is indicative of a bug in portage. this is the current digest for ufed-0.31 files: MD5 ef99cb4ad2389b6cb6bbae7177f4e1af ufed-0.31.tar.bz2 15204 now from my portage dir, and some of the mirrors: -rw-r--r-- 1 root root 15179 Apr 30 16:06 /usr/portage/distfiles/ufed-0.31.tar.bz2 hmm, different file sizes! now md5: 8ab51e1dad0b472302de632a15d03b1e /usr/portage/distfiles/ufed-0.31.tar.bz2 different md5sums too (which is not a surprise with different sizes). If I delete my local copies of the digests and regenerate them, it emerges fine. 'repoman scan' in my cvs checkout does NOT catch this. perhaps there should be an option to force it to check on scan if the file is available? As to why it wanted to continually download, I suspect portage has some code that is reading the size out of the digest file, and using it to request a file resume under some conditions. there needs to be a check for the downloaded file being BIGGER than what the file is supposed to be before any resume of download is done. i have fixed the ufed ebuild for now by recommiting the digests. when it gets out to the rsync servers, could you please try it again Dhruba ?
It fetches and emerges as normal now. Thanks.
Should this bug be closed given that the problem is now fixed?
Dhruba: I believe it is still a bug that portage did not detect the infinite loop.
It's not an infinate loop. It's really not a fixable condition either. Portage can only assume the information it gets from devs/users via digests is correct information. It tries to exhaust all of its options before giving up. Nothing I can do about this one. file is 100 bytes short... portage says 'keep trying'... Server says 'no'... portage moves on to the next server hoping to complete the request. ebuild's digest bug, not portage.
Portage/Ebuild just need a simple check added if the file already exists, what size is it? If it's larger than the digest says it should be, then something is definetly wrong. If it is less than the correct size, try to resume. If it is the correct size, then we have it. This will eradicate the problem.
