Bug#852822: signing buildinfo by default breaks compatibility

[Ian Jackson]

Guillem Jover writes ("Re: Bug#852822: signing buildinfo by default breaks 
compatibility"):
> I actually realized this while I was waking up today, and brought it
> up on IRC. My biggest concern was the buildd network, because that
> is explicitly not signing files from inside the chroots. But due to
> gnupg not being installed anymore by default (and very few packages
> at least directly Build-Depending on it), and the buildd chroots not
> containing any home directory, the signing is not performed anyway.
> So in that sense the upload was "safe" from the major fallout. And I
> was then planning on fixing this for .20, after the testing migration
> as it indeed breaks user's and other tools expectations.

Thanks for fixing it earlier.

I didn't do thorough tests, but the change would have broken dgit.
Probably the test suite; perhaps the build wrapper methods; and
certainly the workflow documentation.

> Yes, that's also the conclusion I had arrived at noon, even though
> that makes the semantics suck a bit, but oh well. The other thing I
> was planning (and I've done locally), is to add a new --no-sign
> option which will make this kind of thing future-proof.

Can you please make a short alias for --no-sign ?  Many tasks
(particularly ones done by non-dds) involve building packages without
signing them.

Also, please bear in mind that runes in documentation like
dgit-user(7) will live on in people's finger macros for many years.

Thanks,
Ian.

https://manpages.debian.org/testing/dgit/dgit-user.7.en.html

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#847926: Bug#852820: Testsuite-Restrictions field is hard to use

[Ian Jackson]

Guillem Jover writes ("Re: Bug#852820: Testsuite-Restrictions field is hard to 
use"):
> On Fri, 2017-01-27 at 15:58:28 +, Ian Jackson wrote:
> > If not interpreted very carefully, this would give a test suite runner
> > the erroneous impression that none of the tests can be run.
> 
> Right, I see what you mean.

Can you please add something to the documentation, sayinng that this
field MUST NOT be used to determine whether a package has any tests
that can be run ?  (Because it cannot be correctly so used.)

> > Also, Iain's stated use case in #847926 does not require anything new
> > in the .dsc and hence Sources.gz.  All that is required to get the
> > full information (debian/tests/control) is to extract the source
> > package.  That extraction of the source package has to be done anyway
> > no matter how the tests will be run.
> 
> OTOH, the same could be said for several of the fields in the .dsc, such
> as Build-Depends, but we still list them because it's more convenient to
> not have to extract the source beforehand.

Build-Depends is not a (perverse) atttempt at a summary of some other
pieces of metadata.

> TBH, I hesitated a bit before adding this, because this percolates
> into many other places. But considered that, while the information
> could be retrieved in other ways, it made life easier for test
> runners. And we can always remove it if it ends up being
> unnecessary/undesirable.

You have permanently assigned the name `Testsuite-Restrictions' for
this unnatural meaning, and you and Iain intend for Iain's software to
start relying on it (so withdrawing it would be troublesomw).
Changing published metadata formats is not so easy, I'm afraid.

> But I certainly agree that this should have probably been discussed
> more widely, which is something I overlooked, sorry about that. And
> agree completely with your two points above. So I'll be adding an
> entry to the FAQ detailing the process to add new information to
> the .dsc file (and probably to the .changes and other interchange
> formats).

Thanks,
Ian.

Bug#852821: Dropping Built-For-Profiles is risky

[Ian Jackson]

Guillem Jover writes ("Re: Bug#852821: Dropping Built-For-Profiles is risky"):
> On Fri, 2017-01-27 at 15:58:30 +, Ian Jackson wrote:
> > This significantly reduces the amount of information available to
> > understand why a .deb might be the way it is.  It also inhibits the
> > ability of the archive to reject oddly-built binaries.
> 
> Not really. This information has been provided in the .changes file
> (which is not exposed by the Debian archive), and recently by the
> .buildinfo file, which is supposed to be made publicly available.
> So the archive software should have (had) enough information to reject
> uploads built with any build-profile.

Thanks.  I'm somewhat reassured.

> So, I did canvas opinions on the #debian-dpkg IRC channel, and people
> seemed fine with the idea.

I think IRC channels are an excellent way to get unblocked if stuck by
some issue which someone can perhaps help with, or to sort out a
conversation which needs some higher-bandwidth to-and-fro.  They can
also be a good way to find who to talk to about something, or to find
someone to deal with an urgent problem.

They are a very bad way of canvassing review of design changes.

>   It also makes reproducible builds and other
> QA and porting efforts more useful. I could have certainly brought this
> up on the list, but TBH as it seemed pretty uncontroversial, that's
> why I didn't end up doing that. OTOH designing and implementing any
> kind of dirty/clean profile tracking seems more controversial as was
> seen on the d-d thread, and would have meant pretty much blocking
> progress on this issue for longer, and it also really seems tangential
> to the topic of dropping the field.

I thought we had a pretty good answer to how to do dirty/clean
profiles.

Anyway, thanks for your attention.  Please feel free to close this
bug.

Ian.

Bug#847926: Bug#852820: Testsuite-Restrictions field is hard to use

[Guillem Jover]

On Sat, 2017-01-28 at 05:47:44 +0100, Guillem Jover wrote:
> On Fri, 2017-01-27 at 15:58:28 +, Ian Jackson wrote:
> > I'm sorry that I'm reporting this bug now, due to happening to see the
> > message on debian-dpkg.  But really I think:
> > 
> >  * Changes to the .dsc format and hence to the Sources format should
> >be discussed more widely than a bug on debian-dpkg.
> > 
> >  * Changes to the handling of autopkgtest (DEP-8) metadata should be
> >discussed on autopkgtest-devel (or other DEP-8 related places).
> 
> But I certainly agree that this should have probably been discussed
> more widely, which is something I overlooked, sorry about that. And
> agree completely with your two points above. So I'll be adding an
> entry to the FAQ detailing the process to add new information to
> the .dsc file (and probably to the .changes and other interchange
> formats).

I've now updated the FAQ to include processes for field inclusions to
.dsc and .changes files:

  

Thanks,
Guillem