Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp16 2015-11-24T20:29:56Z 2015-11-24T20:29:56Z Michael Vogt mvo@ubuntu.com 2015-11-24T20:29:56Z urn:sha1:b52c3af4f970349747e362fdb19a4253c825a08b 2015-11-21T17:15:22Z David Kalnischkies david@kalnischkies.de 2015-11-21T17:15:22Z urn:sha1:90139c7075afb283428d561b81037039bc7ba149 We do not show the architecture as a dedicated field as this is rather technical information, but as packagename it makes sense to show the architecture as other part of apt will refer to it in this way. 2015-11-21T17:04:29Z Justin B Rye justin.byam.rye@gmail.com 2015-11-21T16:50:06Z urn:sha1:d04e44ac8177fc5b70ae0189bb5e437c2502f910 Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html 2015-11-21T12:47:19Z David Kalnischkies david@kalnischkies.de 2015-11-21T12:47:19Z urn:sha1:abd6af5a1ce2c20a5742c5c3182dfadce10367ca In 8d041b4f we made apt figure out based on the last Release file it has if it should request a file or not given that the hashes changed or not. So if we have a last Release file and do a request, do not sent a Last-Modified header as we expect a change so much that a non-change would indeed be an error. The Last-Modified header is therefore at best ignored by the server, so sending it is just wasted effort. In the worst case as time is a fragile thing the server decides against sending us an update with the idea that we already have the latest content, which we know for a fact that we haven't. Given that we sent less information to the server our request is on its own also less identifiable as coming from a returning or new user. The disadvantage is that if we end up getting an old index file after getting a new Release file from another mirror the old mirror will not be able to tell us 'Hit', but instead sends us the complete file we discard, but both lets us end up with the same error class in the end, so the difference isn't big in practice. 2015-11-20T08:46:18Z David Kalnischkies david@kalnischkies.de 2015-11-20T08:46:18Z urn:sha1:89497574da3dd40076d955efc936b54e76a8c59c Reported-By: codespell Git-Dch: Ignore 2015-11-19T23:54:07Z David Kalnischkies david@kalnischkies.de 2015-11-19T23:54:07Z urn:sha1:6789e01e9370b3b7f65d52138c5657eaa712b4d1 Out of memory and similar circumstanzas could cause MMap::Map to fail and especially the mmap/malloc calls in it. With some additional checking we can avoid segfaults and similar in such situations – at least in theory as if this is a real out of memory everything we do to handle the error could just as well run into a memory problem as well… But at least in theory (if MMap::Map is made to fail always) we can deal with it so good that a user actually never sees a failure (as the cache it tries to load with it fails and is discarded, so that DynamicMMap takes over and a new one is build) instead of segfaulting. Closes: 803417 2015-11-19T22:38:49Z David Kalnischkies david@kalnischkies.de 2015-11-19T21:39:13Z urn:sha1:520624d562e54e8e2c0191fae723e668e3ece6b4 If the config.{sub,guess} files we linked in were newer than our configure script we ended up recreating configure and then rerun it without all the configuration options which were (potentially) present for a previous run. We avoid this by changing to the same ruleset as in the debian/rules file which compares the config.* files against a stamp file rather than the configure script itself as its the configuration itself which depends on all scripts, not configure on the config scripts. While at it, we also drop the 'make -s dirs' call as we don't need to do it explicitly here as proper dependencies will take care of it. Thanks: Helmut Grohne for the detailed bugreport. Closes: 804923 2015-11-19T21:38:44Z David Kalnischkies david@kalnischkies.de 2015-11-19T21:38:44Z urn:sha1:033752214285a40f21f1ceb00a9e0b68ec8fc84f 2015-11-19T18:27:09Z David Kalnischkies david@kalnischkies.de 2015-11-19T18:27:09Z urn:sha1:c3c77d09651b5bed315c83ebe2354c9d2cb31253 The hack introduced in aa91826f is replaced with a hopefully better working "proper" solution with a new variable just for the standard we use everywhere we use CXXFLAGS. Git-Dch: Ignore 2015-11-19T16:56:07Z David Kalnischkies david@kalnischkies.de 2015-11-19T15:19:15Z urn:sha1:6aef1942f441e6e667982b92802907026d8cc7c6 In ce1f3a2c we started warning about failing unlinking, which we consistently do for directories. That isn't a problem as directories usually aren't in the places we do want to clean up – with the potential exeception of "lost+found", so lets ignore it like we ignore our own partial/ subdirectory. Closes: 805424