On Fri, Apr 11, 2025 at 02:16:24AM +0200, Simon Josefsson wrote:
Source: oci-seccomp-bpf-hook
Version: 1.2.10+ds-2
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
Hi
Hi Simon :)
This package FTBFS with this diff:
-# Dpkg.Copyright.Grant.ByFile Dpkg::Copyright::Grant::ByFile::_load_fill_blank_data Note: loading debian/fill.copyright.blanks.yml fixes (155)
+# Dpkg.Copyright.Grant.ByFile Dpkg::Copyright::Grant::ByFile::_load_fill_blank_data Note: loading debian/fill.copyright.blanks.yml fixes (156)
See build log:
https://salsa.debian.org/jas/oci-seccomp-bpf-hook/-/jobs/7412272
The same problem has happened a couple of times before:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052084
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093641
There are two other hits of this same problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101228 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101230
Don't worry, I've got bothered enough to look for a more structural
solution ;)
Running 'copyright-scan' when building the package seems to be error
prone because the output seems to change slightly over time and
depending on external factors. It is not good to FTBFS because of that.
I'm 100% with you, thank you for looking into this.
I couldn't tell exactly what it is that trigger these diffs, do you
know? It seems likely it will happen again on some new external change.
I don't know what generates these diffs and honestly I think we should
not care about, it's evidently internal stuff.
Looking a bit further, this package has a lot of build dependencies:
6 upgraded, 879 newly installed, 0 to remove and 0 not upgraded.
Need to get 352 MB of archives.
Adding libconfig-model-dpkg-perl exaggerates that.
That's unfortunate and I've never realized it.
OTOH they are just bits (+ some heat, yes) and the package is built
so rarely that it's surely a negligible part of the whole that Debian
moves around.
I propose to drop this part of the build stage of this package, what do
you think? Managing d/copyright file is usually done by the maintainer
not by build scripts. I'll do an upload shortly cleaning this up a bit
as part of regular Go team maintainance, and will fix the FTBFS this way
too, but happy to resolve it some other way too.
Well, when you asked I was sleeping and you did not give me any
opportunity to answer before the -3 upload. I'm doing it now though.
d/copyright is managed by the maintainer but how to ensure that it's
up to date? It could be that a new release adds some files, or changes something related to copyright.
So I came to this (admittely) baroque way to offload such extremely
boring task that I don't want to ever do again.
My solution would be to filter out the offending line, the only one I
could see changing over time.
Applying this to more packages, not less, would improve the overall
accuracy of the d/copyright files and preserve it over time with the
least possible maintenance effort.
What do you think?
/Simon
Dom
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEGSWGdoKrcEzTtUezikr1XMf+zOIFAmf5S6cACgkQikr1XMf+ zOKZ9g//RBbiPkkHZVfJsvjrtxbKecQoGtcbMaDmWC3CnJEgHoh7T6iQnxnCxhyp uayty1onTi+/8r4REjAU0YJM87BwfFLtYQ08CAkdXET6VDzW1HpdEcSkBSsoou0S 5ema1iw8lCOUouO0+CximzuOMkNnUNck7dKSdv1s8loFgmljfAb9DCfQ1MjuqcIF FRpIvDjWS9dgMoYfegLSqQ2dN81N0reMuZ0fqbUxC/KxV8zytrxTzoZ1oYbt3Pbm vFzGcTu3zGjZDQeMREgEoh+P1fzYTaE28Rf56OuEAtHM4bppzt4R4vap9ATYn9vB fPyBfZMkODFp8jCWOlwFpvO8HTJ8CZ1GzSP+AJ1rPKSGjkrWFnzw179M0L9ttxJa VzQfCr3aBkfGwH9XiPFgiZIsxKs9iERFOEXUvZqir+d19sIlFt1ZnH+Y3vhoU4Za E0sVRUtZHZfRTzsCxhUh0BhiZ4JdLJiFPMGRylD6hScuNB8/O6CLnAIwUh31cej8 ylRNGJqJnFAiis+h8fS5EW9uNsRld56B/+oAzCTKg8jssfQcdDaXE1php3mH+rKd P4hJI/37eNCcWd8vWSP4jpxfDXayw+yJfwPWVRSfOCSLHc+URRUHxpKPrpMivDGo 5ksSfbmeaSSfaVgGPxG3THiz6S8G1Dl+rg+nOa0zvK+Czb8MEuw=
=BiBr
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet