<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-private, 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-07-30T08:14:47Z</updated>
<entry>
<title>prevent C++ locale number formatting in text APIs (try 2)</title>
<updated>2016-07-30T08:14:47Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-30T07:57:50Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7303e11ff28f920a6277c159aa46f80c007350bb'/>
<id>urn:sha1:7303e11ff28f920a6277c159aa46f80c007350bb</id>
<content type='text'>
Followup of b58e2c7c56b1416a343e81f9f80cb1f02c128e25.
Still a regression of sorts of 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf.

Closes: 832044
</content>
</entry>
<entry>
<title>create non-existent files in edit-sources with 644 instead of 640</title>
<updated>2016-07-22T14:05:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-22T11:04:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=01047752b34486607665db99afffa595cb2d43ce'/>
<id>urn:sha1:01047752b34486607665db99afffa595cb2d43ce</id>
<content type='text'>
If the sources file we want to edit doesn't exist yet GetLock will
create it with 640, which for a generic lockfile might be okay, but as
this is a sources file more relaxed permissions are in order – and
actually required as it wont be readable for unprivileged users causing
warnings/errors in apt calls.

Reported-By: J. Theede (musca) on IRC
</content>
</entry>
<entry>
<title>report warnings&amp;errors consistently in edit-sources</title>
<updated>2016-07-22T14:05:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-22T10:33:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=503c7d594125f963b92047ad2d9d0644f39136c7'/>
<id>urn:sha1:503c7d594125f963b92047ad2d9d0644f39136c7</id>
<content type='text'>
After editing the sources it is a good idea to (re)built the caches as
they will be out-of-date and doing so helps in reporting higherlevel
errors like duplicates sources.list entries, too, instead of just
general parsing errors as before.
</content>
</entry>
<entry>
<title>support "install ./foo.changes"</title>
<updated>2016-07-22T14:05:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-08T13:59:23Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=92296fe4b0862a04ea3d965b4cd2d4a420e3be9f'/>
<id>urn:sha1:92296fe4b0862a04ea3d965b4cd2d4a420e3be9f</id>
<content type='text'>
We support installing ./foo.deb (and ./foo.dsc for source) for a while
now, but it can be a bit clunky to work with those directly if you e.g.
build packages locally in a 'central' build-area.

The changes files also include hashsums and can be signed, so this can
also be considered an enhancement in terms of security as a user "just"
has to verify the signature on the changes file then rather than
checking all deb files individually in these manual installation
procedures.
</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: 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>eipp: implement version 0.1 of the protocol</title>
<updated>2016-06-27T09:43:09Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-14T16:07:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7b197262212f49b3b355b1124edf2ba9adb73411'/>
<id>urn:sha1:7b197262212f49b3b355b1124edf2ba9adb73411</id>
<content type='text'>
The very first step in introducing the "external installation planer
protocol" (short: EIPP) as part of my GSoC2016 project.

The description reads: APT-based tools like apt-get, aptitude, synaptic,
… work with the user to figure out how their system should look like
after they are done installing/removing packages and their dependencies.
The actual installation/removal of packages is done by dpkg with the
constrain that dependencies must be fulfilled at any point in time (e.g.
to run maintainer scripts).

Historically APT has a super micro-management approach to this task
which hasn't aged that well over the years mostly ignoring changes in
dpkg and growing into an unmaintainable mess hardly anyone can debug and
everyone fears to touch – especially as more and more requirements are
tacked onto it like handling cycles and triggers, dealing with
"important" packages first, package sources on removable media, touch
minimal groups to be able to interrupt the process if needed (e.g.
unattended-upgrades) which not only sky-rocket complexity but also can
be mutually exclusive as you e.g. can't have minimal groups and minimal
trigger executions at the same time.
</content>
</entry>
<entry>
<title>show right binary name in simulation notice</title>
<updated>2016-06-23T07:02:54Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-23T06:56:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ae2a6be8a2155c136f9535abfbcc750c8c395cd2'/>
<id>urn:sha1:ae2a6be8a2155c136f9535abfbcc750c8c395cd2</id>
<content type='text'>
Closes: 825216
</content>
</entry>
<entry>
<title>add insecure (and weak) allow-options for sources.list</title>
<updated>2016-06-22T12:05:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-20T18:50:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a'/>
<id>urn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a</id>
<content type='text'>
Weak had no dedicated option before and Insecure and Downgrade were both
global options, which given the effect they all have on security is
rather bad. Setting them for individual repositories only isn't great
but at least slightly better and also more consistent with other
settings for repositories.
</content>
</entry>
<entry>
<title>source: if download is skipped, don't try to unpack</title>
<updated>2016-06-22T12:05:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-18T07:59:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=60a0cb424e91acebc2bba0f9add220b474e432e6'/>
<id>urn:sha1:60a0cb424e91acebc2bba0f9add220b474e432e6</id>
<content type='text'>
If apt decides it can't download a file it is relatively pointless to
try to tell dpkg-source to unpack it.
</content>
</entry>
</feed>
