apt/methods/server.cc, branch 1.1.9 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.9 2015-12-27T00:20:41Z Convert most callers of isspace() to isspace_ascii() 2015-12-27T00:20:41Z Julian Andres Klode jak@debian.org 2015-12-26T23:51:59Z urn:sha1:74dedb4ae28fd4f7c89bf769708d4f7edc7ed79a This converts all callers that read machine-generated data, callers that might work with user input are not converted. allow acquire method specific options via Binary scope 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T13:48:36Z urn:sha1:23e64f6d0facf9610c1042326ad9850e071e8349 Allows users who know what they are getting themselves into with this trick to e.g. disable privilege dropping for e.g. file:// until they can fix up the permissions on those repositories. It helps also the test framework and people with a similar setup (= me) to run in less modified environments. wrap every unlink call to check for != /dev/null 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T17:49:52Z urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39 Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore fix two memory leaks reported by gcc 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-11T19:02:19Z urn:sha1:830a1b8c9e9a26dc1101167ac66a75c444902c4d Reported-By: gcc -fsanitize=address -fno-sanitize=vptr Git-Dch: Ignore fix various typos reported by codespell 2015-08-27T09:27:44Z David Kalnischkies david@kalnischkies.de 2015-08-22T14:22:08Z urn:sha1:3a8776a37af38127fb04565959e8e0e449eb04a4 Reported-By: codespell Merge branch 'debian/sid' into debian/experimental 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 Rename "Size" in ServerState to TotalFileSize 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 Fix endless loop in apt-get update that can cause disk fillup 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 detect 416 complete file in partial by expected hash 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. calculate hashes while downloading in https 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).