Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.7 2015-12-14T12:58:46Z 2015-12-14T12:58:46Z Julian Andres Klode jak@debian.org 2015-12-14T12:58:46Z urn:sha1:137e8ad4b6ce28b1a1355d5a125d09670388c2b7 This makes the test suite work on 32 bit-long platforms. Gbp-Dch: ignore 2015-08-12T18:51:08Z Julian Andres Klode jak@debian.org 2015-08-12T18:44:40Z urn:sha1:809aa216c630f1cc61b0c3b9d992d4a3be14be3c Treat invalid pin priorities and overflows as an error. Closes: #429912 2015-08-10T15:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-15T12:36:16Z urn:sha1:dfe66c72ffc010e019e96b35154e1ad4ab506a6e We store very few flags in the cache, so keeping storage space for 8 is enough for all of them and still leaves a few unused bits remaining for future extensions without wasting bytes for nothing. Git-Dch: Ignore 2015-08-10T15:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-15T11:21:21Z urn:sha1:4dc77823d360158d6870a5710cc8c17064f1308f We aren't and we will not be really compatible again with the previous stable abi, so lets drop these markers (which never made it into a released version) for good as they have outlived their intend already. Git-Dch: Ignore 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-21T21:12:24Z urn:sha1:81460e32961bb0b9922bf8a1a27d87705d8c3e51 Having two different formats in the same file is very dirty and causes external tools to fail hard trying to parse them. It is probably not a good idea for them to parse them in the first place, but they do and we shouldn't break them if there is a better way. So we solve this issue for now by giving our deb822 format a new filename extension ".sources" which unsupporting applications are likely to ignore an can begin gradually moving forward rather than waiting for the unknown applications to catch up. Currently and for the forseeable future apt is going to support both with the same feature set as documented in the manpage, with the longtime plan of adopting the 'new' format as default, but that is a long way to go and might get going more from having an easier time setting options than from us pushing it explicitely. 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-18T15:33:15Z urn:sha1:3d8232bf97ce11818fb07813a71136484ea1a44a Various small leaks here and there. Nothing particularily big, but still good to fix. Found by the sanitizers while running our testcases. Reported-By: gcc -fsanitize Git-Dch: Ignore 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T07:29:00Z urn:sha1:6c55f07a5fa3612a5d59c61a17da5fe640eadc8b Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore 2015-08-10T15:24:01Z David Kalnischkies david@kalnischkies.de 2015-06-16T22:14:10Z urn:sha1:e8afd16892e87a6e2f17c1019ee455f5583387c2 Some of them modify the ABI, but given that we prepare a big one already, these few hardly count for much. Git-Dch: Ignore 2015-05-11T15:22:32Z David Kalnischkies david@kalnischkies.de 2015-05-10T20:53:15Z urn:sha1:8d058ea53b18348f81229049a27d14282bd8d8c1 TFRewrite is okay, but it has obscure limitations (256 Tags), even more obscure bugs (order for renames is defined by the old name) and the interface is very c-style encouraging bad usage like we do it in apt-ftparchive passing massive amounts of c_str() from std::string in. The old-style is marked as deprecated accordingly. The next commit will fix all places in the apt code to not use the old-style anymore. 2015-05-11T15:22:32Z David Kalnischkies david@kalnischkies.de 2015-05-09T16:55:41Z urn:sha1:e8fb1cdfdd13e45f2b3abbd57a28b57ae6137f14 dpkg and dak know various field names and order them in their output, while we have yet another order and have to play catch up with them as we are sitting between chairs here and neither order is ideal for us, too. A little testcase is from now on supposed to help ensureing that we do not derivate to far away from which fields dpkg knows and orders.