Aurélien Bompard a écrit 951 commentaires

Effectivement, en plus je vois qu'on est d'accord sur le terme neutre, donc c'est cool. Par contre, je conserve mon avis sur le terme "s'élever".
Mais ça tombe bien, c'est un wiki :)

> s'élever dans le domaine public

Pas mal comme expression. Mais peut-être un peu trop caricatural pour que ça ait une chance de devenir l'usage commun.
Je propose :
- style neutre : « entrer dans le domaine public »
- style plus engagé : « atteindre le domaine public »

Peut-être qu'un héros millionnaire venu de l'espace a décidé de sauver la distrib ?

Trac est un excellent gestionnaire de projets, pas de doutes là-dessus. On l'utilise au boulot et on en est très contents.

Mais j'aimerais attirer l'attention des développeurs Python sur l'archi logicielle de Trac, que je trouve très intéressante. Jetez-y un coup d'oeil ici : http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

Je suis pas un expert d'archi logicielle, mais je trouve que c'est quand même un bel exemple de conception modulaire qui est détaillé ici.

Il semble que ØMQ ne soit pas une implémentation d'AMQP. Sur la première page du site il y a une comparaison avec AMQP indiquant que ØMQ est plus simple et plus rapide, et dans la FAQ il y a :

Does ØMQ support AMQP protocol?
It used to. The feature was dropped to protect ØMQ users from infringement on AMQP-related patents

C'est donc un protocole complètement différent, et probablement spécifique à ØMQ. Quelqu'un peut modifier la dépêche ?

Une autre façon de faire : regarde comment ils ont fait chez Trac
http://trac.edgewall.org/wiki/MailingList

Non, ça concerne tout le monde, mais l'astuce est que ça ne couvre pas tout le langage, loin de là. La réaction de la FSF: http://www.fsf.org/news/2009-07-mscp-mono
Des choses basiques ne sont pas couverte par la promesse, notamment la sérialisation en binaire, les expressions rationnelles, XPath, XSLT, et d'autres encore.
Il faudrait vraiment que le projet Mono sépare en deux le code qu'il distribue, pour que le développeur sache quand il met les pieds en eaux troubles.

Une partie de Mono est couverte par la promesse de "non-utilisation" des brevets de Microsoft, c'est le coeur du langage.

La question est donc : le programme utilise-t-il des parties de Mono qui ne sont pas couvertes ? Si non, alors il n'y a pas de problème, mais si oui, tes craintes sont valides.

C'est vrai que c'est mieux avec l'URL :
https://admin.fedoraproject.org/pkgdb/applications/Grisbi

Comme ce n'est pas flagrant à la lecture du site, je précise que les paquets Fedora sont prêts et publiés pour la 0.6 (Fedora 12 & 13)

> pourquoi cela a ete aussi difficile a mettre en place sur Fedora

Ça n'a pas été spécialement difficile, c'est juste que ça n'avait pas été fait avant.

Fedora, avec sa politique de proposer toujours les dernières versions des paquets, a peu d'infrastructure en place pour gérer les "anciennes" versions. Pour les bibliothèques par exemple, on essaye d'abord de porter le code vers la nouvelle version, et si vraiment on y arrive pas on fait un paquet "compat-libtrucmachin" qui sera viré dès qu'il n'est plus nécessaire.

La politique de Debian est très différente à ce niveau, donc ils ont déjà le travail d'installations parallèles de python depuis longtemps.

Moi je trouve ça bien de citer les gens qui ont fait le boulot. Ça donne un aspect plus "humain" aux développements qui ont été fait, c'est pas juste une entité nébuleuse genre "Red Hat" ou "Debian".

Normal, essaye de trouver des infos sur un futur produit d'Apple, tu verras...

(mode paratroll on)

Et demain, quand vous vous baladerez dans les couloirs du boulot avec votre serviette sur l'épaule, sous le regard incrédule de vos collègues, n'oubliez pas : PAS DE PANIQUE.

> L'utopie voudrait donc qu'un nouveau format de paquets [...] fasse son apparition

Et encore, ça ne résoudrait pas grand chose. On pense souvent que le problème vient du fait que le format DEB et le format RPM sont différents, mais quand on creuse on se rend compte que c'est faux. Exemple : je suis sur Fedora, je vais chercher sur rpmfind.net un paquet lambda qui correspond à mon application manquante. Il se trouve que le paquet vient de chez SuSE ou Mandriva, sur une version n-2, et donc forcément quand j'essaye de l'installer, je me fais jeter.
Et pourtant, c'est bien un RPM.

Le problème de compatibilité entre les paquets des distributions ne vient pas du format, mais du fait qu'ils sont compilés avec des bibliothèques différentes, pas forcément compatibles, avec des options différentes, etc.
En fait, le problème vient du fait que les paquets viennent de distributions différentes.

C'est là d'ailleurs le fond du problème : supposer que n'importe quel RPM peut s'installer sur n'importe quelle distribution basée sur RPM, c'est ignorer (voire nier) le travail de mise en cohérence fait par la distribution.

Et au passage, les deux formats ne sont pas si différents l'un de l'autre. En gros une archive, des méta-données décrivant le paquet et ses dépendances, et des scripts à exécuter autour de l'installation et de la désinstallation du paquet. On fait tout un foin sur les incompatibilités entre ces deux formats, alors que le problème n'est pas là.

Il y a selon moi quatre solutions au problème pour un distributeur de logiciel externe, si on exclut l'inclusion dans la distribution bien sûr :
- la compilation statique
- la fourniture, avec le programme, de ses bibliothèques dynamiques dans un dossier à part. C'est ce qui se fait le plus en ce moment (mozilla, jeux, etc.), mais c'est pas beaucoup mieux que la compilation statique
- l'utilisation d'un format spécifique type autopackage ou klik (le truc de SuSE qui monte dynamiquement une image iso)
- la distribution sous forme de source, avec peut-être un système pour créer automatiquement un package en local (type checkinstall)

Aucune de ces solutions ne semble miraculeuse, sachant qu'elles sont toutes un pis-aller à l'inclusion dans la distribution.

Autopackage n'a jamais vraiment décollé, c'est dommage je trouve. Des avis ?

J'ai un premier début initial de commencement de RPM qui marche, compilé sur Fedora, mais ça devrait marcher aussi sur les autres distribs basées sur RPM :

http://gauret.free.fr/fichiers/rpms/fedora/lugaru/lugaru-0.0(...)

Il y a un SRPM dans le même dossier pour ceux que ça intéresse.

En fait, je l'ai fait il y a quelques heures déjà, mais bon, fallait bien tester... ;-)

Tout ne marche pas génial, notamment le son qui est absent. Quand on fait un strace on voit qu'il essaye de chercher des mp3 alors que les fichiers sont en ogg, donc ça vient peut-être de là. Il y a aussi la limite à quelques niveaux seulement, je ne sais pas si c'est normal, si c'est retirable, et comment. J'utilise le buildsystem basé sur cmake qui a été proposé en contribution dans les heures qui ont suivi la publication en libre :) Voir http://blog.wolfire.com/2010/05/Zero-day-open-source-contrib(...)

Attention chérie, ça va packager.

Rhooo, pile poil avant un jour férié. C'est quand même bien joué :)

> Bien entendu chez fedora il sera beaucoup plus dur d'être un tout petit peu utile de temps en temps, tant pis.

Je pense que ça c'est une idée reçue, Fedora a besoin de monde autant que toutes les autres distribs. Il y a toujours des paquets à faire et à maintenir. Mais là n'est pas le sujet.

> Mais si vous avez lu jusqu'ici vous avez déjà compris que je continuerai d'être un couillon, et de soutenir un tout petit peu comme je peux mandriva. Non pas pour la société, non plus pour la distribution, mais pour son avenir. Parceque je veux encore y croire.

Si "être couillon", c'est "ne pas choisir la facilité systématiquement", alors t'inquiète pas, on est au moins deux. Mandrake-iva a toujours eu un gros potentiel, mais elle n'a pour l'instant pas eu le "déclic" pour décoller. Il faut "juste" trouver où est le frein à main et le débloquer, mais c'est plus facile à dire qu'à faire.

Tiens, ça alors, une rumeur de rachat de Mandriva. C'est bien la première fois que j'entends ça.

À part nous rapprocher du point Godwin, la comparaison n'a pas grand intérêt, vu que l'assoce est à un poste impliquant moins de responsabilités que celui de monsieur H.

Et puis faut arrêter, le calendrier des Dieux du Stade c'est sexiste aussi ?

Putain de politiquement correct de mes couilles.

Voilà, maintenant que ça c'est dit, je vais voir ailleurs. On a une super assoce qui nous parle de son avenir, et tout ce que j'ai trouvé à faire c'est lancer un troll sur une affiche vieille de 7 ans.

Désolé les gars.

Lpod est manifestement très intéressant et mériterait plus de visibilité. Si le code de xhtml2odt peut vous aider, n'hésitez pas (il me semble que les licences sont compatibles puisque vous êtes en GPLv3).

C'est vrai qu'on manque d'une bonne API de haut niveau sur le format OpenDocument, je vous souhaite donc tout le succès possible !

Depuis hier, j'ai fait un certain nombre de corrections dans les scripts fournis (Python et PHP), principalement pour la compatibilité avec des versions plus anciennes des interpréteurs et des bibliothèques.

Donc si vous avez testé hier et que ça vous a explosé dans les doigts, c'est le moment de retester !

Je rappelle qu'on peut récupérer un .tar.gz des sources par ce lien : http://gitorious.org/xhtml2odt/xhtml2odt/archive-tarball/mas(...) (pour ceux qui ne connaîtraient pas par coeur les méandres de Gitorious, et qui ne voudraient pas utiliser Git)

Merci pour les encouragements, ça fait très plaisir.

Exact, je n'étais pas très clair. Ce que je n'ai pas vu ailleurs, c'est un convertisseur de XHTML vers ODT relativement générique. Des plugins d'export ODT, ça existe, je suis bien d'accord. Par exemple j'en ai fait un pour Dokuwiki, et un lecteur écrivait plus haut qu'il y a un système équivalent sur Wikipedia.

Désolé pour la confusion...

On vient de me prévenir que le script PHP a une bête dépendance sur PHP 5.3 à cause de getopt, le module de lecture des arguments de la ligne de commande. C'est une erreur que je vais corriger très rapidement, en attendant utilisez plutôt le script python pour tester.
Merci !

Pas selon Wikipedia : Copyleft.