Pour ta gouverne, puisque ça continue dans les mythes à deux balles, dans Debian, si un paquet n’est pas supporté sur une architecture, il n’est pas supporté, point. Il n’a jamais été question de bloquer l’inclusion de quoi que ce soit pour des raisons de portabilité.

Les problèmes liés au support de nombreuses architectures provoquent ponctuellement des problèmes avec testing, qui n’ont pas d’impact sur le développement dans unstable. Donc dire que ça retarde les releases, c’est vrai dans une faible mesure, mais dire que ça retarde l’inclusion de fonctionnalités, c’est juste étaler ton ignorance.

[ Répondre ]

Prendre tuomov comme modèle. Fabuleux. Ça vous pose le personnage.

Merci pour ce moment de franche rigolade, ça fait du bien.

[ Répondre ]

Hahahaha le vieux maronnier des 56 architectures…

Pour ta gouverne, non seulement supporter plein d’architectures ne représente quasiment rien en temps pour les mainteneurs (ça occupe surtout les porteurs), mais cela permet un travail de QA et de nettoyage du code qui n’aurait jamais lieu sinon.

Par exemple, un bug magnifique trouvé dans XPCOM pas plus tard qu’aujourd’hui : https://bugzilla.mozilla.org/show_bug.cgi?id=434190

De manière générale, je ne sais pas d’où tu sors ta vision du monde du libre, mais tes commentaires sont tout simplement pathétiques.

[ Répondre ]

J'ai regardé pour iceweasel (2.0.0.14), ça ne semble toujours pas le cas

C’est un problème dans la façon dont le paquet est distribué sur les miroirs, mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.

Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.

Personne n’a rien contre de l’audit de patches, au contraire. Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.

[ Répondre ]

C'est peut être assez complexe à embarquer, mais Gecko est tout de même conçu pour être embarqué. Y a une doc et tout. D'ailleurs, si il ne l'était pas, on se demande comment a fait epiphany pendant des années, et comment font les autres logiciels qui embarquent gecko.

Ils s’arrachent les cheveux. D’où l’abandon.

Gecko aussi est fait pour être réutilisé...

Non, trois fois non. Gecko est conçu pour être le moteur de Firefox. Le reste, c’est de la seconde zone.

Gecko aussi. Gecko repose aussi sur cairo, gtk et cie... D'ailleurs l'un des liens le précise. Bref, ce n'est pas un avantage à webkit.

Webkit dispose d’une API entièrement basée sur GObject, qui permet de l’intégrer directement au système de classes de GNOME. Alors que Gecko nécessite l’utilisation de couches d’interface tordues en C++ et d’une quantité de code de glu qui ne fait que croître avec le temps. Quant à parler de réutilisation de GTK+ Gecko, c’est à peu près autant le cas que pour Openoffice. Utilisé oui, mais très mal utilisé, d’où les lenteurs terribles du port X11 par rapport au port Windows, par exemple.

En quoi Gecko ne le serait pas ?

Parce que Gecko est une usine à gaz, et que contrairement aux idées reçues, les développeurs de GNOME cherchent à alléger leurs applications.

[ Répondre ]

Non, c’est un constat objectif de comment les développeurs de Gecko axent leur développement. L’important pour eux, c’est de faire marcher Firefox, et le reste de toute façon est moins bien que l’extraaaaaordinaire Firefox, il est donc inutile de s’escrimer à le supporter.

[ Répondre ]

Gecko a été conçu pour être réutilisé.

Non. Le bon fonctionnement de gtkembedmoz est la dernière des priorités des développeurs. C’est déjà un miracle d’arriver à faire fonctionner quelque chose comme Epiphany dessus, et ça marche grâce à quantité de bidouilles immondes.

[ Répondre ]

Le site indique également que pour distribuer CUPS (avec les noms et logos originaux) dans un produit dérivé (par exemple une version patchée) il faudra l'accord de la société Apple. C'est précisément ce type de clause chez Mozilla qui avait conduit à la création d'Iceweasel par les développeurs Debian.

Ce n'est pas tout-à-fait vrai, et surtout j'ai lu tout et n'importe quoi dans les commentaires.

Ce type de clause existe aussi pour la marque Apache. Pourtant, Debian distribue des paquets Apache modifiés qui portent le nom Apache (ce qu'au passage, Redhat a refusé). Il existe un accord qui permet à Debian de distribuer des paquets modifiés de manière raisonnable sans demander l'accord de la fondation Apache. Cet accord n'a pas été possible avec Mozilla à cause de leurs demandes trop importantes : processus d'approbation des patches (inadmissible dans le cas de patches de sécurité, et ceci n'est qu'une des pièces de l'incompétence totale de Mozilla dans le domaine de la sécurité) et logo imposé à la licence non libre.

Sur le site de CUPS on peut lire : Apple Inc. has trademarked the Common UNIX Printing System, CUPS, and CUPS logo. These names and logos may be used freely in any direct port or binary distribution of CUPS. To use them in derivative products, please contract Apple Inc. for written permission. Our intention is to protect the value of these trademarks and ensure that any derivative product meets the same high-quality standards as the original.

Pour moi ça ressemble plus à Apache et il est plus que probable qu'Apple laisse les distributeurs tranquilles, contrairement à Mozilla.

[ Répondre ]

Le fait que c'est buggé au point d'en être inutilisable ?

[ Répondre ]

Je persiste à penser que ce site ne rend pas service à Debian et attise les ressentiments inutilement.
Et si tu arrêtais de brasser du vent ?

[ Répondre ]

Et aussi ta réponse à http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403330

Il a tagué le bug "confirmed", je ne vois pas ce qu'il te faut de plus.

[ Répondre ]

Groan, ok ubuntu est moins fignolé que debian mais si il ya des problèmes majeurs les releases ne se font pas quand même...
Ah, parce que la release d'edgy ne s'est pas faite ? Première nouvelle...

[ Répondre ]

1) les deadlines sont depasses car le client tire le prix vers le bas au max. Pas l'impression qu'il y ait grand monde qui tire quoi que ce soit vers le bas dans le cas de debian
Bah si justement, dunc-tank. Ils tirent la qualité vers le bas pour releaser plus vite. Le modèle Ubuntu, quoi.

Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
Dunc-tank nuit à la qualité de la distribution. Le but de ce projet est d'empêcher ça. À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank. Ce qui a doublement réussi puisque de nouvelles méthodes de QA ont été inventées conduisant à une amélioration globale de la qualité, et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.

Et Sam de conclure : « J'adore qu'un plan se déroule sans accroc. »

[ Répondre ]

Il faut s'en réjouir parce que la qualité des fixes Ubuntu est absolument à chier. C'est bien simple, à chaque fois que j'ai un patch qui vient de chez Ubuntu, je finis par le réécrire en grande partie avant de l'intégrer.

[ Répondre ]

Lis le rapport de bug Debian et la conversation entre Debian/Mozilla

Merci, mais je n'attends pas de voir passer des trolls sur linuxfr pour m'informer.

Tu le vois où le soucis de Debian pour respecter la marque Firefox ?

Mozilla corp. impose des conditions inacceptables pour utiliser sa marque, point. En particulier, le logo n'est pas libre et ne peut donc être inclus dans la distribution. Au passage je suis convaincu que personne ne respecte vraiment les règles imposées par MozCorp. Par exemple, le logo doit obligatoirement être apposé sur fond noir ou blanc. Manque de pot, avec quasiment tous les thèmes KDE ou GNOME, il se retrouve sur fond gris.

[ Répondre ]

Debian est contre le principe même de marque.

C'est sans doute pour ça que le projet a passé un accord avec la fondation Apache pour avoir le droit d'utiliser le nom Apache dans les paquets (ce que ne fait pas Redhat, par exemple). C'est sûrement encore pour ça que Debian utilisait jusqu'ici le nom Firefox en accord avec la MoFo. C'est aussi sans doute pour ça que Debian a fait chier le Debian Core Consortium pour qu'ils changent de nom.

Le projet Debian, probablement plus que toute autre distribution, est conscient des problèmes de marque. Il protège sa propre marque, dans des limites raisonnables. Mozilla ne veut pas qu'on utilise sa marque ? Très bien. La solution Iceweasel satisfait tout le monde ; à part peut-être Glazou, mais lui on s'en fout.

[ Répondre ]

Oui, tu pourrais. Je suis sûr qu'il y a plus de patch pour Linux que pour Firefox dans Debian. Merci d'avoir l'honnèté de le confirmer...

Sachant que le kernel Debian supporte plus d'architectures que celui de kernel.org, je vois mal comment il pourrait en être autrement.

Cela dit tu serais surpris du peu de patches qui sont appliqués, surtout par rapport à Redhat et son kernel de 200 Mo plein de patches moisis.

[ Répondre ]

Drag and drop depuis la fenêtre des signets, par exemple.

[ Répondre ]