Re: lib static du paquet libvtk5
fred a écrit : > Je voudrais utiliser pour mes propres programmes, une lib en static du > paquet libvtk5. Seulement, ce paquet ne contient que des libs dynamiques. > Quelle est la raison ? Si la lib est utilisé par plusieurs applications, et c'est quand même le rôle d'une librairie, et que l'on découvre un bug voir une faille dans la lib, il est préférable de ne recompilé que la lib et pas les nombreuses applications. Pourquoi vouloir compiler en static alors que debian fournit un outils extrêmement simple de gestion des dépendances ? -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30JabberID : [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [SLIS] mise en place d'un repository
Eric Mercier a écrit : - est-il sérieux de valider "à la main" les mises à jour de security ? oui et non : oui, car 2 vérifications valent mieux qu'une, surtout en prod non car faire intervenir des dépos suplémentaires qui ne sont pas des mirroires des dépos officiels engendre amha plus d'erreurs humaines que pas de vérif :-) Ma solution à 2 bales : - Un dépos apt pour les paquets SLIS - Un ou des proxy apt pour les packets officiels pour décharger les serveurs officiels - Un verrou pour la mise à jour sous forme d'URL http => lancement des apt-get dist-upgrade que si http://monserveur/update contient "GO" -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30JabberID : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transitions problématiques
Pierre THIERRY wrote: > - les paquets foo (0.1-1) et bar (0.2-1) dépendent de libbaz, > - on introduit libbazc102 qui est en conflit avec libbaz, > - foo (0.1-2) est mis à jour pour dépendre de libbazc102, > - si je mets à jour foo, je perds bar, qui dépend encore d'une > bibliothèque qui dégage. ce cas n'arrive que si la libbazc102 est incompatible avec la libbaz. Si la lib présente une compatibilité ascendante la libbaz passe en v+1 et tous les paquets qui en dépendent continuent à fonctionner L'objectif, ce n'est pas d'avoir une sid qui marche bien même avec de multiples versions de librairie, mais bien une futur version stable et cohérente. Le fait de déclancher cette désinstallation permet de rédiger un rapport de bug sur le paquet qui n'a pas été compilé avec la bonne librairie. > En particulier, est-ce que des solutions ont été proposées pour que des > paquets de même nom et de versions différentes puissent coexister dans > l'archive Debian ? apt-get -s ou le "N" à la première question "Souhaitez-vous continuer [O/n] ?" et reportbug :-) -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30JabberID : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par défaut
Josselin Mouette a écrit : > Bon, c'est fini ce délire avec G_BROKEN_FILENAMES ? Non seulement cette > variable n'existe plus depuis belle lurette, mais les bidouillages avec > la gestion des locales de la glib n'ont jamais permis ce genre de > miracles. export [EMAIL PROTECTED] cp logo.png ééé.png gqview => attention pb d'encodage => ???.png dans gqview, renomage en èèè.png => le fichier est enregistré avec un nom en UTF8 export G_BROKEN_FILENAMES=1 même manips qu'au dessus ... gqview => affichage correcte sans message d'erreur export LANG=fr_FR.UTF-8 cp logo.png ààà.png gqview => affichage tout de suite correcte si je laisse un fichier en ISO-... gqview => attention pb d'encodage => ???.png et avec : export G_BROKEN_FILENAMES=1 gqview => affichage correcte sans message d'erreur Mais peut-être que gqview ne devrait plus gérer cette variable trop vielle :-)) -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
Re: nouveau paquet : unik-olsrd
On Thu, Mar 18, 2004 at 08:37:39PM +0100, Ludovic Rousseau wrote: > Le mieux est de placer sur une page web les fichiers nécessaires pour > reconstruire le paquet (.dsc, .diff.gz et .orig.tar.gz). effectivement, j'ais oublié de dire que tout est dispo à cette adresse : ftp://ftp.tcweb.org/pub/debian/ ou ajouter ces lignes dans le sources.list deb ftp://ftp.tcweb.org/pub/debian unstable main deb-src ftp://ftp.tcweb.org/pub/debian unstable main -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
nouveau paquet : unik-olsrd
Bonjour les DD francophone, Voila mon probleme je fabrique les paquets debian "unik-olsrd" et "unik-olsrd-gui" seulement comme ce sont mes premiers paquets, je ne sais pas s'ils sont bien fait. J'ai fait une demande d'aide sur debian-mentor, mais pas de réponse ... Comme mon anglais n'est pas extraordinaire, l'un de vous peut-il me donner un coup de main ? -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
bug ou pas bug : configuration dans /etc/cron.d/...
Bonjour à tous, Je me pose une question sur la légitimité d'un "bug". Voilà mon problème : awstats, du paquet du même nom, permet de faire des stats sur différents type de fichiers de log. Je l'utilise pour analyser les log d'apaches, et de squid. Seulement même si j'ai bien définit des fichiers de conf par fichier analysé (fonction nativement supporté par awstats) il me faut plusieurs entrées dans la crontab j'ai donc modifié le fichier /etc/cron.d/awstats seulement, il n'est pas définit comme fichier de conf donc la prochaine version va me l'écraser. -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
Re: entre stable et testing
sferriol wrote: > en fait j'essaie de voir comment mettre à jour ma distribution, car il y > a des bugs qui me bloquent, sans tout passer au niveau testing. la solution que j'utilises, c'est la recompilation : apt-get source -b :-) -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
Re[2]: Le bug le plus long
jeudi 28 février 2002, 13:51:58, Laurent a écrit : > Martin Quinson <[EMAIL PROTECTED]> writes: >> Le premier, c'est que c'est pas surqu'on ait le droit. La premiere regle de >> la constitution Debian est qu'on ne peut obliger quiconque à travailler sur >> quelque chose qu'il n'a pas choisi de faire. Il faudrait donc changer la >> constitution (ou arguer qu'il a *choisi* d'etre mainteneur), et ca ne se >> fait pas si simplement. > Il a choisi de travailler sur le paquet. Il pourrait aussi décider > qu'il préfère faire des rpm que des deb. On ne peut pas lui interdire ? exactement :) on ne peut pas lui interdire !! > La correction de bug est vraiment essentielle. Si des bugs sérieux > dépassent un an c'est qu'ils sont soit non reproductibles, ou alors le > mainteneur ne sait pas comment le corriger et doit demander plus > d'info ou de l'aide ou alors il fait très très mal sont travail. si tu trouves qu'il fait mal son travail, fait le à sa place et donnes lui la solution. > Il pourrait y avoir un courrier hebdomadaire automatique pour rappeler > au mainteneur qu'il doit fournir une réponse. Ce serait assez ennuyeux > pour que la plupart le fasse il mesemble. non, si moi je te dis fais ça et ça tous les jours, tu risques de te barrer très loin :( A+ Tom -- Thomas Clavier http://www.tcweb.dyndns.org . _/_/_/_/_/ _/_/ Centre d'expertise RGO. _/ _/ DATACEP Nord ._/ _/ +33 3 28 52 53 02 - +33 6 09 25 59 67 . _/ _/_/
