Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.11 2016-04-14T20:21:53Z 2016-04-14T20:21:53Z David Kalnischkies david@kalnischkies.de 2016-04-14T20:02:07Z urn:sha1:b58047e0d8fa8e7d5adca2a24f2ca3ba2596e0ad Tested via (newly) empty index files, but effects also files dropped from the repository or an otherwise changed repository config. 2016-04-14T19:56:01Z David Kalnischkies david@kalnischkies.de 2016-04-14T15:32:17Z urn:sha1:b2fd852459a6b9234255644730f48f071ccad64d There is just no point in taking the time to acquire empty files – especially as it will be tiny non-empty compressed files usually. 2016-04-14T14:15:39Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:01:56Z urn:sha1:e169fa4a85e03b2b03bb1bdba716b96654ae6050 A silly of-by-one error in the stripping of the extension to check for the uncompressed filename broken in an attempt to support all compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5. Fixing this highlights also mistakes in the handling of the Alt-Filename in libapt which would cause apt to remove the file from the repository (if root has the needed rights – aka the disk isn't readonly or similar) 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-13T14:24:12Z urn:sha1:c75e60ebb6bc7a578b57e7c4e01579798bae720b Regression introduced in commit 590f1923121815b36ef889033c1c416a23cbe9a2 (2011!) causing apt to not check if Pre-Depends are satisfied before calling --configure. This managed to hide so perfectly well for years as Pre-Depends aren't that common, apt prefers upgrading these packages first and checks for satisfaction is already in SmartUnpack, so there is only a small window of oppertunity to break a pre-dependency relation (usually with an unpack). Verified by logchecking with two provided status files in the buglog. I would have liked to write a test, but I wasn't able to reach the needed complexity to get apt to fail – but the change is small and reasonable, so what could possible go wrong™, right? LP: #1569099 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-13T13:28:33Z urn:sha1:f41352ade22b159c0057f45bcc656dd893d5e74a It handy to be able to point apt at reading a compressed dpkg/status file in debugging cases, which worked pre-1.1 but somewhere down the line in the massive refactoring. Restoring this behavior in a central place for all realfile index files instead of just for the status file. (This has no effect on index files acquired from an archive – those are handled by different classes and support compressed files just fine) 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-08T10:50:08Z urn:sha1:40703260cdb40409e930a53a04a4061cf2173f42 There is a good chance that the attempt will fail, but if a user mentions certain packages explicitly on the commandline there is a chance that this will consist of a broken system which is resolved by upgrading more packages then just the mentioned. This limitation was not effecting external resolvers. 2016-04-07T11:48:31Z David Kalnischkies david@kalnischkies.de 2016-04-05T23:08:57Z urn:sha1:38f8704e419ed93f433129e20df5611df6652620 With the previous commit we track the state of transactions, so we can now use our knowledge to avoid processing data for a transaction which was already closed (via an abort in this case). This is needed as multiple independent processes are interacting in the process, so there isn't a simple immediate full-engine stop and it would also be bad to teach each and every item how to check if its manager has failed subordinate and what to do in that case. In the pdiff case, which deals (potentially) with many items during its lifetime e.g. a hashsum mismatch in another file can abort the transaction the file we try to patch via pdiff belongs to. This causes some of the items (which are already done) to be aborted with it, but items still in the process of acquisition continue in the processing and will later try to use all the items together failing in strange ways as cleanup already happened. The chosen solution is to dry up the communication channels instead by ignoring new requests for data acquisition, canceling requests which are not assigned to a queue and not calling Done/Failed on items anymore. This means that e.g. already started or pending (e.g. pipelined) downloads aren't stopped and continue as normal for now, but they remain in partial/ and aren't processed further so the next update command will pick them up and put them to good use while the current process fails updating (for this transaction group) in an orderly fashion. Closes: 817240 Thanks: Barr Detwix & Vincent Lefevre for log files 2016-04-07T10:37:08Z David Kalnischkies david@kalnischkies.de 2016-04-05T18:56:56Z urn:sha1:57f16d51f4158dce1a49f6d5f5f05f057125b871 We want to keep track of the state of a transaction overall to base future decisions on it, but as a pre-requirement we have to make sure that a transaction isn't commited twice (which happened if the download of InRelease failed and Release takes over). It also happened to create empty commits after a transaction was already aborted in cases in which the Release files were rejected. This isn't effecting security at the moment, but to ensure this isn't happening again and can never be bad a bunch of fatal error messages are added to make regressions on this front visible. 2016-04-03T12:44:47Z David Kalnischkies david@kalnischkies.de 2016-03-25T12:08:06Z urn:sha1:c48ef8942d87388a67af9e2cad92171aca3be731 Git-Dch: Ignore Reported-By: gcc -fsanitize=address 2016-04-03T12:44:47Z David Kalnischkies david@kalnischkies.de 2016-03-25T11:15:00Z urn:sha1:46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c Hardly noticeable, but given that we have the option to easily enable it, lets enable it as every newline in the message is written individually by the code.