I recently saw a Claude Co-authored-by in a PR:
staging ← someonewithpc:gtk4-dmabuf-fix
opened 06:42PM - 09 Sep 26 UTC
Bumps gtk4 to 4.22.5 ([NEWS](https://gitlab.gnome.org/GNOME/gtk/-/blob/4.22.5/NE… WS)), which includes the two fixes this derivation was carrying as patches, so both are dropped:
- `fix-32bit-VkImage-null.patch`, upstream [!9989](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9989)
- the munmap() fix for the dmabuf format table, upstream [!10305](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/10305) (commit [a8a5692c](https://gitlab.gnome.org/GNOME/gtk/-/commit/a8a5692ce3c334672ac325cf8f1257a138843bf6))
The munmap() fix is why this PR exists. `linux_dmabuf_format_table()` called `munmap()` on a heap-allocated struct instead of the actual mapping while releasing the previous dmabuf feedback format table. `munmap()` normally rejects the misaligned address silently, but when `malloc()` returns a page-aligned chunk it succeeds and unmaps live heap, and the next `g_clear_pointer()` in `linux_dmabuf_done()` segfaults. Any GTK4 Wayland client is affected when its compositor re-sends `zwp_linux_dmabuf_feedback_v1.format_table` during the client's lifetime; Hyprland does this on every monitor hotplug or DisplayPort link retrain. Confirmed against a real crash via coredump and backtrace (frame #0: `linux_dmabuf_done` in `libgtk-4.so.1`).
History: this PR originally backported a8a5692c as a patch; 4.22.5 was tagged in the meantime and the reviewer asked for a bump instead.
Targeted at `staging`, since gtk4 is a mass rebuild.
Verified gtk4 itself builds on x86_64-linux with the bump. I have not re-verified the crash fix on 4.22.5 yet: getting it onto my desktop means rebuilding most of the system against staging, which takes a while. I will report back once that is done and it has been running for a bit.
## Things done
- Built on platform:
- [x] x86_64-linux
- [ ] aarch64-linux
- [ ] aarch64-darwin
- Tested, as applicable:
- [ ] [NixOS tests] in [nixos/tests].
- [ ] [Package tests] at `passthru.tests`.
- [ ] Tests in [lib/tests] or [pkgs/test] for functions and "core" functionality.
- [ ] Ran `nixpkgs-review` on this PR. See [nixpkgs-review usage].
- [ ] Tested basic functionality of all binary files, usually in `./result/bin/`.
- Nixpkgs Release Notes
- [ ] Package update: when the change is major or breaking.
- NixOS Release Notes
- [ ] Module addition: when adding a new NixOS module.
- [ ] Module update: when the change is significant.
- [x] Fits [CONTRIBUTING.md], [pkgs/README.md], [maintainers/README.md] and other READMEs.
- [x] Follows the [automation/AI policy].
[NixOS tests]: https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests
[Package tests]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests
[nixpkgs-review usage]: https://github.com/Mic92/nixpkgs-review#usage
[CONTRIBUTING.md]: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md
[automation/AI policy]: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#automationai-policy
[lib/tests]: https://github.com/NixOS/nixpkgs/blob/master/lib/tests
[maintainers/README.md]: https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md
[nixos/tests]: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests
[pkgs/README.md]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md
[pkgs/test]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/test
---
Disclosure per the [automation/AI policy]: I identified, applied, and tested the original backport myself (build, reverse-dependents, daily use). Claude Code (Claude Sonnet 5, then Claude Opus 5 for the bump) assisted with the derivation edit, this PR description and the commit message, which I reviewed and edited before submitting.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
While I have nothing against use of AI in development (I am actually in favor of it!), this does violate the (excellent!) nixpkgs Automation/AI policy .
Should we add linting into CI to detect these and issue a PR failure, and if so, where? Do we have any other commit message lints that this check could be added to?
I’d be happy to make this change, I just need a few pointers as to where I would put this.
7 Likes
My guess is that people will be opposed to this for the reason described in the original PR adding the policy :
Since LLM‐based AI tools use Co-authored-by:attribution by default, we think that using a different format will serve as a brown M&M test and assist with triage. A commit that contains such a tool in Co-authored-by: but not Assisted-by: is, by definition, one that did not follow the policy and can be closed, potentially automatically.
I’d expect this to go similarly to previous suggestions about adding an AGENTS.md file to the repo.
3 Likes
It does not have to fail the PR, it could close it outright. Or we could not implement this at all! I was just wondering because it seemed to have gone unnoticed in that PR.
4 Likes
Ah fair point! For some reason my eyes completely glossed over that part.
2 Likes
I think this would fit well in ci/github-script/lint-commits.js .
4 Likes
PR to there in case anyone wants to review:
master ← bitbloxhub:push-wlmyrutmsxpz
opened 11:41PM - 23 Sep 26 UTC
## Things done
Reject banned AI attribution emails unless commits include an … Assisted-by trailer conforming to CONTRIBUTING.md. Comment on and close violating pull requests from the trusted workflow.
Feel free to close if not wanted.
More context: https://discourse.nixos.org/t/should-we-add-ai-tool-co-authored-by-linting-to-ci/80177
- Built on platform:
- [ ] x86_64-linux
- [ ] aarch64-linux
- [ ] aarch64-darwin
- Tested, as applicable:
- [ ] [NixOS tests] in [nixos/tests].
- [ ] [Package tests] at `passthru.tests`.
- [ ] Tests in [lib/tests] or [pkgs/test] for functions and "core" functionality.
- [ ] Ran `nixpkgs-review` on this PR. See [nixpkgs-review usage].
- [ ] Tested basic functionality of all binary files, usually in `./result/bin/`.
- Nixpkgs Release Notes
- [ ] Package update: when the change is major or breaking.
- NixOS Release Notes
- [ ] Module addition: when adding a new NixOS module.
- [ ] Module update: when the change is significant.
- [x] Fits [CONTRIBUTING.md], [pkgs/README.md], [maintainers/README.md] and other READMEs.
- [x] Follows the [automation/AI policy].
[NixOS tests]: https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests
[Package tests]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests
[nixpkgs-review usage]: https://github.com/Mic92/nixpkgs-review#usage
[CONTRIBUTING.md]: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md
[automation/AI policy]: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#automationai-policy
[lib/tests]: https://github.com/NixOS/nixpkgs/blob/master/lib/tests
[maintainers/README.md]: https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md
[nixos/tests]: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests
[pkgs/README.md]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md
[pkgs/test]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/test
2 Likes