Hi, Guillem. I'm afraid I find myself writing a critical email.
Guillem Jover writes ("Accepted dpkg 1.18.19 (source) into unstable"):
> Date: Fri, 27 Jan 2017 05:43:36 +0100
> Source: dpkg
> Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
AIUI this has missed the deadline for migration into stretch.
Did you intend this for stretch ? If not then I don't think
it was appropriate to upload it to sid.
I have just filed three bugs, at least the first two of which I think
are troubling for stretch:
#852822 signing buildinfo by default breaks compatibility
#852821 Dropping Built-For-Profiles is risky
#852820 Testsuite-Restrictions field is hard to use
If you did intend it for stretch, then I question the wisdom of making
such large changes so close to the deadline. If (as I calculate) you
have missed the formal deadline, you will need a freeze exception.
I think at the very least changes like these:
> * Avoid useless repeated lstat()s in update-alternatives.
> * Only check for debian/tests/control file once in dpkg-source.
...
> * Do not compute the architecture list twice in dpkg-genchanges.
...
> * Perl modules:
...
> - Call anonymous subs via -> operator instead of casting with &, and fix
> bogus POD documentation to match the code.
...
> - Add a new debug() reporting function, and switch code to use it.
> - Add new Dpkg::BuildOption parse_features() method refactored from
> Dpkg::Vendor::Debian.
ought not to get a freeze exception and are unwise at this point in
the release cycle.
Can you clarify your intent ?
Ian.
