fetchFrom{Forgejo,Codeberg}: init, treewide: fetchFromGitea -> fetchFromCodeberg, docs

[SigmaSquadron]

Closes #482855

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • 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.

[saltrocks]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 483216
Commit: 05ec691d4671e1b88cb5222e7223e01ce7ce4cab

---

x86_64-linux

✅ 1 package built:

• nixpkgs-manual

[SigmaSquadron]

Yes, logically this should be a zero-rebuild. The main review concern here is whether the implementation for fetchFromCodeberg isn't too terrible.

[gepbird]

Thanks!

I like this approach, the first time I encountered a codeberg source I was surprised there's no fetcher for it despite the platform being quite popular. It also feels weird to write fetchFromGitea for forgejo sources.

Grepped for domain = "codeberg.org", can you also migrate these to fetchFromCodeberg? I think a new commit would be preferable:

• pkgs/by-name/xr/xrsh/package.nix
• pkgs/applications/networking/browsers/librewolf/src.nix
• pkgs/by-name/go/gotosocial/package.nix
• pkgs/by-name/ka/katawa-shoujo-re-engineered/package.nix

In your last commit, what is the reason for the second sed call, shouldn't the first one catch trivial instances? I wonder if it can introduce other issues: what if a package has a codeberg source AND non-codeberg gitea source (e.g. a subpackage in the same file)?

for i in (rg 'fetchFromGitea \{\n *domain = "codeberg.org";' --multiline --files-with-matches)
    sed -z 's/fetchFromGitea {\n *domain = "codeberg.org";/fetchFromCodeberg {/g' $i > $i.tmp && mv $i.tmp $i
    sed -i 's/fetchFromGitea/fetchFromCodeberg/g' $i
end

(Slightly related: in another PR programs.forgejo-actions-runnermodule would be nice that acts as programs.gitea-actions-runner with programs.gitea-actions-runner.package = pkgs.forgejo-runner, what do you think?)

[SigmaSquadron]

Thanks for the review! The individual comments were addressed, and the treewide was updated.

Grepped for domain = "codeberg.org", can you also migrate these to fetchFromCodeberg? I think a new commit would be preferable:

* pkgs/by-name/xr/xrsh/package.nix

* pkgs/applications/networking/browsers/librewolf/src.nix

* pkgs/by-name/go/gotosocial/package.nix

* pkgs/by-name/ka/katawa-shoujo-re-engineered/package.nix

I've updated the treewide commit, since it had a conflict and adding these wouldn't be too much of a hassle.

In your last commit, what is the reason for the second sed call, shouldn't the first one catch trivial instances?

The reason is, as usual, because I'm bad at programming. I know I could probably have done it in a nicer way, but I couldn't be bothered for such a quick task.

I wonder if it can introduce other issues: what if a package has a codeberg source AND non-codeberg gitea source (e.g. a subpackage in the same file)?

Eval should catch edge cases like that, but I don't think we have any.

(Slightly related: in another PR programs.forgejo-actions-runnermodule would be nice that acts as programs.gitea-actions-runner with programs.gitea-actions-runner.package = pkgs.forgejo-runner, what do you think?)

I think it's a wonderful idea, and probably reasonably easy to implement given that options don't store their original path in their attributes. I'll attempt this in another PR.

[gepbird]

In your last commit, what is the reason for the second sed call, shouldn't the first one catch trivial instances?

The reason is, as usual, because I'm bad at programming. I know I could probably have done it in a nicer way, but I couldn't be bothered for such a quick task.

Now I realized: you wanted to replace the import at the top, in this case including the comma is safer:

    sed -i 's/fetchFromGitea,/fetchFromCodeberg,/g' $i

I wonder if it can introduce other issues: what if a package has a codeberg source AND non-codeberg gitea source (e.g. a subpackage in the same file)?

Eval should catch edge cases like that, but I don't think we have any.

I can never be too sure about that when working with FODs, just in case I quickly scrolled through the treewide.
There was a file with 2 gitea sources, but both was hosted on codeberg. Overall no issues in the diff!

[SigmaSquadron]

(Slightly related: in another PR programs.forgejo-actions-runnermodule would be nice that acts as programs.gitea-actions-runner with programs.gitea-actions-runner.package = pkgs.forgejo-runner, what do you think?)

I think it's a wonderful idea, and probably reasonably easy to implement given that options don't store their original path in their attributes. I'll attempt this in another PR.

#485596

[SuperSandro2000]

Are there any plans to backports this to make other backports easier and with fewer conflicts?

[nixpkgs-ci]

Backport failed for release-25.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.11
git worktree add -d .worktree/backport-483216-to-release-25.11 origin/release-25.11
cd .worktree/backport-483216-to-release-25.11
git switch --create backport-483216-to-release-25.11
git cherry-pick -x dcc52f0124398d37e1c10c5778dcbfa6ac3433dc adf7a4850b7d89c0658bdae2daff9680832680a7 a1c9639328fb90f894a726d6bca0896fab878b36 3562403503f705f700bcbd9b1c1bae1c6641f519

[SigmaSquadron]

Doing a manual backport as soon as I finish up with a package update