apt/debian, branch 1.2.11Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.2.112016-04-25T13:24:44ZRelease 1.2.112016-04-25T13:24:44ZJulian Andres Klodejak@debian.org2016-04-25T13:24:02Zurn:sha1:4ad57118a8a0225b413de96dedc085e0594726a6releasing package apt version 1.2.102016-04-05T18:24:43ZMichael Vogtmvo@ubuntu.com2016-04-05T18:24:43Zurn:sha1:4c4b610fd029914e789caad7514ef92c6e97a327Fix `OnCalendar=*-*-* 6,18:00` instead of `OnCalendar=*-*-* 6:00,18:00`2016-04-04T14:52:27ZMichael Vogtmvo@debian.org2016-04-04T14:52:27Zurn:sha1:c9a2e4db0001729574bfe52d6663d066f0c59baa
See https://github.com/systemd/systemd/issues/2956 - it appears that
`OnCalendar=*-*-* 6,18:00` and `OnCalendar=*-*-* 6:00,18:00` are
quite different.
Git-Dch: ignore
Use systemd.timer instead of a cron job2016-04-01T11:02:39ZMichael Vogtmvo@ubuntu.com2016-03-17T07:56:58Zurn:sha1:14669d4b95f0f6a9b215d7fa5aebbc3b7198585d
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
Release 1.2.92016-03-27T00:30:31ZJulian Andres Klodejak@debian.org2016-03-27T00:28:12Zurn:sha1:1d4219eef6b88cb08b957378b0ca1f9762996eacRelease 1.2.82016-03-24T18:31:51ZJulian Andres Klodejak@debian.org2016-03-24T18:31:51Zurn:sha1:21895193b664a403179fcd8eee379b9b371084b5Update symbols file2016-03-24T14:16:00ZJulian Andres Klodejak@debian.org2016-03-24T14:15:46Zurn:sha1:77c35637ea85a065da3bcf57a4a8921cf2ad04f0Release 1.2.72016-03-15T18:21:34ZJulian Andres Klodejak@debian.org2016-03-15T18:20:35Zurn:sha1:a99c3a5f51d31f72174c91643e1e04002686452aFix bug where the problemresolve can put a pkg into a heisenstate2016-03-15T17:55:02ZMichael Vogtmvo@ubuntu.com2016-03-15T12:13:54Zurn:sha1:0390edd5452b081f8efcf412f96d535a1d959457
The problemresolver will set the candidate version for pkg P back
to the current version if it encounters an impossible to satisfy
critical dependency on P. However it did not set the State of
the package back as well which lead to a situation where P is
neither in Keep,Install,Upgrade,Delete state.
Note that this can not be tested via the traditional sh based
framework. I added a python-apt based test for this.
LP: #1550741
[jak@debian.org: Make the test not fail if apt_pkg cannot be
imported]
Release 1.2.62016-03-07T18:51:34ZJulian Andres Klodejak@debian.org2016-03-07T18:51:34Zurn:sha1:13df96c5f3a70fd2d49e0622c9e1f7d5f76cc5dd