apt/apt-pkg/acquire.cc, branch 1.3_exp1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_exp12016-05-07T12:44:53Zdelay progress until Release files are downloaded2016-05-07T12:44:53ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-07T12:44:53Zurn:sha1:1eba782fc3c55528a4da14d79e114874b9299453
Progress reporting used an "upper bound" on files we might get, expect
that this wasn't correct in case pdiff entered the picture. So instead
of calculating a value which is perhaps incorrect, we just accept that
we can't tell how many files we are going to download and just keep at
0% until we know. Additionally, if we have pdiffs we wait until we got
these (sub)index files, too.
That could all be done better by downloading all Release files first and
planing with them in hand accordingly, but one step at a time.
make random acquire queues work less random2016-04-25T13:35:52ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-06T10:50:26Zurn:sha1:4aa6ebf6d78131416ef173b1ce472f014da25136
Queues feeding workers like rred are created in a random pattern to get
a few of them to run in parallel – but if we already have an idling queue
we don't need to assign it to a (potentially new) random queue as that
saves us the (agruably small) overhead of starting up a new queue,
avoids adding jobs to an already busy queue while others idle and as
a bonus reduces the size of debug logs a bit.
We also keep starting new queues now until we reach our limit before
we assign work at random to them, which should give us a more effective
utilisation overall compared to potentially adding work to busy queues
while we haven't reached our queue limit yet.
Get accurate progress reporting in apt update again2016-03-16T16:52:40ZMichael Vogtmvo@ubuntu.com2016-03-15T13:50:37Zurn:sha1:fb193b1cd43f0e8c3b7e5f69f183b9abe7e83761
For the non-pdiff case, we have can have accurate progress
reporting because after fetching the {,In}Release files we know
how many IndexFiles will be fetched and what size they have.
Therefore init the filesize early (in pkgAcqIndex::Init) and
ensure that in Acquire::Pulse() looks at already downloaded
bits when calculating the progress in Acquire::Pulse.
Also improve debug output of Debug::acquire::progress
always download changelogs into /tmp first2016-02-11T22:13:47ZDavid Kalnischkiesdavid@kalnischkies.de2016-02-11T21:54:49Zurn:sha1:6fd4b4c0b693b52cb8b593b76e5b60f77e500454
pkgAcqChangelog has the default behaviour of downloading a changelog to
a temporary directory (inside /tmp, not /tmp directly), which is cleaned
up on shutdown, but this can be overridden to store the changelog more
permanently – but that caries a permission problem.
For changelog we can 'easily' solve this by always downloading to a
temporary directory and only move it out of there on done.
revert file-hash based action-merging in acquire2016-01-15T01:45:35ZDavid Kalnischkiesdavid@kalnischkies.de2016-01-15T01:45:35Zurn:sha1:feb674aba51dcb26f5281b5b38fbc5893f757170
Introduced in 9d2a8a7388cf3b0bbbe92f6b0b30a533e1167f40 apt tries to
merge actions like downloading the same (as judged by hashes) file
into doing it once. The implementation was very simple in that it isn't
planing at all. Turns out that it works 90% of the time just fine, but
has issues in more complicated situations in which items can be in
different stages downloading different files emitting potentially the
"wrong" hash – like while pdiffs are worked on we might end up copying
the patch instead of the result file giving us very strange errors in
return. Reverting the change until we can implement a better planing
solution seems to be the best course of action even if its sad.
Closes: 810046
acquire: Allow parallelizing methods without hosts2016-01-07T16:31:24ZJulian Andres Klodejak@debian.org2016-01-07T16:06:55Zurn:sha1:b89cd2e36f9696ccd56167593c792116ae4fc97f
The maximum parallelization soft limit is the number of CPU
cores * 2 on systems defining _SC_NPROCESSORS_ONLN. The hard
limit in all cases is Acquire::QueueHost::Limit.
Use 0llu instead of 0ull in one place too2015-12-07T13:45:52ZJulian Andres Klodejak@debian.org2015-12-07T13:45:52Zurn:sha1:e551e1237da3cbba71f08f17dc57b07832b8d9ac
Gbp-Dch: ignore
Avoid overflow when summing up file sizes2015-12-07T13:44:15ZJulian Andres Klodejak@debian.org2015-12-07T13:42:25Zurn:sha1:5a97834817dd43b7833881f38f512a9f2fdac8a9
We need to pass 0llu instead of 0 as the init value, otherwise
std::accumulate will calculate with ints.
Reported-by: Raphaël Hertzog
Check if the Apt::Sandbox::User exists in CheckDropPrivsMustBeDisabled()2015-11-27T11:29:22ZMichael Vogtmvo@ubuntu.com2015-11-27T11:29:22Zurn:sha1:ef39c148105cf30aea822022a5f41a120897cc65
If it does not exist disabled priv dropping as there is nothing
we can drop to. This will unblock people with special chroots
or systems that deleted the "_apt" user.
Closes: #806406
Deal with killed acquire methods properly instead of hanging2015-11-27T11:10:57ZMichael Vogtmvo@ubuntu.com2015-11-27T11:07:48Zurn:sha1:a416a90b631a430306df6ed3fa1d4f3a1bdc7949
This fixes a regression caussed by commit
95278287f4e1eeaf5d96749d6fc9bfc53fb400d0
that moved the error detection of RunFds() later into the loop.
However this broke detecting issues like dead acquire methods.
Instead of relying on the global error state (which is bad)
we now pass a boolean value back from RunFds() and break on
false.
Closes: #806406