First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 42456
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Portage team <dev-portage@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Jack Byer <wts42@yahoo.com>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 42456 depends on: Show dependency tree
Bug 42456 blocks: 210077 216231
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-02-22 02:05 0000
My internet connection is less than 100% reliable, so sometimes downloads get
interrupted and have to resume. This results in corrupted downloads every so
often. Instead of requiring manual intervention to delete the corrupted file
and re-download, Portage should have a configurable option to delete files that
fail the md5 check and try to download them again. It isn't a majot problem,
but it could save some frustration (you wake up in the morning to discover that
"emerge kde" stopped after the second program).

Reproducible: Always
Steps to Reproduce:

------- Comment #1 From Timothy Miller 2004-11-02 19:39:42 0000 -------
I want to second this bug.

Recently, I was installing a new gentoo system.  One package (dev-java/bcel) would ALWAYS abort in the middle of the download from one mirror (BAD MIRROR), resulting in a resume on the next server.  The result was a CONSISTENTLY corrupted download.

I was completely stuck and still would be if I didn't have another gentoo box from where I was able to manually copy the file.

THIS IS A HUGE PROBLEM.

------- Comment #2 From Jason Stubbs (RETIRED) 2005-07-28 07:25:38 0000 -------
Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 

------- Comment #3 From Marius Mauch (RETIRED) 2007-01-11 12:58:43 0000 -------
Reopening for consideration.

------- Comment #4 From Jakub Moc (RETIRED) 2008-02-17 21:49:25 0000 -------
Well dunno, this appears to be handled perfectly fine w/ recent portage
versions?

------- Comment #5 From Zac Medico 2008-02-18 00:35:11 0000 -------
(In reply to comment #4)
> Well dunno, this appears to be handled perfectly fine w/ recent portage
> versions?

It does that in the background process if you have FEATURES="parallel-fetch"
enabled because the --fetchonly option triggers the more aggressive fetching
behavior.

Maybe we should a PORTAGE_FETCH_CHECKSUM_RETRIES config variable for make.conf
to control the number of retries.

------- Comment #6 From Zac Medico 2008-03-14 06:54:25 0000 -------
There's support for a PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS variable in svn now,
with 5 set as the default number of mirrors to try.

------- Comment #7 From Marius Mauch (RETIRED) 2008-03-20 18:14:35 0000 -------
This is supposed to be fixed in portage-2.2_pre5 or earlier.

------- Comment #8 From Marius Mauch (RETIRED) 2008-03-20 18:15:01 0000 -------
This is supposed to be fixed in portage-2.2_pre5 or earlier.

First Last Prev Next    No search results available      Search page      Enter new bug