nixos/cosmic: use oo7 for Secret portal

[caniko]

Switch COSMIC to the Secret Service backend preferred by upstream COSMIC portal routing: oo7-portal first, with oo7-server available for user D-Bus activation. This keeps xdg-desktop-portal-gtk because upstream COSMIC still declares default=cosmic;gtk;.

GNOME keyring now defaults off for COSMIC, but users can temporarily opt back in with services.gnome.gnome-keyring.enable = true if they need access to old keyrings. Existing GNOME keyring data is preserved in place and is not automatically migrated.

nixpkgs-review-gha is running: https://github.com/caniko/nixpkgs-review-gha/actions/runs/28826584841

Generated with assistance from OpenAI Codex (GPT-5); reviewed before submission.

Things done

• 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.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[caniko]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 539086
Commit: 06c8448645eedab806523d2dbd6a0f184a8d897d (subsequent changes)
Merge: 47777458324c38da53c3c81c4d40a135c3f3e47b

Logs: https://github.com/caniko/nixpkgs-review-gha/actions/runs/28826584841

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

---

aarch64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

---

x86_64-darwin

✅ No rebuilds

---

aarch64-darwin

✅ No rebuilds

[thefossguy]

1. Let's keep gnome-keyring enabled until 26.11 goes EoL. I'd prefer lib.mkDefault (lib.versionAtLeast lib.version "27.05").
2. When gnome-keyring is enabled, lets display a warning that it will be disabled in 26.11 and that one should migrate to OO7 at their earliest convenience.

[nyabinary]

I think gnome keyring being deprecated now and then turned off on 26.11 would be fine though.

[thefossguy]

Totally optional but can you think of any tests related to OO7 that we can add to <nixpkgs/nixos/tests/cosmic/>?

[Pandapip1]

This should be predicated on stateVersion IMO

[nyabinary]

This should be predicated on stateVersion IMO

Perhaps only disabling gnome keyring should be predicated on stateVersion as opposed to this change altogether.

[Pandapip1]

Perhaps only disabling gnome keyring should be predicated on stateVersion as opposed to this change altogether.

IIUC only one service can bind to the secret service dbus path at any time, so that would race

[caniko]

Totally optional but can you think of any tests related to OO7 that we can add to <nixpkgs/nixos/tests/cosmic/>?

We could, but only if there is a testing gap introduced by nixos abstractions. I'd prefer to leave the testing to upstream.

Does gnomeKeyring have any tests?

[HeitorAugustoLN]

Existing GNOME keyring data is preserved in place and is not automatically migrated.

Isn't oo7 a drop-in replacement for gnome-keyring? I am pretty sure GNOME 51 Alpha is already using it

[HeitorAugustoLN]

This PR should also be built upon #526624 ideally

[Pandapip1]

Isn't oo7 a drop-in replacement for gnome-keyring? I am pretty sure GNOME 51 Alpha is already using it

If that's the case (and only if that's the case), then it doesn't need stateVersion.

[caniko]

P1 fixes:

• custom_node_path FileNotFoundError under systemd: regenerated use-writable-runtime-paths.patch against the 0.27.0 base. The --base-directory default now falls back to /var/lib/comfyui when both XDG_DATA_HOME and HOME are unset, so systemd units without User= no longer produce /.local/share/comfyui/custom_nodes.

• PYTHONPATH pollution: added --unset NIX_PYTHONPATH --unset PYTHONPATH to the makeBinaryWrapper call.

• comfy-aimdo aimdo.so loading: added addDriverRunpath postFixup so CUDA shared libraries are found at runtime.

Build fixes (0.27.0 migration):

• Added missing comfyui-workflow-templates-json and comfyui-workflow-templates-media-assets-01 to comfyui-workflow-templates dependencies (these are new subpackages in the 0.27.0 release).

• Fixed hash for comfyui-workflow-templates-json 0.1.1 and comfyui-workflow-templates-media-assets-01 0.1.0 (SRI values were stale from the version bump).

[nyabinary]

GNOME 51 Alpha

Well GNOME switched to it so I assume its the case https://download.gnome.org/sources/gnome-build-meta/51/gnome-build-meta-51.alpha.news

[Pandapip1]

Then fair enough, this doesn't need a stateVersion gate

[Pandapip1]

Empty comment to dismiss stale request changes review

[Pandapip1]

Actually yeah, this just looks fine given that

[nyabinary]

Closed in favor of #539810

[caniko]

@nyabinary, I am not sure how best to proceed here.

For transparency, my workflow is a mix of AI-assisted coding, AI-assisted engineering, and traditional manual work. I do make mistakes sometimes, as you have observed, and I am trying to handle those responsibly.

That said, I would like to avoid turning this into a tempest in a teapot. My understanding is that contributors are expected to follow the nixpkgs AI policies, and I believe I am doing that. If there are specific policy violations or concrete quality issues in this PR, I am happy to address them directly.

However, I do not think disliking my workflow is, by itself, a sufficient reason to shut down my PRs. If maintainers are going to block contributions on the basis of AI-assisted work, I think that needs to be enforced through clear policy and consistent process, not personal preference.

Could you point me to the appropriate place to raise this formally? I would like to either file a complaint, or open a broader discussion about how the AI policy is being interpreted and enforced in nixpkgs.

[DaRacci]

@caniko I think the reason this was closed was due to your seemingly blind usage of AI without any proper testing, and the fact you have a history of doing this.

As provided in that comment from nyabinary, the comments you post in replies to real humans are completely AI generated which frankly is despicable in my view, at the very least i would expect you to have an AI assist you in your reasoning and troubleshooting but when speaking to another person it comes off as dismissive to use a fully AI-generated response without putting your own voice into it.

And expanding on your insistence that you were following the NixOS AI guidelines, in some of your other clearly AI submitted pull requests, there is no notice of it being the work of an AI; You also consistently seem to not bother checking the work the AI is completing for you before submitting it for another person to waste their time sifting your shit.

I am a fairly large user of AI, I have recently started to have it spearhead some projects for me to get them off the floor but the amount of work I have as a reviewer and tester for those is not insignificant.

In summary this is already clearly stated in the guidelines for AI assisted contributions, which it seems you have clearly not read or have disregarded.

Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a responsible person in the loop who is accountable for that contribution and reviews it before submission, and must transparently disclose any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.

[caniko]

@DaRacci, I really want to work with you on this to get my reputation restored.

I believe there is unfair treatment, and I have the following points I would like to raise:

• My past work where it may have been interpreted as "blind" use of AI was before I was made aware of the AI policies, getting used to this decorum has taken some time for me, but I believe I have acclimated. Most of my PRs have a positive impact on the community.
• No communication was made by any maintainer before shutting down this PR, I also partook in every discussion raised in this PR using emojis and text where I saw fit.
• No real evidence where this PR violates the policy have been produced.
• nixos/cosmic: migrate from gnome-keyring to oo7 #539810 is marked as ready, yet I have already found breaking bugs. This PR works on my machine, and another test-flake nixos. I fail to see the discrepancy in quality, and need for transferring to another PR.

I expect us to produce some level of humanity when shutting down each other's work, I can't see that here.

[DaRacci]

@caniko I think i speak in general for the maintainers, but we are more than happy to have you contribute, just without causing burdens or undue work for others.

My issues I've risen about your pull requests is largely because of the burden on others to validate your work; If you properly validate and test your AI assistants outputs, and follow the policies, I don't think anyone will have an issue.

I also understand and agree that the closing without any communication was probably a bit preemptive, nor does this PR violate the policy; However I also agree that instead of working on this fresh PR we should of been building off the existing one that this was closed in favour for.

If you've found issues with the new PR happy to have you take part in reviewing it and adding feedback.

[caniko]

@DaRacci, I appreciate it, and I can empathize with the frustration that led us here! Let us move forward, have a nice Friday and weekend.