| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This is very basic support on the testing side, we just test
the debug output but not how long it actually took. Would be
nice to check time really.
|
| |
|
|
|
| |
Fix the typo, and use the helper function to convert it, so we
do not end up with 5 seconds encoded as 0s and 5*10^6 microseconds.
|
| |
|
|
|
| |
This yields more accurate delays and avoids issues with clock
skew.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is an item with fetchAfter at the top of a queue,
reduce sleep() timeout so we can detect it and start it,
by calling Cycle() on the queue in the next iteration.
For some reasons we have to call select() with a 0s timeout
if we just marked an item as ready. Oh well.
Previous versions of this patch only called global Bump() after a timeout
from select(); this was unfortunately incorrect - it meant that we
never bumped a queue that did not start yet while other queues were
running, potentially significantly delaying retries.
|
| |
|
|
|
|
|
| |
Add a new Item field called FetchAfter, which determines the earliest
time the item should be fetched at. Adjust insertion into queue to
take it into account alongside priority, and only fill pipelines
with items that are ready.
|
| |
|
|
|
|
|
|
| |
Enqueuing by calling Init(), and then resetting the status to
idle means that the item can get enqueued twice if we call
Cycle() from inside pkgAcquire::Run().
Reset the status to StatIdle before calling Init()
|
| |\
| |
| |
| |
| | |
Restore dpkg::chroot-directory functionality
See merge request apt-team/apt!178
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we call dpkg inside a chroot we have to ensure that the temporary
directory we construct to call dpkg --recursive is inside the chroot and
that we strip the path to the chroot from the directory name we pass to
dpkg.
Note that the added test succeeds before and (hopefully) after as we
can't really chroot here or fiddle with the needed settings as we are
already setting up apt to work with a quasi-chroot. The test perhaps
helps in ensuring we don't break it too much in the future though.
(Broken five years (and one day) ago this seems to have an immense user
base at the moment, but it might in the future via mmdebstrap)
References: f495992428a396e0f98886c9a761a804aa161c68
Reported-By: Johannes Schauer Marin Rodrigues on IRC
Tested-By: Johannes Schauer Marin Rodrigues
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Volatile sources are parsed after the status file, so if we have a
version already installed the size information is not stored, so that
a reinstall of said version is refused claiming a broken repository.
References: 1412cf51403286e9c040f9f86fd4d8306e62aff2
|
| |/
|
|
|
|
|
|
| |
The error says the repository is broken but doesn't mention which one it
is. The item description gives us at least all the information, but is
not as nicely formatted. As this message is not even marked for
translation this is a rather temporary affair and we can survive without
the eye candy for a while.
|
| |
|
|
|
|
|
|
| |
The code exists since ever, but no other client supports this and the
specification like debian-policy isn't asking for this either. What it
does do is breaking than all others continue working through: If the
filename includes in fact URI encoded bits (hopefully no quotes) which
is rather unlikely, but none the less possible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keeping URIs encoded in the acquire system depends on having them
encoded in the first place. While many other places got the encoding
2 out of 3 ArchiveURI implementations were missed which are in practice
responsible for nearly all of the URI building, just that index filename
do not contain characters to escape and the Filename fields in Packages
files usually aren't. Usually. Except if you happen to have e.g. an epoch
featuring package with the colon encoded in the filename. On the upside,
in most repositories the epoch isn't part of the filename.
Reported-By: Johannes 'josch' Schauer on IRC
References: e6c55283d235aa9404395d30f2db891f36995c49
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package is not installed yet, we do need to apply
phasing as we otherwise get into weird situations when
installing packages:
In the launchpad bug below, ubuntu-release-upgrader-core
was installed, and hence the phasing for the upgrade to it
was applied. However, ubuntu-release-upgrader-gtk was about
to be installed - and hence the phasing did not apply, causing
a version mismatch, because ubuntu-release-upgrader-gtk from
-updates was used, but -core from release pocket. Sigh.
An alternative approach to dealing with this issue could be to
apply phasing to all packages within the same source package,
which would work in most cases. However, there might be unforeseen
side effects and it is of course possible to have = depends between
source packages, such as -signed packages on the unsigned ones for
bootloaders.
This problem does not occur in the update-manager implementation
of phased updates as update-manager only deals with upgrading packages,
but does not install new packages and thus does not see that issue. APT
however, has to apply phasing more broadly, as you can and often do
install additional packages during upgrade, or upgrade packages during
install commands, as both accept package list arguments and have the
same code in the backend.
LP: #1925745
|
| |\
| |
| |
| | |
See https://github.com/Debian/apt/pull/129
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some C libraries e.g. musl do not implement the new res_n* APIs
therefore keep the old implementation as fallback and check __RES
version macro to determine the API level
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Julian Andres Klode <julian.klode@canonical.com>
|
| |\ \
| | |
| | |
| | |
| | | |
Count uninstallable packages in "not upgraded"
See merge request apt-team/apt!169
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a first step of the solver can figure out that a package is
uninstallable it might reset the candidate so that later steps are
prevented from exploring this dead end. While that helps the resolver it
can confuse the display of the found solution as this will include an
incorrect count of packages not upgraded in this solution.
It was possible before, but happens a fair bit more with the April/May
resolver changes last year so finally doing proper counting is a good
idea.
Sadly this is a bit harder than just getting the number first and than
subtracting the packages we upgraded from it as the user can influence
candidates via the command line and a package which could be upgraded,
but is removed instead shouldn't count as not upgraded as we clearly did
something with it. So we keep a list of packages instead of a number
which also help in the upgrade cmds as those want to show the list.
Closes: #981535
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Mark only provides from protected versioned kernel packages
See merge request apt-team/apt!168
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
They are kinda costly, so it makes more sense to keep them around in
private storage rather than generate them all the time in the
MarkPackage method. We do keep them lazy through as we have that
implemented already.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An interactive tool like aptitude needs these flags current far more
often than we do as a user can see them in apt only in one very well
defined place – the autoremove display block – so we don't need to run
it up to four times while a normal "apt install" is processed as that is
just busywork.
The effect on runtime is minimal, as a single run doesn't take too long
anyhow, but it cuts down tremendously on debug output at the expense of
requiring some manual handholding.
This is opt-in so that aptitude doesn't need to change nor do we need to
change our own tools like "apt list" where it is working correctly as
intended.
A special flag and co is needed as we want to prevent the ActionGroup
inside pkgDepCache::Init to be inhibited already so we need to insert
ourselves while the DepCache is still in the process of being built.
This is also the reason why the debug output in some tests changed to
all unmarked, but that is fine as the marking could have been already
obsoleted by the actions taken, just inhibited by a proper action group.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The autoremove algorithm would mark a package previously after exploring
it once, but it could have been that it ignored some providers due to
them not satisfying the (versioned) dependency. A later dependency which
they might satisfy would encounter the package as already marked and
hence doesn't explore the providers anymore leaving us with internal
errors (as in the contrived new testcase).
This is resolved by introducing a new flag denoting if we explored every
provider already and only skip exploring if that is true, which sounds
bad but is really not such a common occurrence that it seems noticeable
in practice. It also helps us marking virtual packages as explored now
which would previously be tried each time they are encountered mostly
hiding this problem for the (far more common) fully virtual package.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
An out-of-tree kernel module which doesn't see many new versions can
pile up a considerable amount of packages if it is depended on via
another packages (e.g.: v4l2loopback-utils recommends v4l2loopback-modules)
which in turn can prevent the old kernels from being removed if they
happen to have a dependency on the images.
To prevent this we check if a provider is a versioned kernel package
(like an out-of-tree module) and if so check if that module package is
part of the protected kernel set – if not it is probably good to go.
We only do this if at least one provider is from a protected kernel
though so that the dependency remains satisfied (this can happen e.g. if
the module is currently not buildable against a protected kernel).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This code can interact with handwritten files who can have unneeded
commas for writing easy. As dpkg allows it, we should do as well.
Reported-By: Arnaud Ferraris <arnaud.ferraris@gmail.com>
References: https://lists.debian.org/debian-devel/2021/03/msg00101.html
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
The comment and code are a bit too roundabout about what they actually
try to do, so lets just set that straight as this is really just about a
very specific case and doesn't deserve a general resetting.
Gbp-Dch: Ignore
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
dpkg 1.20.8 also made --force-remove-essential optional for
deconfiguring essential packages, so let's do this.
Also extend the test case to make sure we actuall pass
auto-deconfigure and do not make any --remove calls, or
pass --force-remove to dpkg.
|
| | |
| |
| |
| | |
dpkg 1.20.8 no longer requires this.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable the Acquire::Retries option by default, set to 3.
This will help with slightly unreliable networking; future
work is needed for adding backoff and SRV/IP rotation.
LP: #1876035
Gbp-Dch: full
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Repositories without Size information for packages are not
proper and need fixing. This ensures people see an error in
CI, and get notifications and hence the ability to fix it.
It can be turned off by setting Acquire::AllowUnsizedPackages
to true.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Having three different vectors littered over the method to manage
various parts of the lifetime of the argument vector we are creating is
a bit dangerous as it means a simple code change could result in a
desync of these three, so by moving the functionality of them all into a
wrapper class should prevent us from making such mistakes.
|
| | | |
|
| | |
| |
| |
| | |
One less thing to remember to do in all branches.
|
| |/
|
|
|
|
| |
It is easy to make mistakes while dealing with such macros regardless of
how much you guard them, so just using a lambda removes a lot of
concerns here basically for free.
|
| |
|
|
|
|
|
|
|
|
|
| |
The mirror method can distribute requests for files based on various
metadata bits, but some – the main index files – weren't actually
passing those on to the methods as advertised in the manpage.
This is hidden both by mirror usually falling back to other sources
which will eventually hit the right one and that if the repository does
not support by-hash apt will automatically stick to the mirror which was
used for the Release file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Especially in small sections of an archive it can happen that an index
returns to a previous state (e.g. if a package was first added and then
removed with no other changes happening in between). The result is that
we have multiple patches which start from the same hash which if we
perform clientside merging is no problem although not ideal as we
perform needless work.
For serverside merging it would not matter, but due to rred previously
refusing to merge zero-size patches but dak ignoring failure letting it
carry these size-zero patches until they naturally expire we run into a
problem as these broken patches won't do and force us to fall back to
downloading the entire index. By always starting from the last patch
instead of the first with the starter hash we can avoid this problem
and behave optimally in clientside merge cases, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rred method expects the patches to have a certain name, which we
have to rename the file to before calling the method, but by delaying
the rename we ensure that if the download of one of them fails and a
successful fallback occurs they are all properly cleaned up as no longer
useful while in the error case the next apt run can potentially pick
them up as already downloaded.
Our test-pdiff-usage test was encountering this every other run, but did
not fail as the check for unaccounted files in partial/ was wrapped
in a subshell so that the failure produced failing output, but did not
change the exit code.
|
| |
|
|
|
|
|
|
| |
Conflicts do require removing the package temporarily, so they really
should not be used.
We need to improve that eventually such that we can deconfigure packages
when we have to remove their dependencies due to conflicts.
|
| |
|
|
|
|
|
|
|
|
|
| |
This caused python-apt to unset the Python signal handler when running
update or install commands, breaking KeyboardInterrupt amongst possibly
other things.
We do not set those signal handlers in this functions, and the calling
functions restore signal handlers to previous ones.
LP: #1898026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As user "DaOfficialRolex" on GitHub pointed out:
This is needed to allow for APT on iOS to compile correctly. If not included the two following errors happen while compiling APT.
~/apt/apt-pkg/contrib/configuration.cc:900:44: error: constexpr variable cannot have non-literal type 'const std::array<APT::StringView, 3>'
constexpr std::array<APT::StringView, 3> magicComments { "clear"_sv, "include"_sv, "x-apt-configure-index"_sv };
^
~/apt/apt-pkg/contrib/configuration.cc:900:44: error: implicit instantiation of undefined template 'std::__1::array<APT::StringView, 3>'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tuple:219:64: note: template is declared here
template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;
^
|
| |
|
|
|
|
|
|
|
| |
dpkg will be changed in 1.20.8 to not require --force-remove for
deconfiguration anymore, but we want to decouple our changes from the
dpkg ones, so let's always pass --force-remove-protected when installing
packages such that we can deconfigure protected packages.
Closes: #983014
|
| |
|
|
|
|
|
|
|
| |
std::regex pulls in about 50 weak symbols which is complete and
utter madness, especially because we version all our symbols, so no
other library could ever reuse them.
Avoid using the regular expression here all together, loop using
string::find_first_of() and insert backslashes with strng::insert().
|
| | |
|
| |\
| |
| |
| |
| | |
Various patches uplifted from unfinished fuzzer branches
See merge request apt-team/apt!158
|
| | |
| |
| |
| |
| |
| |
| | |
Depending on your configured source 25 MB is hardly enough, so the mmap
housing the cache while it is build has to grow. Repeatedly. We can cut
down on the repeats of this by keeping a record of the size of the old
cache assuming the sizes will remain roughly in the same ballpark.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
APT tries to detect if applying patches is more costly than just
downloading the complete index by combining the size of the patches.
That is correct for client-side merging, but for server-side merging
we actually don't know if we will jump directly from old to current or
have still intermediate steps in between.
With this commit we assume it will be a jump from old to current through
as that is what dak implements and it seems reasonable if you go to
the trouble of server side merging that the server does the entire
merging in one file instead of leaving additional work for the client
to do.
Note that this just changes the heuristic to prevent apt from discarding
patches as uneconomic in the now more common one merged-patch style, it
still supports multiple merged patches as before.
To resolve this cleanly we would need another field in the index file
declaring which hash we will arrive at if a patch is applied (or a field
differentiating between these merged-patch styles at least), but that
seems like overkill for now.
|
| | |
| |
| |
| |
| |
| |
| | |
varg API is a nightmare as the symbols seems different on ever other
arch, but more importantly SendMessage does a few checks on the content
of the message and it is all outputted via C++ iostreams and not mixed
in FILE* which is handy for overriding the streams.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The undefined behaviour sanitizer complains with:
runtime error: addition of unsigned offset to 0x… overflowed to 0x…
Compilers and runtime do the right thing in any case and it is a
codepath that can (and ideally should) be avoided for speed reasons
alone, but fixing it can't hurt (too much).
|
| | |
| |
| |
| |
| |
| |
| | |
Our configuration files are not security relevant, but having a parser
which avoids crashing on them even if they are seriously messed up is
not a bad idea anyway. It is also a good opportunity to brush up the
code a bit avoiding a few small string copies with our string_view.
|
| | |
| |
| |
| |
| |
| |
| | |
strtoul(l) surprises us with parsing negative values which should not
exist in the places we use to parse them, so we can just downright
refuse them rather than trying to work with them by having them promoted
to huge positive values.
|
| | |
| |
| |
| |
| |
| | |
It isn't super likely that we will encounter such big words in the real
world, but we can return arbitrary length, so lets just do that as that
also means we don't have to work with a second buffer.
|
| | |
| |
| |
| |
| |
| | |
This has no attack surface though as the loop is to end very soon anyhow
and the method only used while reading CD-ROM mountpoints which seems
like a very unlikely attack vector…
|
