| Age | Commit message (Collapse) | Author |
|---|
|
If package is installed via an explicitly given deb file we store the
filename as a provides, so that the frontend can request the filename
and get the usual "Selected foo instead of foo.deb" message.
We do not need to trouble the EDSP solvers with that though as these
provides are not valid in various ways and we have already solved the
link between commandline and package (and version) for them.
Closes: #962741
|
|
Closes: #962483
|
|
Partial directories are created with 0700, but the parent is 0755, while
the error message would report 0700 for both… that isn't right and can
be pretty confusing.
Turns out that the messages aren't marked for translation, so no
unfuzzing is required & we just leave it as untranslated for now.
Especially as the more detailed error strings derived from errno
are translated.
Reported-By: Wakko Warner <wakko@animx.eu.org>
Closes: #962310
|
|
|
|
While we process the possible solutions we might modify other solutions
like discarding their candidates and such, so that then we reach them
they might no longer be proper candidates. We also try to drop
duplicates early on to avoid the simple cases of these which
test-explore-or-groups-in-markinstall triggers via its explicit
duplication but could also come via multiple provides.
It only worked previously as were ignoring current versions which
usually is okay expect if they are marked for removal and we want to
reinstate them so the ProblemResolver can decide which one later on.
|
|
Especially if a lot packages have to be removed due to not to explicitly
expressed conflicts the problem resolver can take a few turns to remove
them all. Allowing it to try a little longer if needed seems beneficial
as the worst which can happen is that we now take two times as long to
present an error message to the user.
|
|
For protected packages the "Fixing" done via KillList in the
ProblemResolver will usually not happen as the state change is not
allowed, so the debug message is just confusing and the resolver is
needlessly looping here (which might push it over the edge), so if we
didn't do our thing successfully here we short-circuit a bit to help the
next iteration come to a solution.
|
|
The pkgProblemResolver incorrectly skips protected packages while
considering packages for removal, which was always wrong but is now a
lot more visible as (potentially) far more packages are considered
protected in their state.
Note that the testcase shows that we need more changes to make this
proper.
|
|
We are leaking a d-pointer currently weighting a boolean in size and
MethodConfig is instantiated in small numbers only, so nobody will
actually notice a difference, but proper cleanup is important.
Reported-By: clang LeakSanitizer
References: 04ab37fecaf286f724bef2e0969d2b67ab5ac1b1
|
|
|
|
Closes: #961431
|
|
The non-virtual base-destructor causes its derivate classes to leak
tiny bits of memory otherwise. The header is private and not to be
used outside of APT, so we can perform this tiny ABI break as there
is no ABI to break.
Reported-By: valgrind and clang -fsanitize=leak
|
|
Replacing the macros with stub inline functions allows for more
versatile usage, e.g. fixing this compile error:
In file included from /usr/include/x86_64-linux-gnu/c++/9/bits/c++locale.h:41,
from /usr/include/c++/9/bits/localefwd.h:40,
from /usr/include/c++/9/ios:41,
from /usr/include/c++/9/ostream:38,
from /usr/include/c++/9/iostream:39,
from include/apt-pkg/configuration.h:30,
from ../apt-pkg/contrib/netrc.cc:16:
/usr/include/c++/9/clocale:54:11: error: ‘::setlocale’ has not been declared
54 | using ::setlocale;
Gbp-Dch: Ignore
|
|
As the builtins were used in the feature test also in the default branch
clang fails to compile the test helpfully complaining that you need to
compile with sse4.2 to use that while on gcc it is optimized out as
unused code and produces only a warning for that… removing the code from
the default branch fixes this problem, but we adapt the code some more to
avoid compilers optimizing it out in the future just in case.
|
|
../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
Cnf.CndSet("Dir::State", STATE_DIR + 1);
../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning
We have a few instances of that & it should be reasonably clear that we are not
actually trying to append here, but ignoring or silencing this warning with an
override is far more costly than just using what clang suggests here.
Reported-By: clang
Gbp-Dch: Ignore
|
|
../apt-pkg/edsp.cc:861:23: error: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl]
const char *arch = _config->Find("APT::Architecture").c_str();
Compilers are probably optimizing it the way the patch does by hand now. Small
string optimisation helps likely as well. Othwise that should have failed left
and right as EDSP is used by experimental and such builders to talk to aspcud.
Reported-By: clang
|
|
|
|
Gbp-Dch: Ignore
|
|
For speed reasons pkgDepCache initializes its state once and then has a
battery of update calls you have to invoke in the right order to update
the various states – all in the name of speed. In debug and/or
simulation mode we can sacrifice this speed for a bit of extra checking
though to verify that we haven't made some critical mistake like #961266.
|
|
It looks like hack and therefore I wanted this to be a very isolated
commit so we can find it & revert it easily if need be, but for now it
seems to work.
The idea is that Status is telling us how the candidate is in relation
to the current installed version which is used to figure out if a
package is "kept back" by the algorithm or not, but by discarding the
candidate version we loose this information.
Ideally we would keep better tabs on what we do to a package and why,
but for now that seems okayish. It will cause the wrong version to be
displayed though as if the package is installed the installed version
becomes the candidate and hence (installed => installed) is displayed.
|
|
If we have a negative dependency to deal with we prefer to install an
upgrade rather than remove the current version. That is why we split the
method rather explicitly in two in 57df273 but there is a case we didn't
react to: If we have seen the candidate before as a "satisfier" of this
negative dependency there is no point in trying to upgrade to it later
on. We keep that info by candidate discard if we can, but even if we
can't we can at least keep that info around locally.
This "fixes" (or would hide) the problem described in 04a020d as well as
you don't have to discard installations you never make.
|
|
For a (partially) installed package like the one MarkInstall operates on
at the moment we want to discard the candidate from, we have to first
remove the package from the internal state keeping to have proper broken
counts and such and only then reset the candidate version which is a
trivial operation in comparison.
Take a look at the testcase: Now, what is the problem? Correct,
git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries
to switch the architecture of git here (which is pointless, it knows
that this won't work, but lets fix that in another commit) will
eventually realize that it can't install it and wants to discard the
candidate of git:i386 first removing the broken indication like it
should, removing the install flag and then reapplies the broken
indication: Expect it doesn't as it wants to do that over the candidate
version which the package no longer had so seemingly nothing is broken.
It is a bit of a hairball to figure out which commit it is exactly that
is wrong here as they are all influencing each other a bit, but >= 2.1
is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie.
Closes: #961266
|
|
|
|
References: dcdfb4723a9969b443d1c823d735e192c731df69
|
|
|
|
When we could not find a translated description, we were
pushing V.TranslatedDescription() to the vector, but that
one might not have been good either.
Add the check so we don't crash later when trying to access
it.
LP: #1877987
|
|
Turns out that pkgDepCache and pkgProblemResolver maintain two (semi)
independent sets of protected flags – except that a package if marked
protected in the pkgProblemResolver is automatically also marked in the
pkgDepCache as protected. This way the pkgProblemResolver will have as
protected only the direct user requests while pkgDepCache will
(hopefully) propagate the flag to unavoidable dependencies of these
requests nowadays. The pkgProblemResolver was only checking his own
protected flag though and based on that calls our Mark* methods usually
without checking return, leading to it believing it could e.g. remove
packages it actually can't remove as pkgDepCache will not allow it as it
is marked as protected there. Teaching it to check for the flag in the
pkgDepCache instead avoids it believing in the wrong things eventually
giving up.
The scoring is keeping the behaviour of adding the large score boost
only for the direct user requests though as there is no telling which
other sideeffects this might have if too many packages get too many
points from the get-go.
Second part of fixing #960705, now with pkgProblemResolver output which
looks more like the whole class of problem is resolved rather than a
teeny tiny edgecase it was before.
|
|
The previous commit deals with negative, now we add the positive side of
things as well which makes this a recursive endevour. As we can push the
protected flag forward only if a single solution for a dependency exists
it is easy for trees to not get it, so if resolving becomes difficult it
won't help at all.
|
|
If we propagate protected e.g. due to a user request we should also act
upon (at the moment) satisfied negative dependencies so that the
resolver knows that installing this package later is not an option.
That the problem resolver is trying bad solutions is a bug by
itself which existed before and after and should be worked on.
Closes: #960705
|
|
For positive dependencies this isn't giving much as the dependency
should already be satisfied by such a provider if its protectiveness
would help, but it doesn't hurt to check them first and for negative
dependencies it means that we check those first which are the most
likely to fail to be removed – which is a good idea.
|
|
The important change is adding IsIgnoreable() as it will deal with
self-conflicts and such, but while we are at it lets sprinkle in some
refactoring.
|
|
Reducing the scope of these helpers might allow us to move them
elsewhere and share them or it is a rather pointless exercise,
we will see where it leads us to later on.
Gbp-Dch: Ignore
|
|
We exit early from installing dependencies of a package only if it is
not a user request to avoid polluting the state with installs which
might not be needed (or detrimental even) for alternative choices.
We do continue with installing dependencies though if it is a user
request as it will improve error reporting for apt and can even help
aptitude not hang itself so much as we trim the problem space down for
its resolver dealing with all the easy things.
Similar things can be said about the testcase I have short-circuit
previously… keep going test, do what you should do to report errors!
|
|
The variable this is read to is named Junk and that it is for usecases
like apt-ftparchive which just looks at the items metadata, so instead
of performing this hunked read for data nobody will process we just tell
our FileFd to skip ahead (Internally it might still loop over the data
depending on which compressor is involved).
|
|
With FileFd::Write we already have a helper for this situation we can
just make use of here instead of hoping for the best or rolling our own
solution here.
|
|
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
|
|
Not all filesystems implement this feature in all versions of Linux,
so this open call can fail & we have to fallback to our old method.
|
|
|
|
|
|
|
|
(CVE-2020-3810)
When normalizing ar member names by removing trailing whitespace
and slashes, an out-out-bound read can be caused if the ar member
name consists only of such characters, because the code did not
stop at 0, but would wrap around and continue reading from the
stack, without any limit.
Add a check to abort if we reached the first character in the
name, effectively rejecting the use of names consisting just
of slashes and spaces.
Furthermore, certain error cases in arfile.cc and extracttar.cc have
included member names in the output that were not checked at all and
might hence not be nul terminated, leading to further out of bound reads.
Fixes Debian/apt#111
LP: #1878177
|
|
Closes: #960186
|
|
|
|
References: https://github.com/mquinson/po4a/commit/329f472a378d42c7a33e8110e5091be61480a0fc
|
|
Upstream says it had no effect before, so it seems safe to adapt.
References: https://github.com/mquinson/po4a/commit/ac1e97305b6073ed87fa8cf0a2e32f9b1255d0f1
|
|
Also translating two related strings along the way.
References: https://github.com/Debian/apt/pull/107
|
|
apt marks packages coming from the commandline among others
as protected to ensure the various resolver parts do not fiddle
with the state of these packages. aptitude (and potentially others)
do not so the state is modified (to a Keep which for uninstalled means
it is not going to be installed) due to being uninstallable before
the call fails – basically reverting at least some state changes the
call made before it realized it has to fail, which is usually a good
idea, except if users expect you to not do it.
They do set the FromUser option though which has beside controlling
autobit also gained the notion of "the user is always right" over time
and can be used for this one here as well preventing the state revert.
References: 0de399391372450d0162b5a09bfca554b2d27c3d
Reported-By: Jessica Clarke <jrtc27@debian.org> on IRC
|
|
|
|
We did not merge nl with the template when we updated it,
hence we have quite a bit of churn in that commit and this
one.
|
|
Reinstate * wildcards
See merge request apt-team/apt!118
|
