nadley has quit [Remote host closed the connection]
nadley has joined #nixos-fr
julm has joined #nixos-fr
<julm>
salut :)
<gchristensen>
bonsoir
<julm>
eh ben, à peu près un an que je bidouille sur nixpkgs/nixos ; un peu dur au début de comprendre ce qu'il se passe, mais maintenant c'est un plaisir d'arriver à faire quasiment tout ce dont j'ai besoin, notamment d'empaqueter des paquets ou de modifier leur config
* julm
<3 les modules et les overlays de nixpkgs
<julm>
bon desfois ya des trucs que je ne comprends pas bien comme les "collision between" entre fichiers de paquets ou bien pourquoi quand j'ajoute des fonctions dans lib par un overlay elles ne sont que dans pkgs.lib et pas directement dans le lib de {pkgs, lib, config, ...} ; mais bon :P
<julm>
mais grosso-modo je m'attendais (venant de Haskell) à ce que les lacunes du typage me découragent, mais pas vraiment au final (jusque là)
<samueldr>
les "collision between" arrivent généralement dans la création de "l'environnement", où deux dérivations utilisent le même nom de fichier dans un endroit où ils seront liés symboliquements (symlinkés)
<samueldr>
par exemple, s'il y en a deux qui tentent de définir le binaire hello dans bin/hello, quand les différents "sous-arbres" (sub-trees) seront fusionnés (merged) par défaut nix a aucune idée quoi faire
<julm>
samueldr: voui, du coup j'ai ce cas pour des /usr/share/ avec shorewall-core/shorewall/shorewall6 ; mais je ne pense pas que ça doivent se gérer avec des --set-flag, plutot en mieux réfléchissant à comment faire pour que les 3 paquets accèdent à leur /usr/share
<julm>
samueldr: j'ai aussi parfois des "collision between" avec nsd, pas sûr encore si ça vient de ma config ou de nixpkgs
<julm>
samueldr: comme je pense que c'est des warnings bénins, j'ai pas encore pris le temps d'approfondir trop
<samueldr>
exactement, dans un jeu de dérivations qui doivent coéxister, on peut pas se fier aux set-flag et priorités
<samueldr>
et je liais la section "--set-flag" surtout parce que y'a une description des priorités (meta.priority), qui des fois peut être utilisé
<julm>
bizarre, je n'ai pas de /share ni de /share/shorewall
<samueldr>
qu'est-ce que les autres distros font pour ipv4 vs. ipv6 pour shorewall?
<julm>
debian sépare
<julm>
c'est un peu messy l'installPhase que j'ai faite, je passe par du cp -r -s ${shorewall}/share/shorewall $out/share/ pour repeupler le /usr/share de shorewall6 our qu'il aille rajouter ses propres fichiers
<julm>
d'ailleurs, ça ne changerait rien, mais j'ai vu passer pkgs.symlinkJoin, qui a l'air de faire un peu pareil, je pourrais m'inspirer de ses usages pour voir si ya des trucs à faire
<julm>
c'est tellement un apprentissage par l'exemple nixpkgs, c'est ouf
<samueldr>
est-il nécessaire de coopier les fichiers? puisque shorewall et shorewall-core sont référés dans shorewall6, les deux seront présents dans le store; si au moment de la compilation shorewall a le chemin compilé d'avance, peu importe où il se trouve les fichiers seraient dans /nix/store/...-shorewall{,-core} ?
<samueldr>
à moins que shorewall tente de trouver les fichiers en "sniffant" son emplacement
<julm>
oui mais il les veut dans un même dossier
<julm>
ce serait trop beau si je pouvais lui dire d'aller regarder dans plusieurs dossiers, mais non, c'est pas des -Iblah/include
<julm>
j'ai essayé d’empaqueter sympa aussi (gestionnaire de mailing-lists en Perl), mais finalement je vais plutôt me rabattre sur Discourse (Ruby)
<julm>
j'ai trouvé un .nix pour installer Discourse via Docker dans NixOS, mais franchement c relou
<julm>
je vois que redmine est dans NixOS comme un paquet Ruby, pas de raison que Discourse non plus, même si du coup il faudra reproduire plus ou moins les services de la conf Docker dans des services NixOS je pense
<samueldr>
la dernière fois où j'ai regardé discourse pour l'intégration (avant que je connaisse nix, nixpkgs et nixos), le mot d'ordre était: personne n'est capable de savoir comment installer discourse sans le package omnibus :/
<julm>
omnibus ?
<samueldr>
script qui faisait tout
<julm>
jamais croisé
<samueldr>
c'était y'a au moins 3 ans de ça
<julm>
ok
<samueldr>
ouais, en 2015
<julm>
ma fois, moi j'arrive bien à installer discourse avec bundle install sous debian
<samueldr>
fort probable que la situation se soit améliorée depuis
<julm>
j'imagine que nixos a déjà des exemples d'install similaires qui pourrons me guider
<julm>
notamment car il s’y cache des customisations fines
<julm>
du type RUBY_GLOBAL_METHOD_CACHE_SIZE: 131072
<julm>
devrait pas trop y avoir de pb avec la prise en charge des migrations des données SQL lors d’une màj de Discourse
<julm>
non le plus pénible c'est que c'est des grosses installs qui prennent du temps
<julm>
de l'élec, du CPU et du réseau
<julm>
je préfère les trucs où je peux rapidement tester le résultat
<julm>
déjà rien que de devoir ajouter le support SASL à Dovecot et donc de devoir le recompiler ça me casse mon workflow
<eeva>
salut julm!
<julm>
yo eeva :)
<eeva>
\o/ j'ai réussi à faire tourner une «petite» VM sous NixOS pour builder le soft sur lequel je bosse
<julm>
p'tite colle technique du soir : lorsqu'une option d'un module est de type types.lines (typiquement systemd.services.blah.preStart) comment puis-je écraser le preStart apporté par NixOS pour ne garder que le mien ? (la fusion par défaut est de concaténer les différences configs)
<julm>
eeva: avec nixops et VirtualBox ?
<julm>
s/différences/différentes/
<eeva>
nope, en créant un image qcow2 de base que j'ai exporté sur un «petit» serveur (300G de RAM, 32 CPU, etc.). De là j'utilise libvirtd et kvm (et les drivers virtio) pour faire tourner ma VM
<julm>
ah ouais, « petit »
<eeva>
:D
<eeva>
julm: tu peux peut-être utiliser lib.mkForce pour ta question précédente
<julm>
moi pour l'instant je reste sur le chemin battu de nixops+VirtualBox, meme si bientôt j'envisage de déployer vers un APU de PCEngines ; vraiment pas une bête de compêt : https://www.pcengines.ch/apu2.htm
<eeva>
ou mkOverride
<julm>
eeva: j'ai essayé de bidouillé avec ça oui, mais sans succès, je ne comprends pas très bien cette machinerie pour le moment
<julm>
bidouiller*
<julm>
je réesayerai
<julm>
+s
<eeva>
ok
<eeva>
C'est pas dit que ça soit applicable, ça dépend comment ton option de config est mergée
<eeva>
(youpi les accords avec des mots anglais)
<julm>
ce serait bien utile parfois, surtout quand le preStart check la config, mais que ton bout de preStart (censé mettre les bouts de config requis) est concaténé après le check…
<samueldr>
il faut tirer une page de dragonball, et parler de FUSION (je sors)
<julm>
smurf ^^
<eeva>
:D
<julm>
pour ce qui est de l'install dans une VM via nixops, un bon truc à savoir c'est qu'on peut lui donner une image de base perso, et donc en construire une depuis le nixpkgs qu'on utilise ; ça va bcp plus vite
<julm>
récemment aussi j'ai découvert nix-plugins ; son builtins.extraBuiltins.exec me permet de récupérer des données dans password-store ou des estampillages des fichiers de mon dépôt git de config (typiquement pour générer le serial d’une zone DNS)
<julm>
oh, et si vous ne connaissez pas, j'utilise direnv qui modifie mon environnement en lisant le .envrc dans mon git de config ; très utile pour mettre les bons NIX_PATH/PASSWORD_STORE_DIR/NIXOPS_STATE/NIXOPS_OPTS/NIXOPS_DEPLOYMENT/GNUPGHOME/PATH/DISNIX_CLIENT_INTERFACE/DYSNOMIA_STATEDIR/…
<julm>
bon, j'utilise plus disnix, mais bon peut-être un jour, pour le moment c'est trop overkill
<julm>
dire que tout le monde autour de moi ne jure que par Debian ou Mint, mais pas moyen de revenir en arrière pour moi ; sauf que du coup pas moyen non plus de trouver bcp de personnes intéressées par nix avec qui causer