apt/methods/https.cc, branch 1.3_pre1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_pre12016-07-06T13:53:59Zreport all instead of first error up the acquire chain2016-07-06T13:53:59ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-06T13:10:52Zurn:sha1:b50dfa6b2dd2d459e0c2746ac9367982b96ffac0
If we don't give a specific error to report up it is likely that all
error currently in the error stack are equally important, so reporting
just one could turn out to be confusing e.g. if name resolution failed
in a SRV record list.
use +0000 instead of UTC by default as timezone in output2016-07-02T10:01:17ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-02T09:28:42Zurn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0
All apt versions support numeric as well as 3-character timezones just
fine and its actually hard to write code which doesn't "accidently"
accepts it. So why change? Documenting the Date/Valid-Until fields in
the Release file is easy to do in terms of referencing the
datetime format used e.g. in the Debian changelogs (policy ยง4.4). This
format specifies only the numeric timezones through, not the nowadays
obsolete 3-character ones, so in the interest of least surprise we should
use the same format even through it carries a small risk of regression
in other clients (which encounter repositories created with
apt-ftparchive).
In case it is really regressing in practice, the hidden option
-o APT::FTPArchive::Release::NumericTimezone=0
can be used to go back to good old UTC as timezone.
The EDSP and EIPP protocols use this 'new' format, the text interface
used to communicate with the acquire methods does not for compatibility
reasons even if none of our methods would be effected and I doubt any
other would (in these instances the timezone is 'GMT' as that is what
HTTP/1.1 requires). Note that this is only true for apt talking to
methods, (libapt-based) methods talking to apt will respond with the
'new' format. It is therefore strongly adviced to support both also in
method input.
use std::locale::global instead of setlocale2016-05-28T16:12:02ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-28T11:22:38Zurn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf
We use a wild mixture of C and C++ ways of generating output, so having
a consistent world-view in both styles sounds like a good idea and
should help in preventing regressions.
refactored no_proxy code to work regardless of where https proxy is set2016-04-27T20:55:55ZPatrick Cablepc@pcable.net2016-04-27T20:55:55Zurn:sha1:8707edd9e4684ed68856cd8eeff15ebd1e8c88ea
when using the https transport mechanism, $no_proxy is ignored if apt is
getting it's proxy information from $https_proxy (as opposed to
Acquire::https::Proxy somewhere in apt config). if the source of proxy
information is Acquire::https::Proxy set in apt.conf (or apt.conf.d),
then $no_proxy is honored.
Convert most callers of isspace() to isspace_ascii()2015-12-27T00:20:41ZJulian Andres Klodejak@debian.org2015-12-26T23:51:59Zurn:sha1:74dedb4ae28fd4f7c89bf769708d4f7edc7ed79a
This converts all callers that read machine-generated data,
callers that might work with user input are not converted.
apply various suggestions made by cppcheck2015-11-05T11:21:33ZDavid Kalnischkiesdavid@kalnischkies.de2015-11-04T20:08:55Zurn:sha1:258b9e512c4001e806c5c0966acecd3d742ec6e9
Reported-By: cppcheck
Git-Dch: Ignore
wrap every unlink call to check for != /dev/null2015-11-04T17:42:28ZDavid Kalnischkiesdavid@kalnischkies.de2015-11-02T17:49:52Zurn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39
Unlinking /dev/null is bad, we shouldn't do that. Also, we should print
at least a warning if we tried to unlink a file but didn't manage to
pull it of (ignoring the case were the file is /dev/null or doesn't
exist in the first place).
This got triggered by a relatively unlikely to cause problem in
pkgAcquire::Worker::PrepareFiles which would while temporary
uncompressed files (which are set to keep compressed) figure out that to
files are the same and prepare for sharing by deleting them. Bad move.
That also shows why not printing a warning is a bad idea as this hide
the error for in non-root test runs.
Git-Dch: Ignore
set failreasons similar to connect.cc based on curl errors2015-11-04T17:04:01ZDavid Kalnischkiesdavid@kalnischkies.de2015-10-12T20:26:36Zurn:sha1:bce8e59b81e5bdfa46501c25bc1b3fca60a69cb8
Detecting network errors has some benefits in the acquire system as if
we can't connect to a host trying it for a million files is pointless.
http and co which use connect.cc deal with this, but https which uses
curl had connection failures as "normal" errors which could potentially
be worked around (like trying Release instead of the failed InRelease).
Git-Dch: Ignore
fix two memory leaks reported by gcc2015-09-14T13:22:18ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-11T19:02:19Zurn:sha1:830a1b8c9e9a26dc1101167ac66a75c444902c4d
Reported-By: gcc -fsanitize=address -fno-sanitize=vptr
Git-Dch: Ignore
Merge branch 'debian/sid' into debian/experimental2015-05-22T15:01:03ZMichael Vogtmvo@ubuntu.com2015-05-22T15:01:03Zurn:sha1:4fc6b7570c3e97b65c118b58cdf6729fa94c9b03
Conflicts:
apt-pkg/pkgcache.h
debian/changelog
methods/https.cc
methods/server.cc
test/integration/test-apt-download-progress