| 1 |
Mick wrote: |
| 2 |
> On Sunday, 12 January 2020 23:32:16 GMT Neil Bothwick wrote: |
| 3 |
>> On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote: |
| 4 |
>>>> I had a similar issue with the .tmp-unverified-download-quarantine |
| 5 |
>>>> continually appearing, deleting it made no difference. In the end I |
| 6 |
>>>> deleted the whole portage tree and resynced, then the problem |
| 7 |
>>>> disappeared. This may or may not have a bearing on your profile issue, |
| 8 |
>>>> but it's worth fixing first. |
| 9 |
>>> I just finished running "emerge --sync" again, based on something I saw |
| 10 |
>>> on the internet - it did the whole thing again, takes about 2 hours. |
| 11 |
>> Two hours? How slow is your connection? |
| 12 |
> Assuming this is not the time it takes to run rsync (even on a dial-up |
| 13 |
> analogue modem connection?) I would guess the delay is caused by the post-sync |
| 14 |
> tree verification. The .tmp-unverified-download-quarantine file is where the |
| 15 |
> sync is stored until the signature verification is performed. Even on a |
| 16 |
> really old dual-core laptop with low RAM the sync and verification only takes |
| 17 |
> around 20 minutes. |
| 18 |
> |
| 19 |
> |
| 20 |
|
| 21 |
I'm on DSL, fairly slow DSL but DSL is what they call it, and had a long |
| 22 |
re-sync time until a month or so ago. It started around the time the |
| 23 |
verification part started so I assumed it was that. Then it kept |
| 24 |
getting slower and slower. After a while, I decided to try something |
| 25 |
else. I found a different server to sync too. The first one was a |
| 26 |
little better but still slow. I tried another one and hit the jackpot. |
| 27 |
It was several times faster than the original one. |
| 28 |
|
| 29 |
This may not be your problem but it may be worth looking into. You can |
| 30 |
use mirrorselect to help you find a good server. Try a few and see what |
| 31 |
changes. For me at least, it pretty much maxes out my DSL. Obviously |
| 32 |
there is some things that take a while that is done on my end but if the |
| 33 |
download is slow due to a slow server, maybe you can find a faster one. |
| 34 |
|
| 35 |
I might add, I've always tried to get servers that are physically close |
| 36 |
by because they *should* be faster. I've found that not to be true in |
| 37 |
every case. |
| 38 |
|
| 39 |
As I said, this may not be your problem but it may be worth looking into |
| 40 |
at least. Just in case. |
| 41 |
|
| 42 |
Dale |
| 43 |
|
| 44 |
:-) :-) |
Archives