<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration, branch 2.7.0</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.7.0</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.7.0'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2023-05-02T13:56:30Z</updated>
<entry>
<title>Merge branch 'pu/snapshot' into 'main'</title>
<updated>2023-05-02T13:56:30Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2023-05-02T13:56:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ed818cfe5c53503f8096056f599e639a9308b3da'/>
<id>urn:sha1:ed818cfe5c53503f8096056f599e639a9308b3da</id>
<content type='text'>
Add --snapshot and --update support

See merge request apt-team/apt!291</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>Keep "or group" when installing package to satisfy it</title>
<updated>2023-05-02T11:59:45Z</updated>
<author>
<name>Jacob Kauffmann</name>
<email>jacob@system76.com</email>
</author>
<published>2023-05-02T11:59:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5f9552801139e6ea8d84db20692561b79cda6d00'/>
<id>urn:sha1:5f9552801139e6ea8d84db20692561b79cda6d00</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Merge branch 'pu/never-sections-matching' into 'main'</title>
<updated>2023-03-06T09:23:20Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2023-03-06T09:23:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=278f542caf92750aed06dae88f066fa01f3f09ac'/>
<id>urn:sha1:278f542caf92750aed06dae88f066fa01f3f09ac</id>
<content type='text'>
Fix permissions &amp;&amp; change section matching in config files to be more gitignore style rightmost match

See merge request apt-team/apt!286</content>
</entry>
<entry>
<title>Do not store trusted=yes Release file unconditionally</title>
<updated>2023-03-04T12:07:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2023-03-04T10:55:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=937221fde2a5ca989a0b80728cd3ba3639f9f20e'/>
<id>urn:sha1:937221fde2a5ca989a0b80728cd3ba3639f9f20e</id>
<content type='text'>
A source marked with trusted=yes can still fail verification of the
Release file, mostly for Date related issues, like being too new or too
old, which have other options to force them in.

The update code was not using the Release file (which was a InRelease
file but failed verification – which was overridden by trusted=yes) as
intended, but it marked it for storage, so that this "bad" Release file
would end up being moved into lists/, which is bad as the indexes it
refers to aren't updated while the next update run assumes that the
indexes are in the state the Release file claims them to be in.

Fixed simply by making the storage conditional on the usage as intended,
which also resolves a second issue: The verification can also detect that
a Release file we got is older than what we already have to avoid down-
grade attacks. The more likely explanation is a slightly outdated mirror
in a rotation/CDN through, so this gets the silent treatment to avoid
scaring users by handling it as if we had got the same Release file we
already have stored locally, removing the freshly received older file
in the process alongside setting some variables. Those variables were
already modified in the trusted=yes case though resulting in the stored
Release file being removed instead. Not modifying the variables too early
resolves this problem as well.

Both seem to exist since at least 2015 as traces are visible in 448c38bdcd
already, which shuffled lots of code around including the bad ones, but
as we are in trusted=yes land, security is of no concern here, this
"just" leads to failed pinning, hashsum mismatches and other strange
problems in follow-up calls depending on how out of sync the Release
file (if its still present) is with the rest of the trusted data.

Reported-By: Dima Kogan &lt;dkogan@debian.org&gt; on IRC
Tested-By: Dima Kogan &lt;dkogan@debian.org&gt;
</content>
</entry>
<entry>
<title>Disable retries to speed up failure-propagation test</title>
<updated>2023-03-04T10:52:29Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2023-03-04T10:52:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e90ba0afa2a27ecea792e8039b2917ec55647548'/>
<id>urn:sha1:e90ba0afa2a27ecea792e8039b2917ec55647548</id>
<content type='text'>
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Detect trimmed changelogs and pick online instead</title>
<updated>2023-03-03T16:51:05Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2023-01-28T21:17:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=acbfdf0533602a05de066aa86d1f756b5fe0f4a3'/>
<id>urn:sha1:acbfdf0533602a05de066aa86d1f756b5fe0f4a3</id>
<content type='text'>
We only check the start of these lines to avoid hard coding the exact
command and we pick 150 as maximum line length as the longest package
name on my system is apparently 75 characters long. We could choose
longer or shorter without much issue as over-length just means we
mishandle the rest of the line as a new line and it should be really
unlikely that a) lines are that long in this file and b) that such long
lines contain one of our trigger sequences – but even if, all we do is
start a download of an online file. Could be worse.

This auto-detection can be avoided by setting
Acquire::Changelogs::AlwaysOnline (or Origin specific sub options)
to "true" if you always want the changelog from an online source.
The reverse – setting it to "false" in the hope it would not get the
changelog from an online source – was not and is still not possible.

Closes: #1024457
</content>
</entry>
<entry>
<title>test-apt-get-update-sourceslist-warning: Fix permissions</title>
<updated>2023-02-27T13:01:52Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-02-27T13:01:27Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0899b69b2b613f8b28e270f49d8a2fd23cbfbd77'/>
<id>urn:sha1:0899b69b2b613f8b28e270f49d8a2fd23cbfbd77</id>
<content type='text'>
This test did not work with umask 0002
</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>
</feed>
