<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/debian/rules, branch 1.3_pre3</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_pre3</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_pre3'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-06-29T10:17:41Z</updated>
<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>move 'dump' solver from apt-utils to apt package</title>
<updated>2016-06-08T11:07:21Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-07T18:08:27Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ab07af708e49c9219940ffd3e20a01c763267e03'/>
<id>urn:sha1:ab07af708e49c9219940ffd3e20a01c763267e03</id>
<content type='text'>
</content>
</entry>
<entry>
<title>use *.docs files instead of hardcoding in debian/rules</title>
<updated>2016-05-25T06:32:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-25T06:32:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cb6020cdfea3d6dec6f6ad13843ab46f0c10d562'/>
<id>urn:sha1:cb6020cdfea3d6dec6f6ad13843ab46f0c10d562</id>
<content type='text'>
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>remove semi-support for different build-dirs</title>
<updated>2016-05-25T06:27:58Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-25T06:27:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a97127c3d019ee073c078dbb652a12386f58515b'/>
<id>urn:sha1:a97127c3d019ee073c078dbb652a12386f58515b</id>
<content type='text'>
The debian/rules file tries to guess in which directory it is supposed
to be building, but that guess is always ./build – if it wasn't it
would fail later as not all rules take alternatives into acount.

So, as this is clearly not used lets remove this complexity instead of
fixing it up.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>override lintian on doxygens embedded-javascript-library</title>
<updated>2016-05-24T09:06:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-24T07:55:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=83defe877fad2684179d9ddb6e2a40857c3a89e9'/>
<id>urn:sha1:83defe877fad2684179d9ddb6e2a40857c3a89e9</id>
<content type='text'>
The embedding is done completely automatic by doxygen and documented to
be that way for reasons: /usr/share/doc/doxygen/README.jquery

As we can't do anything about it, it is pointless to keep the warning.
</content>
</entry>
<entry>
<title>Use systemd.timer instead of a cron job</title>
<updated>2016-04-01T11:02:39Z</updated>
<author>
<name>Michael Vogt</name>
<email>mvo@ubuntu.com</email>
</author>
<published>2016-03-17T07:56:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=14669d4b95f0f6a9b215d7fa5aebbc3b7198585d'/>
<id>urn:sha1:14669d4b95f0f6a9b215d7fa5aebbc3b7198585d</id>
<content type='text'>
The rational is that we need to spread the load on the mirrors
that apt update and unattended-upgrades cause. To do so, we
leverage the RandomizeDelay feature of systemd. The other advantage
is that the timer is not run at a fixed daily.daily time but
instead every 24h. This also fixes the problem that the randomized
deplay in the current apt.cron.daily causes other cron jobs to
be deplayed.

A compatibility cron job is also provided for systems that do not
use systemd.

Note that the time is fired two times a day, but the logic inside
of apt.systemd.daily will ensure (via stamp files) that the
servers are hit at most every 24h. Firing two times a day helps
with the worst case update time and it also helps with systems
that are not always on.

LP: #246381, #727685
Closes: #600262, #709675, #663290
</content>
</entry>
<entry>
<title>Allow building without libgtest-dev under &lt;nocheck&gt; build profile</title>
<updated>2016-01-03T14:10:05Z</updated>
<author>
<name>Helmut Grohne</name>
<email>helmut@subdivi.de</email>
</author>
<published>2016-01-03T14:10:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=084faf6a41eaf7f0fb52c0210b0cc7fbf22a7ac6'/>
<id>urn:sha1:084faf6a41eaf7f0fb52c0210b0cc7fbf22a7ac6</id>
<content type='text'>
I'd like to avoid pulling libgtest-dev into the bootstrap set.

Fortunately, libgtest-dev is only used for testing apt and apt
correctly implements DEB_BUILD_OPTIONS=nocheck now. So this
bug is about getting rid of the Build-Depends.

Simply removing it (by adding a build profile) is not sufficient
however as configure fails hard, so an additional bit is necessary
to cover for that.

Closes: #809726
</content>
</entry>
<entry>
<title>part revert, part redo 'which' replacement</title>
<updated>2015-12-06T23:09:10Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-06T23:09:10Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e23ee4c21c6d8045ab020526aa864a48dc16ddd9'/>
<id>urn:sha1:e23ee4c21c6d8045ab020526aa864a48dc16ddd9</id>
<content type='text'>
In e75e5879 'replace "which" with "command -v" for portability' I missed
that command -v isn't actually required to be available in debian, so
for the 5 files we are using it:

Two (abicheck/run_abi_test &amp; test/integration/framework) are called in
environments were I believe sh is at least dash or 'better' as the first
one is "interactive" for apt developers and the later is sourced by ~200
tests in the same directory run by hand and ci-services – for the later
we have pulled some uglier hacks for worser things already, so if there
should actually end up needing something more compatible we will notice
eventually (and the later actually had a command -v call for some time
already and nobody came running).

debian/rules and debian/apt.cron.daily I switched back to which as that
is more or less debian-specific or at least highly non-critical.

That leaves cmdline/apt-key.in with a bunch of calls where I will
implement that functionality in shell as this is relatively short-lived
as it is used to detect wget (for net-update, which Michael wants to
revive and in that process will properly use apt-helper instead of wget)
and to detect gpg vs. gpg2 systems, where the earlier is supposed to go
away in the longrun (or the later, but by replacing the earlier…).
[and this gpg/gpg2 detection is new in sid, so I have some sympathy for
that being a problem now.]

Thanks: Jakub Wilk for pointing out #747320
</content>
</entry>
<entry>
<title>replace "which" with "command -v" for portability</title>
<updated>2015-12-06T13:03:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-06T13:03:35Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e75e5879c0e8d232a2e8f045685beeb8c965aba4'/>
<id>urn:sha1:e75e5879c0e8d232a2e8f045685beeb8c965aba4</id>
<content type='text'>
which is a debian specific tool packaged in debianutils (essential)
while command is a shell builtin defined by POSIX.

Closes: 807144
Thanks: Mingye Wang for the suggestion.
</content>
</entry>
</feed>
