@[email protected] · Reply to Sandro :nixos: :verified_gay:'s post
@sandro @ma27 @hexa The work #lix is doing demonstrates well that language evolution is not really held back and that #nixpkgs inability to change is really a nixpkgs problem, which is not really limited to nix 2.3 compatibility either.
#lix pushing the envelope is a good thing in my opinion and nixpkgs has to do the work to keep up.
PSA: The #nixpkgs bot on matrix @nixpkgs-bot:maralorn.de is currently recovering from a major outage. The underlying git repository got somehow corrupted a few weeks ago. Users had reported the outage but I thought it was just the usual my server is being ddosed by ai companies, so I didn’t notice the problem. 😆
PSA: The #nixpkgs bot on matrix @nixpkgs-bot:maralorn.de is currently recovering from a major outage. The underlying git repository got somehow corrupted a few weeks ago. Users had reported the outage but I thought it was just the usual my server is being ddosed by ai companies, so I didn’t notice the problem. 😆
@[email protected] · Reply to Paul Meyer's post
On the nixpkgs side of things, the no-broken-symlinks hook was added to catch builds containing dangling or reflexive symlinks, as these are indicative of problems with packaging. The hook can be disabled by providing dontCheckForBrokenSymlinks = true; as an argument to mkDerivation.
substituteAll and substituteAllFiles have been deprecated in favor of replaceVars and will be removed in the next release.
And I already posted about the improvements of lib.packagesFromDirectoryRecursive] being able to construct nested scopes matching the directory tree passed as input..
NixOS 25.05 "Warbler" is now released! 🎉
NixOS 25.05 "Warbler" is now released! 🎉
finally set aside to actually do the proper #nixpkgs contributions for these. https://github.com/NixOS/nixpkgs/pull/409599 & https://github.com/NixOS/nixpkgs/pull/409605. fairly easy process so far! i have no idea what to expect for the rest of it tho; how fast will they get merged? how fast will that merge make it to the nixos-unstable branch? only time will tell :)
https://social.treehouse.systems/users/PolyWolf/statuses/114481040733025077@[email protected] · Reply to PolyWolf's post
oh it's like actually actually unmaintained: i got a ModuleNotFound error that i'm pretty sure should not be happening if Nixpkgs is set up right.
technically it's in another unmaintained Python package (tracerite), but also this comes up if u run the first (sanic) in its basic config, so yeah time 2 maintain
For many, overlays, and fixed-point functions as underlying concept, are hard to gasp in #Nix.
I found the documentation to be actually quite good in this case, checkout the function docs of fix and extends (and read in this order). Both have great examples/steps that guide you through, which was really helpful to me.
Security Advisory: Local privilege escalation in make-initrd-ng
https://discourse.nixos.org/t/security-advisory-local-privilege-escalation-in-make-initrd-ng/63315
Nice, screen sharing with chromium + pipewire fixed again on NixOS.
https://github.com/NixOS/nixpkgs/pull/398963
Commit is already included in all unstable channels.
Security Advisory: Local privilege escalation in make-initrd-ng
https://discourse.nixos.org/t/security-advisory-local-privilege-escalation-in-make-initrd-ng/63315
In #NixOS the snow theme was used to illustrate that each flake is a perfect recreation, which didn't aptly describe this glorified build system.
The best analogy (even within the #NixOS community) has been the cooking analogy.
#Nix are the kitchen utensils, #Nixpkgs the recipes, #NixStore the pantry, packages ingredients, profiles are tables and derivations are dishes.
This proves that we need #marketing, because #engineers suck at naming things.
loongarch64 native stdenv is here! #NixOS #Nixpkgs
https://github.com/NixOS/nixpkgs/pull/399167
loongarch64 native stdenv is here! #NixOS #Nixpkgs
https://github.com/NixOS/nixpkgs/pull/399167
For many, overlays, and fixed-point functions as underlying concept, are hard to gasp in #Nix.
I found the documentation to be actually quite good in this case, checkout the function docs of fix and extends (and read in this order). Both have great examples/steps that guide you through, which was really helpful to me.
For many, overlays, and fixed-point functions as underlying concept, are hard to gasp in #Nix.
I found the documentation to be actually quite good in this case, checkout the function docs of fix and extends (and read in this order). Both have great examples/steps that guide you through, which was really helpful to me.
Any way to trigger a command in #NixOnDroid with the press of a button on the home screen?
For #termux there is the widget app but it doesn't appear to work with #nix-on-droid.
I really don't want to have to install and maintain #gitAnnex using some install script and some prebuilt global FHS binaries when I could simply get it from #nixpkgs.
The more I look into other packaging systems as #nixpkgs the more I am horrified. They call themselves a distro but have no good way to handle a go repository without a vendor directory.
@[email protected] · Reply to daniel :nixos:'s post
Fixed my overlays, but I think the error message is very #nixpkgs specific? If you simply use something like pkgs.python3.pkgs.buildPythonPackage, you don't have a "generic python parameter" ...
@[email protected] · Reply to Jake Hamilton's post
Aux Lib is, by and large, a rewrite and downsizing of Nixpkgs' `lib`. Though, there are things that have been removed, changed, or added. Still, we would not be able to release this today without the work of all the #Nixpkgs contributors.
Nice, lib.packagesFromDirectoryRecursive now supports nested scopes!
packagesFromDirectoryRecursive transforms a directory tree of packages into a nested attribute set of derivations. You can use it to manage a package set in a similar way to by-name in nixpkgs (without the sharding part). The package files in tree must be suitable for callPackage.
Subdirectories in the tree result in nested attribute sets. In the following example, packages d, e and f will be in a nested attribute set called my-namespace.
my-packages
├── a.nix
├── b.nix
├── c
│ ├── my-extra-feature.patch
│ ├── package.nix
│ └── support-definitions.nix
└── my-namespace
├── d.nix
├── e.nix
└── f
└── package.nix
Previously, this would only use one scope (my-packages), so e could only depend on d as my-packages.d. With the introduction of nested scopes, e can refer to d within the same scope directly.
PR: https://github.com/NixOS/nixpkgs/pull/392800
function doc on noogle (which isn't yet updated for the new behavior): https://noogle.dev/f/lib/packagesFromDirectoryRecursive
I though it had been a while without any #NixOS drama, but of course the universe provides.
Guess what, telemetry in #devenv is coming back. Again, it's Opt-Out, not Opt-In.
The difference: this time that work is sponsored by the NixOS Foundation.
https://github.com/cachix/devenv/pull/1776/files
https://oceansprint.org/reports/2025/
Brought to you by @domenkozar of course.
@[email protected] · Reply to Paul Meyer's post
Further, I opened a PR to add keep-sorted to the nixpkgs CI. keep-sorted is a language-agnostic formatter that sorts lines between two markers in a larger file. It will help us to get some order in the large top-level files like all-packages.nix!
@[email protected] · Reply to Paul Meyer's post
If you want to learn more about gobuild.nix and why we need it, checkout my talk at FOSDEM this year:
https://fosdem.org/2025/schedule/event/fosdem-2025-5654-go-in-the-nix-ecosystem-vulnerability-scanning-and-experiments-towards-a-next-gen-builder/
#OceanSprint 2025 is over, it was an great experience!
I mostly worked on gobuild.nix, a next-generation builder for Go in nixpkgs. gobuild.nix removes vendoring for Go packages in nixpkgs, modeling the full dependency graph in Nix. Each module dependency will be its own derivation, including build cache on a module level.
During the sprint, I moved gobuild.nix from linking dependency source into a vendor directory to providing a local directory that can be used as GOPROXY. This is both more versatile and simple.
Together with @britter I started implementing a code generation tool that will help to package the large number of packages that will be part of the Go dependencies package set. The tool generates the Nix code for these packages, including the FOD hashes.
Who needs pigs to fly? I think that the end times will be marked by an occasion where two #NixOS or #nixpkgs users agree on the correct way to build a FOSS project.
"use devshell"
"use flake"
"use this other flake thing"
"just use upstream nixpkgs"
"upstream nixpkgs is slow, let's use this fhsENV thing"
"use flakeutils, it's really handy"
"flakeutils that everyone uses is a waste of time, just use nix directly"
"nix2 solved all of our problems, flakes just add unnecessary complexity"
"structure the flake like this"
The “not-a-fork”[sic] fork of Nix has decided to go ahead and take over the next major version number out of the hands from the official Nix package, and from there, take over the mindshare of the version 3.0.
What the actual fuck?
This is effectively a hostile takeover of the Nix name. Nix 3.0 will surface the “not-a-fork”[sic] fork.
They will surely be using the excuse that it's “Determinate Nix”, which is a different name. But in practice, you know how it is. They are polluting the mindshare with their “not-a-fork”[sic] fork.
Also, this is absolutely 100% a fork, even though they say it's not.
This is a fork that has made the current state of Flakes stable. A major fork in the road. Either Nix will have to become "incompatible" with the stability “promises” from the “not-a-fork”[fork], or bow down to what Determinate Systems decides for compatibility, for their future.
I guess it's a good time to jump over to Lix, for anyone who hasn't done so. It work just fine with NixOS.
Hopefully we'll have a statement from the Nix project regarding this.
This is a serious proposal, we should actually ban and denounce determinate systems now.
https://discourse.nixos.org/t/we-should-urgently-ban-and-denounce-determinate-systems/61356
Please.
This is a serious proposal, we should actually ban and denounce determinate systems now.
https://discourse.nixos.org/t/we-should-urgently-ban-and-denounce-determinate-systems/61356
Please.
This is a serious proposal, we should actually ban and denounce determinate systems now.
https://discourse.nixos.org/t/we-should-urgently-ban-and-denounce-determinate-systems/61356
Please.
Want to help out Nixpkgs but don't know what to do? I compiled a list of still failing packages due to switching to GCC-14 in stdenv a while back. GCC changed some warning to errors in this version and lots of especially older projects fail to build now.
Plenty of examples of the fix already in Nixpkgs, ideal for first time contributors.
Want to help out Nixpkgs but don't know what to do? I compiled a list of still failing packages due to switching to GCC-14 in stdenv a while back. GCC changed some warning to errors in this version and lots of especially older projects fail to build now.
Plenty of examples of the fix already in Nixpkgs, ideal for first time contributors.
Can we please remove @determinatesystems from the #nixpkgs #nixos community?
The “not-a-fork”[sic] fork of Nix has decided to go ahead and take over the next major version number out of the hands from the official Nix package, and from there, take over the mindshare of the version 3.0.
What the actual fuck?
This is effectively a hostile takeover of the Nix name. Nix 3.0 will surface the “not-a-fork”[sic] fork.
They will surely be using the excuse that it's “Determinate Nix”, which is a different name. But in practice, you know how it is. They are polluting the mindshare with their “not-a-fork”[sic] fork.
Also, this is absolutely 100% a fork, even though they say it's not.
This is a fork that has made the current state of Flakes stable. A major fork in the road. Either Nix will have to become "incompatible" with the stability “promises” from the “not-a-fork”[fork], or bow down to what Determinate Systems decides for compatibility, for their future.
I guess it's a good time to jump over to Lix, for anyone who hasn't done so. It work just fine with NixOS.
Hopefully we'll have a statement from the Nix project regarding this.
The “not-a-fork”[sic] fork of Nix has decided to go ahead and take over the next major version number out of the hands from the official Nix package, and from there, take over the mindshare of the version 3.0.
What the actual fuck?
This is effectively a hostile takeover of the Nix name. Nix 3.0 will surface the “not-a-fork”[sic] fork.
They will surely be using the excuse that it's “Determinate Nix”, which is a different name. But in practice, you know how it is. They are polluting the mindshare with their “not-a-fork”[sic] fork.
Also, this is absolutely 100% a fork, even though they say it's not.
This is a fork that has made the current state of Flakes stable. A major fork in the road. Either Nix will have to become "incompatible" with the stability “promises” from the “not-a-fork”[fork], or bow down to what Determinate Systems decides for compatibility, for their future.
I guess it's a good time to jump over to Lix, for anyone who hasn't done so. It work just fine with NixOS.
Hopefully we'll have a statement from the Nix project regarding this.
The latest set of GRUB2 #security vulnerabilities from mid-February https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html requires **79** patches, along with some adjustments, to be applied to the latest stable tarball without breaking #NixOS tests.
This does not make life easy for downstream consumers.
If other distro maintainers want to take a look, I have isolated the patches so you don't have to deal with Nix: https://gist.github.com/LeSuisse/34059dd08bddc9b509097d42d3ca9109
The latest set of GRUB2 #security vulnerabilities from mid-February https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html requires **79** patches, along with some adjustments, to be applied to the latest stable tarball without breaking #NixOS tests.
This does not make life easy for downstream consumers.
If other distro maintainers want to take a look, I have isolated the patches so you don't have to deal with Nix: https://gist.github.com/LeSuisse/34059dd08bddc9b509097d42d3ca9109
The latest set of GRUB2 #security vulnerabilities from mid-February https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html requires **79** patches, along with some adjustments, to be applied to the latest stable tarball without breaking #NixOS tests.
This does not make life easy for downstream consumers.
If other distro maintainers want to take a look, I have isolated the patches so you don't have to deal with Nix: https://gist.github.com/LeSuisse/34059dd08bddc9b509097d42d3ca9109
🚀 New Blog Post! 🚀
I've been working on optimizing Gradle build support in nixpkgs! In my latest post, I take a deep dive into how it currently works, the limitations of the existing approach, and an optimization that improves efficiency and maintainability.
Check it out here: https://britter.dev/blog/2025/02/19/nixpkgs-gradle-optimization/
I’d love to hear your thoughts! Also, if your team needs Gradle or NixOS consulting, I’d be happy to help. 😊
🚀 New Blog Post! 🚀
I've been working on optimizing Gradle build support in nixpkgs! In my latest post, I take a deep dive into how it currently works, the limitations of the existing approach, and an optimization that improves efficiency and maintainability.
Check it out here: https://britter.dev/blog/2025/02/19/nixpkgs-gradle-optimization/
I’d love to hear your thoughts! Also, if your team needs Gradle or NixOS consulting, I’d be happy to help. 😊
@[email protected] · Reply to hexa-'s post
Unfortunately #nixpkgs is not well-equipped to resolve this conflict. There is no explicit policy and common sense seems not to be equally distributed.
Ultimately this is a governance issue for #NixOS where the steering committee would be in a great position to limit the scope of what is acceptable behaviour.
In fact, if you have an opinion on the matter, please reach out to any steering committee representative and tell them:
https://github.com/NixOS/org/blob/main/doc/governance.md
🧵3/n
@[email protected] · Reply to hexa-'s post
Unfortunately #nixpkgs is not well-equipped to resolve this conflict. There is no explicit policy and common sense seems not to be equally distributed.
Ultimately this is a governance issue for #NixOS where the steering committee would be in a great position to limit the scope of what is acceptable behaviour.
In fact, if you have an opinion on the matter, please reach out to any steering committee representative and tell them:
https://github.com/NixOS/org/blob/main/doc/governance.md
🧵3/n
@[email protected] · Reply to hexa-'s post
The #devenv CLI does not do informed consent and neither `devenv.sh` nor `devenv.new` have a privacy policy or will tell you who runs the service and who it shares its data with.
In #nixpkgs the package was bumped to 1.4.0 after which a contributor immediately sent a follow-up PR¹ to enable `DO_NOT_TRACK=1` when wrapping the devenv binary.
This was promptly reverted² by the author of devenv.
🧵2/n
[1] https://github.com/NixOS/nixpkgs/pull/381817
[2] https://github.com/NixOS/nixpkgs/pull/381981
Domen, creator of devenv, recently added telemetry to his devenv thing, as part of adding AI to the product, and when nixpkgs contributors removed the telemetry, he reverted the change, with a self merge, without a fucking review even.
https://github.com/NixOS/nixpkgs/pull/381981
This is a clear conflict of interest. We need to stop this from happening in the NixOS organization, corpos need to have some respect for users.
Discussion thread: https://discourse.nixos.org/t/should-commercial-actors-ship-telemetry-in-nixpkgs/60279/8
Domen, creator of devenv, recently added telemetry to his devenv thing, as part of adding AI to the product, and when nixpkgs contributors removed the telemetry, he reverted the change, with a self merge, without a fucking review even.
https://github.com/NixOS/nixpkgs/pull/381981
This is a clear conflict of interest. We need to stop this from happening in the NixOS organization, corpos need to have some respect for users.
Discussion thread: https://discourse.nixos.org/t/should-commercial-actors-ship-telemetry-in-nixpkgs/60279/8
@[email protected] · Reply to flashfox's post
@[email protected] · Reply to Joe 'Oz' Fredette's post
At least in #nixpkgs the telemetry seems to be of by default now
@emilychwiggy I don't pin the extensions. Missing executables can generally provided with the direnv extension.
#Nixpkgs doesn't provide a mature vscode or vscodium distribution yet. Needs automated tests and more maintainers, I would guess.
After some months of work, I got the legacy `buildGoPackage` builder removed from #nixpkgs. Most packages using the legacy builder were migrated to `buildGoModule`. Now we have less maintenance burden and thus the chance to work on something new!
https://github.com/NixOS/nixpkgs/issues/318069
Check out the updated Go section in the nixpkgs manual: https://nixos.org/manual/nixpkgs/unstable/#sec-language-go
Shortly after the branch off for the upcoming release of NixOS 24.11, there was quite a drop in the share of Go package sources that are vulnerable, compared to the last scan 3 months ago.
Report with all vulnerable packages can be found here: https://github.com/katexochen/govulncheck-nixpkgs
@[email protected] · Reply to Paul Meyer's post
#nixpkgs issue for this is https://github.com/NixOS/nixpkgs/issues/84312
TIL: `git archive` is used by GitHub and other forges to create an archive of a repo to download. git can do unexpected thing when creating such archive, like variable substitution using the `export-subst` feature. So even if a commit is immutable, you can still download different content if a ref or tag changed.
https://git-scm.com/docs/git-archive/2.46.0#Documentation/git-archive.txt-export-subst
Example: https://github.com/smallstep/cli/blob/master/.VERSION
That's a real problem in context of reproducible builds (or just source-pinning in general).
So I ran the script that @kees adapted from @bagder 's initial concept on the older×biggest repo I still make use of.
(Side-note, It would be interesting to have an AST-aware equivalent that can guesstimate the age of the constructs, rather than the age the "source" stringy-based serialization, especially since it's likely some changes refreshed some line's age, but actually only changed part of its semantics, or nothing at all.)
I ran it on the release tags (in other words, the initial point in time a numbered release was marked stable).
It took a surprisingly long amount of time, but I did not change the implementation. Maybe there's some accidentally quadratic operation that could be made faster... But also this is a legitimately big git repo, and maybe the hours it spent on the last few tags were legitimate.
There will be a Go meetup @ NixCon on Sunday, 11:00. Join us in discussing Go in nixpkgs, buildGoModule and community projects around Go and Nix. Check out the pad and feel free to add topics: https://pad.fluxfingers.net/E6VPRRYGQ2-0KtAjj_zKGA?both
I've been nominated for the first NixOS Steering Committee!
You can read my candidate form here, where I explain some of my goals, previous work, and motivation in running for this position. I also encourage everyone to check the issues of this repository, which is filled with some great questions from the community and responses by myself and my fellow candidates
I will be continuing this thread by highlighting some of the questions I find most important for this election 🧵
https://github.com/NixOS/SC-election-2024/blob/main/candidates/getchoo.md
Iunno how to use social media or Mastodon, but I've been meaning to give this a try for awhile. #Introduction :
- 24yo trans CS student in Leipzig, Germany
- Life for me revolves around tech. Preferably Linux, old computers and sound chips.
- #Programming since 6th grade. Used Lua, Object Pascal, C, C++, and many more over the years. Currently C# and Assembly for uni.
- #NixOS user & #Nixpkgs contributor since 2018, Linux user since 2015…-ish?
- Current project: Slowly getting #Lomiri submitted into #Nixpkgs / #NixOS, + dealing with uni.
Iunno what I'll post on here or expect to get out of this yet. Prolly complaining about programming stuff. Maybe finding like-minded and/or local people? We'll see I guess.
Hello World.
I'm a consultant/developer for Embedded Systems Security.
Every now and then I contribute to #NixOS and #nixpkgs
I tried blogging a few times before, but either the service went out of business after a few posts or I ran out of time for longer posts.
Expect #Security and or #Nix orientended content from me.
Ocassional ramblings on random things, too.