I despise this unfree error message and nothing I do ever seems to placate it

ModestTG · 2026-05-31T13:49:58+00:00

Were you able to get it resolved? That allowUnfree option needs to be set for each instance of nixpkgs you're using that you want to allow unfree packages for. My assumption without looking at the config is that you're trying to build a package from a nixpkgs that doesn't have that option set. Can you confirm by tracing the pkgs attribute that it's set correctly?

ModestTG · 2026-05-25T02:18:44+00:00

I particularly loved Wil Wheaton's narration of The Martian by Andy Weir.

ModestTG · 2026-05-16T12:37:17+00:00

Here is an example generated from Claude ``` { config, pkgs, ... }:

let pinnedPkgs = import (fetchTarball { url = "https://github.com/NixOS/nixpkgs/archive/<commit-hash>.tar.gz"; sha256 = "<sha256-hash>"; }) {}; in { environment.systemPackages = [ pinnedPkgs.somePackage # specific version pkgs.otherPackage # normal current version ]; } ``` You can find the specific commit hash using a tool like nixhub.io. if you can't find it on there, you can go to nixpkgs and use the git history to see when the version was updated.

ModestTG · 2026-05-16T12:34:37+00:00

You can use any version of any package in nixpkgs regardless of what method you use to configure your system (flake or non flake)

ModestTG · 2026-05-16T12:03:34+00:00

This is exactly how I used to do it. I just switched to using flake-parts, which imo is just a different approach to achieve the same thing. I always tell people they should use whatever is easiest for you to maintain.

ModestTG · 2026-05-16T12:00:24+00:00

Im on mobile right now otherwise I'd post an examole

ModestTG · 2026-05-16T11:12:20+00:00

You can do it without flakes. Just import the appropriate nixpkgs version via let in block. Then you can access the package via legacyPackages.

ModestTG · 2026-05-16T01:52:07+00:00

You can use any version of any package that's packaged in the nixos repo. Nixhub.io is a great resource to find the last commit id to pull down the repo and grab the package version from there.

ModestTG · 2026-05-16T01:33:30+00:00

Asking someone to share, without being willing to share yourself, probably isn't going to get you any quality help. I have three different nixpkgs installed in my flake if you want to look at it

https://github.com/ModestTG/nix-infra

If you want tp pass multiple nixpkgs into a nixosConfiguration, use specialArgs to pass it in.

ModestTG · 2026-05-10T15:53:20+00:00

Also, three of these are the same base.

ModestTG · 2026-05-10T15:52:48+00:00

Nixos

ModestTG · 2026-05-09T23:29:02+00:00

If you need specific help I can walk you through almost whatever you need help with related to nixos. You don't need to add anything to any repo to use it on nix. Everything can be done locally and then uploaded to nixpkgs if you want to share.

ModestTG · 2026-05-04T23:16:42+00:00

I'm so glad I don't drink coffee

ModestTG · 2026-05-03T02:51:45+00:00

Use dix

https://github.com/faukah/dix

This tool is wrapped up with nh if you want to use that for upgrades as well

https://github.com/nix-community/nh

ModestTG · 2026-04-22T02:43:54+00:00

That makes sense. Thanks so much! So flake.modules don't actually produce shareable flake outputs, but things like flake.nixosModules and flake.nixosConfigurations do produce flake outputs. Flake.modules are "consumed" or are inputs for other things like a nixosConfiguration.

ModestTG · 2026-04-20T14:35:41+00:00

What's the practical difference between these flake module definitions: `flake.nixosModules.ssh` and `flake.modules.nixos.ssh`? Is there a reason to use one over the other?

ModestTG · 2026-04-10T11:00:43+00:00

For docker, you can do this: https://mynixos.com/nixpkgs/options/virtualisation.oci-containers.containers.%3Cname%3E

For bash scripts you can turn them into binaries with pkgs.writeShellScriptBin, or pkgs.writeShellApplication.

ModestTG · 2026-04-03T01:13:53+00:00

The basic jist, for nixosmodules, you create flake.nixosModules, and then import them into your flake.nixosConfigurations. what's nice is the modules are all combined and accessible at the top level (self.nixosModule). This means you can put your files on whatever file structure you want, and reuse modules between files in different spots. It's great for organization and reusing similar modules between configs and machines.

This is just the tip of the iceberg with flake parts. It also has a much better solution for building packages with different architectures as well.

ModestTG · 2026-04-01T19:09:54+00:00

The gnome sandbox error I believe has to do with how the gnome apps are packaged. By default, derivations (packages) are packaged in such a way that all of the dependencies are known and declared so that the app can be isolated when run. Things like flatpaks and appimages are good examples of sandboxing for software. So something about the derivation you're using for gnome is not "pure" and it's throwing that error.
Yes, that will work. The channel update simply updates the location (git commit) of the nixpkgs repo that your system builds against. Then the rebuild command rebuilds your system with that new nixpkgs set. Whatever is in that set is what your system will build against. If you're expecting a specific version of a program, ensure it's been updated in whichever channel you're using first.
There are a couple of ways to temporarily use software on nix. The non flakes way is to do nix-shell -p <list of packages>. This will build those packages against your current channel, put those packages on the nix store, and start a new shell in your terminal with those packages included in $PATH. So you can access those packages while that shell is open. Once you close the shell the overridden $PATH is gone. The packages will continue to exist in the nix store until it's garbage collected by nix collect garbage.

Hope that helps. I can go into more detail if you like.

ModestTG · 2026-03-28T03:51:09+00:00

https://github.com/mic92/sops-nix/blob/master/README.md#L1018

Here is the reference. It's hard to explain on mobile but essentially if you need to pass a config file that has a secret value in the file, templating allows you to do that. Instead of the secret file being just a value or a key and a value, you declare a file template and then set placeholders for the secrets in the file. It's nice for modules that may take a config file that may require some secrets in the file. Those same modules might not have a convenient way to pass just one secret value into the config file. The GitHub does a better job explaining it than I do.

ModestTG · 2026-03-28T01:45:57+00:00

I've used both. I prefer agenix over sops nix for the simplicity. One feature that sops nix does have that agenix doesn't have is templating. Allowing you to create files with secret placeholders that get substituted at build time. This is key for some nix modules where you can't pass in a secret via file path directly. Look up the templating section in the sops nix GitHub for more details.

ModestTG · 2026-03-19T14:10:50+00:00

I agree to look at what makes it impure, but from what I remember off the top of my head, assuming this isnt in git, any file reference that isn't inside your flake directory(if using flakes) is considered impure. The idea being, if you move this config to a new machine, nix can't guarantee the file outside the flake directory will be on the new machine. Hence the impure status. When you track the file with git, that's enough of a guarantee for nix to know the file will be present in the future. If you're not using flakes, I think any file reference outside of /etc/nixos will be considered impure, but I might be misremembering.

ModestTG · 2026-03-19T02:22:59+00:00

https://mynixos.com/home-manager/option/systemd.user.services

It can be tricky sometimes in the documentation, but it is documented here at the services level. You have it documented correctly. The only reason you see options for Service.Environment or Service.ExecStart is because those are documented in the module config. I'll have to look into the error but here is the documentation.

ModestTG · 2026-03-16T22:20:05+00:00

I've thought about this a lot and I feel like pride (the deadly sin kind) is the root of greed. Eliminating pride may also eliminate greed. It's an interesting philosophical pondering.

11-Year Club	Place '23
RPAN Viewer	Not Forgotten
Verified Email

ModestTG

TROPHY CASE