| 2 Jun 2025 |
 kdn | update:
rpi4 finished building subpackage client and started management of netbird in 4 minutes- router still builds subpackage client after 8 minutes
| 16:32:19 |
| kdn | yep, router built in 28 minutes, rpi in 8.5 | 17:25:48 |
 K900 | Some weird I/O bottleneck? | 17:27:41 |
| kdn | I do suspect something like this, but got no clue how to verify. I'm running this on AMD CPUs and Intel N6005, it also seems tightly related to nix build environment, it builds perfectly fine as a standalone project outside Nix | 17:31:24 |
| kdn | I'd be up for any pointers on how to analyze the situation | 17:50:23 |
| K900 | perf top? | 17:54:58 |
| 4 Jun 2025 |
|  @hedgemage:unredacted.org joined the room. | 19:23:35 |
 @awwpotato:envs.net | having some trouble in https://github.com/NixOS/nixpkgs/pull/414070, I'm trying to get the version command to work correctly but it's still not despite me adding the ldflags from the goreleaser | 22:05:15 |
| 5 Jun 2025 |
 @s_r:matrix.org | What workflow do you typically use to develop in a nix shell? I have some minor trouble with the dependencies:
If I just go in a dev shell (i.e. with nix develop) and run go build it will fail because it expects the dependencies in vendor.
- I can run
go mod vendor and then things work.
- Or I can run
runPhase configurePhase and get the vendor directory from nix, that also works.
The other minor issue is that I need to change the vendorHash every time I change a dependency, or I'd get a stale ~vendor~ directory and nix build fails (which took me a while to figure out, because I was doing go mod vendor to develop in my shell.
From this experience, it seems that running the configure phase is a better approach, but it contradicts a bit what me and @jrick discussed a few days ago, from which I understood (perhaps wrongly) that using go tools directly was preferred.
Curious about what other people are doing :)
| 04:46:00 |
 Alison Jenkins | Has anyone got a decent solution to build go projects with private dependencies? | 05:03:22 |
 diamond (it/its) | how are you making the devShell? if you use it directly via a package, that's gonna happen | 05:55:30 |
| diamond (it/its) | when you're packaging, you won't really be able to avoid the vendorHash unless you actually automate it away | 05:55:51 |
| diamond (it/its) | it's not really because of go mod vendor (if anything, vendor actually frees you from needing to update that hash) | 05:56:11 |
| diamond (it/its) | i asked this on the discourse 6 years ago! https://discourse.nixos.org/t/git-buildgomodule-private-repositories/5167 | 05:56:38 |
| diamond (it/its) | browse to your heart's content; there's no 1 good solution afaict | 05:56:48 |
 Paul Meyer (katexochen) | So the first issue here is that the embedding doesn't work as the path to the var is wrong.
You can check with strings result/bin/az-pim-cli | grep v1.6.1
The following patch fixes it to point to the version var in cmd package:
diff --git a/pkgs/by-name/az/az-pim-cli/package.nix b/pkgs/by-name/az/az-pim-cli/package.nix
index 4ff1e44032e7..b27dda9ffaad 100644
--- a/pkgs/by-name/az/az-pim-cli/package.nix
+++ b/pkgs/by-name/az/az-pim-cli/package.nix
@@ -29,7 +29,7 @@ buildGoModule (finalAttrs: {
ldflags = [
"-s"
"-w"
- "-X=main.version=v${finalAttrs.version}"
+ "-X=github.com/netr0m/az-pim-cli/cmd.version=v${finalAttrs.version}"
];
The other thing is that the embedded values will only be used if there is no debug.BuildInfo available, as stated here: https://github.com/netr0m/az-pim-cli/blob/e4bb4d7617a0561ae2fad3fb00c1e12d1548d5fc/cmd/version.go#L50-L53
And as the doc for that func say, it is will always available when build with module support. So you would need to patch that out for the program to actually print the embedded version.
| 06:02:16 |
| @s_r:matrix.org | I do nix develop on the package that I'm building, with the working path being the source of that package | 06:43:58 |
| diamond (it/its) | yeah don't do that; just use a regular devShell containing your dependencies | 06:44:24 |
