Package: dgit Version: 12.3 Severity: serious As part of trying to get rid of our ubiquitous use of fakeroot, dpkg-buildpackage has started treating a lack of Rules-Requires-Root as meaning "no" rather than "binary-targets". Also, the "binary" rule now implies "build".
dgit's test suite uses some rule-invocation-tracking test packages to see which targets get invoked by various build modes. (This is necessary to make sure that dgit's invocations of various build tools DTRT.) These tests now fail, due to the different behaviour of dpkg-buildpackage. We want our test suite to pass with old dpkg, so we can't just change the expected behaviour. This is a serious problem because: * It is preventing the new src:dpkg from migrating, since these tests run in ci.debian.net. (So by usual rules, this bug needs to be serious severity here in dgit.) * It is causing our CI tests to fail. This is because a (not-allow-fail) job runs these tests on sid. We probably don't want this situation. Probably, we should be using testing, so that our CI don't start to fail, and block all our work, due to changes outside dgit.git. I think the simplest way to deal with this would be: * In our tests, pass an option to dpkg-buildpackage to engage the old behaviour. (Probably, expecting the old behaviour is a sufficiently thorough test.) * Wait several Debian releases for all old versions of dpkg-buildpackage to be unsupported everywhere. * Stop passing the option and adjust the src:dgit tests (possibly adding new test invocations if coverage otherwise becomes poor). But, it's not clear yet if this is going to be a workable approach. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
