Packager des schémas XML
Dans les paquets demandés, j'en ai vu un qui m'intéresse, et qui ne devrait pas être d'une formidable complexité : les schémas XML expérimentaux de DocBook. L'ennui, c'est que s'il y a des règles pour les DTD SGML et XML, il n'y a sembe-t-il rien pour les schémas. J'ai bien trouvé une doc écrite par Mark Johnson, mais rien encore dans Debian officiellement. Dans ce cas, je les colle simplement dans /usr/share/docbook-xsd ? J'ai vu qu'il y a un /usr/share/xml installé par libglade, est-ce que je devrais y mettre les schémas ici ? Techniquement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpNH93USpy6A.pgp Description: PGP signature
Re: même programme en GTK 1.2 et GTK 2.0 dans le même paquet ?
Hello, > Le bug #196821 me demande : > jpilot: compile jpilot with --enable-gtk2 > gtk1.2 is on its way out, and jpilot supports gtk2 > > Que dois-je faire ? > 1. compiler avec gtk2 et me prendre plein de rapport de bugs ? Plein de rapport de bugs ? La version gtk2 n'est vraiment pas au point, ou il lui manque une bonne partie des bugs de la version 1.2 ? > 2. laisser tomber ce bug #196821 pour l'instant Autant éviter de laisser tomber un rapport de bug s'il est possible de le régler... > 3. créer un paquet jpilot2 avec l'application compiler pour gtk2 Cette solution est à éviter à mon avis. La plupart des paquets app2 ont été renommé en app au fur et à mesure des mois. Maintenant gtk+/gnome2 est la version par defaut pour la prochaine stable ... inutile d'ajouter un nouveau paquet à l'archive pour le faire retirer dans pas longtemps. > 4. avoir dans le même paquet jpilot les binaires pour gtk 1.2 et gtk 2.0 ? J'avouerai que cette solution ne me plait pas trop, mais pourquoi pas ... 'fin bon, j'éviterais quand même. > Les 3 premières solutions ne me conviennent pas vraiment. > Est-ce que la 4ème solution est jouable/souhaitable/une connerie ? Perso je pencherais largement pour la solution 1 si la version gtk2 est utilisable. A la limite attendre un peu et laisser le bug en état quelque temps ... mais la solution 4 n'est pas approprié à mon avis, et la solution 3 à oublier. Salutations, Sébastien Bacher
Re: même programme en GTK 1.2 et GTK 2.0 dans le même paquet ?
Ludovic Rousseau <[EMAIL PROTECTED]> writes: > Je maintiens le paquet jpilot qui est une application GTK 1.2. Le support > de GTK 2.0 n'est pas encore terminé mais il est possible de compiler > l'application avec --enable-gtk2 pour avoir une application > fonctionnelle (le « seul » problème concerne le texte avec lettres > accentuées donc ça ne gène pas tout le monde). Certainement pango qui râle car il ne peut pas afficher des textes non encodés en UTF-8. Ça concerne quand même tous les utilisateurs sauf les anglophones ! > Que dois-je faire ? > 1. compiler avec gtk2 et me prendre plein de rapport de bugs ? > 2. laisser tomber ce bug #196821 pour l'instant > 3. créer un paquet jpilot2 avec l'application compiler pour gtk2 > 4. avoir dans le même paquet jpilot les binaires pour gtk 1.2 et gtk 2.0 ? > > Les 3 premières solutions ne me conviennent pas vraiment. > Est-ce que la 4ème solution est jouable/souhaitable/une connerie ? Personnellement, je choisirais la deuxième solution. Un utilisateur peut ne pas être content, mais si le portage n'est pas stable, autant attendre plutôt que de se compliquer la vie. La quatrième solution n'est pas envisageable car elle duplique les dépendances, donc force à avoir les deux versions de GTK installées simultanément. Quand à la troisième, c'est encombrer l'archive Debian pour pas grand chose. A+ -- o Benjamin Drieu: [EMAIL PROTECTED] [EMAIL PROTECTED] o APRIL:http://www.april.org/ pgphuY6mSosIV.pgp Description: PGP signature
même programme en GTK 1.2 et GTK 2.0 dans le même paquet ?
Bonsoir, Je maintiens le paquet jpilot qui est une application GTK 1.2. Le support de GTK 2.0 n'est pas encore terminé mais il est possible de compiler l'application avec --enable-gtk2 pour avoir une application fonctionnelle (le « seul » problème concerne le texte avec lettres accentuées donc ça ne gène pas tout le monde). Le bug #196821 me demande : jpilot: compile jpilot with --enable-gtk2 gtk1.2 is on its way out, and jpilot supports gtk2 Que dois-je faire ? 1. compiler avec gtk2 et me prendre plein de rapport de bugs ? 2. laisser tomber ce bug #196821 pour l'instant 3. créer un paquet jpilot2 avec l'application compiler pour gtk2 4. avoir dans le même paquet jpilot les binaires pour gtk 1.2 et gtk 2.0 ? Les 3 premières solutions ne me conviennent pas vraiment. Est-ce que la 4ème solution est jouable/souhaitable/une connerie ? À+ -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --
Re: SCO license for Debian distrib
Christian Kaenzig <[EMAIL PROTECTED]> writes: > On Thursday 07 August 2003 21:37, Nicolas THOMAS wrote: > > .. mais je demendais ce qui ce passerai si un groupe publiait le > > noyau Linux en pretendant qu'il ne contient plus une ligne du code > > incrimine. > > Ca reviendrait à avouer qu'il y avait _effectivement_ du code appartenant à > SCO dans Linux. Qui a dit que tu devais enlever quelque chose :-) j'ai juste dit qu'il fallait le faire croire. Le seul bien qui pourrait sortir de tout ce remue ménage serait une jurisprudence prudence ... de violation de la GPL par SCO ! A part alimenter le FUD que peut on faire ? Y a t'il une assoce pour assigner SCO en référé comme chez les Allemands ?? Y a t'il un juriste dans la salle ? Très cordialement, Nicolas
Re: SCO license for Debian distrib
* Sven Luther [06:48 08/08/03 CEST]: Vous savez bien sur que autant IBM que Redhat on fait un proces en retour contre SCO, et que Redhat a mis en place un fond de 1 million de $ pour de futur proces contre des projet opensource. Mais IBM a ouvert la boite de pandore en utilisant sa montagne de brevets pour contre-attaquer SCO. Pour rappel, Bill Gates a récemment rapporté qu'il était probable que certains programmes en GPL utilisent des brevets appartenant à microsoft. Or comme les programmes sont sous la GPL, il est impossible de dire "OK on utilise ce brevet mais vous vous utilisez celui là, vous laissez tombez OK ?". Donc IBM en utilisant ses brevets pourrait ouvrir la voie vers d'autres actions contre certains programmes. De plus, que se passera-t-il quand IBM décidera qu'ils en ont leur soupe de linux ? -- (°> Nicolas Évrard / ) Liège - Belgique ^^ pgpzIYbgoG2v4.pgp Description: PGP signature
Re: SCO license for Debian distrib
On Fri, Aug 08, 2003 at 01:22:53AM +0200, Christian Kaenzig wrote: > On Thursday 07 August 2003 21:37, Nicolas THOMAS wrote: > > .. mais je demendais ce qui ce passerai si un groupe publiait le > > noyau Linux en pretendant qu'il ne contient plus une ligne du code > > incrimine. > > Ca reviendrait à avouer qu'il y avait _effectivement_ du code appartenant à > SCO dans Linux. > > > L'important a mon avis et de couper court a ce genre d'elucubration > > pour pas que d'autre soient trop tente > > > > On peut aussi jouer la mauvaise foi .. :-) > > Je pense aussi qu'il faut la leur fermer mais soit en les amenant à court > d'arguments, soit en leur balançant en retour un argument en béton (pour ça, > il faudrait déjà qu'ils précisent leur reproche. :-/). > > Le danger dans l'histoire est, à mon avis, bien sûr la discréditation de > Linux > vis-à-vis du grand public mais aussi que SCO ou d'autres s'attaquent à > d'autres producteurs de logiciel libre qui n'auraient peut-être pas les > moyens (surtout financiers) de IBM pour se défendre ! Vous savez bien sur que autant IBM que Redhat on fait un proces en retour contre SCO, et que Redhat a mis en place un fond de 1 million de $ pour de futur proces contre des projet opensource. Amicalement, Sven Luther
Re: SCO license for Debian distrib
On Thu, Aug 07, 2003 at 09:37:15PM +0200, Nicolas THOMAS wrote: > Georges Roux <[EMAIL PROTECTED]> writes: > > > Bonsoir, > > > > Je ne désre pas lance de troll sur ce forum. > > Moi non plus > .. mais je demendais ce qui ce passerai si un groupe publiait le > noyau Linux en pretendant qu'il ne contient plus une ligne du code > incrimine. BTW, l'avantage de debian, c'est que dans le pire des cas, on peut toujours utiliser le noyau HURD ou NetBSD, bien que ces ports ne soit pas encore reelement officiel. Amicalement, Sven Luther
