Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp15 2015-11-04T17:42:28Z 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 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-12T14:48:59Z urn:sha1:9f301e0f2d828d662bd67da2be9d8f227caadd07 All other reasons from methods/connect.cc were already included. Git-Dch: Ignore 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-11T18:53:07Z urn:sha1:ae732225ec2fa0d7434c9f40a92ced8683752211 Reported-By: gcc Understandable: no Git-Dch: Ignore 2015-09-01T12:19:44Z David Kalnischkies david@kalnischkies.de 2015-09-01T11:58:00Z urn:sha1:63d609985eb7eefa5f2332bfe4fab96f017760a1 We want to declare some hashes as not enough for security, so that a user will need --allow-unauthenticated or similar to get data secured only by those hashes, but we can still us these hashes for integrity checks if we got them. 2015-08-27T09:27:43Z David Kalnischkies david@kalnischkies.de 2015-08-21T22:10:08Z urn:sha1:b6a0018e1c4bb22132e0316a81b7a455c6333cf1 Fetched() was reported for mostly nothing, while we should be calling it for files worked with from non-local sources (e.g. http, but not file or xz). Previously this was called from an acquire item, but got moved to the acquire worker instead to avoid having it (re)implemented in all items, but the checks were faulty. 2015-08-17T12:29:02Z Michael Vogt mvo@debian.org 2015-08-17T12:29:02Z urn:sha1:ac7f8f7916f16905d8eeb0133bc650d89726d0f4 Git-Dch: ignore 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 2015-08-12T09:55:47Z Luca Bruno lethalman88@gmail.com 2015-08-11T18:08:43Z urn:sha1:94171725b18be91ddcc2530c5fe5f40e78d041c1 Thanks: Andre Felipe Machado for initial patch Closes: 414848 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-08-09T15:40:57Z urn:sha1:dd676dc71e31c20f66d5b9d9ac1c5a4c8883cd79 Reporting errors from Done() is bad for progress reporting and such, so factoring this out is a good idea and we start with moving the supposed- to-be clearsigned file isn't clearsigned out first – improving the error message in the process as we use the same message for a similar case (NODATA) as this is what I have to look at with the venue wifi at DebCamp and the old errormessage doesn't really say anything. 2015-08-10T15:27:17Z David Kalnischkies david@kalnischkies.de 2015-07-09T10:21:20Z urn:sha1:a4b8112b19763cbd2c12b81d55bc7d43a591d610 Redirectors like httpredir.debian.org orchestra the download from multiple (hopefully close) mirrors while having only a single central sources.list entry by using redirects. This has the effect that the progress report always shows the source it started with, not the mirror it ends up fetching from, which is especially problematic for error reporting as having a report for a "Hashsum mismatch" for the redirector URI is next to useless as nobody knows which URI it was really fetched from (regardless of it coming from a user or via the report script) from this output alone. You would need to enable debug output and hope for the same situation to arise again… We hence reuse the UsedMirror field of the mirror:// method and detect redirects which change the site and declare this new site as the UsedMirrror (and adapt the description). The disadvantage is that there is no obvious mapping anymore (it is relatively easy to guess through with some experience) from progress lines to sources.list lines, so error messages need to take care to use the Target description (rather than current Item description) if they want to refer to the sources.list entry.