- Past meeting notes
- Matrix announcement
- Lead by: @infinisil
- Meeting notes by: @infinisil
- Attendees: @roberth @phaer @DavHau @tomberek @ashkitten @j-k (I think)
Notes
- @phaer leaves the team
- Nixpkgs updates
-
nixos/stub-ld: init module by tejing1 · Pull Request #269551 · NixOS/nixpkgs · GitHub
- Better error message when trying to run unpatched binaries
- General agreement to have it
- Touches
lib.systems
- roberth: Maybe structure it as components, each with their own maintainers, doc chapters, etc
- core (
attrsets
,lists
,strings
, etc.) - module system (
options
,modules
,types
) - systems (
systems
)
- core (
- Issue opened: Split `lib` files and documentation by components: core, `systems`, module system · Issue #270666 · NixOS/nixpkgs · GitHub
- Maybe shouldn’t be in
lib
, but ratherstdenv
- Potential future work to move it to a better place and document it
- roberth: Maybe structure it as components, each with their own maintainers, doc chapters, etc
-
Ensure all jobset attributes evaluate, and check that in CT · Pull Request #269356 · NixOS/nixpkgs · GitHub
- Potential to fix the ofborg eval slowness (with follow-up PR)
- https://github.com/NixOS/rfcs/pull/166
- [RFC 0146] Meta.Categories, not Filesystem Directory Trees by AndersonTorres · Pull Request #146 · NixOS/rfcs · GitHub
- Automatically updated nixos channel pins by infinisil · Pull Request #252057 · NixOS/nixpkgs · GitHub should be discussed a bit more
-
lib.fileset
library, see Function for transforming store path contents · Issue #264541 · NixOS/nixpkgs · GitHub for a potential function to work on arbitrary store paths
-
nixos/stub-ld: init module by tejing1 · Pull Request #269551 · NixOS/nixpkgs · GitHub
- Update on RFC 140
- @infinisil will continue with RFC 140 migration plan · Issue #258650 · NixOS/nixpkgs · GitHub
- Can ping @DavHau
- Package set unification? Package set standardization · Issue #21 · nixpkgs-architecture/issues · GitHub
- @infinisil doesn’t have the time, somebody else has to pick it up
-
@tomberek: Considering doing that, worth doing?
- @infinisil: 100% agree worth doing, exactly the thing for the NAT!
-
@DavHau: Do unification of package overriding first?
- @infinisil: Intermediate unified package sets will help with future improvements to overriding
- @tomberek: I want it to be teachable to beginners, currently intractable
-
@ashkitten: Various ways to update packages, would be good to have a unified way that works, maybe even builtin
- @infinisil: Relates to flake lockfile and dream2nix
-
@roberth: Nix team perspective: team has no bandwidth or scope do anything specific to Nixpkgs or write to files. Could use
nix run
or provide some command. -
maintainers/scripts/update.nix
is kind of terrible, would be great to change it to a normal script- @roberth: A script with a better UX would be great and not controversial
-
passthru.updateScript
standardisation work would be great -
@r-ryantm uses GitHub - Mic92/nix-update: Swiss-knife for updating nix packages., relates to Announcing nixpkgs-merge-bot
- Great RFC topic for somebody
- @ashkitten interested in working on update script standardisation: passthru.updateScript standardization · Issue #24 · nixpkgs-architecture/issues · GitHub
-
@tomberek: possible to expose the full scope of callPackge through a lazy value (may be related to the package set uni.). Garbage collection is likely impacted.
package.passthru.context package.overrideAttrs package.override - callPackageWith package.context ./default.nix {} callPackage ./hello.nix { python = python3; }
- @DavHau: Maybe better to fix the underlying reason why it’s hard to reproduce packages
- @infinisil: Please describe it in an issue