'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 attachment 161413 [details, diff] 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.
