Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre1 2016-07-06T13:53:59Z 2016-07-06T13:53:59Z David Kalnischkies david@kalnischkies.de 2016-07-06T12:49:39Z urn:sha1:3af3ac2f5ec007badeded46a94be2bd06b9917a2 Instead of only trying the first host we get via SRV, we try them all as we are supposed to and if that isn't working we try to connect to the host itself as if we hadn't seen any SRV records. This was already the intend of the old code, but it failed to hide earlier problems for the next call, which would unconditionally fail then resulting in an all around failure to connect. With proper stacking we can also keep the error messages of each call around (and in the order tried) so if the entire connection fails we can report all the things we have tried while we discard the entire stack if something works out in the end. 2016-07-06T13:53:59Z David Kalnischkies david@kalnischkies.de 2016-07-06T13:10:52Z urn: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. 2016-07-06T00:25:51Z David Kalnischkies david@kalnischkies.de 2016-07-05T18:04:27Z urn:sha1:3465138575e1fd0d5892d9b6be1ae232eb873460 If we have files in partial/ from a previous invocation or similar such those could be symlinks created by file:// sources. The code is expecting only real files through and happily changes owner, modification times and permission on the file the symlink points to which tend to be files we have no business in touching in this way. Permissions of symlinks shouldn't be changed, changing owner is usually pointless to, but just to be sure we pick the easy way out and use lchown, check for symlinks before chmod/utimes. Reported-By: Mattia Rizzolo on IRC 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T11:07:29Z urn:sha1:4460551841d909d3ee9c1de00156ed3cdf8b1665 methods/http.cc:640:13: runtime error: reference binding to null pointer of type 'struct FileFd' This reference is never used in the cases it has a nullptr, so the practical difference is non-existent, but its a bug still. Reported-By: gcc -fsanitize=undefined 2016-07-02T10:01:17Z David Kalnischkies david@kalnischkies.de 2016-07-02T09:28:42Z urn: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. 2016-06-27T09:43:09Z David Kalnischkies david@kalnischkies.de 2016-06-25T10:32:11Z urn:sha1:cc0a4c82b3c132abba9b9ec35fd61bc8b45a1b80 Seen in #828011 if we fail to parse a header field like Last-Modified we end up interpreting the data as response header for coming requests in case we don't rotate to a new server in DNS rotation. 2016-06-27T08:58:29Z Julian Andres Klode jak@debian.org 2016-06-27T08:54:26Z urn:sha1:25a694165ae46c159e0d91bf0b27717f00dbc66e wu-ftpd sends the response without parens, whereas we expect them. I did not test the patch, but it should work. I added another return true if Pos is still npos after the second find to make sure we don't add npos to the string. Thanks: Lukasz Stelmach for the initial patch Closes: #420940 2016-06-15T11:38:51Z David Kalnischkies david@kalnischkies.de 2016-06-15T10:45:07Z urn:sha1:99968cf75b46210bded1662d34c4c2b0ef07be04 Most servers who close the connection do not send a content-length as this is redundant information usually, but some might and while testing with our server and with 'aptwebserver::response-header::Connection' set to 'close' I noticed that http hangs after a redirect in such cases, so if we have the information, just use it instead of discarding it. 2016-06-02T11:35:28Z David Kalnischkies david@kalnischkies.de 2016-06-02T10:44:58Z urn:sha1:62600666d21aacea63cece3b4ec64f0ffb40168b In 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf changing to usage of C++ way of setting the locale causes us to be terminated in case of usage of an ungenerated locale as LC_ALL (or similar) – but we don't want to fail here, we just want to carry on as before with setlocale which we call in that case just for good measure. 2016-05-28T16:12:02Z David Kalnischkies david@kalnischkies.de 2016-05-28T11:22:38Z urn: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.