| Age | Commit message (Collapse) | Author |
|---|
|
As testcases are running really fast it can happen that files which are
changed in reality are considered unchanged as the modify time isn't
changed. What we could do is disable those caches by default, but some
tests actually depend on those and deriving too much from the default by
default (pun intended) is not a good idea for tests after all.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
|
|
|
|
feature/install-progress-refactor
Conflicts:
apt-pkg/deb/dpkgpm.cc
apt-pkg/makefile
|
|
ported from the mvo/feature/install-progress-refactor branch
|
|
|
|
|
|
|
|
|
|
messages that include the architecture
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
stunnel4 is required for https tests
Git-Dch: Ignore
|
|
The tests require nowadays a (somewhat) multiarch-capable dpkg, so
replace the workaround as marked in the FIXME with a proper install as
the workaround isn't working always correctly, letting the test fail.
Git-Dch: Ignore
|
|
With a bit of trickery we can reuse the usual infrastructure we have in
place to acquire deb files for the 'download' operation as well, which
gains us authentification check & display, error messages, correct
filenames and "downloads" from the root-owned archives.
|
|
Git-Dch: Ignore
|
|
We can't remove packages which are held back by the user with a hold, so
marking them (or its dependencies) as garbage will lead our autoremover
into madness – and given that the package is important enough that the
user has held it back it can't be garbage (at least at the moment), so
even if a front-end wants to use the info just for information display
its a good idea to not consider it garbage for them.
Closes: 724995
|
|
Servers might respond with a complete file either because they don't
support Ranges at all or the If-Range condition isn't statisfied, so we
have to parse the headers curl gets ourself to seek or truncate the file
we have so far.
This also finially adds the testcase testing a bunch of partial
situations for both, http and https - which is now all green.
Closes: 617643, 667699
LP: 1157943
|
|
If we get a 416 from the server it means the Range we asked for is above
the real filesize of the file on the server. Mostly this happens if the
server isn't supporting If-Range, but regardless of how we end up with
the partial data, the data is invalid so we discard it and retry with a
fresh plate and hope for the best.
Old behavior was to consider 416 an error and retry with a different
compression until we ran out of compression and requested the
uncompressed file (which doesn't exist on most mirrors) with an accept
line which server answered with "406 Not Acceptable".
Closes: 710924
|
|
Closes: 722549
Git-Dch: Ignore
|
|
While the InstallPackages code was moved from apt-get into the private
library the output was moved from (std::)cout to c1out which isn't shown
in quiet level 2 (and above), so we flip back to std::cout to ensure
that it is always printed as you are not going to use --print-uris if
you don't want to see the uris…
Closes: 722207
|
|
--allow-unauthenticated switches the download to a pre-0.6 system in
which a package can come from any source, rather than that trusted
packages can only come from trusted sources.
To allow this the flag used to set all packages as untrusted, which is a
bit much, so we check now if the package can be acquired via an
untrusted source and only if this is the case set it as untrusted.
As APT nowadays supports setting sources as trusted via a flag in the
sources.list this mode shouldn't be used that much anymore though.
[Note that this is not the patch from the BTS]
Closes: 617690
|
|
The parser goes a bit to far by stripping :any from dependencies in a
single architecture environment. the flag "Multi-Arch: allowed" doesn't
care any architecture restrictions in that case (as in single arch
everything is native), but it still limits the possible versions
statisfying the dependency so stripping :any over-simplifies in upgrade
situations from "Multi-Arch: none" to "Multi-Arch: allowed".
Closes: 723586
|
|
The Eof check was added (by me of course) in
0aae6d14390193e25ab6d0fd49295bd7b131954f
as part of a fix up ~a month ago (at DebConf).
The idea was not that bad, but doesn't make that much sense either
as this bit is set by the FileFd based on Actual as well, so this is
basically doing the same check again – with the difference that the
HitEof bit can still linger from a previous Read we did at the end of
the file, but have seek'd away from it now.
Combined with the length of entries, entry order and other not that
easily controllable conditions you can be 'lucky' enough to hit this
problem in a way which even visible (truncating of other fields might
not be visible easily, like 'Tags' and others).
Closes: 723705
Thanks: Cyril Brulebois
|
|
Git-Dch: Ignore
|
|
Compressing files in 4 different styles eats test-time for no practical
gain if we don't test them explicitly, so default to just building 'gz'
compressed files as it is the simplest compression algorithm supported
Git-Dch: Ignore
|
|
Looks like the travis service runs on Ubuntu in a version which has dpkg
with an earlier interface implementation, so lets try if we can't make
the framework work with this dpkg version as well.
Git-Dch: Ignore
|
|
Add test for bug 507998
|
|
|
|
This adds ::InfoFD option alongside the ::Version one to request sending
the information to the specified FD, by default it is STDIN as it was
the case before.
The environment variable APT_HOOK_INFO_FD contains the FD the data is on as
a confirmation that the APT version used understood the request.
Allowing the hook to choose the FD is needed/helpful e.g. for shellscripts
which have a hard time accessing FDs above 9 (as >= 10 are usually used
internally by them)
Closes: #671728
|
|
In bugreport deb:719629 Paul Wise mentions both to enable some malloc
checks and as more testing can't hurt we enable both for all testcases.
Git-Dch: Ignore
|
|
Having fragement files means there is a good chance that there is one
key per keyring, so deal with that as well as with setups in which
keyrings are linked into trusted.gpg.d as we can't just modify those
files (they might be in /usr for example).
|
|
Git-Dch: Ignore
|
|
Might come in handy for more than just a simple testcase.
|
|
First redirect output to a file, then redirect other outputs to this
output, not the other way around as this will not work.
Git-Dch: Ignore
|
|
The constructors of our (clear)sign-acquire-items move a pre-existent
file for error-recovery away, which gets restored or discarded later as
the acquire progresses, but --print-uris never really starts the
acquire process, so the files aren't restored (as they should).
To fix this both get a destructor which checks for signs of acquire
doing anything and if it hasn't the file is restored.
Note that these virtual destructors theoretically break the API, but
only with classes extending the sign-acquire-items and nobody does this,
as it would be insane for library users to fiddle with Acquire
internals – and these classes are internals.
Closes: 719263
|
|
For many commands the output isn't stable (like then dpkg is called) but
the exitcode is, so this helper enhances the common && msgpass ||
msgfail by generating automatically a msgtest and showing the output of
the command in case of failure instead of discarding it unconditionally,
the later being chronic-like behaviour
Git-Dch: Ignore
|
|
Signing files with expired keys is not as easy as it sounds, so the
framework jumps a few loops to do it, but it might come in handy to have
an expired key around for later tests even if it is not that different
from having no key in regards to APT behaviour.
Git-Dch: Ignore
|
|
We start your quest by using the version of a package applying to a
specific pin, but that version could very well be below the current
version, which causes APT to suggest a downgrade even if it is
advertised that it never does this below 1000.
Its of course questionable what use a specific pin on a package has
which has a newer version already installed, but reacting with the
suggestion of a downgrade is really not appropriated (even if its kinda
likely that this is actually the intend the user has – it could just as
well be an outdated pin) and as pinning is complicated enough we should
atleast do what is described in the manpage.
So we look out for the specific pin and if we haven't seen it at the
moment we see the installed version, we ignore the specific pin.
Closes: 543966
|
|
The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly. It shouldn't be ranked ahead of choosing packages
> from the native architecture. In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.
This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.
Closes: #718482
|
|
nl_langinfo is used to acquire the YESEXPR of the language used,
but it will return the one from LC_MESSAGES, which might be different
from the language chosen for display of the question (based on LANGUAGE)
so this commit removes the [Y/n] help text from the questions itself and
moves it to the prompt creation in which the usage of LC_MESSAGES is
forced for it, so that the helptext shown actually represents the
characters accepted as input for the question.
There is still room for problems of course starting with an untranslated
"[Y/n]" but a translated YESEXPR or the problem that the question is
asked in a completely different language which might have a conflicting
definition of [Y/n] input or the user simple ignores the helptext and
assumes that an answer matching the question language is accepted, but
the mayority of users will never have this problem to begin with, so we
should be fine (or at least a bit finer than before).
Closes nothing really, but should at least help a bit with bugs like
deb:194614, deb:471102, lp:1205578, and countless others.
|
