jon a écrit 67 commentaires

Salut !

Tu écris :

1. Création d'un agent sur Azure via Azure CLI

Avant la création de la VM sur Azure, je m'assure d'avoir fait la configuration d'un agent côté Jenkins Master.

Tu pourrais détailler ce que tu fais exactement ici ?

De ce que je comprends :

• Tu créés une fois pour toute un agent dans le master, avec une adresse IP particulière X
• Cet agent reste toujours là, (pas de provisionnement dynamique au niveau du master)
• Quand tu lances az vm create, tu t'assures juste de spécifier l'adresse IP X (+ les autres paramètres)

Du coup, le (ou les) agent(s) configuré(s) sur le master reste toujours, même quand les agents sont éteints, j'ai tout compris ?

Autre question:

Ce plugin [Azure VM Agents] ne propose par défaut qu'une seule distribution Linux : Ubuntu. Même si FusionForge semble fonctionner sur Ubuntu, ce n'est pas dans la cible. Il est possible de créer des templates complémentaires. 2ème limite, le stockage de ces templates a un coût. Je suis un radin, j'ai abandonné la création de nouveaux templates et je me suis tourné vers une autre solution.

À la place de pre-créer des images spécifiques et des les passer en paramètres au plugin, as-tu essayé de :

• Passer en nom d'image "custom" les images officielles que tu utilises déjà via az vm create. Ça a l'air possible:

Using any marketplace image by specifying an image reference (provide image reference by publisher, offer, sku and version). You can get the publisher, offer and sku by looking at the ARM template of that image

• De passer ton script d'initialisation au plugin également (pas sûr de pouvoir passer une URL, mais au moins le copier dans Jenkins ?)

Enfin, je ne suis pas sûr de comprendre le temps passé sur ces VMs dans le dernier graphe (pas sûr de comprendre ce que tu veux dire par "validation des installations"), mais si tu créés beaucoup de VMs chaque jour, tu peux gagner un peu en temps d'exécution (et en fiabilité) avec des templates d'images : tu payeras un peu plus en coûts de stockage, mais tu payeras moins en tant d'exécution de VMs ;)

Merci pour les détails de ton installation, le bétail c'est cool !

C'est pas un peu bizarre d'appeler rsync "autrement" ?

Et voilà, encore un discours vendu au profit des sociétés pharmaceutiques.

Le cousin de ma sœur était bien malade et il en a pris une fois. Depuis, il a pu partir vers monde meilleur, alors hein. Arrêtons de cacher les mensonges et restons dans le concret.

Rapidement, tu peux expliquer tes aventures de vagabondage ? (j'ai vagabondé un peu aussi il y a pas si longtemps que ça, et la photo rappelle des souvenirs… :)

Et j'imagine que coder ou quoi avec ce que tu as l'air d'avoir sur cette première photo, c'est difficile, voir pas vraiment d'actualité pendant ce genre de voyage/vagabondage. Comment ça se passe/s'est passé avec tes différents projets/contributions ?

Sid : Presque bleeding edge et quelques bugs, jamais cassée

jamais cassée, je n'irais pas jusque là, ça m'est arrivé une poignée de fois en fait … en une douzaine d'années, bon OK.

Ceci dit, je suis d'accord avec toi sur le reste, cette Sid a bien mauvais réputation, alors que ça marche vraiment bien en pratique.

Il y avait eu il y a quelques mois une discussion intéressante sur Reddit à propos de ce format, discussion qui se trouve ici

Les avis y semblent beaucoup plus partagés qu'ici…

Tu dis dans des précédents commentaires que tu fais aussi pas mal de Salt, comment tu comparerais les deux aujourd'hui ?

Salut,

de loin, on dirait que FusionDirectory et FreeIPA se ressemble un peu, comment se comparent-ils en pratique ?

Article intéressant, mais vraiment trop spécifique à Debian : pourquoi faire des liens vers la page Debian de lynis alors que le projet a une vraie page web qui apporte un peu plus d'info quand même ?

Je me demandais quand est-ce qu'une initiative comme ça allait apparaître, vu comment CACert (qui reste à priori le "champion" actuel des certificats gratuits) n'arrive pas à percer, et que ça n'a pas l'air de vouloir changer.

Donc, à partir des "specs" d'acceptation pour être une autorité de certification reconnue de nos jours, de la part des grands distributeurs de certificats (comme ça, je dirais Mozilla, Debian, Fedora, et on peut en rajouter d'autres aussi), il "suffit" de trouver le juste milieu entre tout ça et de mettre en place une infrastructure d'autorité certification dont un des objectifs serait de se faire accepter par ses distributeurs…

Cool cool cool.

Je suis d'assez loin et de manière passive le développement de systemd et je suis globalement plutôt positif quand aux changements proposés.

Mais la dépêche commence avec :

systemd est un système de démarrage alternatif au démon init de System V spécifiquement conçu pour le noyau Linux, avec une meilleure gestion des dépendances entre services et le chargement en parallèle des services au démarrage.

… et en lisant le reste, je me demande à quel point cette description est encore vraie. Rien que dans cette dépêche, l'apparition d'un daemon SNTP et DHCP me paraît un peu bizarre. Je peux comprendre, à la limite, qu'on veuille mettre en place ces informations le plus tôt possible, mais de là à les intégrer à systemd directement ?

J'ai l'impression que ce logiciel grossi de plus en plus en phagocytant de plus en plus de services qui étaient avant externes à systemd, dans des projets bien séparés, et ça me fait un peu penser au syndrome NIH (Not Invented Here)

Pour être plus exact, gamin serait plutôt un remplaçant à FAM : il est plus récent que FAM, s'interface avec des sous-systèmes plus récent dans Linux (inotify au lieu de dnotify par exemple), est moins "dangereux" (fonctionne en tant qu'utilisateur qui a besoin de la fonctionnalité, pas en tant que root) et est censé consommé moins de ressources.

Il fournit la même API que FAM, c'est pour ça que les dépendances dans Debian sont définies comme ça.

(cf. https://people.gnome.org/~veillard/gamin/overview.html)

OK, je comprends ton problème.

Vu que tu as l'air d'être impliqué dans Debian, est-ce que ça serait pas mieux de mettre à jour le paquet python-mpd dans Debian pour utiliser python-mpd2 à la place ?

Comme tu le dis, le site officiel ne marche plus maintenant, l'auteur n'a pas été très présent (je crois qu'il avait redonné des signes de vie juste avant que le site ferme), le code officiel de ce paquet n'est plus disponible à part en remontant dans l'historique des dépôts Git ici et là… Jusqu'à la version < 0.5, python-mpd2 est censé assuré la compatibilité descendante avec python-mpd (j'ai cassé amélioré des trucs dans la version 0.5). Il y avait même, comme tu l'avais dis en 2012, un ITP qui a été laissé à l'abandon…

(et puis si j'ai un jour j'arrive à sortir une nouvelle version stable de Sonata, ça serait bien que ça soit déjà packagé dans Debian aussi :p )

Est-ce que tu pourrais détailler un peu plus ce qui ne va pas avec python-mpd2 et pourquoi tu as forké ?

J'ai rapporté un bug, non pas sur le Bugzilla de Wikimedia, mais sur le Jira de Wikidata Game à https://jira.toolserver.org/browse/MAGNUS-421

Je pense que pendant pas mal de temps, c'était malgré tout la solution la plus "standard", ou pratique, pour sérialiser de la donnée destinée à être échanger avec d'autres langages/logiciels.

Encore aujourd'hui en fait: mise à part JSON qui est livré de base avec pas mal de langages/bibliothèques de base, YAML qui est souvent cité comme alternative à XML n'est pas aussi disponible par défaut. C'est souvent juste à une nouvelle dépendance sur une bibliothèque, mais ça m'étonne pas que ça soit déjà trop pour certains développeurs…

… ca fait partie de la suite icedove/iceowl qui ont la bonté d'ajouter une restriction de plus à tes libertés d'utilisateurs puisque pour installer icedove+iceowl il est obligatoire abandonner la langue française au profit de l'anglais?

iceweasel-l10n-fr c'est pas bien ?

… icedove installe calandar-google-provider

$ apt-cache rdepends calendar-google-provider       
calendar-google-provider
Reverse Depends:
  iceowl
  iceowl-extension
$ apt-cache show iceowl iceowl-extension | grep calendar-google-provider
Recommends: calendar-google-provider
Recommends: calendar-google-provider

Recommends, pas Depends…

Bref ?

Parce que ça a de quoi miner le travail des DD ça …

Dernier commit sur le projet lui-même : 2012-09-21
Tout les liens vers l'historique des salons de discussions sont pétés depuis … au moins deux ans.

J'ai des projets qui sont hébergés là bas que je voulais suivre, c'est mal barré :/

Après vérification, c'est vrai que la liste des permissions demandées à l'installation fait un peu peur :
[…]

C'est en fait vrai pour la plupart des applications "flashlight" dans le top 10 sur Play Store…

En même temps, tes choix sont très limités : quand tu installes une application, tout un tas de permission te sont demandés sans, comme dit dans un autre commentaire, savoir vraiment à quoi elles sont utilisées pour.
Plusieurs fois, ça m'est arrivé de vouloir installer une application qui avait l'air top-moumoute pour ce que je voulais faire, et à regarder la liste des permissions, ça demandait des trucs bizarres pour ce qu'elle faisait. Oh, pas forcément super bizarres, mais on se demande le rapport.
Et dans ce cas là, à part dire "non" et ça s'arrête là, ben on ne peut pas faire grand chose de plus (à part avoir le code source, et vérifier, etc.)

Après vérification, c'est vrai que la liste des permissions demandées à l'installation fait un peu peur :

• Storage : modify or delete SD card contents
• System tools: Prevent phone from sleeping (bon OK)
• Your location: Coarse location & fine location
• Phone calls: Read phone status and identity
• Network communication: full Internet access
• Hardware controls: Take pictures and videos (ptêtre pour la flashlight?)

(plus celles qui sont "cachées" par défaut):

• System tools: install shortcuts, etc.
• Network communication: view WI-FI state, network state
• Hardware controls: control flashlight (ah ben non !)

Je me demande même ce qui se passe si on installe une application avec un ensemble de permission X et que ces permissions changes au cours du temps ? Est-ce qu'elles sont reconfirmées au moment de la mise à jour ou est-ce que c'est silencieux ?

Ça me rappelle il y a quelques mois, je voulais jeter un oeil au livre "Real World Ocaml" alors qu'il était encore en phase de relecture. C'était possible via une application web qui demandait un accès au compte Github via OAuth ou un truc du genre (pour avoir un système de commentaires de revue sur le livre, je me souviens plus les détails de comment ça marchait), et les permissions minimales demandées donnaient accès en lecture/écriture à tout les dépôts de ton compte Github… Super ! La FAQ tentait d'expliquer pourquoi ça demandait tant de permissions (apparemment, c'était pour le coup une limitation de Github), mais ça m'a calmé du coup. Et j'ai pas revue le livre avant la sortie du coup.

Bref, sans commentaires de l'auteur, sans vérification du code pour être sûr, je suis un peu sceptique sur ces histoires de permissions, quand on en demande beaucoup comme ça.

Je suis mainteneur d'un projet qui utilise PyGObject (Python 3 + GObject-Introspection) et je suis pour le moment moyennement satisfait.

PyGObject a encore pas mal de défauts je trouve qui rende son utilisation pas forcément facile :

• manque de doc : la plupart du temps, il faut lire l'API C du module qu'on veut utiliser et essayer de deviner comment l'utiliser en Python. http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html est intéressant mais pas suffisant, j'ai une todo-list longue comme le bras de trucs que je voudrais rajouter dedans, mais j'ai jamais pris le temps de le faire (ça c'est ma faute).
  Du coup, pour les fonctionnalités de base, c'est assez facile, mais dès qu'on sort de l'ordinaire, ça devient parfois compliqué, surtout que …

• le wrapper n'est pas complet : PyGObject introduit une espèce de couche intermédiaire en Python (les "overrides") qui masque l'API C en proposant une API Python "plus agréable", comme par exemple récupérer le résultat d'un appel de fonction comme résultat de la fonction Python, et non comme un pointeur à passer à la fonction. Sauf que ces "overrides" sont fait à la main, au cas par cas, et que quand on tombe dans un cas où il n'existe pas, c'est pas joli à voir. J'ai plus d'exemple en tête, mais il faut créer des objets GVariant avec les types qui vont bien, les passer en paramètres à la fonction et récupérer le résultat dedans après…
  Il y a aussi des bugs dans les bibliothèques qui fournissent les informations d'introspection, qui font ben qu'il faut attendre la prochaine version pour avoir un truc utilisable. Les mainteneurs sont assez ouverts pour rajouter un override qui va bien, sauf que …

• c'est le bordel dans les versions de PyGObject : si on veut pas se taper le boilerplate ci-dessus, on est obligé de cibler une version super-récente de PyGObject … qui n'est pas disponible de partout : Debian testing a 11 versions de retard par exemple (Debian stable n'en parlons pas), j'avais des utilisateurs sous Gentoo qui étais obligé d'unmasker python-gobject je crois et d'autres problèmes sous Archlinux. J'ai des warnings quand je lance mon application, si je fixe mon warning ça ne marche pas avec des anciennes versions de PyGObject (j'ai dû annuler mon commit).
  Au final, on se retrouve soit à ajouter du boilerplate vraiment dégeulasse et temporaire pour pallier au manque de PyGObject, soit on vise que des versions super-récentes de la bibliothèque, soit on ne fait pas (en ce moment, je fais juste pas :/ )

• les performances. PyGObject et PyGtk (l'ancien wrapper statique) sont le jour et la nuit niveau performance ; sur des exemples simples (ajouter des éléments dans un Gtk.ListStore par exemple), on a des temps multipliés par 4 en utilisant PyGObject. Les mainteneurs sont au courant qu'il y a des problèmes de performance, et il y a eu plusieurs modifications dans ce sens, mais c'est pas encore assez suffisant :/

• la stabilité : je sais pas si ça vient exactement de PyGObject dans ce cas là, mais j'ai eu plusieurs Segmentation Fault depuis qu'on est passé à Python 3 + PyGObject, inreproduisible, ça arrive juste comme ça. Par mauvaise conscience, j'accuserais quand même PyGobject, sans vraiment pouvoir le montrer…

Au delà de ça, je trouve la techno super intéressante, et c'est un point de passage obligé dès qu'on cible Python 3, mais à l'usage c'est pas forcément très agréable…

J'ai commencé à m'intéresser à LDAP cette année, et j'aurais bien fais un saut pour voir un peu ce que peuvent en dire des gens qui l'utilisent depuis longtemps, mais entre le prix de la conférence et le prix de l'aller-retour avec Grenoble, j'ai laissé tomber. Dommage :/

Multi-tâches.
Pouvoir consulter un mail ou plusieurs en même temps qu'on en rédige un nouveau. Et pouvoir ouvrir une pièce jointe en tâche de fond.

Loin de dire que Mutt est mieux en terme de multi-tâches que Claws-mail (j'ai juste pas de multi-tâches dans mon Mutt, je le vis pas plus mal en fait), mais c'est bien quelque chose qui m'a vraiment énervé avec Claws-mail : le fait qu'il bloque les 3/4 des opérations effectuables sur la boîte mail dès qu'une opération est déjà en cours. Je suis plus trop sûr de mes exemples, mais j'avais à un moment une petite quarantaine de dossiers dans lesquels je classais mes emails, et quand Claws-mail parcourait le tout pour voir si il y avait des nouveaux messages, impossible de consulter quoi que se soit dans la dossier actuellement ouvert dans l'interface. Ou quand je cliquais malencontreusement sur un message envoyé par maman avec de belles pièces jointes de 4 Mo chacunes, pareil, blocage tant que toutes les pièces jointes n'avaient pas été téléchargées.

Et c'est pas tant l'interface graphique elle-même qui reste bloquée. C'est juste les opérations sur les messages et dossiers. C'est encore presque plus frustrant, plusieurs fois je me suis retrouvé à killer Claws-mail ou à déconnecter le réseau pour qu'il arrête juste.

Bref, j'ai plus le problème avec Mutt, j'ai pas la possibilité de faire plusieurs choses à la fois. Ça a réduit quelque part (un peu) ma frustration (ya des trucs qui m'énerve aussi..!)

Brefle. /coup de gueule

Même si effectivement, il y a un cout à aller demander à la base de données ses définitions, je ne pense pas que ça soit très impactant niveau performance, surtout que c'est effectué qu'une seule fois au chargement de l'application, et que c'est probablement optimisé et rapide de toute manière (pas testé, mais je suppose). C'est éventuellement un problème pour des scripts qui ne s'exécute qu'une seule fois, mais je pense que le cout est minime par rapport au reste malgré tout.

Pas sur de comprendre la deuxième partie de ta phrase ? Le SQL a beau être une norme, vous serez obligés de dépendre d'un SGBD de toutes manières, ne serait-ce que pour les différences de syntaxe entre chaque moteur de base de données.

J'avais fais un truc qui construisait des requêtes avec cette partie de SQLAlchemy, et qui générait derrière des vrais requêtes SQL complètes (pas séparées entre requête et données comme vous faites dans python-sql) suivant le type de moteur qu'on voulait interroger (SQLite, PostgreSQL, MySQL, etc.), pour le donner ensuite au requêteur de Twisted. C'était une fonction de 5-6 lignes à tout péter je crois, mais j'arrive pas à remettre la main dessus :(