Par contre si ca marche je te suggère de contribuer au projet en modifiant nixos-hardware la conf de ta machine (ca évitera aux autres de se casser les dents :) )

Exemple de l'implémentation ici => https://github.com/NixOS/nixos-hardware/blob/b34a6075e9e298c4124e35c3ccaf2210c1f3a43b/common/gpu/intel/default.nix#L12

Bonsoir,

Actuellement, j'ai un core dump avec l'outil meld (outil qui permet d'avoir des diff facilement lisible), il semblerait que ce core dump soit lié avec la lib GTK3, j'ai donc fait un overlay de cette MR.

Mais ca fait presque 3H que ca build et j'ai l'impression que je vais en avoir pour longtemp (vous me direz normal, cette lib doit être utilisé par tout les paquets).

Sachant qu'actuellement la PR est dans la branche staging => https://nixpk.gs/pr-tracker.html?pr=275702

Comment faites vous ou comment ferez vous pour tester ces nouvelles features ?

• vous créer un nouveau input rien que pour ce package ? (utilisant la branch staging ?)
• utiliser l'input staging pour l'ensemble des paquets (me parait risqué, si l'ont doit faire un downgrade, par exemple revenir à la branche nixos-unstable

Effectivement, un load average de 58 je crois qu'ils n'aiment pas trop.

Là ca me rapelle l'époque Gentoo :)

Hello !
Je viens de penser que maintenant que j’ai mes paquets dans nixpkgs, je peux ajouter une CI avec juste un default.nix qui contient { pkgs ? import <nixpkgs> {} }: pkgs.monpaquet.overrideAttrs { src = ./.; } et un nix-build dans github actions, et je trouve ça trop cool :D

Par contre, j’ai une question sur les caches. Chacun de mes build CI va avoir un hash différent des sources, donc construire une dérivation différente, et donc j’aurai jamais de cache-hit, non ? Du coup c’est quoi l’intérêt des trucs comme https://github.com/DeterminateSystems/magic-nix-cache-action ?