| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
As lengthy discussed in lp:1157943 partial https support was utterly
broken as a 206 response was handled as an (unhandled) error. This is
the first part of fixing it by supporting a 206 response and starting to
deal with 416.
|
|
No effective behavior change, just shuffling big junks of code between
methods and classes to split them into those strongly related to our
client implementation and those implementing HTTP.
The idea is to get HTTPS to a point in which most of the implementation
can be shared even though the client implementations itself is
completely different. This isn't anywhere near yet though, but it should
beenough to reuse at least a few lines from http in https now.
Git-Dch: Ignore
|
|
Our http client requests the "filesize - 1" for the small edgecase of
handling a file which was completely downloaded, but not yet moved to
the correct place as we get 416 errors in that case, but as we can
handle 416 returns now we just special-case the situation of requesting
the exact filesize and handle it as a 200 without content instead.
|
|
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
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Okay, maybe it does have a "few", but the DDTP issues mentioned in this
file are long since gone, so lets just drop the file and look at the PTS
instead: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=apt
Git-Dch: Ignore
|
|
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
|
|
It even reuses the message used for the other check-for members, so one
less message to translate (good, as not that many people will ever see it).
Closes: 722710
|
|
--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
|
|
#724073
|
|
|
|
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
|
|
When a data.tar.{gz,xz} contains a path name that is exactly
100 characters long, it will get truncated to 99 chars upon
extraction in ExtractTar::Go().
Using all of the 100 available characters for the filename
seems to be new behaviour in gnu tar.
Closes: #689582
Thanks: Mika Eloranta for the testcase!
|
|
#722324)
|
|
|
|
|
|
|
|
|
|
|
|
The testcode happily mixes FILE* operations and direct access to fds
which is even a bit suprising that it works on linux and worked so
long for non-linux ports, so we switch to usage of FileFd instead
which provides us with simple fd-only operations. Its overkill for this
test as its a bare file and we ask for the descriptor all the time, but
it shouldn't hurt to implicitly test it a bit this way.
Closes: 721723
Thanks: Aaron M. Ucko
|
|
Git-Dch: Ignore
|
|
Thanks to Philipp Weis (closes: #721477)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
FileFd currently supports no fileflags which would make sense to provide
via mkostemp, so we can just use mkstemp here which is a standard
function compared to glib extension mkostemp.
O_CREAT (Create) and O_TRUNC (Empty) are implied by O_EXCL, which is the
mode mkstemp uses by default. The file description is opened ReadWrite,
but that used to be the default for FileFd in the old times and not a
problem as the difference is needed by FileFd to decide in which way the
compressor pipeline needs to be created (if any).
Git-Dch: Ignore
|
|
Avoid the warning "the use of `mktemp' is dangerous,
better use `mkstemp' or `mkdtemp'". It is not strictly necessary to
change the usage from a security point of view here, but mktemp is
also removed from the standard since POSIX.1-2008.
The mkostemp call returns a file descriptor the logic for
TemporaryFileName has been changed accordingly to get the same results.
The file permissions are corrected by using fchmod() as the default for
FileFd is 666 while mkstemp creates files with 600 by default.
|
|
|
|
The --with-allow-new option maps to APT::Get::UpgradeAllowNew and
will allow "apt-get upgrade" to install new packages (but not to
delete existing packages)
|
|
dist-upgrade 2vcard- 4g8+
|
|
|
|
|
|
|
|
|
|
|
