<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/doc, branch 1.3_pre2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_pre2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_pre2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-07-08T12:34:37Z</updated>
<entry>
<title>Release 1.3~pre2</title>
<updated>2016-07-08T12:34:37Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-07-08T12:33:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b8c465aa89406d6bba17e8ecf04710eae2c71d08'/>
<id>urn:sha1:b8c465aa89406d6bba17e8ecf04710eae2c71d08</id>
<content type='text'>
Yes, we might still add new features to 1.3 or break some more
stuff. Stay tuned!
</content>
</entry>
<entry>
<title>Release 1.3~pre1</title>
<updated>2016-07-07T18:39:03Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-07-07T18:38:00Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4bdf29d39c401ac479f6486469328fa648f9feab'/>
<id>urn:sha1:4bdf29d39c401ac479f6486469328fa648f9feab</id>
<content type='text'>
</content>
</entry>
<entry>
<title>apt-key.8: Put (deprecated) into the term tag</title>
<updated>2016-07-07T18:20:44Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-07-07T18:20:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ec51fe3ff619835a0e2e672112f42ad3293ee760'/>
<id>urn:sha1:ec51fe3ff619835a0e2e672112f42ad3293ee760</id>
<content type='text'>
Now post-build script should no longer complain...

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>use +0000 instead of UTC by default as timezone in output</title>
<updated>2016-07-02T10:01:17Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-02T09:28:42Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0b45b6e5de1ba4224ced67a9952e009d0f4139a0'/>
<id>urn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0</id>
<content type='text'>
All apt versions support numeric as well as 3-character timezones just
fine and its actually hard to write code which doesn't "accidently"
accepts it. So why change? Documenting the Date/Valid-Until fields in
the Release file is easy to do in terms of referencing the
datetime format used e.g. in the Debian changelogs (policy §4.4). This
format specifies only the numeric timezones through, not the nowadays
obsolete 3-character ones, so in the interest of least surprise we should
use the same format even through it carries a small risk of regression
in other clients (which encounter repositories created with
apt-ftparchive).

In case it is really regressing in practice, the hidden option
  -o APT::FTPArchive::Release::NumericTimezone=0
can be used to go back to good old UTC as timezone.

The EDSP and EIPP protocols use this 'new' format, the text interface
used to communicate with the acquire methods does not for compatibility
reasons even if none of our methods would be effected and I doubt any
other would (in these instances the timezone is 'GMT' as that is what
HTTP/1.1 requires). Note that this is only true for apt talking to
methods, (libapt-based) methods talking to apt will respond with the
'new' format.  It is therefore strongly adviced to support both also in
method input.
</content>
</entry>
<entry>
<title>deprecate 'apt-key update' and no-op it in Debian</title>
<updated>2016-07-01T22:03:20Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T21:44:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f4dcab0504a68595d9e95c953ce66f46f9ad30aa'/>
<id>urn:sha1:f4dcab0504a68595d9e95c953ce66f46f9ad30aa</id>
<content type='text'>
Debian isn't using 'update' anymore for years and the command is in
direct conflict with our goal of not requiring gnupg anymore, so it
is high time to officially declare this command as deprecated.
</content>
</entry>
<entry>
<title>warn if apt-key is used in scripts/its output parsed</title>
<updated>2016-07-01T20:00:52Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T20:00:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=08fcf9628806af202e555bd02b3611e4e9a3d757'/>
<id>urn:sha1:08fcf9628806af202e555bd02b3611e4e9a3d757</id>
<content type='text'>
apt-key needs gnupg for most of its operations, but depending on it
isn't very efficient as apt-key is hardly used by users – and scripts
shouldn't use it to begin with as it is just a silly wrapper. To draw
more attention on the fact that e.g. 'apt-key add' should not be used in
favor of "just" dropping a keyring file into the trusted.gpg.d
directory this commit implements the display of warnings.
</content>
</entry>
<entry>
<title>alias apt-key list to finger</title>
<updated>2016-07-01T14:40:36Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T14:40:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a5f9b45e4a67246f7af2c6fc62de9c531cd314a4'/>
<id>urn:sha1:a5f9b45e4a67246f7af2c6fc62de9c531cd314a4</id>
<content type='text'>
There is no real point in having two commands which roughly do the same
thing, especially if the difference is just in the display of the
fingerprint and hence security sensitive information.

Closes: 829232
</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: rename stanza 'Install' to 'Unpack'</title>
<updated>2016-06-27T09:57:13Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-25T17:53:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=262fdd8b5882dcd23f3b4cb266132ad3c326f83a'/>
<id>urn:sha1:262fdd8b5882dcd23f3b4cb266132ad3c326f83a</id>
<content type='text'>
Freeing 'Install' for future use as an interface for "dpkg --install",
which is currently not used by any existent planer, so the
implementation of it itself will be delayed until then.
</content>
</entry>
<entry>
<title>eipp: add Allow-Temporary-Remove-of-Essentials</title>
<updated>2016-06-27T09:57:12Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-06T15:58:00Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8d1cb6da6e21302c654da3f09de3975af7e4a11f'/>
<id>urn:sha1:8d1cb6da6e21302c654da3f09de3975af7e4a11f</id>
<content type='text'>
A rather special need option, but the internal planer supports this and
we have a testcase for it &amp; sometimes it is hit (as a bug through). The
option itself mostly serves as a reminder for implementors that they
should be careful with removes and especially temporary removes if they
perform any.
</content>
</entry>
</feed>
