I see that LLM use in Debian has escalated from "Don't tell me what tools _I_ can use" to sending "an LLM-based check of its licensing and packaging, run by the DFSG team using the Debian Inference service" for every new package. I don't think this even falls within the extremely broad parameters of the recent GR, since no human signed off on this message. This is not a request to convince me that this is good, actually.

@werdahias But but but... think of all the contributors we are loosing by not embracing LLMs like everybody else does -- come on it's 2026, go with the times! I'm looking fondly at the times when I had stuck my packages in NEW for half a year because they were inspected by humans only... @bremner

@werdahias If and when I receive such a review I will bounce it back with a request to have a human verify that the review is factually correct, per the spirit of the GR. @josch

@werdahias @bremner We probably agree that even if it were correct and even if it were faster, it would not be worth the cost. Yes, the lack of communication bugs me a lot as well. The "it's faster" argument also completely rubs me the wrong way because I'm not contributing to FOSS in general to be "productive" and increase the code I produce... Unfortunately, the buy-in into LLMs is successful especially because "produce more code" is such a popular metric for businesses...

@werdahias Part of the problem is the the DFSG team seems to have decided to take on a bunch of issues that have nothing to do with the DFSG. We already have lintian. I don't want an opaque LLM based replacement, and I particularly don't want it wielded by the gatekeepers to the archive. @josch

@werdahias @josch @bremner @bandali are you able to mark the LLM output as spam?

@bremner @werdahias @josch 💯

@bremner Link for the uninformed? I'm sure the major labs train their models to be super conscious of copyright concerns, of course (sarcasm).

@bremner That GR was a travesty.

@bremner Oh, I see from reading some of the responses that apparently there is no public announcement, and maintainers just get emailed after an upload? Do I understand that correctly?

@collinfunk yes

@bremner I find the entire concept of new processing increasingly idiotic. We have so many codebases with complete spdx headers in the code, why do we even need a maintained debian/copyright file for these? Instead of an llm these could be reliably auto-created by 30 lines of Perl...

@jmm @bremner and for upstreams that haven't done that work yet, it would be a better effort to contribute it there, as with most other metadata in debian/. I've long believed that any Debian data that isn't strictly about Debian specific integration, belongs to upstream patches

@josch @werdahias @bremner fuck this, FOSS is not a business…

@werdahias @josch @bremner yeah, I wrote "only" about 420 lines of actual code yesterday for something, but I did it carefully, mentally modelling everything, including thinking of reuse for the other scripts dealing with the on-disc structure (moving some to an include file even), adjusting the notes I did before writing during the writing with new details, and I may even add the 1% at the end that will make it reusable by Debian ca-certificates and submit it as a suggestion.

Key is not high amounts of code at high speed.

Key is concise, carefully thought-out, understandable code.

@bremner I haven't interacted much with the DSFG-NEW team (or Debian, really) since the GR, so I didn't really get what you mean. Are now NEW queue reviews completely automated?!

@jmm @bremner I agree that maintaining d/copyright when SPDX headers exist is pointless, but in a way it forces people to verify that the declared licensing terms from upstream are correct (or at least that's what it does to me). So yeah, d/copyright is a bit weird to have but I still see value in new processing

@tachi @bremner But how would I even be able to verify that? If upstream attaches a SPDX header to a given file, then all future contributions to that file also align with the originally declared license. And if a codebase retroactively applies SPDX headers, then it's the duty of the author of that patch to properly validate the license, but _once_ and there's no need to repeat that, especially not for a distro maintainer who has better things to do.

@tachi Here's a sample report

https://dfsg-new-queue.debian.org/reviews/openexr#assistant-report

These "minor" issues are basically like auto generated wishlist bugs. I'm pretty sure if I turned Claude loose on the BTS I would (should) be banned pretty quickly. I don't have to assume bad intentions to recognize a power imbalance between the DFSG-NEW team and people doing uploads. So I think there's a great deal of systematic pressure on people to engage with these reports (even if individual team members are not pushy about it), which means that the maintainer is doing the verification part that should have been done by the submitter.

@bremner wow, yeah, that's incredibly bad :(

I feel the DSFG-NEW team needs someone with more sensitivity to these dynamics, otherwise it risks being even worse than the defunct FTP team :/

@jmm There is precedence:

* https://sources.debian.org/src/fonts-iosevka/latest/debian/copyright.py
* https://sources.debian.org/src/ldraw-parts/2602%2Bds-1/debian/gencopyright.py
* https://salsa.debian.org/games-team/play.it-community/-/blob/c328696c4f5b82c363bad17ecef4133583d9d948/debian/copyright.sh

Unfortunately, these scripts which convert upstream machine readable copyright information into the d/copyright format were written by LLM-haters like me and @vv221 and now it is apparently fine to be 99% correct by using a slot machine that you cannot even repair when it does the translation incorrectly. I am (was?) in Debian because I love things to be 100% correct

@bremner

@bremner and as far as I can tell the result is passed on as-is to the package uploader — which manages to go against the recent GR’s outcome, which says “Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices.” I’ve had comments about missing RRR, missing Priority, use of debhelper 14, and a bunch of other things that give the impression the team don’t know what they’re doing ...

@bremner ... since of course they don’t disclose that the report is LLM-generated.

@skitt The version I received (via a team mailing list) was clear that it was an LLM generated report / email. Here is the body of the email corresponding to the report above (sorry for bad formatting, I think mastodon is just like that). You might be right that previous versions were also "LLM-assisted"; I don't know about that, but given the apparent LLM-enthusiasm of the team it would not surprise me. I also agree this goes against at least the spirit of the GR outcome.

-------------------------- Email text follows ---------------------------------------------------------------

Your upload of openexr 3.5.2+ds-1 to the NEW queue has had an automated review: an LLM-based
check of its licensing and packaging, run by the DFSG team using the Debian Inference service.
It is not a decision on the package, and - like other LLM-based work - it can be wrong.

It found 0 blocker, 0 important, 2 minor issues:

- [minor] [packaging] Six installed OpenEXR tools have no manual page
- [minor] [packaging] libopenexr-doc has stale sphinx/query doc Depends

You can read the full review here:

https://dfsg-new-queue.debian.org/reviews/openexr#assistant-report

Please look at it, and respond by visiting the link below (you'll be asked to authenticate
with Salsa first):

https://dfsg-new-queue.debian.org/llm-review/8ogmySuR5BPikth_HMzzvsLitrAVOUmn

There you may choose to reject the upload yourself, while you fix issues and re-upload, or add
comments to clarify or dispute the review. Comments are public, and in particular are shown to
the DFSG reviewer with the review. You may also use markdown in case you want to link to
further clarifying information.

If you have any questions, please reply to this e-mail and someone from the
team will respond.

@bremner ah right, in my case the comments I think were LLM-generated were mixed in with human-authored comments; see https://dfsg-new-queue.debian.org/reviews/nestopia/2.0.0-1/de00971d2e840afc32d9b3bb374f22481510d95cf50e3a6d168cd9a11027c2c3 and https://dfsg-new-queue.debian.org/reviews/qtea/0.1.1-1/325cb6fc90310078ff6250e40c609aefd5d9b9019cbc5cf2972888208303c163 (the rejection reasons were perfectly valid, they’re not the issue here).