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
signature.asc
Description: PGP signature
