Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-27T09:27:44Z 2015-08-27T09:27:44Z David Kalnischkies david@kalnischkies.de 2015-08-22T14:22:08Z urn:sha1:3a8776a37af38127fb04565959e8e0e449eb04a4 Reported-By: codespell 2015-05-22T15:01:03Z Michael Vogt mvo@ubuntu.com 2015-05-22T15:01:03Z urn:sha1:4fc6b7570c3e97b65c118b58cdf6729fa94c9b03 Conflicts: apt-pkg/pkgcache.h debian/changelog methods/https.cc methods/server.cc test/integration/test-apt-download-progress 2015-05-22T13:40:18Z Michael Vogt mvo@ubuntu.com 2015-05-22T13:40:18Z urn:sha1:6291f60e86718697f261519a6818e1d5ee433216 The variable "Size" was misleading and caused bug #1445239. To avoid similar issues in the future, rename it to make the meaning more obvious. git-dch: ignore 2015-05-22T13:28:53Z Michael Vogt mvo@ubuntu.com 2015-05-22T13:28:53Z urn:sha1:ceafe8a6edc815df2923ba892894617829e9d3c2 The apt http code parses Content-Length and Content-Range. For both requests the variable "Size" is used and the semantic for this Size is the total file size. However Content-Length is not the entire file size for partital file requests. For servers that send the Content-Range header first and then the Content-Length header this can lead to globbing of Size so that its less than the real file size. This may lead to a subsequent passing of a negative number into the CircleBuf which leads to a endless loop that writes data. Thanks to Anton Blanchard for the analysis and initial patch. LP: #1445239 2015-05-11T22:30:16Z David Kalnischkies david@kalnischkies.de 2015-05-11T22:30:16Z urn:sha1:dcbb364fc69e1108b3fea3adb12a7ba83d9af467 If we have the expected hashes we can check with them if the file we have in partial we got a 416 for is the expected file. We detected this with same-size before, but not every server sends a good Content-Range header with a 416 response. 2015-04-18T23:13:09Z David Kalnischkies david@kalnischkies.de 2015-04-11T08:23:52Z urn:sha1:34faa8f7ae2526f46cd1f84bb6962ad06d841e5e We do this in HTTP already to give the CPU some exercise while the disk is heavily spinning (or flashing?) to store the data avoiding the need to reread the entire file again later on to calculate the hashes – which happens outside of the eyes of progress reporting, so you might ended up with a bunch of https workers 'stuck' at 100% while they were busy calculating hashes. This is a bummer for everyone using apt as a connection speedtest as the https method works slower now (not really, it just isn't reporting done too early anymore). 2015-04-18T23:13:09Z David Kalnischkies david@kalnischkies.de 2015-03-30T18:47:13Z urn:sha1:9224ce3d4d1ea0428a70e75134998e08aa45b1e6 Methods get told which hashes are expected by the acquire system, which means we can use this list to restrict what we calculate in the methods as any extra we are calculating is wasted effort as we can't compare it with anything anyway. Adding support for a new hash algorithm is therefore 'free' now and if a algorithm is no longer provided in a repository for a file, we automatically stop calculating it. In practice this results in a speed-up in Debian as we don't have SHA512 here (so far), so we practically stop calculating it. 2015-03-16T17:00:50Z David Kalnischkies david@kalnischkies.de 2015-03-09T00:54:46Z urn:sha1:905fba60a046646a26a56b4c5d4a5dc7d5906f0d Bug #778375 uncovered that https wasn't properly integrated in the class family tree of http as it was supposed to be leading to a NULL pointer dereference. Fixing this 'properly' was deemed to much diff for practically no gain that late in the release, so commit 0c2dc43d4fe1d026650b5e2920a021557f9534a6 just fixed the synptom, while this commit here is fixing the cause plus adding a test. 2015-03-16T16:59:31Z David Kalnischkies david@kalnischkies.de 2015-03-09T00:34:10Z urn:sha1:d61960d9244340956a27f4ca46aecd15cc75e18b 2015-02-23T11:52:01Z Tomasz Buchert tomasz.buchert@inria.fr 2015-02-15T23:57:29Z urn:sha1:0c2dc43d4fe1d026650b5e2920a021557f9534a6 Do not crash in ServerState::HeaderLine if there is no Owner. Closes: #778375