apt/debian, branch 1.3_exp1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_exp12016-05-11T08:51:06ZRelease 1.3~exp12016-05-11T08:51:06ZJulian Andres Klodejak@debian.org2016-05-11T08:51:06Zurn:sha1:5b0577488ff60e7163fe7dc62a044329d398d726implement Identifier field for IndexTargets2016-05-08T16:15:28ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-08T16:03:48Zurn:sha1:39c724b4848ef8d85c8c425f982dda85f0df1277
A frontend like apt-file is only interested in a specific set of files
and selects those easily via "Created-By". If it supports two locations
for those files through it would need to select both and a user would
need to know that implementation detail for sources.list configuration.
The "Identifier" field is hence introduced which by default has the same
value as "Created-By", but can be freely configured – especially it can
be used to give two indexes the same identifier.
move gnupg|gnupg2 from apt Depends to Recommends2016-05-01T10:50:53ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-01T10:50:53Zurn:sha1:87d468fe355c87325c943c40043a0bb236b2407f
apt doesn't need gnupg in its main execution paths to function,
especially the Release file verification is done with gpgv only.
It is only used by apt-key for advanced key management functionality
most user will never use nor need.
The intend is to demote it eventually to Suggests, but we opt here for a
staged downgrade as there are still third-party repositories out there
which require apt-key functionality without depending on gnupg (or apt
for that matter).
bugscript: include all configuration fragment files2016-05-01T08:50:24ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-29T16:40:08Zurn:sha1:451051d8e946d2d3a6664222b976768406e743c7
Closes: 820861
Release 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:21895193b664a403179fcd8eee379b9b371084b5