Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.5_beta2 2017-08-12T14:03:26Z 2017-08-12T14:03:26Z Julian Andres Klode jak@debian.org 2017-08-12T14:02:45Z urn:sha1:79c0a12d5c2d4fd8e6bfcf3a632a452239c07fe0 This caused a build failure in the test suite. 2017-08-04T11:06:10Z David Kalnischkies david@kalnischkies.de 2017-07-28T16:20:14Z urn:sha1:d108e019d3ca74c31a1ab646ddef5c60744a5e7d If 'apt-ftparchive packages /path/to/files/' (or sources) is used the files to include in the generated index (on stdout) were included in the order in which they were discovered, which isn't a very stable order which could lead to indexes changing without actually changing content causing needless changes in the repository changing hashsums, pdiffs, rsyncs, downloads, …. This does not effect apt-ftparchive calls which already have an order defined via a filelist (like generate) which will still print in the order given by the filelist. Note that a similar effect can be achieved by post-processing index files with apt-sortpkgs. Closes: 869557 Thanks: Chris Lamb for initial patch & Stefan Lippers-Hollmann for testing 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-14T15:07:22Z urn:sha1:8580574ec63fedd39a3ab3b9f0025e08eae5f620 The feature exists for a long while even if we get around to document it properly only now, so we should push for its adoption a bit to avoid the problems its supposed to solve like avoiding usage of non-world readable configuration files as they can cause strange behaviour for the unsuspecting user (like different solutions as root and non-root). 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-14T11:49:33Z urn:sha1:054243fd0febfef5f1ba89f61eed0e6a34c6a25f We detect the effected sources by matching Release info – that has potential by-catch of repositories which have incorrect field values, but those are better fixed now anyhow. The bigger incorrectness is that this message will not only be printed for the Debian services itself but also for all mirrors not under Debian control but serving Debian like more local/private mirrors which will not (directly) shutdown. It is likely through that many of them will follow suite with less visible announcements or break downright if their upstream source disappears, so having false-positives here seems benefitial for the user in the end. 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-07T19:59:01Z urn:sha1:6291fa81da6ed4c32d0dde33fa559cd155faff11 On HTTP Connect we since recently look into the auth.conf file for login information, so we should really look for all proxies into the file as the argument is the same as for sources entries and it is easier to document (especially as the manpage already mentions it as supported). 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-07T14:24:21Z urn:sha1:ea408c560ed85bb4ef7cf8f72f8463653501332c We have support for an netrc-like auth.conf file since 0.7.25 (closing 518473), but it was never documented in apt that it even exists and netrc seems to have fallen out of usage as a manpage for it no longer exists making the feature even more arcane. On top of that the code was a bit of a mess (as it is written in c-style) and as a result the matching of machine tokens to URIs also a bit strange by checking for less specific matches (= without path) first. We now do a single pass over the stanzas. In practice early adopters of the undocumented implementation will not really notice the differences and the 'new' behaviour is simpler to document and more usual for an apt user. Closes: #811181 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-15T13:08:35Z urn:sha1:51751106976b1c6afa8f7991790db87b239fcc84 We used to fail on unreadable config/preferences/sources files, but at least for sources we didn't in the past and it seems harsh to refuse to work because of a single file, especially as the error messages are inconsistent and end up being silly (like suggesting to run apt update to fix the problem…). LP: #1701852 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-15T12:12:50Z urn:sha1:3317ad864c997f4897756c0a2989c4199e9cda62 Using different ways of opening files means we have different behaviour and error messages for them, so by the same for all we can have more uniformity for users and apt developers alike. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-26T16:35:42Z urn:sha1:f2f8e89f08cdf01c83a0b8ab053c65329d85ca90 Failing on too much data is good, but we can do better by checking for exact filesizes as we know with hashsums how large a file should be, so if we get a file which has a size we do not expect we can drop it directly, regardless of if the file is larger or smaller than what we expect which should catch most cases which would end up as hashsum errors later now a lot sooner. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-24T12:30:41Z urn:sha1:d7518dba50e2285c41c7002a1d86f876401fd9ea We tend to operate on rather large static files, which means we usually get Content-Length information from the server. If we combine this information with the filesize we are expecting (factoring in pipelining) we can avoid reading a bunch of data we are ending up rejecting anyhow by just closing the connection saving bandwidth and time both for the server as well as the client.