apt/apt-pkg, branch 2.9.0Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.9.02024-04-12T13:57:05ZOpProgress: Erase lines when done2024-04-12T13:57:05ZJulian Andres Klodejulian.klode@canonical.com2024-04-12T10:00:45Zurn:sha1:8ddfeb2fb65dd45267d8f7abfc540d2b8cb73a5c
It's interesting to the user to see the progress when it happens,
but arguably once it's done it is just visual clutter, so let's
not write newlines, and when we are done, instead of appending
"Done", let's just empty the line.
This requires some effort to keep apt-cdrom happy which just writes
lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix
for it, but this gets us going.
Revert "debrecords: Do not reparse if given same location"2024-03-22T10:10:24ZJulian Andres Klodejulian.klode@canonical.com2024-03-21T21:18:58Zurn:sha1:c8641c40d1a67408439c3a3a37ea203b838eb21a
This reverts commit 9bb953fddae0246a4dcedddb769d75d3521e1f2f.
debrecords: Do not reparse if given same location2024-03-22T10:10:24ZJulian Andres Klodejulian.klode@canonical.com2024-03-21T21:18:08Zurn:sha1:5414789489f9814aaacdc6169975bae1b871a44f
The TagFile parser will have already parsed further and can't go
back so it needs to reopen the file if compressed.
Closes: #1067440
pkgTagFile::Jump: Use lookback buffer to rejump to current position2024-03-21T21:31:04ZJulian Andres Klodejulian.klode@canonical.com2024-03-21T21:28:44Zurn:sha1:88e55d1b7237e6c3b5689b7ce154ef98b11fbf74
If we get called twice with the same offset, our d->Start and d->iOffset
will already point at the offset for the next section. But since we have
the start of the last parsed section still in the buffer, just make sure
to always go back to the start first.
Closes: #1067440
Parse unsupported != relation in dependencies2024-03-07T15:35:17ZDavid Kalnischkiesdavid@kalnischkies.de2024-01-23T13:45:46Zurn:sha1:3d1614b0a6c9c185ed1b2834e338f14d4de5b124
libapt has a NotEquals relation for version constraints in
dependencies, which is used internally e.g. in the MultiArch
implementation, but this relation is not supported by Debian
policy and as such can not be used in packages.
Our parser here is extremely accepting, even unknown relations are
parsed as Equals relation – but the version that must match will be a
rather strange one…
For our own testcases and e.g. on the command line with 'satisfy' it
can make sense to have != available… and what strange things apt does
parsing unsupported relations is not really much of a concern. Real
packages will not have such relations anyhow as we are (mostly) just
a consumer, not a producer of packages and index files.
Handle EINTR in the static FileFd::Write overload2024-03-05T11:57:03ZDavid Kalnischkiesdavid@kalnischkies.de2024-03-04T14:50:44Zurn:sha1:1437dcbe489ee9bcd39000cfef30324ad0260b41
While the code claims to handle it by just continuing the loop, the
looping condition will actually cause a break from the loop failing the
interrupted writing. The non-static FileFd::Write (and ::Read) deal with
this by setting acceptable values for the loop condition as well – but
for more simplicity and consistency we can instead remove this extra loop
condition and perform the continue/break due to error handling more
explicitly.
Implement gpgv --assert-pubkey-algo=>=rsa2048,ed25519,ed4482024-02-28T17:22:01ZJulian Andres Klodejulian.klode@canonical.com2024-02-28T14:14:43Zurn:sha1:50e3fee26ae843a812b1c9ec8531946931773fd3
The assertion can be overriden using apt::key::assert-pubkey-algo,
the default is the most opinionated one.
This will inform the user during apt-cdrom add as we do not
pass --quiet to user, so adjust test case.
Add a simple test case for it to test-method-gpgv.
LP: #2055193
Delete SHADOWED metaIndex if we don't actually use snapshots2024-02-20T17:50:14ZJulian Andres Klodejulian.klode@canonical.com2024-02-20T08:56:06Zurn:sha1:e2949fc463f9e087978b072c82b11860ee02fdb6
This adds a bit more code but avoids any surprises later on by
having both the shadowed and non-shadowed meta index in the
list.
Gbp-Dch: ignore
Automatically enable snapshots where supported2024-02-20T17:50:14ZJulian Andres Klodejulian.klode@canonical.com2024-02-19T11:07:55Zurn:sha1:b6274188312e6338e94edc45dbf9cc410d650477
Convert sources.list Snapshot option from opt-in to automatic. If
we can find a snapshot server, Snapshot: yes is assumed if a snapshot
is specified.
On the implementation side, we record automatic snapshot enablement
by adding a '?' suffix to the snapshot timestamp, if any is specified,
this avoids introducing bugs into the code where we could end up with
an empty snapshot.
This has an annoying internal implementation caveat: Since we call
GetDebReleaseIndexBy() with the SHADOWED option emplaced, if we do
not find a server, we need to remove the SHADOWED option again, but
we already have inserted a shadowed release index into the list.
This will simply insert the release index a second time without the
SHADOWED option which in preliminary testing works fine, but it would
arguably be more correct to also remove the release index again if
we have created it.
FIXME: This only has one test case: A source with supported snapshot
server is auto-discovered. We should also add a test case where we
cannot detect a server and then don't fail in automatic mode.
Modernize standard library includes2024-02-20T12:49:04ZJulian Andres Klodejulian.klode@canonical.com2024-02-20T12:43:08Zurn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49
This was automated with sed and git-clang-format, and then I had to
fix up the top of policy.cc by hand as git-clang-format accidentally
indented it by two spaces.