nixos-rebuild uses the new experimental interface when your config is a flake, and the old one otherwise.
I was referring to what I see when running nixos-rebuild switch --upgrade, explicitly.
There’s definitely more of this kind of stuff when I enter a flake devshell via direnv.
If this is coming, or at least already partly there: great! I hope this means the tasks necessary to surface it better are indeed simpler!
Oh, I wasn’t aware that the progress is not there if you do not use a flake configuration…
1 Like
The --upgrade tells me, that you are probably not using flake. Then as @tejing pointed out, what you see is different from what we see.
1 Like
Not for system configs, there hasn’t (yet) been a sufficient need or motivation. This could be one…
1 Like
You can pipe your non-flakes and flakes build to nix-output-monitor for a great progress meter 
it shows a dependency graph and average time for each step, current time, downloaded packages etc…
4 Likes
Oh, it does work for flakes now? I need to take a closer look!
2 Likes
it does work with flakes 
it produces a much nicer output than flakes 
1 Like
Is it doable to release an alpha version NixOS with the new features as default ?
What do you mean? Which features?
Any new feature that would indeed be available in the next release, is available by default when using nixos-unstable.
There you can use them if you need them.
Not as much projects/tasks but areas to explore that I suspect have a lot of low hanging fruits:
-
Better (any?) tracking for CVEs and security vulnerabilities remediation. ckauhaus used to do the vulnerability roundup bugs every once in a while, but as far as I can tell that’s not happening anymore and there was a ton of space to improve the process (tracking, figuring how to handle false positives better, making things more realtime, etc.).
-
More automation to help maintainers keep their packages up to date and building successfully. ryantm’s bot is great, but as far as I can tell when it fails to create an auto-update PR that still builds it just ignores the problem without telling anyone! I’d much rather get an email/bug saying “there’s a new version but it needs manual work to update, have a look when you can” (in fact I’ve built myself some automation to do exactly that…). Similarly, when one of the packages I maintain is broken on Hydra I might not notice until the next time I update my systems, leading to things being broken for longer than they should.
-
It might be useful to have something to identify “important packages lacking maintainers” (easy), as well as “important packages that have maintainers on paper but the maintainers don’t actively maintain them anymore” (harder). Someone with access to cache.nixos.org stats could probably figure out “important packages” based on download stats – it’s not a perfect heuristic but likely good enough. I’d happily adopt some of these packages! (I do that regularly, but usually when I notice it’s because the packages in question got involved in annoying me with bugs / being outdated / … and I’d rather we just skip the annoyance part
).
3 Likes
Solving the wrapper problem, for the uninitiated: this means creating shell scripts that setup the environment for running a program (typically, but no exclusively a GUI application).
The infrastructure for doing this in Nixpkgs is a horrible mess: there are many diffent wrapSomething functions for Xorg, GTK, Qt, etc. and they don’t compose at all (yes, there are programs that use both GTK and Qt). Worse, it doesn’t work for libraries that need to propagate the dependency on some environment to the program they’re being linked to. We’re shipping actually broken software because of this situation.
Fixing this is not particularly difficult but it requires some level of coordination which for some reason or another has never been achieved. Just look at the amount of (abandoned) proposals: PR #95569, PR #144722, PR #102949, PR #53816, PR #83321.
If we could focus on one simple, realistic, solution and put an end to this madness it would really be great for both the Nixpkgs maintainers and users.
13 Likes
Close abandoned PRs
Not so high impact on a small scale but if even a few people unite to decide if an old, maybe abandoned PR should be closed this could reduce some of the maintenance backlogs of the repo.
2 Likes
Another thing is something like NUR but with hydra support.
It’s not so convenient to build everything from scratch and a source of truth of the core would be hella useful for cache hits.
IPFS spreading and derivation result consensus would be cool but this is very high-effort work.
1 Like
I think an autocomplete script generator for this guy would be sick
But I don’t have that much time to grok on this rn
Ability to fake uname -m output integrated directly into nixpkgs’s kernels would be really helpful for native compiling armv6l/armv7l binaries on aarch64 hardware:
https://github.com/nix-community/aarch64-build-box/pull/133
Support running nixos-rebuild as regular user:
https://github.com/NixOS/nixpkgs/pull/170501
Improve installation experience for creating users in NixOS:
https://github.com/NixOS/nixpkgs/pull/124602
Looking for duplicates PR is also useful. A case that often happen is someone opens a PR for an update but it doesn’t get merge, and later someone else open a PR for a newer update of the same package.
5 Likes
Enable easy sharing of nix store among local machines.
1 Like
Another one, but probably not so low-effort: allow machines in NixOS tests to specify a different type of virtualisation (with a full VM being the default).
Many tests should also work inside e.g. a Firecracker-VM, which can save a lot of runtime as often the time required for booting the VM is substantial part of the whole test runtime.
2 Likes