buildNpmPackage: init #189539

winterqt · 2022-09-03T02:20:31Z

Description of changes

This PR introduces buildNpmPackage, a new builder for npm-based projects. Alongside it is fetchNpmDeps, a new fetcher for npm dependencies inspired by fetchYarnDeps in that it constructs a cache for npm to install from using a small purpose-built fetcher.

I've tested this with both npm 8 (shipped in Node 18, the latest version) as well as npm 6 (shipped in Node 14). The cache format has been stable for 5 years, which makes me confident in using it as an output for a FOD.

I believe this is an improvement in terms of reproducibility over existing solutions to this issue, most notably #128749. This is notably more reproducible for a few reasons, but the main one is that it's guaranteed to have the same output across systems. This is because npm allows installing dependencies only on a specific platform, which obviously causes irreproducibility.

~~npmInstallHook depends on npm/cli#5430 when using packages with {pre,post}pack scripts.~~ This will be released in npm 9, but I'll need to backport it to Node versions that don't include it.

Things done

winterqt · 2022-09-03T02:21:04Z

pkgs/build-support/node/build-npm-package/default.nix

+  # TODO: how do we expose these like Rust? `npmHooks`?
+  inherit (callPackage ./hooks { inherit nodejs; }) npmConfigHook npmBuildHook npmInstallHook;


I'm not really sure what the best name for exposing the hooks would be, which is why I didn't do it here.

pkgs/build-support/node/build-npm-package/default.nix

winterqt · 2022-09-03T02:23:56Z

pkgs/build-support/node/fetch-npm-deps/default.nix

+
+      outputHashMode = "recursive";
+      outputHash = hash;
+    } // args); # TODO: removeAttrs? what attrs?


I saw this in fetchCargoTarball -- what's the benefit of removing the args it does? Should we remove any here?

winterqt · 2022-09-03T02:24:36Z

pkgs/servers/jellyfin/web.nix

@@ -62,6 +34,5 @@ stdenv.mkDerivation rec {
    homepage = "https://jellyfin.org/";
    license = licenses.gpl2Plus;
    maintainers = with maintainers; [ nyanloutre minijackson purcell jojosch ];
-    platforms = nodejs.meta.platforms;


Note to self: set this by default in buildNpmPackage.

winterqt · 2022-09-03T02:25:55Z

pkgs/top-level/all-packages.nix

@@ -4112,7 +4112,9 @@ with pkgs;

  jellyfin-mpv-shim = python3Packages.callPackage ../applications/video/jellyfin-mpv-shim { };

-  jellyfin-web = callPackage ../servers/jellyfin/web.nix { };
+  jellyfin-web = callPackage ../servers/jellyfin/web.nix {
+    buildNpmPackage = buildNpmPackage.override { nodejs = nodejs-14_x; };


I should probably comment why this is done (Jellyfin's web client uses lockfile v1 at this tag, which doesn't work well on newer versions with our setup).

Maybe I can also add a hint for this somewhere, based on the version? Or maybe just in docs.

Maybe it'd be better to have an attribute along the lines of nodeJs which defines the version used.

That would make it more clear from the child derivation which version is used, and make changing it (upon a package update or something) more intuative.

~~I'm confused -- what do you mean by this, where would that attribute be located? Can you provide an example of what that API would look like?~~

Ah, I see what you mean -- define the Node copy used in the arguments to the builder. My only issue with that is that we don't do it for any other language, see rustPlatform and buildGo117Module. We should probably strive for consistency with other languages, in this case. How about at least defining aliases like buildNpmPackageNode14 (I can't come up with any clear naming, but you get what I mean), so overrides for common cases don't have to be done manually?

Ah right, I forgot other builders do it like that. Creating buildNpmPackage14 etc sounds like a good idea 👍

Maybe buildNpm14Package would be better naming? I'm not entirely sure.

winterqt · 2022-09-03T02:27:10Z

pkgs/build-support/node/fetch-npm-deps/default.nix

+    { name ? "npm-deps"
+    , src ? null
+    , srcs ? [ ]
+    , patches ? [ ]
+    , sourceRoot ? [ ]
+    , hash ? ""
+    , ...
+    } @ args: stdenv.mkDerivation ({


I'm not sure why these are set to their default/empty values in fetchCargoTarball... I did it here anyways, though I'm guessing they can probably be removed (both here and in fetchCargoTarball).

I think { foo ? {} } @ args: doesn't keep the {} for foo, args removes the default.

winterqt · 2022-09-03T02:41:41Z

A npmTestHook which runs npm test should probably be added.

winterqt · 2022-09-03T02:45:26Z

pkgs/build-support/node/fetch-npm-deps/src/main.rs

+    let lock: PackageLock = serde_json::from_str(&fs::read_to_string(args.next().unwrap())?)?;
+
+    let out = PathBuf::from(args.next().unwrap()).join("_cacache");
+
+    let print_hash = args.next().is_some();


Adding a help message would be good, considering this will be used by update scripts.

winterqt · 2022-09-03T02:46:43Z

pkgs/build-support/node/fetch-npm-deps/default.nix

+    , srcs ? [ ]
+    , patches ? [ ]
+    , sourceRoot ? [ ]
+    , hash ? ""


Should support for sha256 be added, to match other fetchers? (As well as adding npmDepsSha256 to buildNpmPackage.)

Yes, i think that's a good idea.

IvarWithoutBones

This PR is looking great, I'm very happy to see npm build support being improved this substantially :)

Left you some comments/suggestions.

pkgs/build-support/node/build-npm-package/hooks/npm-config-hook.sh

IvarWithoutBones · 2022-09-03T17:38:20Z

pkgs/build-support/node/build-npm-package/hooks/npm-config-hook.sh

+    echo "Finished npmSetupHook"
+}
+
+configurePhase=npmSetupHook


Think its a good idea to make this overridable.

Suggested change

configurePhase=npmSetupHook

if [ -z "$configurePhase" ]; do

configurePhase=npmSetupHook

fi

Same goes for the other phases.

This is the only phase that that wasn't added -- I'm not sure when you'd want to override this when using buildNpmPackage (and duplicate the effort in the phase), since it sets up everything, but for consistency I guess that makes sense?

It might be worth adding corresponding dont options (or options that act as that) to all these phases as well (which I only currently do in two of them).

Though, now that I think about it, having both conditionals creates confusion:

When using buildNpmPackage, setting a custom configurePhase will cause the npm phase not to be used

When using this hook on its own, why would you set dontNpmConfigure instead of just... not including the hook?

I don't know, I'm confused. Cargo does this in its build hook, and I don't really see why both are needed.

@jonringer What do you think about this, as the person who added these options in #114716? It seems like these options don't really provide much benefit when hooks are used properly -- maybe I'm missing something?

It might be worth adding corresponding dont options (or options that act as that) to all these phases as well (which I only currently do in two of them).

I definitely agree, that's the most consistent with other builders as well AFAIK. Can't hurt to have a mechanism to disable these when using buildNpmPackage :)

When using buildNpmPackage, setting a custom configurePhase will cause the npm phase not to be used

Yes, which might be preferable in some scenarios. That way you can have complete control over the build process, you can override the phase with custom behaviour that produces a similar result yourself.

When using this hook on its own, why would you set dontNpmConfigure instead of just... not including the hook?

That does seem useless yeah, I can't imagine any scenario you'd do that.

Can't hurt to have a mechanism to disable these when using buildNpmPackage

To be clear, what I mean is that all of these should be disabled if a custom phase is already set -- having dont options is useless as long as those conditionals exist.

pkgs/build-support/node/build-npm-package/hooks/npm-config-hook.sh

IvarWithoutBones · 2022-09-03T18:04:35Z

pkgs/build-support/node/fetch-npm-deps/default.nix

+    , srcs ? [ ]
+    , patches ? [ ]
+    , sourceRoot ? [ ]
+    , hash ? ""


Yes, i think that's a good idea.

IvarWithoutBones · 2022-09-03T18:06:03Z

pkgs/build-support/node/fetch-npm-deps/default.nix

+    { name ? "npm-deps"
+    , src ? null
+    , srcs ? [ ]
+    , patches ? [ ]
+    , sourceRoot ? [ ]
+    , hash ? ""
+    , ...
+    } @ args: stdenv.mkDerivation ({


I think { foo ? {} } @ args: doesn't keep the {} for foo, args removes the default.

pkgs/build-support/node/fetch-npm-deps/default.nix

IvarWithoutBones · 2022-09-03T18:11:15Z

I just saw this is still marked as a draft, it appears i got a bit excited with the review 😅

Hope you dont mind

winterqt · 2022-09-03T18:43:41Z

I just saw this is still marked as a draft, it appears i got a bit excited with the review 😅

These are the kind of reviews I want, hah -- these'll get it ready to actually be merged.

winterqt · 2022-09-04T04:48:05Z

@IvarWithoutBones I've migrated to jq -- that wasn't as bad as I thought.

I can't respond to some of your comments for whatever reason... any clue why? This is all I see:

These look like responses to my other comments, but GitHub... doesn't properly show them as responses? 🧐

yu-re-ka

I won't have the spoons to look at this in detail anytime soon.

I really like the overall design of the fetcher, it is similar to fetchYarnDeps which is already proven, just for npm. Much less risks for FOD reproducibility compared to running npm ci in an FOD.

Doing the second part - buildNpmPackage - right is pretty hard though. I feel like Javascript builds don't really match the stdenv model with its phases well. I wonder if the fetcher could be useful already without a specialized build environment, or just with an npm install hook. This could reduce the scope of this PR a lot.

Anyways, thanks for working on this!

yu-re-ka · 2022-09-04T09:47:34Z

Oh, there is a critical feature for helping debug FOD issues that we have in fetchYarnDeps, and I'd also like to see here:

Copy the package-lock.json to the FOD output.
In npmInstallHook, compare the package-lock.json from the cache FOD to the package-lock.json present in the working directory.
If it doesn't match, warn the user that they might have forgotten to update the FOD hash and don't even attempt to use the cache.

IvarWithoutBones · 2022-09-04T15:59:54Z

Doing the second part - buildNpmPackage - right is pretty hard though. I feel like Javascript builds don't really match the stdenv model with its phases well.

Do you have an example as to what could cause problems with our stdenv's phases? I'm not very familiar with Javascript, but the current implementation looks like it fits in fairly well.

I wonder if the fetcher could be useful already without a specialized build environment, or just with an npm install hook. This could reduce the scope of this PR a lot.

I do think using just the fetcher would be more work in the end. Packages could be refactored to use it but would still end up having a fair bit of code duplication. They would have to be refactored again once buildNpmPackage gets merged.

The added complexity of the configure and build hooks is fairly small, I'd say it is definitely worth trying to get those additions merged as well if we're gonna include the install hook.

I do think reducing the scope of this PR is something that needs to happen though. In my opinion we should drop the commits converting packages to this new builder. Those will all need to be reviewed by the individual packages maintainers, which will greatly increase the time and care needed to get this merged.

Without those changes I think the diff is very reasonable.

IvarWithoutBones · 2022-09-04T16:03:20Z

@IvarWithoutBones I've migrated to jq -- that wasn't as bad as I thought.

Neat, this looks a lot nicer IMO :)

I can't respond to some of your comments for whatever reason... any clue why? This is all I see:

These look like responses to my other comments, but GitHub... doesn't properly show them as responses? 🧐

I think that's because I was responding to comments you posted in my review. Github just shows my one comment but doesn't display any additional context or let you reply in that case. It's kinda weird. If you scroll up to your original comment you should be able to reply.

winterqt · 2022-09-04T17:53:39Z

Doing the second part - buildNpmPackage - right is pretty hard though. I feel like Javascript builds don't really match the stdenv model with its phases well.

Can you provide an example as to what you mean?

I feel like the default phases I have here are pretty representative of what projects that use npm do:

configurePhase: installs dependencies
buildPhase: runs a build script
installPhase: npm pack + wrapping binaries

Of course, these can always be overridden by packages when needed, but I feel like these are good defaults.

winterqt · 2022-09-05T03:41:57Z

Copy the package-lock.json to the FOD output.

This is already done, by the way. :)

DavHau · 2022-10-26T09:41:42Z

The cache format has been stable for 5 years, which makes me confident in using it as an output for a FOD.

Still, putting complex logic inside an FOD always comes with some risk. If at any time, there appears to be a bug in your fetcher, you might not be able to fix it without breaking peoples hashes. Also, adding features later might be hard, because those must never change the output for existing users.

It would be good if critical inputs, like the rust code of the fetcher, would trigger a re-build of the FOD once changed.
I think that can be achieved, by hashing the store path names of these inputs via builtins.hashString and putting that hash into the name of the FOD.

winterqt · 2022-10-26T10:53:55Z

It would be good if critical inputs, like the rust code of the fetcher, would trigger a re-build of the FOD once changed.

I already do this for a cherry-picked set of test cases, which will be run automatically by OfBorg whenever the code is changed (see here).

winterqt · 2022-10-27T00:34:17Z

Hi all.

This push addresses a majority of comments surrounding the docs and flags, as well as fixes using old lockfiles with modern npm. As such, I've marked this PR as ready for review.

I still need to find a clean way to make a npmSourceRoot -- just not sure what to name it. This option would allow specifying a path to cd to, where the package-lock.json is. Thoughts welcome.

For future reference: that one Nix test is failing even when marked as flaky. Triggered a re-run.

dit7ya · 2022-11-01T15:24:40Z

I am super excited about this getting merged to nixpkgs. Thank you so much for this amazing work! How hard do you think it would be to write something like this but for the pnpm package manager (which uses a pnpm-lock.yaml lockfile)? I can try on my own if you have some pointers.

happysalada · 2022-11-09T15:35:48Z

I'm also excited to try this tbh, this might need more work, but I think it's ready for testing, we can add subsequent PRs later.

winterqt · 2022-11-09T15:44:32Z

I would appreciate you having asked me if this was acceptable to be merged, @happysalada. I was waiting on some reviews. Maybe I should have just kept this as a draft? 😕

happysalada · 2022-11-09T16:10:48Z

My bad, there usually isnt a lot of action on some MRs, i didnt want to let this go to waste.

Lets keep the discussion going here to see if any changes are requested. Ill be sure to ask you before a merge on any follow ups

winterqt · 2022-11-09T16:24:11Z

My bad, there usually isnt a lot of action on some MRs

Please be more diligent in reading the (most recent) discussion.

i didnt want to let this go to waste.

I don't see what you mean? This would have been merged in the next few weeks. There is still active interest in it. It wouldn't have gone to waste in any circumstance.

happysalada · 2022-11-09T16:44:10Z

There were several previous attempts at this that just died out after inactivity.

Its often quite hard to know if something will just die or if there is still legitimate interest.

Being eager about this i didnt read the comments well enough.

Please accept my apology for merging too early.

fricklerhandwerk · 2022-11-09T19:51:14Z

We can still revert and re-open, to avoid locking users into an unfinished API. Just sad to lose some context of then discussion. It's your PR @winterqt, what do you prefer?

delroth · 2022-11-09T23:29:09Z

FWIW I would not have found this if it wasn't merged today, and it was exactly what I needed for a new package (etherpad-lite) that just wasn't going to work with node2nix. Leaving some feedback here from my experiments, lmk if you'd rather collect this somewhere else. Ordered from most important (bugs -> missing features) to least important (docs/confusion -> notes):

I think there's an issue with OldPackage -> Package conversion where a dependency with bundled: true (and thus no resolved/integrity) can take precedence on a dependency declaring resolved/integrity, which causes packages to be missing from cache. I've hack-patched this locally in the Cargo code by skipping OldPackage objects with bundled: true, and it seems to work. You can check for fast-deep-equal in etherpad-lite's package-lock.json for an example.
If a dependency's version is a git URL (e.g. "https://github.com/mapbox/node-sqlite3#593c9d498be2510d286349134537e3bf89401c4a") npm install tries to use git and contact the remote (in the main derivation, not the fixed output deps one):
```
Installing dependencies
npm ERR! Error while executing:
npm ERR! /nix/store/86vv52z14rp30rdw0jpyadspf4ii4psb-git-2.38.1/bin/git ls-remote -h -t https://github.com/mapbox/node-sqlite3.git
npm ERR!
npm ERR! fatal: unable to access 'https://github.com/mapbox/node-sqlite3.git/': Could not resolve host: github.com
```
Using "codeload.github.com" URLs in the package-lock.json fixes that, but I'm not sure why :)
The current npm-install-hook does not work with npm v6, it doesn't support --omit. Instead it's very confused at the "dev" on the command line and tries to ask the registry about it :P
```
npm ERR! code ENOTCACHED
npm ERR! request to https://registry.npmjs.org/dev failed: cache mode is 'only-if-cached' but no cached response available.
```
Doing instead NODE_ENV=production npm prune should be equivalent and work on both v6 and v8.
The npm prune seems to have another weird issue where it can't find something from the cache which worked fine for all prior npm invocations. In my case:
```
npm ERR! request to https://codeload.github.com/mapbox/node-sqlite3/tar.gz/593c9d498be2510d286349134537e3bf89401c4a failed: cache mode is 'only-if-cached' but no cached response available.
```
For now I've disabled the "npm prune" until I can figure out what's going on. This happens to also be a package that needs to be node-gyp built, so maybe this has something to do with it.
fetchNpmDeps does not currently handle URLs like "github:user/repo#rev" which are apparently valid for npm. I worked around this with a patch to rewrite these to "https://github.com/user/repo#rev" in the src's package-lock.json, but the Rust code should likely take care of that instead.
I hit this in the npm ci phase:
```
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
npm WARN old lockfile
npm WARN old lockfile This is a one-time fix-up, please be patient...
```
Which obviously fails because this is not in the fixed output derivation anymore. I worked around this by overriding nodejs = nodejs-14_x; but I wonder if this could be handled better (either by doing the requisite package-lock massaging in the fixed output derivation, or better diagnostics/error messages).
nativeBuildInputs = [ python3 ]; needs to be manually added if a package requires a node-gyp build. I don't know if that's good or bad or just needs to be documented, just making a note of it in case it's not a deliberate decision.
The error message when npm build fails should likely mention dontNpmBuild, I had to dig it up from the hook's source code. That should probably be more documented.
This new buildNpmPackage seems like it completely obsoletes applications/version-management/sourcehut/fetchNodeModules.nix by doing the same thing better :-) Yay for less custom "frameworks" in nixpkgs.

I'm super excited to see something making nodejs/npm app packaging in nixpkgs better! Let me know if any of my previous points are unclear and if I can help with repro or anything. https://gist.github.com/delroth/e7b67c8cc514a9de62f6c53656d1c96a is my current draft package with which I found these issues :)

winterqt · 2022-11-10T03:45:00Z

@happysalada It's alright.

@fricklerhandwerk I'm going to keep it like this, but I'd really appreciate a review of the documentation (as you didn't respond to my previous request for one). I want it to be ~perfect before branch-off/before 21.11, hopefully.

@delroth I've addressed your issues in #200470, but I also wanted to comment on a few things that we didn't fix in #dev or the linked PR:

nativeBuildInputs = [ python3 ]; needs to be manually added if a package requires a node-gyp build. I don't know if that's good or bad or just needs to be documented, just making a note of it in case it's not a deliberate decision.

This was deliberate. I don't see a reason for packages that don't use node-gyp to needlessly depend on Python 3 (yay, closure size).

This new buildNpmPackage seems like it completely obsoletes applications/version-management/sourcehut/fetchNodeModules.nix by doing the same thing better :-) Yay for less custom "frameworks" in nixpkgs.

:) I'll get this switched over.

I'm super excited to see something making nodejs/npm app packaging in nixpkgs better!

❤️ Yeah, me too.

pkgs/build-support/node/build-npm-package/hooks/npm-install-hook.sh

nixos-discourse · 2022-11-10T23:32:36Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/announcing-js2nix-scale-your-node-js-project-builds-with-nix/23111/8

dhess · 2022-11-22T16:00:24Z

Thanks for this. Sorry if I'm missing something obvious, but if I'd like to use this not just to package someone else's Node package for Nix, but also to develop/maintain my own, how does one get a Nix shell with the package's dependencies in it?

For example, if I've got a Node package in a git repo, and I'd like to use buildNpmPackage to build it and test it using Nix, how would I go about creating a Nix shell for the package such that I could do:

% nix develop
...
bash-5.1$ npm build

where all the Node dependencies needed for the npm build step are either copied or symlinked to ./node_modules?

winterqt commented Sep 3, 2022

View reviewed changes

winterqt requested a review from yu-re-ka September 3, 2022 02:27

ofborg bot added 8.has: clean-up 8.has: package (new) labels Sep 3, 2022

winterqt mentioned this pull request Sep 3, 2022

fetchNodeModules: init #128749

Closed

11 tasks

ofborg bot requested review from nyanloutre, minijackson, jojosch and purcell September 3, 2022 02:31

ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 labels Sep 3, 2022

winterqt commented Sep 3, 2022

View reviewed changes

IvarWithoutBones requested changes Sep 3, 2022

View reviewed changes

winterqt force-pushed the npm-ng branch from f973fd7 to f1d702e Compare September 4, 2022 04:45

winterqt force-pushed the npm-ng branch from f1d702e to 508bbb5 Compare September 4, 2022 05:08

yu-re-ka reviewed Sep 4, 2022

View reviewed changes

winterqt force-pushed the npm-ng branch from 508bbb5 to 016efab Compare September 5, 2022 03:59

winterqt removed request for purcell, jojosch, minijackson and nyanloutre September 5, 2022 04:00

winterqt force-pushed the npm-ng branch 2 times, most recently from 8fc8ac2 to 90250e2 Compare October 27, 2022 00:30

winterqt marked this pull request as ready for review October 27, 2022 00:32

winterqt requested review from fricklerhandwerk and infinisil October 27, 2022 00:34

winterqt force-pushed the npm-ng branch from 90250e2 to 7cf9d25 Compare October 27, 2022 02:34

buildNpmPackage: init

c95adb6

winterqt force-pushed the npm-ng branch from 7cf9d25 to c95adb6 Compare October 28, 2022 00:12

huantianad mentioned this pull request Nov 7, 2022

tetrio-desktop: cleanup, fix GApps wrapping, add tetrio-plus option #199948

Merged

13 tasks

happysalada merged commit 1672290 into NixOS:master Nov 9, 2022

22.11 Blockers automation moved this from In progress to Done Nov 9, 2022

winterqt deleted the npm-ng branch November 10, 2022 03:45

dotlambda mentioned this pull request Nov 10, 2022

deltachat-desktop: 1.30.1 -> 1.32.0 #185813

Closed

13 tasks

lilyinstarlight reviewed Nov 10, 2022

View reviewed changes

pkgs/build-support/node/build-npm-package/hooks/npm-install-hook.sh Show resolved Hide resolved

reckenrode mentioned this pull request Nov 12, 2022

Various buildNpmPackage fixes #200470

Merged

13 tasks

dhess mentioned this pull request Nov 30, 2022

feat: Use dream2nix to build the project (WIP). hackworthltd/primer-app#639

Closed

		# TODO: how do we expose these like Rust? `npmHooks`?
		inherit (callPackage ./hooks { inherit nodejs; }) npmConfigHook npmBuildHook npmInstallHook;

buildNpmPackage: init #189539

buildNpmPackage: init #189539

Conversation

winterqt commented Sep 3, 2022 • edited

Description of changes

Things done

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

winterqt Sep 3, 2022 • edited

Choose a reason for hiding this comment

IvarWithoutBones Sep 4, 2022 • edited

Choose a reason for hiding this comment

winterqt Sep 3, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

winterqt commented Sep 3, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

IvarWithoutBones left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

winterqt Sep 3, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

IvarWithoutBones commented Sep 3, 2022

winterqt commented Sep 3, 2022

winterqt commented Sep 4, 2022 • edited

yu-re-ka left a comment

Choose a reason for hiding this comment

yu-re-ka commented Sep 4, 2022

IvarWithoutBones commented Sep 4, 2022

IvarWithoutBones commented Sep 4, 2022 • edited

winterqt commented Sep 4, 2022

winterqt commented Sep 5, 2022

DavHau commented Oct 26, 2022

winterqt commented Oct 26, 2022

winterqt commented Oct 27, 2022 • edited

dit7ya commented Nov 1, 2022

happysalada commented Nov 9, 2022

winterqt commented Nov 9, 2022

happysalada commented Nov 9, 2022

winterqt commented Nov 9, 2022

happysalada commented Nov 9, 2022

fricklerhandwerk commented Nov 9, 2022

delroth commented Nov 9, 2022

winterqt commented Nov 10, 2022

nixos-discourse commented Nov 10, 2022

dhess commented Nov 22, 2022

winterqt commented Sep 3, 2022 •

edited

winterqt Sep 3, 2022 •

edited

IvarWithoutBones Sep 4, 2022 •

edited

winterqt Sep 3, 2022 •

edited

winterqt Sep 3, 2022 •

edited

winterqt commented Sep 4, 2022 •

edited

IvarWithoutBones commented Sep 4, 2022 •

edited

winterqt commented Oct 27, 2022 •

edited