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 ?

In reply to @gsaurel:laas.fr
même avec exactement le même commit dans deux branches différentes, ça build pas la même dérivation (le fichier .git/HEAD est différent…)

In reply to @gsaurel:laas.fr
Dans le tiens, ça build plusieurs dérivations du coup ? Tu as un lien ?

In reply to @gsaurel:laas.fr
Dans le tiens, ça build plusieurs dérivations du coup ? Tu as un lien ?