libdrm participates in dependency loops (e.g. #870176) relevant to
architecture bootstrap. As we noticed, this problem is hard, so I looked
into easily droppable dependencies instead. Turns out valgrind is not
one of them. On the bright side, libdrm no longer builds its
documentation with xsltproc and ruses restructred text now. It also no
longer uses xutils-dev. And libx11-dev is only used in some tests. We
can drop the first two and annotate libx11-dev <!nocheck>. Please
consider applying the attached patch.

Helmut

I was able to confirm that those can be dropped.

Is that still the case?
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 don't know. I filed the patch more than two years ago. A relatively

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.

I am not sure what you mean with heavy-handed here and why that would be
an issue.

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.

Helmut

That was one of the reasons I asked ;)

Not fully understanding it, it felt like "some tests may be problematic, let's
disable all them"

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

Do I understand correctly that this no longer is your understanding?

Fair enough. I can offer you two ways forward. You may add me as
reviewer, so I can do the defending part if it becomes necessary. The
correctness of a nocheck build profile can be technically validated. If
you locally perform a build with and without nocheck and both produce
the same artifacts (the reproducible bit-identical ense), then that's a
very strong clue that the dependency wasn't used for building (but maybe
used for testing). And since "nocheck" really means disabling all tests,
you're right in thus annotating the dependency.

Fine.

Looking at the original reason always is a good idea. :) And yeah, the
referenced bug #870176 has a cycle via valgrind. So while looking into
libdrm was motivated by the presence of cycles. The approach was looking
for low hanging fruit (i.e. relatively obviously unused dependencies) in
packages relevant to cycles. So it's not about a particular dependency
here.

Helmut

Yep, it adds the option to not do the test and in that case you also don't
need the build dependency. Thus it doesn't unconditionally disable (all) the
test, but gives the option/flexibility to do so.

Thinking about it some more, I actually use it myself a lot when building
kernels. I pretty much always use the 'nodoc' profile, which saves ~1 GB of
dependencies to install (IIRC, mostly due to texlive-latex-extra).
Or use the 'cross' profile when cross-compiling a kernel.

There's still a lot of magic (to me) involved and I don't fully/properly
understand how it works (yet), but I do use it.

I actually have now build libdrm locally, but I usually let Salsa's CI do that
for me. And I'm compiling it on my main PC and have yet to learn how to do it
with tools like sbuild. It's on my TODO, but I'm not there yet.
I also want to learn tools like diffoscope (I think R-B is amazing), but I
don't understand (its output) one bit. One day I will, but that will not be in
the near future.

Did I miss option 2?

Thanks again,
  Diederik