| 10 Jan 2024 |
 Bruno Adele | Effectivement, un load average de 58 je crois qu'ils n'aiment pas trop.
Là ca me rapelle l'époque Gentoo :)
| 20:23:34 |
| 12 Jan 2024 |
 nim65s | 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 ?
| 14:51:25 |
| nim65s | 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…) | 14:57:06 |
 Minijackson | dans ton cas, magic-nix-cache-action est utile si tu as des produits intermédiaires que tu compiles | 14:57:30 |
| Minijackson | perso, j'ai utilisé magic-nix-cache-action pour un projet Python + Poetry, et l'action me cache la compilation de toutes les dépendances | 14:58:18 |
| nim65s | ok, oui, je vois, merci. Dans le cas sur lequel je suis, les dépendances sont toutes dans nixpkgs, donc tout est fetch depuis cache.nixos.org. donc c’est pas la peine de rajouter une autre cache, je suppose | 15:00:14 |
| nim65s | Dans le tiens, ça build plusieurs dérivations du coup ? Tu as un lien ? | 15:01:33 |
| Minijackson | tu peux regarder https://github.com/epics-extensions/WeTest/ si tu veux | 15:02:03 |
| Minijackson | mais il build les dépendances de l'exécutable comme dépendance du programme principal | 15:02:33 |
| Minijackson | * mais il build les dépendances de l'exécutable comme dépendance | 15:02:42 |
| Bruno Adele | C'est quoi un module EPICS ? | 15:51:16 |
| Minijackson | C'est un composant d'un logiciel qu'on utilise pour faire des systèmes de contrôles pour des grandes installations de physique (accélérateur de particules ou autres). C'est très spécifique | 15:57:24 |
|  @nighthawk:jameskitt616.one changed their display name from [Lord] Shin to shin. | 16:07:08 |
| Bruno Adele | Merci pour ta réponse 👍️ | 16:13:53 |
 @delroth:delroth.net | 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…) src = pkgs.lib.cleanSource ./. règle ce problème fwiw (https://discourse.nixos.org/t/filtering-source-trees-with-nix-and-nixpkgs/19148) | 16:16:18 |
| nim65s | delroth: pas mal ça ! Avec ça, ça build exactement la même dérivation quand je push le même commit dans deux branches différentes :D
Par contree ça la rebuild, donc magic-nix-cache-action n’a pas cache-hit… J’ai du rater un truc. | 18:17:22 |
| Minijackson | il faut faire attention aux permissions: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache | 18:24:03 |
| nim65s | Bien vu, j’ai fait un commit vide, et ça a marché, merci !
Bon, c’est pas hyper utile de gérer les commits vides, mais dans la même idée que cleanSource, si je filtre d’autres trucs qui servent à rien dans la construction du paquet, ça peut vraiment être intéressant (genre les changements dans .github, ou le changelog qui sont pas spécialement packagés) | 19:49:19 |
| 13 Jan 2024 |
 Gaël Reyrol | In reply to @gsaurel:laas.fr
Dans le tiens, ça build plusieurs dérivations du coup ? Tu as un lien ? De mon coté j'utilise le concept de matrices de Github Actions pour créer des jobs spécifiques par paquets, ça peut permettre de gérer les builds par arch et c'est bien pratique ! https://github.com/FriendsOfOpenTelemetry/opentelemetry-nix/blob/main/.github/workflows/build.yml#L12 | 13:55:56 |
| Gaël Reyrol | In reply to @gsaurel:laas.fr
Dans le tiens, ça build plusieurs dérivations du coup ? Tu as un lien ? * De mon coté j'utilise le concept de matrices de Github Actions pour créer des jobs spécifiques par paquet, ça peut permettre de gérer les builds par arch et c'est bien pratique ! https://github.com/FriendsOfOpenTelemetry/opentelemetry-nix/blob/main/.github/workflows/build.yml#L12 | 13:56:06 |
| Gaël Reyrol | 
Download image.png | 13:56:58 |
| Gaël Reyrol | Ça donne un truc comme ça : | 13:56:59 |
 Julien | Petit rappel, jeudi prochain: https://mobilizon.fr/events/c749d890-9411-465b-b963-f847c8460f4f | 14:43:02 |
 Auguste Baum | In reply to @julienmalka:matrix.org
Petit rappel, jeudi prochain: https://mobilizon.fr/events/c749d890-9411-465b-b963-f847c8460f4f Ouch, c'est trop dernière minute pour moi 😢 Amusez-vous bien ! | 18:56:20 |
| 14 Jan 2024 |
| nim65s | le plus simple que j’ai trouvé, c’est :
{ pkgs ? import <nixpkgs> {} }:
pkgs.python3Packages.eigenpy.overrideAttrs {
src = pkgs.nix-gitignore.gitignoreSource [./.nixignore] ./.;
}
Et ça ignore .git, tout ce qu’il y a dans .gitignore, et ce que j’ai ajouté dans .nixignore en plus
| 01:52:56 |
| Bruno Adele | Redacted or Malformed Event | 22:59:58 |
| Bruno Adele | Bonsoir, j'ai un petit souci avec wezterm j'obtiens l'erreur suivante
Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1)
J'ai l'impression que les paquets nixpkgs du home-manager ne sont pas synchro avec mon flake ?
Note: la version nix shell est pourtant fonctionnelle
| 23:00:14 |
| Bruno Adele | 
Download 2024-01-14_23-57.png | 23:00:31 |
| Bruno Adele | Y'a un truc que j'ai raté ? (j'avoue que je me mélange encore les pinceaux entre :
nix channelnix registryflake il tape sur quoi ? sur nix channelounix registry` ?
| 23:04:51 |
| Bruno Adele | * Y'a un truc que j'ai raté ? (j'avoue que je me mélange encore les pinceaux entre :
nix channelnix registryflake il tape sur quoi ? sur nix channelounix registry ?
| 23:14:58 |
