It would be nice if lintian checked for the presence of a .buildinfo file when processing a .changes file. For a stretch goal, it would be nice if it also checked if the .buildinfo file was signed. :) live well, vagrant
tags 944707 + moreinfo thanks Hi Vagrant, I'm obviously sold on the idea of .buildinfo files but what error or mistake might such a missing file imply on behalf of the developer? Regards,
I'm not sure it's a mistake, per se, but suggests that they're using very old tooling to build packages, or home-grown tooling, both of which might have various bugs... but that seems a weak argument to me. My goal in filing this bug is to gently nudge developers to include developer built .buildinfo files, and ideally sign them as well, which increases the number of .buildinfo files we are able to use to verify a given build. It is in Debian policy that packages *should* be reproducible, and .buildinfo files are a cruicial element to be able to demonstrate and verify that packages are reproducible. Ideally with a source-only upload, every build would have at least one .buildinfo from the build daemon and one .buildinfo from the developer who submitted the source package and at least two potential points of convergence. I would think something at the info or pedantic level would be most appropriate at this point in time, if deemed appropriate at all... All of which you're probably well aware, but at least this is forcing me to think it out more verbosely... Maybe lintian isn't the right place for this (yet), but happy to have started and to continue the conversation. live well, vagrant
Dear Vagrant, Agreed and just to underline again I am — of course — very much +1 on the case for .buildinfo files, but I would likely agree with you that Lintian is not the best place for this, at least right now. For starters, if Lintian complained about unsigned .buildinfo files it would seem sensible to warn about unsigned .changes "first", unless we wanted to specifically check the rather niche-sounding case of a signed .changes but an unsigned .buildinfo; technically possible with the right arguments to dpkg-buildpackage, but it feels a bit unlikely. (Practically-speaking, if a user/workflow was using very old tooling it is unlikely they would be using a [future] version of Lintian that would have this check too. And does lintian.debian.org even have access to buildinfo files...? These are lesser and somewhat rhethorical questions that do not really need an answer.) Anyway, thanksindeed for starting this conversation in terms of finding ways of getting more .buildinfo files into the archive. :) Best wishes,
Dear Vagrant, Agreed and just to underline again I am — of course — very much +1 on the case for .buildinfo files, but I would likely agree with you that Lintian is not the best place for this, at least right now. For starters, if Lintian complained about unsigned .buildinfo files it would seem sensible to warn about unsigned .changes "first", unless we wanted to specifically check the rather niche-sounding case of a signed .changes but an unsigned .buildinfo; technically possible with the right arguments to dpkg-buildpackage, but it feels a bit unlikely. (Practically-speaking, if a user/workflow was using very old tooling it is unlikely they would be using a [future] version of Lintian that would have this check too. And does lintian.debian.org even have access to buildinfo files...? These are lesser and somewhat rhethorical questions that do not really need an answer.) Anyway, thanksindeed for starting this conversation in terms of finding ways of getting more .buildinfo files into the archive. :) Best wishes,
The logical logical order is that lintian runs before signing, signing potentially broken packages feels wrong. dput already rejects unswigned changes, and this is the right place for the check. cu Adrian
Or passing the --buildinfo-option=-O/tmp/dpkgisstupid option to dpkg-buildpackage because buildinfo files don't make sense for source-only uploads. cu Adrian