Bug#867190: stretch-pu: package apt/1.4.7
On Wed, Jul 05, 2017 at 07:58:11AM +0200, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
>
> Hi,
>
> Julian Andres Klode <jak@debian.org> (2017-07-04):
> > This release fixes several smaller bugs in the network connection.
> > Apart from the changes in the changelog, there also are some changes
> > to our travis CI integration and the test suite to make CI more
> > reliable (by fixing coverage errors messing up our tests), more future
> > proof (by using docker instead of mixing travis' ubuntu trusty with
> > wily and xenial packages...), and the CI now runs on stretch, so
> > that's good too :)
> >
> > All fixes are straight cherry-picks from unstable, just the travis
> > stuff had some changes (one less variant to build and stretch isntead
> > of testing), but that does not affect us.
>
> apt will need to migrate to testing before we could tentatively accept
> anything from stretch-new; but we're not there yet.
grr, why did the bits email Adam sent then say:
" * The bug you want to fix in stable must be fixed in unstable
already (and not waiting in NEW or the delayed queue)"
I guess you'll see a lot more people trying to do stable updates
only in unstable if that's what people have been told is needed
- perhaps send a follow-up correction?
>
> > Let me know if this is good to go.
> >
> > apt (1.4.7) stretch; urgency=medium
>
> I'll let Adam comment on whether it's OK for this specific case not to
> use +debXuY versioning, since you seem to be going for 1.4.x series in
> stretch.
We also did this in jessie. dpkg also does this.
APT now maintains stable branches matching Debian and Ubuntu
releases, and 1.4.y is the branch for stretch and artful.
>
> > * New microrelease fixing issues in http method (LP: #1702326)
> > => I'll also upload this to Ubuntu, that's just a tag for them, it
> > also helps summarizing the main part of the upload
>
> This isn't much informative: I have no idea what issues you're fixing,
> or how. Users won't know, either.
That's true. I'm still figuring out the best way to keep the Ubuntu
one in sync, so I thought I'd just add the tracking bug I need for
that release there in here and then upload the whole thing there
after fiddling with changes. I'm basically just trying to keep a
single continuity of 1.4.y, and not have 1.4.y-debian and
1.4.y-ubuntu. That won't last long however, the Ubuntu release
only has 9 months of support since April.
We can of course make it more helpful, if you have any
suggestions :)
>
> > [ Robert Luberda ]
> > * fix a "critical" typo in old changelog entry (Closes: 866358)
> >
> > => Remove a letter, and works around a bug in apt-listchanges.
>
> Having a quick glance at the BTS, severity:minor isn't exactly what
> we're considering for proposed-updates. Having correct bug meta data
> would help (from reading the bug report, working around the issue might
> be an idea, but fixing apt-listchanges in stable as well might be
> better).
It's not the main focus of this release, but since we are already
fixing the important bugs in the http stack, I thought we'd include
this for the ride. It's removing a single character from a changelog
file, after all.
>
> > [ David Kalnischkies ]
> > * use port from SRV record instead of initial port
> > => Might have picked the wrong port
> >
> > [ Julian Andres Klode ]
> > * Reset failure reason when connection was successful
> > => Some failures were only treated as warnings, not errors
>
> No bug reports with details for those?
[...]
>
> > * http: A response with Content-Length: 0 has no content
> >
> > => Downloading failed if server responded with Content-Length: 0, as
> > APT was waiting for content to read.
>
> No bug report with details?
I discovered the last two while writing the TLS support in 1.5, so I did
not open up a bug report for each. I'm not sure how David noticed the
first one, but all of them seem to be important bugs.
(1) SRV Stuff: Clearly if we connect to the target host with the wrong
port, then it does not work. You could work around that by using
only SRV records where target port = src port.
(2) Failure reason: This caused random failures in the test suite for https
because some repositories with missing InRelease files did not cause an error,
but only a warning; and apt did not try fetching Release and Release.gpg because
it thought it could not connect to the host at all. Not sure why it only randomly
failed, I assume there's another bug somewhere. For this to happen, you need to have
a server with multiple IP addresses, and not be able to connect() to one of them
before you can connect to it.
I think not following up on a missing InRelease and try to fetch Release.gpg
and Release can be considered release critical, as can the fact that the failing
repository does not cause "update" to exit with an error.
(3) Content-Length: I only noticed this when interacting with Launchpad, or rather when Ubuntu ran
the apport test suite, as that was downloading a file from launchpad. Launchpad
sends a (perfectly valid) redirect response with Content-Length: 0, but APT then
tries to read content (because it just looks at the presence of the header, not
if the value is > 0) and eventually the whole thing failed because the server
closed the connection.
I'm not sure how many servers respond with Content-Length: 0 on stuff, and it's less
of an important bug for apt-get and friends, but we also ship apt-helper which contains
a generic download-file tool, and an API in python-apt that might be used by users on
servers with such responses.
>
> > diff -Nru apt-1.4.6/Dockerfile apt-1.4.7/Dockerfile
> > --- apt-1.4.6/Dockerfile 1970-01-01 01:00:00.000000000 +0100
> > +++ apt-1.4.7/Dockerfile 2017-07-04 17:11:59.000000000 +0200
> > @@ -0,0 +1,11 @@
> > +FROM debian:stretch
> > +COPY . /tmp
> > +WORKDIR /tmp
> > +RUN sed -i s#://deb.debian.org#://cdn-fastly.deb.debian.org# /etc/apt/sources.list \
> > + && apt-get update \
> > + && adduser --home /home/travis travis --quiet --disabled-login --gecos "" --uid 1000 \
> > + && env DEBIAN_FRONTEND=noninteractive apt-get install build-essential ccache ninja-build expect curl git -q -y \
> > + && env DEBIAN_FRONTEND=noninteractive ./prepare-release travis-ci \
> > + && dpkg-reconfigure ccache \
> > + && rm -r /tmp/* \
> > + && apt-get clean
>
> Not documented in changelog. Not sure this addition belongs to stable
> anyway.
Of course not, it does not affect debian at all, that's why we hide
it from the changelog - but did mention it in the email. We could
add them to the changelog, but this would only confuse users, as
this has zero effect on the package.
We only need those changes (.travis.yml, Dockerfile, and testing framework)
to fix our continuous integration which was flaky all the time, mostly
failing, and might stop working at some point. It is not used in Debian
at all, it's strictly a "prepare the release" kind of fix.
> > diff -Nru apt-1.4.6/test/integration/framework apt-1.4.7/test/integration/framework
> > --- apt-1.4.6/test/integration/framework 2017-06-01 10:50:26.000000000 +0200
> > +++ apt-1.4.7/test/integration/framework 2017-07-04 17:11:59.000000000 +0200
> > @@ -1428,12 +1428,12 @@
> > local TMPFILE2="${TMPWORKINGDIRECTORY}/rootdir/tmp/checkdiff.2.tmp"
> > touch "$TMPFILE1" "$TMPFILE2"
> > if [ "$1" != '-' ]; then
> > - sed -e '/^profiling:/ d' < "$1" >"$TMPFILE1"
> > + sed -e '/^profiling:/ d' -e '/\.\.\.profiling:/{N;s#\.\.\.profiling:.*\n#...#g}' < "$1" >"$TMPFILE1"
> > else
> > TMPFILE1='-'
> > fi
> > if [ "$2" != '-' ]; then
> > - sed -e '/^profiling:/ d' < "$2" >"$TMPFILE2"
> > + sed -e '/^profiling:/ d' -e '/\.\.\.profiling:/{N;s#\.\.\.profiling:.*\n#...#g}' < "$2" >"$TMPFILE2"
> > else
> > TMPFILE2='-'
> > fi
>
> Not documented.
Same here, not used in Debian, this just helps the CI
to get going again, as that currently just fails randomly. (OK,
ci.debian.net would use it on unstable, but we don't run package
tests in stable).
The problem is that gcov sometimes writes profiling:<some message>
lines in stderr when it can't open files, and since our test suite
compares program outputs, that causes it to fail. This mostly happens
on CI, but probably also if you run locally (which I don't).
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: