<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-private, branch 2.7.6</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.7.6</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.7.6'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2023-09-20T07:47:47Z</updated>
<entry>
<title>Downgrade unmerged-usr from error to two warnings</title>
<updated>2023-09-20T07:47:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-09-20T07:46:51Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=925ada57d999a502dc2342092f32232b803be254'/>
<id>urn:sha1:925ada57d999a502dc2342092f32232b803be254</id>
<content type='text'>
One warning will be issued before the Y/n prompt, the other will
be issued at the end after package installs have been attempted
or if there were other failures, such that the last line you see
is warnings about unmerged-usr

I do not anticipate this to be the final version either, but
there we go.

Closes: #1052058
</content>
</entry>
<entry>
<title>Only accept installs of usrmerge on unmerged-usr systems</title>
<updated>2023-09-16T10:37:31Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-09-16T10:34:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=99c888b5eabbb7008bf4451bc62c277f28bb925f'/>
<id>urn:sha1:99c888b5eabbb7008bf4451bc62c277f28bb925f</id>
<content type='text'>
As of bookworm, merged-usr is mandatory, and people got caught
in the crosshairs of the dpkg fsys-unmessusr debacle and inadvertently
reverted back to an unmerged configuration and continue to remain
on an unsupported system unknowingly.

Help them by erroring out when they are installing packages on /,
they are not in a chroot, and a usrmerge package is available.
</content>
</entry>
<entry>
<title>update: Add notice about missing Signed-By in deb822 sources</title>
<updated>2023-06-27T17:21:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-06-27T17:14:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=aba813975abb880f8b27d659147f7760c02f99e7'/>
<id>urn:sha1:aba813975abb880f8b27d659147f7760c02f99e7</id>
<content type='text'>
We want to gently steer users towards having Signed-By for each
source such that we can retire a shared keyring across sources
which improves resilience against configuration issues and
incompetent malicious actors.
</content>
</entry>
<entry>
<title>Initial support for snapshot servers, apt --snapshot option</title>
<updated>2023-05-02T13:23:14Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-02-22T13:14:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a19f606aad717fe5c9c69237c3af53feb547115e'/>
<id>urn:sha1:a19f606aad717fe5c9c69237c3af53feb547115e</id>
<content type='text'>
Provide snapshot support for offical Debian and Ubuntu archives.

There are two ways to enable snapshots for sources:

1. Add Snapshot: yes to your sources file ([snapshot=yes]). This
   will allow you to specify a snapshot to use when updating or
   installing using the --snapshot,-S option.

2. Add Snapshot: ID to your sources files to request a specific
   snapshot for this source.

Snapshots are discovered using Label and Origin fields in the Release
file of the main source, hence you need to have updated the source at
least once before you can use snapshots.

The Release file may also declare a snapshots server to use, similar
to Changelogs, it can contain a Snapshots field with the values:

1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@`
   is a placeholder that is replaced with the requested snapshot id

2. `Snapshots: no` to disable snapshot support for this source.
   Requesting snapshots for this source will result in a failure
   to load the source.

The implementation adds a SHADOWED option to deb source entries,
and marks the main entry as SHADOWED when a snapshot has been
requested, which will cause it to be updated, but not included
in the generated cache.

The concern here was that we need to keep generating the shadowed
entries because the cleanup in `apt update` deletes any files not
queued for download, so we gotta keep downloading the main source.

This design is not entirely optimal, but avoids the pitfalls of
having to reimplement list cleanup.

Gaps:

- Ubuntu Pro repositories and PPAs are not yet supported.
</content>
</entry>
<entry>
<title>Add apt install,upgrade,... -U,--update options</title>
<updated>2023-05-02T13:16:54Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-04-11T14:37:51Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3625351722e67903dc34993fe318e50863bd2d31'/>
<id>urn:sha1:3625351722e67903dc34993fe318e50863bd2d31</id>
<content type='text'>
This runs update before opening the cache and sources.list for
installing/upgrading.
</content>
</entry>
<entry>
<title>Suggest using non-free-firmware in update for Debian</title>
<updated>2023-02-04T16:56:41Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2023-01-29T22:24:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9712edf6151308148518058bfbd5ccd937509143'/>
<id>urn:sha1:9712edf6151308148518058bfbd5ccd937509143</id>
<content type='text'>
In an ideal world everyone would read release notes, but if the last
sources.list change is any indication a lot of people wont. This is
even more a problem in so far as apt isn't producing errors for
invalid repositories, but instead carries on as normal even through it
will not be able to install upgrades for the moved packages.

This commit implements two scenarios and prints a notice in those cases
pointing to the release notes:
a) User has 'non-free' but not 'non-free-firmware'
b) User has a firmware package which isn't available from anywhere

Both only happen if we are talking about a repository which identifies
itself as one of Debian and is for a release codenamed bookworm (or
sid). Note that as (usually) apt/oldstable is used to upgrade to the
new stable release these suggestions only show for users after they
have upgraded to bookworm on apt command line usage after that.
</content>
</entry>
<entry>
<title>Respect users pkg order on `apt install` for resolving</title>
<updated>2022-09-02T21:37:58Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-09-02T09:07:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e1f332324f81b589561a9d9bce8a55d4895f26ec'/>
<id>urn:sha1:e1f332324f81b589561a9d9bce8a55d4895f26ec</id>
<content type='text'>
The command line is evaluated in two steps: First all packages given
are marked for install and as a second step the resolver is started on
all of them in turn to get their dependencies installed.

This is done so a user can provide a non-default choice on the command
line and have it respected regardless of where on the command line it
appears.

On the other hand, the order in which dependencies are resolved can
matter, so instead of using a "random" order, we now do this in the
order given on the command line, so if you e.g. have a meta package
pulling in non-default choices and mention it first the choices are
respected predictably instead of depending on first appearance of the
package name while creating the binary cache.

I might have "broken" this more than a decade ago while introducing the
reworked command line parsing for Multi-Arch, which also brought in the
split into the two steps mentioned above which was the far more
impactful 'respect user choice' change. This one should hardly matter in
practice, but as the tests show, order can have surprising side effects.
</content>
</entry>
<entry>
<title>Avoid triggering unused variable ‘State’ in doAutoInstall</title>
<updated>2022-09-02T20:32:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-08-31T14:08:54Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=009cf61122b7a0ac22b541035a26e6092c9ac529'/>
<id>urn:sha1:009cf61122b7a0ac22b541035a26e6092c9ac529</id>
<content type='text'>
Reported-By: gcc
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Keep color disabled if APT::Color was set to false</title>
<updated>2022-08-08T08:22:50Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-06-09T07:38:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=dc25210d889ebbcdfe96bd814a355961e80bccb3'/>
<id>urn:sha1:dc25210d889ebbcdfe96bd814a355961e80bccb3</id>
<content type='text'>
Support for envvar NO_COLOR was added in 2.3.11, but with our own
options we can also be a tiny bit more sensible in not overriding
an explicit choice to disable colors.

References: 400a6895566b67d70bcde43dc8a1cc1c7121f87d
</content>
</entry>
<entry>
<title>Let the auto installer loose for non-broken packages too</title>
<updated>2022-07-11T14:37:35Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-07-08T11:37:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e481022470322b50a3289d2397b42b6eeacfc6e7'/>
<id>urn:sha1:e481022470322b50a3289d2397b42b6eeacfc6e7</id>
<content type='text'>
Because the auto installer now also marks other binaries in the
package for upgrade, we do need to run it or we don't mark those
for upgrade.
</content>
</entry>
</feed>
