<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/acquire.cc, branch 1.9.2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.9.2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.9.2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2019-07-08T11:18:31Z</updated>
<entry>
<title>Distribute host-less work based on backlog of the queues</title>
<updated>2019-07-08T11:18:31Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-04-27T14:13:02Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=79b1a82983e737e74359bc306d9edb357c5bdd46'/>
<id>urn:sha1:79b1a82983e737e74359bc306d9edb357c5bdd46</id>
<content type='text'>
Work like applying patches via rred can be performed by many concurrent
rred processes, but we can't just spawn new ones forever: We limit us to
the number of CPUs which can drive them and reuse existing ones if they
have nothing to do at the moment.

The problem arises if we have reached the limit of queues and all of
them are busy which is more likely to happen on "slow" machines with few
CPUs. In this case we opted for random distribution, but that can result
in many big files (e.g. Contents) being added to one queue while the
others get none or only small files.

Ideally we would ask the methods how much they still have to do, but
they only know that for the current item, not for all items in the
queue, so we use the filesize of the expected result.
</content>
</entry>
<entry>
<title>apt-pkg: URI: Add 'explicit' to single argument constructor</title>
<updated>2019-04-30T15:43:56Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2019-04-30T10:32:54Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=af74a9e2d55d6a9532eb3fbb9b96c65b7ddc1e4d'/>
<id>urn:sha1:af74a9e2d55d6a9532eb3fbb9b96c65b7ddc1e4d</id>
<content type='text'>
This needs a fair amount of changes elsewhere in the code,
hence this is separate from the previous commits.
</content>
</entry>
<entry>
<title>acq: worker: Move CurrentSize, TotalSize, ResumePoint to CurrentItem</title>
<updated>2019-04-30T15:40:38Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2019-04-29T18:05:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cccef6ca60c2775e918d964fdad1afc1dcad4d0e'/>
<id>urn:sha1:cccef6ca60c2775e918d964fdad1afc1dcad4d0e</id>
<content type='text'>
These status fields belong to the current item, move them there. This
prepares us for eventually having multiple current items.
</content>
</entry>
<entry>
<title>Don't limit cpu-limited queues to at most 10</title>
<updated>2019-04-16T10:59:54Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-04-16T10:53:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f426580b9964a15fbb2074aee6d5fb61b5e45ee2'/>
<id>urn:sha1:f426580b9964a15fbb2074aee6d5fb61b5e45ee2</id>
<content type='text'>
Queues for processes like rred are not created by hostname but we
spawn at most CPU*2 queues to place items in. The problem is that we
then proceeded to limit it to at most 10 queues (via QueueHost::Limit)
again at the end of the method so that all items (after the first 10
queues are busy) are forcibly placed into a generic catch-all instance
which is bad because we don't keep all CPUs we have available busy and
worse we end up sheduling the most work to a single one while random
distribution was intended.
</content>
</entry>
<entry>
<title>acquire: Remove deprecated pkgAcquire::Setup() function</title>
<updated>2019-02-26T15:31:20Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2019-02-26T11:44:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a9182c8f789e7d19def3d6e178cb02bd9a46aa24'/>
<id>urn:sha1:a9182c8f789e7d19def3d6e178cb02bd9a46aa24</id>
<content type='text'>
</content>
</entry>
<entry>
<title>acquire: Fold pkgAcquireStatus2 into pkgAcquireStatus</title>
<updated>2019-02-26T15:31:20Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2019-02-26T11:42:42Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=91e1f7d49830289d8e9d3fdd7ebbe7544a9838b8'/>
<id>urn:sha1:91e1f7d49830289d8e9d3fdd7ebbe7544a9838b8</id>
<content type='text'>
Clean up the code, make it neat, lalala
</content>
</entry>
<entry>
<title>Fix calculation of elapsed usec in downloads</title>
<updated>2018-09-24T07:27:01Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-09-24T07:27:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=089e627153781ae7c320a5a0724c6c70d684b689'/>
<id>urn:sha1:089e627153781ae7c320a5a0724c6c70d684b689</id>
<content type='text'>
A recent change to use chronos inadvertently replaced the
difference of new usec - old usec with new sec - old usec,
which is obviously wrong.
</content>
</entry>
<entry>
<title>Use a steady clock source for progress reporting</title>
<updated>2018-05-28T15:59:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-05-26T15:36:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=79b61ae7673eb6213493e2cb202f0d70c390932d'/>
<id>urn:sha1:79b61ae7673eb6213493e2cb202f0d70c390932d</id>
<content type='text'>
Clock changes while apt is running can result in strange reports
confusing (and amusing) users. Sadly, to keep the ABI for now the
code is a bit more ugly than it would need to be.
</content>
</entry>
<entry>
<title>Remove obsolete RCS keywords</title>
<updated>2018-05-07T11:41:31Z</updated>
<author>
<name>Guillem Jover</name>
<email>guillem@debian.org</email>
</author>
<published>2018-05-06T20:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=164f1b78d1849a0f33df7352875f86e28f5de06a'/>
<id>urn:sha1:164f1b78d1849a0f33df7352875f86e28f5de06a</id>
<content type='text'>
Prompted-by: Jakub Wilk &lt;jwilk@debian.org&gt;
</content>
</entry>
<entry>
<title>ensure correct file permissions for auxfiles</title>
<updated>2018-02-19T14:56:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-02-02T18:14:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b3e7a16265e7c6c3b6892b9ec8a787d692ced6e6'/>
<id>urn:sha1:b3e7a16265e7c6c3b6892b9ec8a787d692ced6e6</id>
<content type='text'>
The interesting takeaway here is perhaps that 'chmod +w' is effected by
the umask – obvious in hindsight of course. The usual setup helps with
hiding that applying that recursively on all directories (and files)
isn't correct. Ensuring files will not be stored with the wrong
permissions even if in strange umask contexts is trivial in comparison.

Fixing the test also highlighted that it wasn't bulletproof as apt will
automatically fix the permissions of the directories it works with, so
for this test we actually need to introduce a shortcut in the code.

Reported-By: Ubuntu autopkgtest CI
</content>
</entry>
</feed>
