| 19 Jun 2023 |
 Pol | Je n'arrive pas a les faire fonctionner. | 20:17:55 |
 Minijackson | je vois:
ERROR: Guacamole protocol violation. Perhaps the version of guacamole-client is incompatible with this version of guacd?
| 20:18:52 |
| Minijackson | j'ai l'impression qu'il s'attend à être contacté avec le protocole guacamole, plutôt qu'une requête HTTP "normale" | 20:19:25 |
| Minijackson | * j'ai l'impression qu'il s'attend à être contacté avec le protocole guacamole, plutôt qu'une requête HTTP "normale" / vide | 20:19:31 |
| Minijackson | si jamais c'est trop embêtant, perso je ferait un seul test NixOS qui teste le serveur et le client en même temps | 20:21:12 |
| 21 Jun 2023 |
 Jules Lamur | Bonjour ici 👋 Ça serait possible pour quelqu'un ici d'approve / update cette PR pour bump ansible en 8.0.0 ? https://github.com/nixos/nixpkgs/pull/235220
Merci d'avance :) | 14:51:08 |
 raitobezarius | Salut Jules Lamur , y a des paquets cassés par cette PR ou c'était comme ça avant? | 16:03:26 |
| raitobezarius | Il faut que tu regardes si tu as introduit des breakages | 16:03:35 |
| raitobezarius | Sinon tu dois les marquer broken ou pinger les mainteneurs | 16:03:45 |
| raitobezarius | Et idéalement ne pas pinger @mweinelt même s'il était mainteneur par le passé, il ne veut plus gérer ce paquet IIRC | 16:03:57 |
| Jules Lamur | Hello, merci pour ta réponse. | 16:07:32 |
| Jules Lamur | Je ne suis pas l'auteur de la PR pour info. J'ai juste besoin d'ansible 8. | 16:07:48 |
| Jules Lamur | Je regarderai ca un peu plus en détail ce soir pour les paquets qui ont fail. | 16:09:54 |
| raitobezarius | Ah pardon, je pense qu'il faut répondre à l'auteur ceci du coup | 16:18:48 |
| raitobezarius | Et c'est pour ça que cette PR est bloquée je pense | 16:18:56 |
| 22 Jun 2023 |
|  ·☽•Nameless☆•777 · ± changed their profile picture. | 07:11:37 |
| 23 Jun 2023 |
|  @tomh:riotchat.de left the room. | 04:44:32 |
| 25 Jun 2023 |
| ·☽•Nameless☆•777 · ± changed their profile picture. | 06:23:50 |
 kidanger | Bonjour, j'essaie de comprendre un peu mieux la dynamique de nixpkgs. Par exemple le paquet mapcache est cassé depuis un moment (https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.mapcache.x86_64-linux/all?page=4). Quand je fais tourner nixpkgs-review sur un commit sur une des dépendances de mapcache, ça me donne une erreur, normal.
- Comment est-ce que les mainteneurs s'y retrouvent pour savoir si une erreur étaient déjà présente avant une contribution ?
- Comment est-ce que les mainteneurs décident d'accepter ou non une contribution dans le cas où elle casse un paquet (il y a bien un commit qui a cassé mapcache à un moment) ?
S'il y a de la doc sur ce sujet ("comment gérer une distribution") je suis preneur !
| 11:37:00 |
 symphorien | c'est très informel | 11:38:44 |
| symphorien | si c'est une dépendance très bas niveau, par exemple glibc, qui casse un paquet "feuille", c'est assez inévitable que ça arrive, donc c'est mergé si le nombre de paquets cassés, et leur importance subjective, est suffisamment faible | 11:39:39 |
| symphorien | pour des paquets intermédiaires (pas assez fondamentaux pour avoir une surveillance des conséquences spécifique comme glibc, mais qui ont quand même beaucoup de dépendances inverses) nixpkgs-review prend trop de temps donc personne ne se rend compte de rien | 11:40:53 |
| symphorien | fut un temps où hydra envoyait un mail au mainteneur quand son paquet était cassé, mais la logique avait des ratés qui spammaient beaucoup donc ça a été désactivé | 11:41:49 |
| symphorien | résultat il est possible que le mainteneur de mapcache ne soit pas au courant que son paquet est cassé | 11:42:08 |
| symphorien | (par ex je suis sur stable donc même si je me sers régulièrement de la plupart des paquets que je maintiens, s'ils sont cassé sur unstable je ne m'en rendrai pas compte) | 11:42:43 |
| symphorien | aussi parfois le mainteneur est juste passé à autre chose | 11:43:38 |
| symphorien | si ce paquet t'intéresse tu peux le corriger et t'ajouter comme mainteneur :) | 11:44:06 |
| symphorien | aussi y'a des cas où un changement linux casse darwin sans que les parties impliquées puissent tester darwin | 11:45:15 |
| kidanger | d'accord, c'est assez clair !
et côté "channels", est-ce que le fait que des paquets soit cassés sans être indiqués "broken" ralenti la publication de nixpkgs-unstable par exemple ? ou uniquement sur les paquets les plus importants ? | 11:45:33 |
| symphorien | il y a une liste de choses qui doivent marcher pour que le channel avance, et ça ne couvre certainement pas tout | 11:46:00 |
