<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration, branch 1.4_beta4</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.4_beta4</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.4_beta4'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2017-01-17T00:59:15Z</updated>
<entry>
<title>https: Quote path in URL before passing it to curl</title>
<updated>2017-01-17T00:59:15Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-12-29T13:16:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=994515e689dcc5f963f5fed58284831750a5da03'/>
<id>urn:sha1:994515e689dcc5f963f5fed58284831750a5da03</id>
<content type='text'>
Curl requires URLs to be urlencoded. We are however giving it
undecoded URLs. This causes it go completely nuts if there is
a space in the URI, producing requests like:

    GET /a file HTTP/1.1

which the servers then interpret as a GET request for "/a" with
HTTP version "file" or some other non-sense.

This works around the issue by encoding the path component of
the URL. I'm not sure if we should encode other parts of the URL
as well, this one seems to do the trick for the actual issue at
hand.

A more correct fix is to avoid the dequoting and (re-)quoting
of URLs when a redirect occurs / a new request is sent. That's
been on the radar for probably a year or two now, but nobody
bothered implementing that yet.

LP: #1651923
</content>
</entry>
<entry>
<title>Read dpkg tables to handle architecture wildcards</title>
<updated>2017-01-17T00:43:50Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-01-16T23:08:16Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6ede8952f55a1bc356b42b1adc7b9bd504af943c'/>
<id>urn:sha1:6ede8952f55a1bc356b42b1adc7b9bd504af943c</id>
<content type='text'>
Our implementation of wildcards was rudimentary. It worked for some
common ones, but it was also broken: For example, armel matched any-armel,
but should match any-arm.

With this commit, we load the correct tables from dpkg. Supported are
both triplets and quadruplet tables (the latter introduced in dpkg 1.18.11).

There are some odd things we have to deal with in the cache filter for
historical and API reasons:

* The character "*" must be accepted as an alternative to any - in fact
  it may appear anywhere in the wildcard as we also allow fnmatch() style
  wildcard matching on the commandline.

* The code might get passed an arch with a minus at the end, for example
  the cmdline "install apt:any-arm-" will first try to check if any-arm-
  is a valid architecture. We deal with this by rejecting any wildcard
  ending in a minus.

* Triplets are actually implemented by extending them to faux quadruplets
  - by prepending a "base" component for the architecture tuple, and "any"
  if there is a wildcard component.

Once we have constructed a wildcard, it is transformed into an fnmatch()
expression for historical reasons. In the future, we should really get a
tuple class and implement matching in a better, more explicit way.

This does for now though - it passes all the test cases and accepts all
things it should accept.

Closes: #748936
Thanks: James Clarke &lt;jrtc27@jrtc27.com&gt; for the initial patch
</content>
</entry>
<entry>
<title>allow warning generation for non-whitelisted options</title>
<updated>2016-12-31T17:24:12Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-31T17:24:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9'/>
<id>urn:sha1:ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9</id>
<content type='text'>
The idea is simple: Each¹ Find*( call starts with a call check if the
given option (with the requested type) exists in the whitelist. The
whitelist is specified via our configure-index file so that we have
a better chance at keeping it current. the whitelist is loaded via a
special (undocumented for now) configuration stanza and if none is
loaded the empty whitelist will make it so that no warnings are shown.

Much needs to be done still, but that is as good a time as any to take a
snapshot of the current state and release it into the wild given that it
found some bugs already and has no practical effect on users.

¹ not all in this iteration, but many
</content>
</entry>
<entry>
<title>expand -f to --fix-broken in error messages</title>
<updated>2016-12-31T01:29:20Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-29T11:55:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cfc11b2e1d8480727208b9d3e9577172de9a4038'/>
<id>urn:sha1:cfc11b2e1d8480727208b9d3e9577172de9a4038</id>
<content type='text'>
Users end up believing that this is a --force mode as -f is common for
that, but apt doesn't have such a mode and --fix-broken is really not
about forcing something but actually trying to fix the breakage which
tends to be the result of a user forcing something on its system via
low-level forced dpkg calls.

Example: The "common" pattern of "dpkg -i ./foo.deb; apt install -f" is
nowadays far better dealt with via "apt install ./foo.deb".

And while at it the two places handing out this suggestion are changed
to use the same strings to avoid needless translation work in the future
and the suggestion uses 'apt' instead of 'apt-get' as this will be run
interactively by a user, so its a good opportunity to showcase what we
can do and will allow us to be more helpful to the user.

Closes: #709092
Thanks: Kristian Glass for initial patch!
</content>
</entry>
<entry>
<title>allow default build-essentials to be overridden</title>
<updated>2016-12-31T01:29:20Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-29T11:41:23Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=abbe74b2b4690b9138da94d26a7e45ad80a3bf6c'/>
<id>urn:sha1:abbe74b2b4690b9138da94d26a7e45ad80a3bf6c</id>
<content type='text'>
The config list APT::Build-Essential gets a similar treatment to other
lists now by having the value of the option itself be an override for
the list allowing to disable build-essentials entirely as well as
adding/overriding as usual by now in other lists.

Reported-By: Johannes 'josch' Schauer on IRC
</content>
</entry>
<entry>
<title>add --indep-only for build-dep command</title>
<updated>2016-12-31T01:29:20Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-29T11:12:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0c646119dea438abb3ee8797994d016ba6834cd2'/>
<id>urn:sha1:0c646119dea438abb3ee8797994d016ba6834cd2</id>
<content type='text'>
The implementation is quite different compared to --arch-only due to ABI
reasons but functionality wise they are similar and usually both
available for symmetry at least.

Closes: #845775
</content>
</entry>
<entry>
<title>ensure generation of valid EDSP error stanzas</title>
<updated>2016-12-31T01:29:20Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-29T10:20:18Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0161280405fe5aa256dc9df6a56106dd3a1a6f38'/>
<id>urn:sha1:0161280405fe5aa256dc9df6a56106dd3a1a6f38</id>
<content type='text'>
The crude way of preparing a message to be a multiline value failed at
generation valid deb822 in case the error message ended with a new line
like the resolving errors from apt do. apt itself can parse these, but
other tools like grep-dctrl choke on it, so be nice and print valid.

Reported-By: Johannes 'josch' Schauer on IRC
</content>
</entry>
<entry>
<title>warn if clearsigned file has ignored content parts</title>
<updated>2016-12-31T01:29:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-16T18:50:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3'/>
<id>urn:sha1:6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3</id>
<content type='text'>
Clearsigned files like InRelease, .dsc, .changes and co can potentially
include unsigned or additional messages blocks ignored by gpg in
verification, but a potential source of trouble in our own parsing
attempts – and an unneeded risk as the usecases for the clearsigned
files we deal with do not reasonably include unsigned parts (like emails
or some such).

This commit changes the silent ignoring to warnings for now to get an
impression on how widespread unintended unsigned parts are, but
eventually we want to turn these into hard errors.
</content>
</entry>
<entry>
<title>tests: cache the apt-key homedir used for Release signing</title>
<updated>2016-12-21T18:36:10Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-18T16:42:17Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4ce2f35248123ff2366c8c365ad6a94945578d66'/>
<id>urn:sha1:4ce2f35248123ff2366c8c365ad6a94945578d66</id>
<content type='text'>
Importing a new secret key into gpg(2) can be increadibly slow which
prolongs the test runs significantly – by caching the homedir we gain a
significant speedbonus as reimporting already present keys seems like a
far less costly operation.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>let {dsc,tar,diff}-only implicitly enable download-only</title>
<updated>2016-12-16T12:50:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-25T14:51:21Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=58ebb3017baf46e33a9bb2c1779d6daede27d108'/>
<id>urn:sha1:58ebb3017baf46e33a9bb2c1779d6daede27d108</id>
<content type='text'>
That was the case already for tar-only and diff-only, but in a more
confusing way and without a message while dsc "worked" before resulting
in a dpkg-source error shortly after as tar/diff files aren't available…
</content>
</entry>
</feed>
