On Monday, 6 November 2023 22:13:45 CET Helmut Grohne wrote: > On Mon, Nov 06, 2023 at 09:52:54PM +0100, Diederik de Haas wrote: > > > And libx11-dev is only used in some tests. > > > We can annotate libx11-dev <!nocheck>. > > > > Is that still the case? > > I don't know. I filed the patch more than two years ago. A relatively That was one of the reasons I asked ;) > > Can you perhaps expand on why that annotation is appropriate (for my > > learning experience)? Policy 4.9.1 mentions "to not run any build-time > > test suite provided by the package" with the 'nocheck' tag, but that > > sounds a bit heavy- handed to me? > > I am not sure what you mean with heavy-handed here and why that would be > an issue. Not fully understanding it, it felt like "some tests may be problematic, let's disable all them" > The technical term for <!nocheck> is "restriction formula" according to > man deb-src-control. It expresses that when the nocheck build profile is > enabled, the annotated dependency is disabled. The nocheck build profile > may be used together with the nocheck build option to disable running > build-time tests. Any such testing is not supposed to affect the output > artifacts of the package in case the build succeeds. The method I used > for validation here is performing such a nocheck build and comparing its > artifacts with a regular build using diffoscope. > > Note that none of the regular build daemons used for building packages > on release architectures ever enable this build profile. It is enabled > on some ports architectures and it is also enabled by default for cross > builds. Nevertheless, a failure to build with a nocheck profile is > considered release-critical since trixie, because the autoremover will > consider breaking <!nocheck> annotated dependencies. Thanks so much for taking the time to explain it :-) While I'm now less clueless about this then before, I don't feel comfortable enough that I would be able to 'defend' the inclusion of the <!nocheck> annotation, so I won't include that part in the MR I'm working on. I did add the removal of the 2 B-Ds in that MR, but as it doesn't include all the items of this bug report, I won't close this bug with those changes. Note that (currently?) the valgrand B-D is commented out/disabled in debian/control, so together that may help with the (original) reason for filing this bug? Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.