cbqn: 0.8.0 -> 0.9.0

[Prince213]

Resolves #391350.

This PR removes sources.nix entirely by using fetchSubmodules.
It also moves the package to by-name (RFC 0140).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[sternenseemann]

I've created a PR with just the update (#400662) and will merge that as soon as CI passes, thanks. I think that change should be uncontroversial.

I don't really have an opinion on using fetchSubmodules, though actually using git for fetching can be slow and brittle – not sure. Maybe @AndersonTorres can describe why they implemented it as they did and whether it should or should not be changed?

I don't like moving cbqn to by-name, it doesn't really make sense for this sort of thing and makes the bootstrapping wiring-up in all-packages.nix even more confusing.

[sternenseemann]

If you remove the mkdir before, it can become

Suggested change

	cp -r build/singeliSubmodule/* build/singeliLocal/
	mv build/singeliSubmodule/ build/singeliLocal

Should also work for the other instances of this!

[AndersonTorres]

I don't really have an opinion on using fetchSubmodules, though actually using git for fetching can be slow and brittle – not sure. Maybe @AndersonTorres can describe why they implemented it as they did and whether it should or should not be changed?

Obscure things about reproducibility. I remember some specific, illustrative examples like the yuzu corpse.

• The issue of vendoring dependencies is an argument I employed against using fetchSubmodules.

• Further, there are caveats (somewhere around comments in Nixpkgs) about git not following certain assumptions, so that .git is a source of impurities. This is another reason to not rely on git metadata at all.

• Because of the above, I manually tracked these submodules and put them in their places, emulating the fetchSubmodules behavior.

[Prince213]

Thanks for the input.

The thoughts I have on fetchSubmodules is that we don't have any patch at the moment and that it seems to be unhappy with newer version of submodules (it will not build). Also we don't really use much git metadata and we have fixed input with hash as well, so probably no problems with reproducibility.

What do you think? @sternenseemann @AndersonTorres

[AndersonTorres]

I have no feelings on this.
Do it as you feel more comfortable.

[wegank]

cbqn is at 0.9.0 on master, please rebase.