<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/methods, branch 1.8.0_alpha2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.8.0_alpha2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.8.0_alpha2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2018-11-13T09:20:09Z</updated>
<entry>
<title>Revert "http: Fix handling of server connection closure"</title>
<updated>2018-11-13T09:20:09Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-11-13T09:19:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9bb831d7d489eac732d4aaccc1a014d923e711ff'/>
<id>urn:sha1:9bb831d7d489eac732d4aaccc1a014d923e711ff</id>
<content type='text'>
This reverts commit fb3f36593563d09a8d1727cc7c6deb0b49823ca2. It
caused downloads to hang on long-lived connections on certain
servers.

Gbp-Dch: full
</content>
</entry>
<entry>
<title>http: Fix handling of server connection closure</title>
<updated>2018-11-12T10:51:56Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-11-02T17:19:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=fb3f36593563d09a8d1727cc7c6deb0b49823ca2'/>
<id>urn:sha1:fb3f36593563d09a8d1727cc7c6deb0b49823ca2</id>
<content type='text'>
If the server closed the connection while we're reading data, and
we end up not having any data left to write; that is, for example,
we received 0 bytes, then we did not exit before, as we only returned
success if there was data to write.

This is wrong: Obviously, if we have reached our limit, we are done
anyway. It's a bit unclear if we actually ever reached this part, but
it does make some sense wrt the bug below.

LP: #1801338
</content>
</entry>
<entry>
<title>Merge branch 'feature/subkeys' into 'master'</title>
<updated>2018-10-14T19:23:41Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2018-10-14T19:23:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b80e48783c183aeaf1d30d898a7743f091d96336'/>
<id>urn:sha1:b80e48783c183aeaf1d30d898a7743f091d96336</id>
<content type='text'>
Support subkeys and multiple keyrings in Signed-By options

See merge request apt-team/apt!27</content>
</entry>
<entry>
<title>http: Stop pipeline after close only if it was not filled before</title>
<updated>2018-09-18T14:07:24Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-08-31T14:07:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=df696650b7a8c58bbd92e0e1619e956f21010a96'/>
<id>urn:sha1:df696650b7a8c58bbd92e0e1619e956f21010a96</id>
<content type='text'>
It is perfectly valid behavior for a server to respond with
Connection: close eventually, even when pipelining. Turning
off pipelining due to that is wrong. For example, some Ubuntu
mirrors close the connection after 101 requests. If I have
more packages to install, only the first 101 would benefit
from pipelining.

This commit introduces a new check to only turn of pipelining
for future connections if the pipeline for this connection did
not have 3 successful fetches before, that should work quite well to
detect broken server/proxy combinations like in bug 832113.
</content>
</entry>
<entry>
<title>Support multiple keyrings in sources.list Signed-By</title>
<updated>2018-09-11T11:16:11Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-17T14:33:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8375d5b58038fc026098dcccc3de87cd9d740334'/>
<id>urn:sha1:8375d5b58038fc026098dcccc3de87cd9d740334</id>
<content type='text'>
A user can specify multiple fingerprints for a while now, so its seems
counter-intuitive to support only one keyring, especially if this isn't
really checked or enforced and while unlikely mixtures of both should
work properly, too, instead of a kinda random behaviour.
</content>
</entry>
<entry>
<title>Support subkeys properly in Signed-By options</title>
<updated>2018-09-11T11:16:11Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-17T09:59:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ff8fa4ab4b80384a9240f0df63181f71077a8d83'/>
<id>urn:sha1:ff8fa4ab4b80384a9240f0df63181f71077a8d83</id>
<content type='text'>
If we limit a file to be signed by a certain key it should usually
accept also being signed by any of this keys subkeys instead of
requiring each subkey to be listed explicitly. If the later is really
wanted we support now also the same syntax as gpg does with appending an
exclamation mark at the end of the fingerprint to force no mapping.
</content>
</entry>
<entry>
<title>Report (soon) worthless keys if gpg uses fpr for GOODSIG</title>
<updated>2018-08-19T15:30:31Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-16T21:36:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b934870c4f893be28eb1537910c0aadce6dd6e09'/>
<id>urn:sha1:b934870c4f893be28eb1537910c0aadce6dd6e09</id>
<content type='text'>
gpgs DETAILS documentation file declares that GOODSIG could report keyid
or fingerprint since gpg2, but for the time being it is still keyid
only. Who knows if that will ever change as that feels like an interface
break with dangerous security implications, but lets be better safe than
sorry especially as the code dealing with signed-by keyids is prepared
for this already. This code is rewritten still to have them all use the
same code for this type of problem.
</content>
</entry>
<entry>
<title>Use steady clock source for bandwidth limitation</title>
<updated>2018-05-29T11:04:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-05-26T19:26:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f6655a1138a11e80884959014939a25f23a1e308'/>
<id>urn:sha1:f6655a1138a11e80884959014939a25f23a1e308</id>
<content type='text'>
Using the time of day for this is slightly wrong just like it is for
progress, just less visible.
</content>
</entry>
<entry>
<title>Remove unused time-tracking from http method</title>
<updated>2018-05-28T15:59:38Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-05-26T19:28:55Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=2fc09a90e7e62a4c3e4a67506bf90fcf4c6ccfaf'/>
<id>urn:sha1:2fc09a90e7e62a4c3e4a67506bf90fcf4c6ccfaf</id>
<content type='text'>
The Stats method isn't called anywhere, was partly commented out before,
but we keep updating the time for it – lets avoid this pointless busywork.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Lower default timeout from 120s to 30s</title>
<updated>2018-05-24T12:31:31Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-05-24T12:31:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=329a4a6159f1972ff5ec7bc2db26430f26dc61f3'/>
<id>urn:sha1:329a4a6159f1972ff5ec7bc2db26430f26dc61f3</id>
<content type='text'>
120s is an insanely high default time out, lower it to 30s
to make things a bit nicer.
</content>
</entry>
</feed>
