| 16 Jan 2024 |
infinisil | In reply to @infinisil:matrix.org And here's the problem and fix: https://github.com/NixOS/nixpkgs/pull/281390 (this is not urgent) We don't need to rush this, but it's a small PR and it contains the fix without which we can't proceed to make pkgs/by-name required for new packages. Reviews appreciated :) | 21:02:57 |
Philip Taron (UTC-8) | In reply to @infinisil:matrix.org We don't need to rush this, but it's a small PR and it contains the fix without which we can't proceed to make pkgs/by-name required for new packages. Reviews appreciated :) Done. Not much to say, other than a wonder about what approaches would have caught this earlier. | 21:31:33 |
infinisil | Philip Taron (UTC-8): At least the new test in the PR should prevent this in the future (though for it to trigger automatically we have to wait for ofborg eval to finish) | 21:32:30 |
infinisil | I opened some more follow-up work, I won't link everything here though, you can check out the RFC 140 milestone which I always keep up-to-date: https://github.com/NixOS/nixpkgs/milestone/25 | 22:49:43 |
| 18 Jan 2024 |
infinisil | Just opened https://github.com/NixOS/nixpkgs/pull/281835, this is the final follow-up (for now), which now actually starts enforcing pkgs/by-name! Very small PR due to all the preparatory work :) | 17:57:29 |
| 22 Jan 2024 |
| Minijackson joined the room. | 17:19:11 |
Minijackson | hello everyone! I had a question related to the pkgs/by-name RFC. I have a "versioned" package netbox_3_6, netbox_3_5, and an alias netbox which points to the latest one. To remove duplication, we have a generic.nix file that is importable with arguments that differ from version to version. Is this something that I can implement inside pkgs/by-name? The checker is failing for my latest PR | 17:22:48 |
Minijackson | Thanks for the answer, infinisil x) | 17:25:08 |
infinisil | Minijackson: Oh I just commented on your PR :) https://github.com/NixOS/nixpkgs/pull/282929#issuecomment-1904468118 | 17:25:10 |
infinisil | Three minor issues have come up with the enforcement of pkgs/by-name for new packages. The one above with netbox doesn't have a fix yet, but the other two do:
- https://github.com/NixOS/nixpkgs/pull/282707
- https://github.com/NixOS/nixpkgs/pull/283017
| 23:11:03 |
| 23 Jan 2024 |
| Alexandros Liarokapis joined the room. | 08:36:56 |
Alexandros Liarokapis | Hi all! I am not sure if this is the proper channel to ask. I have a large set of embedded-compatible cmake libraries which I define using stdenv.mkDerivation. I would like to use the gcc-arm-embedded package in order to create a custom stdenv instead of going through the gcc bootstrapping with crossSystem. For caching reasons but also because the resulting library/executable binaries are ~40% larger. Is there any easy way currently to convert such toolchains to valid stdenvs? | 08:46:12 |
Alexandros Liarokapis | Looking at the llvm stdenv it seems like a non-trivial process. I have also found a gist for using the zig toolchain as an stdenv: https://gist.github.com/Cloudef/acb74ff9e36ab41709479240596ab501 but I am not sure if the resulting stdenv takes into consideration everything. In general the process of creating stdenvs seems a bit ad-hoc but maybe it's just me being unfamiliar with the infra. | 08:49:35 |
Alexandros Liarokapis | My end goal is to have something like the current localSystem/crossSystem infra but being able to easily use other toolchains because bootstrapping gcc is non trivial and it is also hard to modify the configure flags through naive overlays. I /think/ this is possible now through using the replaceStdEnv in crossSystem but I am unsure. | 08:53:34 |
Alexandros Liarokapis | * My end goal is to have something like the current localSystem/crossSystem infra but being able to easily use other toolchains because bootstrapping gcc is non trivial and it is also hard to modify the gcc toolchain configure flags through naive overlays. I /think/ this is possible now through using the replaceStdEnv in crossSystem but I am unsure. | 08:55:19 |
| 25 Jan 2024 |
9999years | could i get a review on this PR? not sure what valentin's @ is on here
https://github.com/NixOS/nixpkgs/pull/280592 | 01:40:48 |
raitobezarius | Valentin is not here | 02:02:25 |
raitobezarius | afaik | 02:02:25 |
| @qyriad:matrix.org joined the room. | 06:53:56 |
John Ericson | https://github.com/NixOS/nixpkgs/pull/279619 is this staging backport fail innocuous? | 23:52:23 |
| 26 Jan 2024 |
9999years | In reply to @raitobezarius:matrix.org Valentin is not here lol i love the nixos matrix server. "we do not have all the team members in the official team channels. good luck!" | 00:59:55 |
9999years | me: nobody reviews my nix prs, this sucks
everyone: you simply have to be in the matrix and ask people for reviews directly
the matrix: doesn't even have the people responsible present | 01:00:29 |
Alyssa Ross | You can't force people to participate | 01:01:55 |
Alyssa Ross | But Valentin is on Matrix, just not in this particular room. | 01:02:55 |
Alyssa Ross | It would be nice if the matrix first in lib.maintainers was used more⦠| 01:03:46 |
9999years | yeah i mean. it would just be nice if people on nix teams did their team communication in matrix rooms | 01:12:50 |
9999years | anyways i'm noticing that valentin isn't even on https://nixos.org/community/teams/nixpkgs-architecture | 01:13:00 |
9999years | would someone on the team be willing to help me get this over the line then? https://github.com/NixOS/nixpkgs/pull/280592 | 01:13:20 |
raitobezarius | infinisil is in this channel and I guess you just need a new review from them | 01:35:15 |
infinisil | 9999years: Not sure why you're upset about this, this is the room for Nixpkgs architecture, Valentin isn't really involved in that, he's not in the Nixpkgs architecture team either, never has been, so there's really no need for him to be in this room. Though yeah he also doesn't appear to be in the #nix-dev:nixos.org room, which would make more sense (though he's low on availability this quarter) | 01:40:03 |