On Wed, 2017-07-05 at 09:38 +0200, Julian Andres Klode wrote: > On Wed, Jul 05, 2017 at 07:58:11AM +0200, Cyril Brulebois wrote: > > Control: tag -1 moreinfo > > > > Hi, > > > > Julian Andres Klode <j...@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?
There are two things here that I think may be getting confused. The requirement for accepting an update to p-u has always been that it doesn't affect unstable - either by the affected code not being present or (more commonly) by the bug having already been fixed in unstable. That requirement is to ensure that the fix gets at least some exposure before the point release, and because it's quicker and simpler to get any required follow-up fixes applied in unstable. We do of course want to fix to be available to users of testing asap, but that's not a blocker for the p-u request. In order for the fix to then get into stable itself, the version of the package in testing must be strictly higher than that of the p-u update. It's preferable if that occurs due to a more recent package having migrated to testing, but if necessary ftp-master will (at our request) force packages into testing and/or unstable during the point release, in order to avoid violating the archive's inter-suite version constraints. > > > > > 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. ACK. > > > * 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 :) See related comments later. > > > [ 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. Seems ok. > > > [ 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. I'm okay with the fixes, but the changelog descriptions aren't particularly great. For instance, you've explained in this thread that the Content-Length: bug caused apt to wait (indefinitely?) for content that would never arrive, but that's not really clear (at least to me) from the changelog. > > > 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. Whilst it may be true that the changes don't affect the Debian package, I'd expect them to be documented /somewhere/ as they are clearly changes relative to the previous upstream release (and not simply "release preparation" imho as other changes to version numbers etc are). There doesn't seem to be an upstream changelog, NEWS file or similar in apt, so I'm not sure where other than the Debian changelog you'd suggest that they should be documented. Regards, Adam
