| 21 Jun 2023 |
 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 |
| symphorien | https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents pour nixos-unstable (le lien vient de status.nixos.org) | 11:46:34 |
| kidanger | je vois, donc les paquets plus ésotériques sont plus souvent rattrapés lors des releases tous les 6 mois, ou marqué broken à ce moment j'imagine | 11:48:52 |
| symphorien | oui | 11:49:04 |
| symphorien | ça c'est un peu plus formalisé | 11:49:09 |
| symphorien | "rattraper lors des releases" s'appelle zhf (zero hydra failures) et en théorie tout ce qui ne compile pas après zhf est marqué broken | 11:49:42 |
| symphorien | une autre chose qui n'est pas du tout formalisée c'est quand on enlève un paquet parce qu'il est broken depuis longtemps | 11:50:29 |
| symphorien | le seul truc formel c'est d'ajouter un alias qui throw avec un message qui dit que le paquet a été supprimé | 11:50:58 |
| kidanger | merci pour les explications ! 👌 | 11:51:28 |
