[apparently this ended up sat in my drafts for a while] On Sun, 2017-10-01 at 23:49 +1100, Russell Coker wrote: > On Friday, 29 September 2017 4:39:15 PM AEDT Adam D. Barratt wrote: > > On Sat, 2017-09-30 at 01:08 +1000, Russell Coker wrote: > > > I've attached the patches. These all come from the package > > > currently > > > in > > > Testing. > > > > Thanks, but we don't review individual patches (at least, we don't > > ack/nack uploads based on looking at individual patches). > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html > > Section 5.5.1 of the above seemed to indicate that I should do it > that way. > Did I misunderstand it or does the documentation need improving?
Some combination. :-) You used reportbug to file the report - did it not ask for a debdiff? > > If you'd like an ack for an upload to stable, we'd need to see a > > full > > source debdiff for a package that's been built and tested on > > stable. > > I've attached such a debdiff. NB It has one thing that is not > required (but > is still handy) that is a build-conflicts against too-new versions of > the SE > Linux tools. This prevents anyone from accidentally building it on > Testing or > Unstable (which will be unusable). Obviously the package will work > OK without > such a build-conflict, unless you build it with the wrong packages > installed. Technically, it's version-constrained build-dependencies, rather than a build-conflict. In any case, the diff you supplied has: +refpolicy (2:2.20161023.1-10) unstable; urgency=medium which obviously isn't what you're proposing using for an upload to stable. I realise I said "a package", but the implication was that it be a package that you could simply upload "as-is" if the diff was OKed. Regards, Adam