Bug 138840 – Better message for parallel-fetch download status

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Jose daLuz 2006-07-02 05:25:08 UTC]

During an emerge -u world, I encountered the following message:
waiting for lock on /var/portage/distfiles/.locks/OOo_2.0.3_LinuxIntel_install.tar.gz.portage_lockfile

I did figure out that the latest openoffice.org tarball was still downloading in the background. Still, this is not exactly transparent. Could you at least mention "Waiting for <package_X> download to complete" for the benefit of those who don't know from lockfiles?

[Comment 1 Aaron Peterson 2006-07-03 16:44:12 UTC]

I wholely agree.

I have an actioncrap router that doesn't update the DNS server properly.. and I have to manually add a  DNS server every time I boot.  I knew that I had to edit /etc/resolv.conf when I saw the error.. but I don't think everybody would know that....

[Comment 2 Aaron Peterson 2006-07-03 16:48:14 UTC]

here are a list of errors that I can forsee

 downloading  x percent
 DNS error
 File not found error
 network disconnected

and number of tries

[Comment 3 Zac Medico 2006-07-03 17:17:37 UTC]

You should be able to see what's happening with the download in /var/log/emerge-fetch.log.

[Comment 4 Jose daLuz 2006-07-03 17:37:40 UTC]

(In reply to comment #3)
> You should be able to see what's happening with the download in
> /var/log/emerge-fetch.log.
> 
Hmmm. This is what mine currently looks like:
>>> Previously fetched file: LogKit-1.2-src.tar.gz MD5 ;-)
>>> Previously fetched file: LogKit-1.2-src.tar.gz RMD160 ;-)
>>> Previously fetched file: LogKit-1.2-src.tar.gz SHA1 ;-)
>>> Previously fetched file: LogKit-1.2-src.tar.gz SHA256 ;-)
>>> Previously fetched file: LogKit-1.2-src.tar.gz size ;-)
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking LogKit-1.2-src.tar.gz ;-)
>>> Previously fetched file: git-1.4.1.tar.bz2 MD5 ;-)
>>> Previously fetched file: git-1.4.1.tar.bz2 RMD160 ;-)
>>> Previously fetched file: git-1.4.1.tar.bz2 SHA1 ;-)
>>> Previously fetched file: git-1.4.1.tar.bz2 SHA256 ;-)
>>> Previously fetched file: git-1.4.1.tar.bz2 size ;-)
>>> Previously fetched file: git-manpages-1.4.1.tar.bz2 MD5 ;-)
>>> Previously fetched file: git-manpages-1.4.1.tar.bz2 RMD160 ;-)
>>> Previously fetched file: git-manpages-1.4.1.tar.bz2 SHA1 ;-)
>>> Previously fetched file: git-manpages-1.4.1.tar.bz2 SHA256 ;-)
>>> Previously fetched file: git-manpages-1.4.1.tar.bz2 size ;-)
...and a few more lines of the same. Nothing in the file shows download status or anything about downloads other than that they already happened.

Couldn't the log output of wget be filtered to add the download status to the log? And in my case above, where emerge is waiting for a download to complete, couldn't the current download status be the message? I haven't encountered a parallel-fetch download error yet so I don't know what the error message looks like, but wget's error reporting is good, so perhaps that could be provided to answer Aaron Peterson's issues as well.

[Comment 5 Jose daLuz 2006-07-03 17:39:44 UTC]

I've got an emerge going now, so I see the download info is there. Does it get wiped after every emerge?

[Comment 6 Zac Medico 2006-07-03 19:01:29 UTC]

Yeah, it's overwritten with each parallel fetch.  The log from comment #4 shows that the files had already been fetched, probably from a previous parallel fetch.

[Comment 7 Robert Zaleski 2006-09-25 09:35:19 UTC]

Yeah this one got me too.  At first I thought it was some bug from a ctrl-c of emerge or such that left the lockfile there.  It took me awhile to realize the lockfile was for the parallel fetch.  A note saying waiting on download would be the minimal solution, really nice would be to start printing the progress but at least it should tell me why it's waiting.  This really should only happen if an early package is really big I think.

I do like the parallel fetch allot btw.  I used to start a fetchonly followed by a  emerge all the time, and this is much safer and easier. 

[Comment 8 Jakub Moc (RETIRED) 2006-12-04 05:39:10 UTC]

*** Bug 157087 has been marked as a duplicate of this bug. ***

[Comment 9 Pacho Ramos 2007-01-19 16:34:56 UTC]

(In reply to comment #0)
> During an emerge -u world, I encountered the following message:
> waiting for lock on
> /var/portage/distfiles/.locks/OOo_2.0.3_LinuxIntel_install.tar.gz.portage_lockfile
> 
> I did figure out that the latest openoffice.org tarball was still downloading
> in the background. Still, this is not exactly transparent. Could you at least
> mention "Waiting for <package_X> download to complete" for the benefit of those
> who don't know from lockfiles?
> 

In that situation I prefer that wget output is shown instead of "waiting for lock..." or "Waiting for <package_X> download to complete"

Thanks

[Comment 10 David Watzke 2007-02-26 19:43:24 UTC]

Created attachment 111342 [details, diff]
Patch to show a better message

It's for Portage 2.1.2-r11.

[Comment 11 Zac Medico 2007-02-26 22:06:01 UTC]

(In reply to comment #10)
> Created an attachment (id=111342) [edit]
> Patch to show a better message

That seems like a good idea.  To make it more generic, I think we should pass in the entire "waiting for lock" message as raw string via a parameter called waiting_msg.  I suppose the message could even hint to the user that they can check /var/log/emerge-fetch.log for progress details.

[Comment 12 Zac Medico 2007-03-03 09:51:48 UTC]

This is fixed in svn r6144.

[Comment 13 Zac Medico 2007-03-03 12:32:52 UTC]

This has been released in 2.1.2-r14.