<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test, branch 1.1_exp14</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.1_exp14</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.1_exp14'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2015-09-15T08:21:36Z</updated>
<entry>
<title>tests: add a -j $jobs mode to test runner for parallel execution</title>
<updated>2015-09-15T08:21:36Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-15T07:56:57Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=61e927785a8b79141cb5aac622cb00b547b78b9b'/>
<id>urn:sha1:61e927785a8b79141cb5aac622cb00b547b78b9b</id>
<content type='text'>
Now that tests can be run in parallel, lets actually do it… The mode has
some downsides like not collecting the failed tests, but it can be a lot
faster than a sequential run and is therefore a good alternative in
testing those "this shouldn't break anything" changes (which tend to
break everything if untested).

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>tests: don't use hardcoded port for http and https</title>
<updated>2015-09-15T08:16:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-14T22:33:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6c0765c096ffb4df14169236c865bbb2b10974ae'/>
<id>urn:sha1:6c0765c096ffb4df14169236c865bbb2b10974ae</id>
<content type='text'>
This allows running tests in parallel.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>fallback to well-known URI if by-hash fails</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-14T12:57:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=af81ab9030229b4ce6cbe28f0f0831d4896fda01'/>
<id>urn:sha1:af81ab9030229b4ce6cbe28f0f0831d4896fda01</id>
<content type='text'>
We uses a small trick to implement the fallback: We make it so, that
by-hash is a special compression algorithm and apt already knows how to
deal with fallback between compression algorithms.

The drawback with implementing this fallback is that a) we are guessing
again and more importantly b) by-hash is only tried for the first
compression algorithm we want to acquire, not for all as before – but
flipping between by-hash and well-known for each compression algorithm
seems to be not really worth it as it seems unlikely that there will
actually be mirrors who only mirror a subset of compressioned files, but
have by-hash enabled.

The user-experience is the usual fallback one: You see "Ign" lines in
the apt update output. The fallback is implemented as a transition
feature, so a (potentially huge) mirror network doesn't need a flagday.
It is not meant as a "someday we might" or "we don't, but some of our
mirrors might" option – we want to cut down on the 'Ign' lines front so
that they become meaningful – if we wanted to spam everyone with them, we
could enable by-hash by default for all repositories…
sources.list and config options are better suited for this.

Closes: 798919
</content>
</entry>
<entry>
<title>add by-hash sources.list option and document all of by-hash</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-14T11:18:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=24e8f24e1e94ec3816b0bfc7a05d1c4e3f73248e'/>
<id>urn:sha1:24e8f24e1e94ec3816b0bfc7a05d1c4e3f73248e</id>
<content type='text'>
This changes the semantics of the option (which is renamed too) to be a
yes/no value with the special additional value "force" as this allows
by-hash to be disabled even if the repository indicates it would be
supported and is more in line with our other yes/no options like pdiff
which disable themselves if no support can be detected.

The feature wasn't documented so far and hasn't reached a (un)stable
release yet, so changing it without trying too hard to keep
compatibility seems okay.
</content>
</entry>
<entry>
<title>tests: try to support spaces in TMPDIR</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-14T00:26:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=63c7141275c8c5c0f6e60f5242785e50cabaf2a0'/>
<id>urn:sha1:63c7141275c8c5c0f6e60f5242785e50cabaf2a0</id>
<content type='text'>
Not all tests work yet, most notable the cdrom tests, but those require
changes in libapt itself to have a proper fix and what we have fixed so
far is good enough progress for now.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>deal with spaces in path, command and filepaths in apt-key</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-13T20:16:32Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=fecfbf2e4cbb71d20364306baf6aa7886c5f3ecd'/>
<id>urn:sha1:fecfbf2e4cbb71d20364306baf6aa7886c5f3ecd</id>
<content type='text'>
Filenames we get could include spaces, but also the tmpdir we work in
and the failures we print in return a very generic and unhelpful…
Properly supporting spaces is a bit painful as we constructed gpg
command before, which is now moved to (multilevel) calls to temporary
scripts instead.
</content>
</entry>
<entry>
<title>tests: use SHA1 checksum only by default in tests</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-13T15:25:23Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c5ede4cac6e6496ce19ccea3313ac6b49ba5e8d6'/>
<id>urn:sha1:c5ede4cac6e6496ce19ccea3313ac6b49ba5e8d6</id>
<content type='text'>
This is mostly a small speedup for the testcases, but it is also handy
to document which tests actually deal with a specific hash compared to
those which 'just' need some hash which can be important while adding
new hashes.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>do not ignore differently versioned self-provides</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-13T09:58:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b755de2540ae87f25b8699a555b557c1e291fa76'/>
<id>urn:sha1:b755de2540ae87f25b8699a555b557c1e291fa76</id>
<content type='text'>
Reported-By: Konomi on IRC
</content>
</entry>
<entry>
<title>various changes to increase test-coverage</title>
<updated>2015-09-14T13:22:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-12T08:35:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7414af7fa88164209eec9c585b8d175c1618ecbc'/>
<id>urn:sha1:7414af7fa88164209eec9c585b8d175c1618ecbc</id>
<content type='text'>
And of course, testing obscure things ends up showing obscure 'bugs' or
better shortcomings/inconsitencies, so lets fix them with the tests.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>implement apt-get source msg 'Please use: $vcs' for git</title>
<updated>2015-09-14T13:22:18Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-12T08:15:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7c4f1ca5fe315a8223570b05994d6d7ca7c55c4f'/>
<id>urn:sha1:7c4f1ca5fe315a8223570b05994d6d7ca7c55c4f</id>
<content type='text'>
A bit unfair that only Bzr had this message. Lets at least print it for
git as well with the option of adding more later without string changes.
</content>
</entry>
</feed>
