Bugzilla Bug 232985

'emerge -pvuDN world' needs very long (more than 40 minutes) trying to download
cups-1.3.8-source.tar.bz2. Sometimes I see the message "Fetching files in the
background. To view fetch progress, run `tail -f /var/log/emerge-fetch.log` in
another terminal", but not everytime. E.g. just now I see in the window, were I
started 'emerge -pvuDN world' as the last message:

/usr/lib/tcl8.5 is not a valid Tcl/Tk library directory
Check the definitions of TCL_LIBRARY_PATH and TK_LIBRARY_PATH
make: *** [/usr/lib/tcl8.5/tclIndex] Error 1
 * 
 * ERROR: media-tv/nxtvepg-2.8.0 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 2174:  Called die
 * The specific snippet of code:
 *           emake -j1 CC=$(tc-getCC) prefix="/usr" || die "emake failed";
 *  The die message:
 *   emake failed
 * 
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/media-tv/nxtvepg-2.8.0/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/media-tv/nxtvepg-2.8.0/temp/environment'.
 * 

and nothing happens for several minutes. If I try in a other window 'tail -f
/var/log/emerge-fetch.log', I get the message: "Connecting to
belnet.dl.sourceforge.net|193.190.198.97|:80...", so I see emerge is trying to
download something. But it would be good to have some information in the
window, where I started 'emerge -uvDN world'.

same here

*** This bug has been marked as a duplicate of bug 232978 ***

I would like to reopen the bug. I mean it is not a duplicate of bug 232978.
The core of this bug is not the missing tar file, but the long hanging of
emerge without any message about the problem.

Which Portage version are you using? I did override FETCHCOMMAND locally,
because default wget time out values suck completely, but I don't know, if this
really is the reason Portage stalls here.

Hi Carsten,

I am using portage-2.2_rc3.

Juergen

Created an attachment (id=161413) [details]
cancel fetchers when they are all that's keeping the main loop alive

Somebody reported this yesterday and it was fixed in svn r11185.

This is fixed in 2.2_rc4.