Vincent Bernat a écrit 148 commentaires

Ce n'est pas dramatique non plus. Si LilyPond sort une version qui se compile avec Guile 2 dans quelques mois, il sera toujours possible de la backporter pour Stretch. Il suffit de continuer à utiliser le LilyPond de Jessie en attendant.

Sous Linux, cela utilise speech-dispatcher (démon "speechd"). Pour moi, cela a marché out of the box mais la voix par défaut n'est pas terrible. speech-dispatcher gère plusieurs moteurs, dont espeak et Festival ainsi que les moteurs utilisant mbrola. Au final, y'a quand même pas mal de composants en jeu et je n'ai pas réussi à avoir une voix correcte avec espeak en natif et Firefox ne semble pas aimer qu'on utiliser espeak+mbrola (peut-être n'arrive-t'il pas à lister les langages disponibles).

J'espère que quelqu'un va nous faire un journal sur "comment configurer speechd avec des super voix".

La discussion est assez symptomatique. La personne à l'origine de la discussion explique bien qu'il n'a pas le temps d'upgrader tous les six mois et donc qu'il utilise des paquets Debian. On lui répond en gros qu'il faut payer pour avoir une version maintenue à long terme.

Je vois ça comme de l'hypocrisie : ce besoin d'une version stable est publiquement considérée comme une hérésie alors qu'il y a manifestement de telles versions maintenues pour des clients qui paient (c'est donc un marché intéressant pour OwnCloud/NextCloud).

/etc/systemd/logind.conf est un fichier de configuration (car il est listé dans /var/lib/dpkg/info/systemd.conffiles). Aussi, s'il a été modifié des deux côtés, son remplacement sera toujours demandé à l'utilisateur, sauf si celui-ci lance dpkg avec --force-confnew (ce qui se fait difficilement par accident). Ce n'est pas quelque chose qui est géré par debconf donc le niveau de priorité n'a aucune importance.

A priori, les alternatives étaient plutôt poussives. Perso, j'ai utilisé tla/Arch pour travailler sur un fork interne de OpenWRT qui contenait également les sources du noyau, et fallait pas moins de 20 minutes pour commiter. Je crois me souvenir que c'était le même problème chez les concurrents, d'où l'insatisfaction de Linus quant à ces solutions.

Le cache IPv6 est bien différent de l'ancien cache IPv4. La table de routage IPv6 a toujours été organisée sous forme de FIB tree (alors que ce n'était pas le cas en IPv4 par défaut et donc le cache était à part) et le cache se trouvait alors sous forme d'entrées dans cet arbre.

Pas grand chose à rajouter, le résumé est bon.

Le problème de fond est effectivement que je n'ai plus trop le temps de le maintenir. Cela dit, une personne s'est proposée il y a quelques mois pour aider et a effectué la plus grande partie de l'upgrade. Le résultat est dans experimental. Ce sera uploadé rapidement dans unstable et quand ça atteindra testing, il y aura un retroportage vers Jessie qui sera fait. Ce sera beaucoup plus simple à maintenir car la sécurité se fait en backportant des versions plus récentes plutôt qu'en appliquant les correctifs sur des versions plus anciennes.

Roundcube est un bon upstream. Les failles critiques sont rétroportées sur les versions plus anciennes mais ce qui est plus mineur (i.e XSS et CSRF) ne l'est pas. On peut comprendre qu'ils ont aussi des contraintes de leur côté.

autocomplete est standard: https://html.spec.whatwg.org/multipage/forms.html#autofill

Ça a l'air assez sympa. Toutefois, la solution n'est pas décrite techniquement. Il faut un peu lire les sources. Quelques questions :

• Pas de vérification du certificat. D'ailleurs, comment sont distribués les certificats ?
• Utilisation de AES256-SHA comme suite d'algos. Quelque chose basé sur du Diffie-Hellman pour l'échange du master secret serait plus sympa. D'ailleurs, il y a l'air d'avoir aussi le support des suites ADH (mais pas d'échange de certificats donc sensible au MITM).
• Ça a l'air de passer sur du TCP, c'est pas ce qui est le mieux pour un VPN, il faudrait faire de l'UDP mais cela obligerait à passer par du DTLS.
• Est-ce qu'il faut un point de contact centralisé ou est-ce que cela fonctionne entièrement en pair à pair ?

sdb1 peut très bien apparaître plus tard. Du coup, systemd attend un certain temps plutôt que de ne pas monter le bidule. En l'absence d'indication contraire (notamment de la présence de l'option nofail), il ne démarre pas d'autres services car ceux-ci pourraient avoir besoin de ce point de montage. /etc/fstab ne permet pas d'exprimer des dépendances très complexes. Cela ne serait pas le cas avec un point de montage défini sous forme d'unit (en .mount).

zsh a une fonctionnalité de nom dynamique pour les répertoires. Ce sont des répertoires de la forme ~[X]. zsh appelle une fonction pour faire la traduction dans un sens ou dans l'autre (ce qui est utile pour que ton prompt affiche ~[titi]/toto $).

Je l'utilise pour faire des bookmarks ici.

bookmark titi
cd /
emacs ~[titi]/toto.txt

L'avantage, c'est que zsh gère pas mal de choses, dont la complétion et que cela fonctionne avec toutes les commandes. Comme taper ~[, c'est pas facile, je tape @@ à la place et zle le transforme en ~[ et ensuite, j'utilise la complétion.

Dans le cas de l'image, d'après l'auteur du journal elle était originellement dans le domaine public. > À partir de là, le PNG l'est aussi si l'auteur le désire, et distribuer le PNG respecte la licence. Ce n'est pas du logiciel !

Tout ce qui est distribué dans Debian doit respecter la DFSG qui impose la présence des sources. Ce point a été clarifié lors d'une GR et s'applique aussi aux images. La licence originale peut être plus permissive mais l'ensemble doit respecter la DFSG quand même, sinon, ça ne rentre pas dans Debian.

Dans debian/rules, le mainteneur touch les assets source et paf, ça reconstruit. Ou on efface les assets cibles et ça reconstruit aussi.

Il peut laisser les assets précompilés dans les sources. Les utilisateurs qui n'ont pas les dépendances continuent à les utiliser.

Mouais, facile de critiquer sans citer.

La plupart des critiques semblent venir du fait qu'on t'a demandé de t'assurer que les assets sont bien compilés depuis les sources. C'est une condition pour être compatible avec la DFSG. Il n'est toutefois pas interdit de fournir des assets précompilés, il faut juste que lors de la construction du paquet Debian, ces assets soient recompilés et donc que les sources soient présentes. Pour les autres utilisateurs, il n'y a donc aucune dépendance à ajouter, ils utiliseront les assets précompilés. Et cela n'a rien à voir avec le fait que tu sois upstream.

À partir de là, je prends les autres critiques avec des pincettes vu qu'on a bien dû t'expliquer la raison et que tu préfères en donner une autre ("on va sûrement économiser quelques centaines d’octets grâce à ça").

Le retrait de HAProxy est un souhait de l'upstream qui n'a pas aimé la façon dont HAProxy a été traité dans les précédentes releases. Debian a toujours traditionnellement suivi les choix de l'upstream. HAProxy a été immédiatement mis à jour dans les backports pour combler ce manque et sera présent dans Jessie.

Pas tout à fait légal vu que la licence indique qu'il ne peut être utilisé que pour des tests.

Hello,

J'ai regardé vite fait le packaging déjà fait par Ross et ça me semble OK (à première vue, faut juste squasher le changelog). Si quelqu'un se propose pour maintenir, je peux sponsoriser.

Si tu regardes, tu verras que y'a finalement pas grand chose de compliqué dans le packaging actuel. Le Python, ça se package assez bien. Si tu as un peu de temps, tu peux sans problème prétendre à maintenir toi-même le paquet dans Debian.

node.js n'a pas été affecté "par chance" par heartbleed: https://github.com/joyent/node/commit/28c6e42e

Un peu curieux de mettre Scratch en avant alors que c'est du Flash. Ou alors, il marche avec Shumway?

Comme pour le moment, le projet est orienté dev, il semble normal de préférer requirements.txt à setup.py.

Quant au fait de proposer le répertoire debian dans le dépôt même, cela n'a jamais été une mauvaise pratique tant que les tarballs releasés sont exempts de ce répertoire. Tiré du wiki:

Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default.

Perso, j'ai fait comme ça dans mon zshrc: https://github.com/vincentbernat/zshrc/blob/master/rc/paste.zsh

Voir aussi:

• https://github.com/robbyrussell/oh-my-zsh/pull/1698
• http://thejh.net/misc/website-terminal-copy-paste
• http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinwyc/what_you_see_is_not_what_you_copy.txt

systemd a sauté de la 44 à la 182 lors de l'intégration d'udev.

C'est une technique courante pour éviter l'allocation de /30 pour les interconnexions entre routeurs. Cela permet d'éviter de gaspiller des adresses IP.

Quelques éléments de réponse ici : http://justice4assange.com/US-Extradition.html#WUKJA