AviBlog

Pousser une branche locale sur le distant avec git

Vous avez cloné un dépôt Git et avez commencé une nouvelle fonctionnalité dans une branche locale (histoire de ne pas polluer la branche principale). Avant de fusionner, vous souhaitez publier le résultat de vos élucubrations pour une revue par vos pairs. Ce n'est pas si simple, et certains se sont penchés sur la question. Le résultat de cette recherche est une manip un peu barbare. Supposons que la branche en question s'appelle `zzz` bq. $ git checkout -b zzz # Let the hacking commence... $ git push origin zzz $ git checkout master # voir note[1] $ git branch -f zzz origin/zzz $ git checkout zzz # Let the hacking continue... La ligne bizarre est ??git branch -f zzz origin/zzz?? qui écrase localement la branche avec la référence de la branche distante. fn1. Comme l'explique l'auteur de l'article, on ne peut pas scier la branche sur laquelle on est assis, ce qui explique aussi le tour de passe-passe des checkout de master puis retour sur zzz.

La gestion de version revisitée

Ce soir, c’est les vacances !

Alors je vais vous parler de git . En fait, ça fait un moment que je voulais vous en parler.
Utiliser un système de gestion de version pour suivre correctement les évolutions d’un projet à base de fichiers a pu être une grande décision par le passé. Aujourd’hui, c’est d’une simplicité affligeante, et ne souffre aucun contre-argument (quoi ? Vous n’utilisez pas de système de gestion de version ?). C’est d’autant plus vrai pour les logiciels libres, car cela simplifie grandement la publication et le partage du code source. Mais justement, le partage du code source simplifié, reste le moyen simple de permettre à un tiers de commencer simplement à contribuer au projet.

Avec les systèmes de gestion de version centralisés (comme par exemple subversion qui est d’une bonne efficacité), beaucoup de barrières sont levées pour la collaboration des codeurs accrédités sur le projet, mais un tiers qui aura récupéré le code source du projet se retrouvera bien embêté pour commencer à gérer les versions en y incluant ses propres modifications. C’est ce que proposent de résoudre les gestionnaires de version distribués qui apportent la souplesse de permettre à un tiers de commencer à modifier, étendre et repartager un projet aussi simplement qu’un membre du projet. Git fait partie de cette (pas si) nouvelle espèce d’outils de gestion de version qui apporte souplesse et puissance au développement libre.

N’ayant testé que peu de ses concurrents, avec les déboires qu’on connait , je ne saurais dire quelle comparaison il soutient, mais les faits sont là : il est utilisé pour le kernel, wine, vlc, android et bien d’autres, ce qui devrait vous convaincre de sa puissance.

Mais je suis déjà en train de paraphraser le guide de Git progit que je suis en train de traduire . Les sources se trouvent là sur la plateforme github que je salue chapeau bas pour la simplicité et la puissance qu’elle confère à l’utilisation de git. Si vous souhaitez vous initier à cet outil fabuleux, pourquoi ne pas dupliquer mon dépôt et commencer à prêter main forte ?

Petits tracas dans l'informatique

“It’s not a bug, it’s a feature”. Cette phrase bien connue dans le monde informatique peut faire rire, ou pleurer… Cette dernière expérience m’est arrivée pas plus tard qu’hier.

Contexte : un ordinateur démarre connecté au réseau. Ses services se lancent très rapidement tandis que son interface réseau paramétrée par DHCP ne se trouve en nominal que bien après. Cependant, certains des services utilisent le réseau et cherchent à résoudre des noms avant d’avoir la connectivité.

Lorsque le service fait appel à la fonction gethostbyname, le fichier /etc/resolv.conf est lu pour déterminer les DNS à contacter pour obtenir la résolution des noms. Problème : ce fichier n’est lu qu’une fois, et ses données sont conservées en mémoire indépendamment du fait que le fichier /etc/resolv.conf puisse être mis à jour par la suite par le client dhcp.

Vous imaginez bien que c’est assez gênant de se retrouver sans résolution de nom dans un daemon qui doit a priori communiquer avec le monde extérieur. Je considère ceci comme un bug de la libc et pour plusieurs raisons :

* L’interface offerte au niveau de gethostbyname est une abstraction qui permet d’aller chercher la résolution de nom par différents moyens à disposition du système. Que le système aille piocher dans un fichier, sur un serveur avec un protocole spécifique, le client n’en a cure car il demande juste le service. * D’un point de vue architecture, le fait que la bibliothèque charge le contenu du fichier /etc/resolv.conf est une accélération par l’utilisation d’un cache. MAiS un cache doit avoir une politique de gestion d’obsolescence de ses données, et visiblement la glibc n’en a pas pour ce service de résolution.

Alors bien sur, “man resolver” indique clairement que le fichier n’est lu que lors du premier appel, mais le fait de documenter un bug ne suffit pas à le faire disparaître.

Je ne suis pas le seul à avoir rencontré ce problème. Des tickets de bugs ont été remontés au mainteneur de la glibc, le bien connu Ulrich Drepper, surtout connu pour ses rapports très tendus (à la Torvalds, diront certains) avec les personnes avec lesquelles il n’est pas d’accord. Sur ce point, M. Drepper n’est justement pas d’accord. Sa réponse est aussi simple que fausse :

bq[en]. nscd is required to make changes work. Period. I won’t add code into the stub resolver to check the file every time. This is far too slow. We have a perfectly fine solution, so use it.

bq[en]. I’ve been arguing to change the default to use nscd by default for a long time. In fact, we should completely remove the option to not use nscd.

Franchement, rajouter une dépendance pour ne pas avoir à gérer proprement un cache, ça me dépasse. Au final, c’est à l’application d’avoir à descendre dans les méandres de la résolution de nom du système pour obtenir que le service soit rendu correctement. Dans le cas de notre application, daemon embarqué sur un système complêtement sous notre maîtrise, c’est encore acceptable, mais il faut voir que pour toutes les applications dont la durée de vie est susceptible de dépasser le temps de connexion à un réseau (PC avec capacité de veille sur disque), celà signifie une danse avec les appels systèmes pour se remette à jour par soi-même. Un beau gaspillage de ressource…

Heureusement, la glibc est un projet libre et permet la dérivation. eglibc en est l’exemple. Debian et Ubuntu ont déjà basculé sur cette nouvelle libc, surement parce que leurs propositions de patch sont mieux acceptées upstream, ce qui doit rester l’avantage du logiciel libre.

Un petit mot au type derrière le comptoir.

Juste un conseil : pas la peine d’user ta salive en argumentation commerciale… C’est déjà grillé d’avance

Voilà celle qui propose une loi sur internet.

tout va bien : je suis protégé

Devinette pour les geeks

Pas de moi, donc interdite à tous les lecteurs GLMF :
Qu’est ce que le 14 février 2009 à minuit 31 et 30 secondes a de très spécial pour un geek unixien ?

Firefox et la communauté

Comment faire comprendre le principe de communauté autour du logiciel libre ? Avec une métaphore en forme de film

imprimante PDF sous ubuntu Ibex

J’ai eu du mal à trouver alors voilà :

bc. $ sudo apt-get install cups-pdf $ sudo /etc/init.d/cups restart $ sudo aa-complain cupsd

puis aller déclarer dans l’interface d’administration une nouvelle imprimante de type PDF, avec backend PDF. et voilà.

La dernière commande en ligne sert à ce que l’imprimante ait le droit d‘écrire le PDF généré dans le répertoire ~/PDF