On Sat, 2026-11-07 at 18:31 +0100, Santiago Vila wrote: > Hello DFSG team. > > I'd like to make a minor comment about this automated review. > > On Sat, Nov 07, 2026 at 04:03:05PM +0000, [email protected] wrote: > > > - [minor] [packaging] node-gulp-mocha is marked <!nocheck> although > > gulpfile.js requires it for the build, not only for the tests > > Build failures with the nocheck build profile are considered to be RC > by the Release Managers, and this is included in the Release Policy > for forky, so I would assign this a higher severity than "minor". > > Not sure how many intermediate levels are there between "minor" and > "blocking". If the automated system actually tries to build the > package with nocheck build profile and it fails, or if you estimate > that the failure will happen with very high confidence, I think it > would be ok to use "blocking" here.
Thanks. This is good to know. The issue classification is only minor/important/blocking so not a lot of levels. The LLM is discouraged from going overboard with `packaging` critiques, and especially with statements about build issues since it is reasoning about them from little input - it doesn't *do* a build. I'd love to be able to do a build within this process so the LLM could work from actual build logs rather than trying to follow a logic chain, which is especially fraught with false positives. What the LLM does have available to it: - Searchable Debian Policy - Searchable Debhelper man pages (all of them) - Other general man pages (by name, not all of them) - The unpacked package, with patches applied and very little else. It is running in a sandbox, so it can't look something up on the internet unless I create a special tool to let it do that. I really want to be able to do a full build of packages in the NEW queue so we can provide *reliable* early signals of this sort of thing as well as of whether they are repeatable builds, but until we have something like that I don't fully trust these signals about whether the build will or will not work - too often I've had a reply from the maintainer saying this is fine, usually because of some obscure debhelper behaviour the LLM didn't reason through correctly. > Note: I make archive rebuilds from time to time with nocheck build > profile, and report what I find here: > > https://bugs.debian.org/cgi-bin/[email protected];tag=ftbfs-nocheck-profile > > so if we can avoid adding new packages early to the "set of affected > packages", the better. I've added an issue for this: https://salsa.debian.org/dfsg-team/dfsg-omp-review/-/work_items/27 and it would be helpful if you can add any more useful clarifying information there that might help me explain to the LLM exactly how to differentiate this issue better. Thanks, Andrew McMillan -- ---------------------------------------------------------------------- Porirua, New Zealand +64 (27) 288 6741 https://andrew.mcmillan.net.nz Facts do not cease to exist because they are ignored. -- Aldous Huxley, "Proper Studies", 1927 ---------------------------------------------------------------------- -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
