<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/debian/tests/run-tests, branch 2.7.10</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.7.10</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.7.10'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2022-05-07T08:45:44Z</updated>
<entry>
<title>Link interactive helpers against system libapt for autopkgtest</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-20T23:45:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8d8b45a96ceceb015f7836cf25b99279c2f377b9'/>
<id>urn:sha1:8d8b45a96ceceb015f7836cf25b99279c2f377b9</id>
<content type='text'>
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
</content>
</entry>
<entry>
<title>Avoid building inside the source dir in autopkgtest</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-20T16:51:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ee06eb541e5aa477880ff0fc575be317eccbd929'/>
<id>urn:sha1:ee06eb541e5aa477880ff0fc575be317eccbd929</id>
<content type='text'>
autopkgtest says:
Tests may not modify the source tree (and may not have write access to it).

We don't really modify the source of course, but we created our build/
directory in the tree, which seems to work just fine (for now), but lets
be nice.
</content>
</entry>
<entry>
<title>Try to show core dump info in test framework</title>
<updated>2021-08-28T19:11:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-04-25T20:26:42Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=255ec5a46aa55ad96e7dc7f9d43d5cdf71627812'/>
<id>urn:sha1:255ec5a46aa55ad96e7dc7f9d43d5cdf71627812</id>
<content type='text'>
If the system tells us that a core dump was created we should try to
display the contained info as that system might not be easily available
when we see the error (like C-I or autopkgtest).

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>reset HOME, USER(NAME), TMPDIR &amp; SHELL in DropPrivileges</title>
<updated>2016-11-09T18:33:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-09T18:15:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=34b491e735ad47c4805e63f3b83a659b8d10262b'/>
<id>urn:sha1:34b491e735ad47c4805e63f3b83a659b8d10262b</id>
<content type='text'>
We can't cleanup the environment like e.g. sudo would do as you usually
want the environment to "leak" into these helpers, but some variables
like HOME should really not have still the value of the root user – it
could confuse the helpers (USER) and HOME isn't accessible anyhow.

Closes: 842877
</content>
</entry>
<entry>
<title>debian: make autopkgtest run with CMake build dir</title>
<updated>2016-08-10T14:11:48Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-08T09:31:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7c317e9e90ccbaaab88550f69b902e88e379055c'/>
<id>urn:sha1:7c317e9e90ccbaaab88550f69b902e88e379055c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>CMake: debian: Switch packaging over to CMake and dh 9</title>
<updated>2016-08-06T20:36:02Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-06T19:40:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e825742bbbbe99b99d525a3b34832b25a7396c84'/>
<id>urn:sha1:e825742bbbbe99b99d525a3b34832b25a7396c84</id>
<content type='text'>
This new packaging is much easier to read, although the duplication
in the install files is a bit annoying. We should probably also get
rid of the movefiles for solvers, planners, and https method; but
then we have to keep track of which methods exist in the apt package.

Another disadvantage is that building only the documentation packages
also requires building the code, as there's no way to turn off code
building in the project.
</content>
</entry>
<entry>
<title>eipp: let apt make a plan, not make stuff plane</title>
<updated>2016-06-29T10:17:41Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-29T07:16:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8e99b22c31eb47d0422e9a69e83dc99bb315ded8'/>
<id>urn:sha1:8e99b22c31eb47d0422e9a69e83dc99bb315ded8</id>
<content type='text'>
Julian noticed on IRC that I fall victim to a lovely false friend by
calling referring to a 'planer' all the time even through these are
machines to e.g. remove splinters from woodwork ("make stuff plane").
The term I meant is written in german in this way (= with a single n)
but in english there are two, aka: 'planner'.

As that is unreleased code switching all instances without any
transitional provisions. Also the reason why its skipped in changelog.

Thanks: Julian Andres Klode
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>eipp: provide the internal planer as an external one</title>
<updated>2016-06-27T09:57:12Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-28T13:40:59Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f74d99c6a78caafdc6e32d8cb135683b7154795c'/>
<id>urn:sha1:f74d99c6a78caafdc6e32d8cb135683b7154795c</id>
<content type='text'>
Testing the current implementation can benefit from being able to be
feed an EIPP request and produce a fully compliant response. It is also
a great test for EIPP in general.
</content>
</entry>
<entry>
<title>autopkgtest: use the quiet mode as for travis and co</title>
<updated>2015-11-28T12:27:06Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-28T00:30:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=052a7f48e769c10fb25d5b8adbc71dc085913add'/>
<id>urn:sha1:052a7f48e769c10fb25d5b8adbc71dc085913add</id>
<content type='text'>
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>sync TFRewrite*Order arrays with dpkg and dak</title>
<updated>2015-05-11T15:22:32Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-05-09T16:55:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e8fb1cdfdd13e45f2b3abbd57a28b57ae6137f14'/>
<id>urn:sha1:e8fb1cdfdd13e45f2b3abbd57a28b57ae6137f14</id>
<content type='text'>
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.
</content>
</entry>
</feed>
