<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/deb, branch 1.7.0_alpha1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.7.0_alpha1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.7.0_alpha1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2018-06-13T21:36:08Z</updated>
<entry>
<title>Fix lock counting in debSystem</title>
<updated>2018-06-13T21:36:08Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-06-13T16:45:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=79f012bd09ae99d4c9d63dc0ac960376b5338b32'/>
<id>urn:sha1:79f012bd09ae99d4c9d63dc0ac960376b5338b32</id>
<content type='text'>
debSystem uses a reference counted lock, so you can acquire it
multiple times in your applications, possibly nested. Nesting
locks causes a fd leak, though, as we only increment the lock
count when we already have locked twice, rather than once, and
hence when we call lock the second time, instead of increasing
the lock count, we open another lock fd.

This fixes the code to check if we have locked at all (&gt; 0).

There is no practical problem here aside from the fd leak, as
closing the new fd releases the lock on the old one due to the
weird semantics of fcntl locks.
</content>
</entry>
<entry>
<title>Start pkg records for deb files with dpkg output</title>
<updated>2018-05-11T15:58:46Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-04-11T10:39:40Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=117ab302176a65536d9d55de30c53e94f08057ae'/>
<id>urn:sha1:117ab302176a65536d9d55de30c53e94f08057ae</id>
<content type='text'>
It is easier to prepend our fields, but that results in confusion for
things working on the so generated records as they don't start with the
usual "Package" – that shouldn't be a problem in theory, but in practice
e.g. "apt-cache show" shows these records directly to the user who
will probably be more confused by it than tools.
</content>
</entry>
<entry>
<title>Remove obsolete RCS keywords</title>
<updated>2018-05-07T11:41:31Z</updated>
<author>
<name>Guillem Jover</name>
<email>guillem@debian.org</email>
</author>
<published>2018-05-06T20:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=164f1b78d1849a0f33df7352875f86e28f5de06a'/>
<id>urn:sha1:164f1b78d1849a0f33df7352875f86e28f5de06a</id>
<content type='text'>
Prompted-by: Jakub Wilk &lt;jwilk@debian.org&gt;
</content>
</entry>
<entry>
<title>Fix various typos reported by spellcheckers</title>
<updated>2018-05-04T22:34:27Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-05-04T17:56:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b12bdeaf8acd050c5526ecc05526db70df5fd485'/>
<id>urn:sha1:b12bdeaf8acd050c5526ecc05526db70df5fd485</id>
<content type='text'>
Reported-By: codespell &amp; spellintian
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Check that Date of Release file is not in the future</title>
<updated>2018-02-19T15:05:01Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-01-29T15:15:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9e5899cac1a6367e3769af52a724821880e538f6'/>
<id>urn:sha1:9e5899cac1a6367e3769af52a724821880e538f6</id>
<content type='text'>
By restricting the Date field to be in the past, an attacker cannot
just create a repository from the future that would be accepted as
a valid update for a repository.

This check can be disabled by Acquire::Check-Date set to false. This
will also disable Check-Valid-Until and any future date related checking,
if any - the option means: "my computers date cannot be trusted."

Modify the tests to allow repositories to be up to 10 hours in the
future, so we can keep using hours there to simulate time changes.
</content>
</entry>
<entry>
<title>Introduce inrelease-path option for sources.list</title>
<updated>2018-01-17T10:52:38Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-01-16T15:53:46Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=698f9e3f9877be2aa181d6e40d3dc5c41ea318b7'/>
<id>urn:sha1:698f9e3f9877be2aa181d6e40d3dc5c41ea318b7</id>
<content type='text'>
Allow specifying an alternative path to the InRelease file, so
you can have multiple versions of a repository, for example.

Enabling this option disables fallback to Release and Release.gpg,
so setting it to InRelease can be used to ensure that only that
will be tried.

We add two test cases: One for checking that it works, and another
for checking that the fallback does not happen.

Closes: #886745
</content>
</entry>
<entry>
<title>dpkg status parsing: check if name is valid before use</title>
<updated>2018-01-05T00:18:40Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-01-04T21:57:21Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=df2d614900476920671779f27fcc4143d3c1b5b7'/>
<id>urn:sha1:df2d614900476920671779f27fcc4143d3c1b5b7</id>
<content type='text'>
The summary line sounds a bit much: what we end up doing is just adding
two more guards before using results which should always be valid™.

That these values aren't valid is likely a bug in itself somewhere, but
that is no reason for crashing.
</content>
</entry>
<entry>
<title>give the methods more metadata about the files to acquire</title>
<updated>2017-12-13T22:56:29Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-10-27T16:38:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9f572c0a6d13cc983a4f8880a3dee3a8e46604bb'/>
<id>urn:sha1:9f572c0a6d13cc983a4f8880a3dee3a8e46604bb</id>
<content type='text'>
We have quite a bit of metadata available for the files we acquire, but
the methods weren't told about it and got just the URI. That is indeed
fine for most, but to avoid methods trying to parse the metadata out of
the provided URIs (and fail horribly in edgecases) we can just as well
be nice and tell them stuff directly.
</content>
</entry>
<entry>
<title>convert various c-style casts to C++-style</title>
<updated>2017-12-13T22:53:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-12-13T12:26:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=957381a0d26ec11a172ebfc64f892d1b31f0c193'/>
<id>urn:sha1:957381a0d26ec11a172ebfc64f892d1b31f0c193</id>
<content type='text'>
gcc was warning about ignored type qualifiers for all of them due to the
last 'const', so dropping that and converting to static_cast in the
process removes the here harmless warning to avoid hidden real issues in
them later on.

Reported-By: gcc
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>deprecate the single-line deprecation ignoring macro</title>
<updated>2017-12-13T22:53:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-12-13T11:51:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5d5ca1aac76448cdfd16972090d246c44671dce6'/>
<id>urn:sha1:5d5ca1aac76448cdfd16972090d246c44671dce6</id>
<content type='text'>
gcc has problems understanding this construct and additionally thinks it
would produce multiple lines and stuff, so to keep using it isn't really
worth it for the few instances we have: We can just write the long form
there which works better.

Reported-By: gcc
Gbp-Dch: Ignore
</content>
</entry>
</feed>
