Re: backport Xfree-4.3 sarge/sid?
On Thu, 18 Dec 2003 12:31:40 +0100 Stan Pinte <[EMAIL PROTECTED]> wrote: > bonjour, > > quelqu'un aurait-il un backport qui traîne pour Xfree 4.3, pour > sarge/sid? > > people.debian.org est toujours down... Oui, je m'en suis aperçu et ai mis le paquet xserver-xfree4.3 sur deb ftp://boisson.homeip.net/Xfree4.3 ./ C'est le paquet qu'il y avait sur people.debian que j'ai récupéré dans un cache. Ravi si ça t'est utile François Boisson > > Merci!! > > Stan. > > -- > Stan Pinte > tel: +32 499 25 94 24 > > > -- > Pensez à lire la FAQ de la liste avant de poser une question : > http://savannah.nongnu.org/download/debfr-faq/html/ > > Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
Re: backport Xfree-4.3 sarge/sid?
Le jeu 18/12/2003 à 12:31, Stan Pinte a écrit : > bonjour, > > quelqu'un aurait-il un backport qui traîne pour Xfree 4.3, pour sarge/sid? > > people.debian.org est toujours down... > > Merci!! > > Stan. > > -- > Stan Pinte > tel: +32 499 25 94 24 Bonjour, Pour une sid , voila comment j ai procédé : Changement de /etc/apt/sources.list rajout de : # XFree86 4.3 for experimental deb http://http.us.debian.org/debian/ ../project/experimental main contrib non-free deb-src http://http.us.debian.org/debian/ ../project/experimental main contrib non-free Ensuite : apt-get -t experimental install x-window-system-core libxcursor1 libxcursor-dev x-window-system xbase-clients xfonts-100dpi-transcoded xfonts-75dpi-transcoded xfonts-75dpi xfonts-100dpi xfonts-base xfonts-base-transcoded xfonts-scalable xfree86-common xserver-xfree86 Enfin : dpkg-reconfigure xserver-xfree86 Personnellement ,sur mon portable compaq 2544ea , la carte graphique n etait pas reconnue par XFree .( ATI Technologies Inc Radeon IGP 340M ) Depuis le changement , c est nickel. En espérant que ca t aide . -- - Christian Dare CRI/IUP Telecom et reseaux tel CRI : 02-98-01-82-39 6 Avenue le Gorgeu tel STAPS : 02-98-01-82-60 C.S. 93837 29238 Brest Cedex 3 -
backport Xfree-4.3 sarge/sid?
bonjour, quelqu'un aurait-il un backport qui traîne pour Xfree 4.3, pour sarge/sid? people.debian.org est toujours down... Merci!! Stan. -- Stan Pinte tel: +32 499 25 94 24
Re: Backport XFree 4.3
On Fri, Jun 13, 2003 at 07:43:51PM +0200, Erwan David wrote: > Le Fri 13/06/2003, Sven Luther disait > > > > S'il faut compiler le noyau alors autant le patcjher directement et > > > tout faire d'un coup. > > > > Explique moi alors comment tu fait pour par exemple les drivers unicorn > > pour les modems Bewan ADSL PCI st et USB ? Tu ne peut pas patcher ton > > noyau. De la meme maniere, de nombreux modules livre sous forme de > > package ne sont pas des patches, mais des modules package separement > > (pas packager dans le sens debian, mais dans le sens upstream). > > Je suis la doc qui viens avec le source et je fous le .o dans > /lib/modules tout simplement. Et je vais t'étonner mais ça marche. Et > s'il y a un problème à reporter au développeur ce ne sera pas > parasité par la machinerie debian Oui, sauf que moi en tant que mainteneur debian, j'ai de bon contacte avec upstream, que la version qui est dans le package debian (0.5.3) n'est pas disponible chez upstream (0.5.2), que j'ai ajouter un patch apres discussion avec upstream qui est necessaire pour les cartes meres a base de chipset KT400, qu'en cas de probleme, upstream sera plus a meme de m'ecouter moi, qui aurai deja fais un tri entre les bugreport qui valent la peine et les autres, ou d'ecouter un utilisateur quelconque. Que la machinerie debian ne vient en rien perturber mes relations avec upstream, tout au contraire, elle l'ont obliger a mettre au clair certaines choses qui etait un peu brouillo precedement (surtout au niveau des Makefiles). Que par dessus le marche, si tu install le module upstream, et que tu n'a pas ta carte pci dans la machine a ce moment la, tu te retrouve uniquement avec les modules usb, ce qui ne marche pas trop, alors que le package debian install les deux. Mais bon, je vais suivre les conseils et arreter ici ce thread (je sais, je sais, deuxieme fois que je le dis), de toute facon, tu a deja ton idee et rien ne t'en fera demordre. Amicalement, Sven Luther
Re: Backport XFree 4.3
* Erwan David <[EMAIL PROTECTED]> [2003-06-13 18:29] : > Le Fri 13/06/2003, Frédéric Bothamy disait > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nvidia&searchon=names&subword=1&version=all&release=all > > > > et la documentation des paquets nvidia-kernel-src et nvidia-glx-src > > explique clairement comment faire (si on prend le temps de la lire). > > c'est ce que je disais, mais elle n'utilise pas make-kpkg (ou alors > c'est caché) Ah zut, c'est tellement caché que c'est indiqué dans la 2e méthode. Si tu avais lu le fichier README.modules, tu aurais vu qu'il s'agit exactement de la même méthode. > > La documentation de make-kpkg (exactement le fichier README.modules) > > détaille précisément ce cas-là. > > Non. README.modules commence par > té&léchergez le source du noyau et compilez le. Et compilez-le "avec make-kpkg" ... > S'il faut compiler le noyau alors autant le patcjher directement et > tout faire d'un coup. Tu patches ton noyau avec les pilotes nvidia ? Je croyais qu'il fallait les compiler séparément ... Fred -- LA FAQ d-u-f ? http://savannah.nongnu.org/download/debfr-faq/html/
Re: Backport XFree 4.3
Erwan David a écrit : Le Fri 13/06/2003, Raphaël SurcouF Bordet disait Le ven 13/06/2003 à 19:27, Erwan David a écrit : En voilà une autre: gérer les divers patchs que tu veux y appliquer. Une fois l'outil en main, ça n'a rien à voir avec le mode manuel... Y'a plus besoin de récupérer les patchs et de les passer ? Tu n'es pas obligé d'appliquer tous les patchs des paquets kernel-patch que tu récupères... non, faut juste 1) se limiter aux patchs packagés, 2) les installer avant de compiler. On a trouvé une utilisation très limitée (quand on veut patcher avec des patchs packagés mais pas appliqués)... Bof, bof, bof. Croyais pas qu'il faudrait couper se fil, qui n'a plus aucun rapport avec son contenu original (Relisez le sujet ;-)) ) Cordialement, Nicolas.
Re: Backport XFree 4.3
Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > Le ven 13/06/2003 à 19:27, Erwan David a écrit : > > > > En voilà une autre: gérer les divers patchs que tu veux y appliquer. > > > Une fois l'outil en main, ça n'a rien à voir avec le mode manuel... > > > > Y'a plus besoin de récupérer les patchs et de les passer ? > > Tu n'es pas obligé d'appliquer tous les patchs des paquets kernel-patch > que tu récupères... non, faut juste 1) se limiter aux patchs packagés, 2) les installer avant de compiler. On a trouvé une utilisation très limitée (quand on veut patcher avec des patchs packagés mais pas appliqués)... Bof, bof, bof. -- Erwan
Re: Backport XFree 4.3
Le ven 13/06/2003 à 19:27, Erwan David a écrit : > > En voilà une autre: gérer les divers patchs que tu veux y appliquer. > > Une fois l'outil en main, ça n'a rien à voir avec le mode manuel... > > Y'a plus besoin de récupérer les patchs et de les passer ? Tu n'es pas obligé d'appliquer tous les patchs des paquets kernel-patch que tu récupères... -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Fri 13/06/2003, Sven Luther disait > > S'il faut compiler le noyau alors autant le patcjher directement et > > tout faire d'un coup. > > Explique moi alors comment tu fait pour par exemple les drivers unicorn > pour les modems Bewan ADSL PCI st et USB ? Tu ne peut pas patcher ton > noyau. De la meme maniere, de nombreux modules livre sous forme de > package ne sont pas des patches, mais des modules package separement > (pas packager dans le sens debian, mais dans le sens upstream). Je suis la doc qui viens avec le source et je fous le .o dans /lib/modules tout simplement. Et je vais t'étonner mais ça marche. Et s'il y a un problème à reporter au développeur ce ne sera pas parasité par la machinerie debian > De plus, appliquer certains patch au noyau peut entrainer une rupture de > la GPL si tu distribue le resultat. Je m'en fous : je ne redistribue pas. -- Erwan
Re: Backport XFree 4.3
Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > Le ven 13/06/2003 à 17:56, Erwan David a écrit : > > > C'est pas ce qu_i est dans la doc. De toute façon le problème n'est > > pas là. On peut certainement faire pleind echoses avec > > make-kpkg. C'est simpelemnt une usine à gaz complexe qui n'apporte > > *rien* à celui qui n'a pas besoin de déployer son noyau sur plusieurs > > machines. > > > > Personne n'a encore été capable de citer une autre utilisation ou > > make-kpkg et ses incantations de magies noires apporte quoi que ce > > soit. > > En voilà une autre: gérer les divers patchs que tu veux y appliquer. > Une fois l'outil en main, ça n'a rien à voir avec le mode manuel... Y'a plus besoin de récupérer les patchs et de les passer ? -- Erwan
Re: Backport XFree 4.3
On Fri, Jun 13, 2003 at 06:29:19PM +0200, Erwan David wrote: > Le Fri 13/06/2003, Frédéric Bothamy disait > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nvidia&searchon=names&subword=1&version=all&release=all > > > > et la documentation des paquets nvidia-kernel-src et nvidia-glx-src > > explique clairement comment faire (si on prend le temps de la lire). > > c'est ce que je disais, mais elle n'utilise pas make-kpkg (ou alors > c'est caché) > > > La documentation de make-kpkg (exactement le fichier README.modules) > > détaille précisément ce cas-là. > > Non. README.modules commence par > té&léchergez le source du noyau et compilez le. > > S'il faut compiler le noyau alors autant le patcjher directement et > tout faire d'un coup. Explique moi alors comment tu fait pour par exemple les drivers unicorn pour les modems Bewan ADSL PCI st et USB ? Tu ne peut pas patcher ton noyau. De la meme maniere, de nombreux modules livre sous forme de package ne sont pas des patches, mais des modules package separement (pas packager dans le sens debian, mais dans le sens upstream). De plus, appliquer certains patch au noyau peut entrainer une rupture de la GPL si tu distribue le resultat. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le ven 13/06/2003 à 17:56, Erwan David a écrit : > C'est pas ce qu_i est dans la doc. De toute façon le problème n'est > pas là. On peut certainement faire pleind echoses avec > make-kpkg. C'est simpelemnt une usine à gaz complexe qui n'apporte > *rien* à celui qui n'a pas besoin de déployer son noyau sur plusieurs > machines. > > Personne n'a encore été capable de citer une autre utilisation ou > make-kpkg et ses incantations de magies noires apporte quoi que ce > soit. En voilà une autre: gérer les divers patchs que tu veux y appliquer. Une fois l'outil en main, ça n'a rien à voir avec le mode manuel... -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Fri 13/06/2003, Sven Luther disait > > > > Personne n'a encore été capable de citer une autre utilisation ou > > make-kpkg et ses incantations de magies noires apporte quoi que ce > > soit. > > Surtout lorsqu'on ferme les yeux lorsque le 'personne' en question te > les expliques. Non, tu m'as expliqué que même avec make-kpkg il fallait toujours recompiler complètement le noyau. Ça se fait qussi bien sans make-kpkg. L'apport est nul. -- Erwan
Re: Backport XFree 4.3
Le Fri 13/06/2003, Frédéric Bothamy disait > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nvidia&searchon=names&subword=1&version=all&release=all > > et la documentation des paquets nvidia-kernel-src et nvidia-glx-src > explique clairement comment faire (si on prend le temps de la lire). c'est ce que je disais, mais elle n'utilise pas make-kpkg (ou alors c'est caché) > La documentation de make-kpkg (exactement le fichier README.modules) > détaille précisément ce cas-là. Non. README.modules commence par té&léchergez le source du noyau et compilez le. S'il faut compiler le noyau alors autant le patcjher directement et tout faire d'un coup. -- Erwan
Re: Backport XFree 4.3
On Fri, Jun 13, 2003 at 05:56:11PM +0200, Erwan David wrote: > Le Fri 13/06/2003, Philippe Marzouk disait > > > > surtout que les modules nvidia sont packagés (bien qu'avec > > téléchargement du tar.gz chez Nvidia) et donc compilable via > > make-kpkg. > > C'est pas ce qu_i est dans la doc. De toute façon le problème n'est > pas là. On peut certainement faire pleind echoses avec > make-kpkg. C'est simpelemnt une usine à gaz complexe qui n'apporte > *rien* à celui qui n'a pas besoin de déployer son noyau sur plusieurs > machines. > > Personne n'a encore été capable de citer une autre utilisation ou > make-kpkg et ses incantations de magies noires apporte quoi que ce > soit. Surtout lorsqu'on ferme les yeux lorsque le 'personne' en question te les expliques. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Fri 13/06/2003, Philippe Marzouk disait > > surtout que les modules nvidia sont packagés (bien qu'avec > téléchargement du tar.gz chez Nvidia) et donc compilable via > make-kpkg. C'est pas ce qu_i est dans la doc. De toute façon le problème n'est pas là. On peut certainement faire pleind echoses avec make-kpkg. C'est simpelemnt une usine à gaz complexe qui n'apporte *rien* à celui qui n'a pas besoin de déployer son noyau sur plusieurs machines. Personne n'a encore été capable de citer une autre utilisation ou make-kpkg et ses incantations de magies noires apporte quoi que ce soit. Ou alors les questions religieuses. -- Erwan
Re: Backport XFree 4.3
* Erwan David [16:00 13/06/03 CEST]: Le Fri 13/06/2003, Raphaël SurcouF Bordet disait Le ven 13/06/2003 à 14:30, Erwan David a écrit : > > Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le > > manuel de la commande ?... > > Arrivé à quoi ? à compiler des modules pour un noyau debian installé > par un paquet kernel-image téléchargé ? Tu devines sans doute mieux > que moi. Parceque ce n'est pas mon cas. Et en tout cas tu ne suis pas > la doc dans ce cas là. Tu parles d'un module livré avec la distribution de Linux ou d'un module externe comme celui du paquet drm-trunk ? L'un ou l'autre. les seuls que j'ai pu compiler c'était les nvidia. Qui n'utilisent *pas* make-kpkg. Et la doc de make-kpkg passe tout simplemen,t sous silence ce cas là. QUe ce osit un module dont les sources sont packagés ou pas d'ailleurs. Je n'y tenais pas mais bon, je pose ma petite pierre à ce thread inutile car : 1- Le paquet nvidia-kernel-src s'installe ultra simplement avec make-kpkg (il suffit d'aller lire la FAQ d'ailleurs). 2- Le fichier README.modules, explique en 8 points comment créer le deb qui va bien pour ce module. C'est un fait qu'il n'explique pas comment faire sans recompiler son kernel, mais c'est déjà un bon début. D'ailleurs je pense que make-kpkg râle si on ne le lance pas depuis un répertoire contenant les sources du noyau, ce qui justifierait cet oubli. 3- Le fichier README.gz décrèté incompréhensible principalement à cause d'un mélange entre exemple et explications est tout de même très lisible. Le tout se passe clairement en deux phases (introduites subtilement par "Phase ONE" et "Phase TWO"). Les commandes à faire sont préfixées par 1%, 2%, 3%, 4%, 5#, 6#. Je ne sais pas si tout le monde l'a remarqué mais les étapes dont le numéro se termine par un % (tiens comme à la fin du prompt shell quel hasard) peuvent se réaliser en tant qu'utilisateur non privilégié. Celles qui se teminent par un # (tiens comme à la fin du prompt shell de root, encore un hasard probablement) doivent être entrée en tant que root (ou assimilé). Alors, oui je suis d'accord certains paquets peuvent être trop lourds, les options mal choisies, la doc mal écrite. Mais, il y a le BTS pour corriger de tels problèmes, discuter et arriver éventuellement à une solution satisfaisant tout le monde. Tu noteras que je ne demande à personne de faire un patch. Un rapport de bug est suffisant pour indiquer un problème. -- Ne postez pas idiot ! Lisez la FAQ : http://savannah.nongnu.org/download/debfr-faq/html/ pgpfQWnrwFfY6.pgp Description: PGP signature
Re: Backport XFree 4.3
* Erwan David <[EMAIL PROTECTED]> [2003-06-13 16:00] : > Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > > Le ven 13/06/2003 à 14:30, Erwan David a écrit : > > > > Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le > > > > manuel de la commande ?... > > > > > > Arrivé à quoi ? à compiler des modules pour un noyau debian installé > > > par un paquet kernel-image téléchargé ? Tu devines sans doute mieux > > > que moi. Parceque ce n'est pas mon cas. Et en tout cas tu ne suis pas > > > la doc dans ce cas là. > > > > Tu parles d'un module livré avec la distribution de Linux ou d'un module > > externe comme celui du paquet drm-trunk ? > > L'un ou l'autre. les seuls que j'ai pu compiler c'était les > nvidia. Qui n'utilisent *pas* make-kpkg. Et la doc de make-kpkg passe > tout simplemen,t sous silence ce cas là. QUe ce osit un module dont > les sources sont packagés ou pas d'ailleurs. Euh si : http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nvidia&searchon=names&subword=1&version=all&release=all et la documentation des paquets nvidia-kernel-src et nvidia-glx-src explique clairement comment faire (si on prend le temps de la lire). La documentation de make-kpkg (exactement le fichier README.modules) détaille précisément ce cas-là. Fred -- LA FAQ d-u-f ? http://savannah.nongnu.org/download/debfr-faq/html/
Re: Backport XFree 4.3
On Fri, Jun 13, 2003 at 04:37:24PM +0200, Raphaël SurcouF Bordet wrote: > Le ven 13/06/2003 à 16:00, Erwan David a écrit : > > > > Tu parles d'un module livré avec la distribution de Linux ou d'un module > > > externe comme celui du paquet drm-trunk ? > > > > L'un ou l'autre. les seuls que j'ai pu compiler c'était les > > nvidia. Qui n'utilisent *pas* make-kpkg. Et la doc de make-kpkg passe > > tout simplemen,t sous silence ce cas là. QUe ce osit un module dont > > les sources sont packagés ou pas d'ailleurs. > > Dans ce cas, arrête de te plaindre, veux-tu... > Si tu utilises des modules non empaquettés, assumes ! > Surtout que dans le cas de drm-trunk, ce n'est même pas officiellement > supporté par le projet Debian. > Pour ce qui est des modules de nvidia, demande au constructeur soit > qu'il fasse un paquet nvidia-modules-sources, soit qu'il fournisse enfin > les sources, voire juste les spécifications... > Au lieu d'attendre que tout tombe tout cru, chacun peut contribuer. > surtout que les modules nvidia sont packagés (bien qu'avec téléchargement du tar.gz chez Nvidia) et donc compilable via make-kpkg. Philippe
Re: Backport XFree 4.3
Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > > Dans ce cas, arrête de te plaindre, veux-tu... > Si tu utilises des modules non empaquettés, assumes ! Eh oui, il y a une vie en dehors des paquets et même des trucs de qualité. > Surtout que dans le cas de drm-trunk, ce n'est même pas officiellement > supporté par le projet Debian. > Pour ce qui est des modules de nvidia, demande au constructeur soit > qu'il fasse un paquet nvidia-modules-sources, soit qu'il fournisse enfin > les sources, voire juste les spécifications... > Au lieu d'attendre que tout tombe tout cru, chacun peut contribuer. Oui, par exmeple en arrantra d'emerder ceux qui nje respectenty pas le doogme du paquet à tpout prix. Tiens le dernier exemple qui a foiré : lm-sensors (oui maintenant il existe tout compilé, mais à l'époque ce n'était pas le cas). Au fait répond à ma question : est-il *possible* d'ajouter des modules à un noyau d'un paquet kernel-image. -- Erwan
Re: Backport XFree 4.3
Le ven 13/06/2003 à 16:00, Erwan David a écrit : > > Tu parles d'un module livré avec la distribution de Linux ou d'un module > > externe comme celui du paquet drm-trunk ? > > L'un ou l'autre. les seuls que j'ai pu compiler c'était les > nvidia. Qui n'utilisent *pas* make-kpkg. Et la doc de make-kpkg passe > tout simplemen,t sous silence ce cas là. QUe ce osit un module dont > les sources sont packagés ou pas d'ailleurs. Dans ce cas, arrête de te plaindre, veux-tu... Si tu utilises des modules non empaquettés, assumes ! Surtout que dans le cas de drm-trunk, ce n'est même pas officiellement supporté par le projet Debian. Pour ce qui est des modules de nvidia, demande au constructeur soit qu'il fasse un paquet nvidia-modules-sources, soit qu'il fournisse enfin les sources, voire juste les spécifications... Au lieu d'attendre que tout tombe tout cru, chacun peut contribuer. -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > Le ven 13/06/2003 à 14:30, Erwan David a écrit : > > > Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le > > > manuel de la commande ?... > > > > Arrivé à quoi ? à compiler des modules pour un noyau debian installé > > par un paquet kernel-image téléchargé ? Tu devines sans doute mieux > > que moi. Parceque ce n'est pas mon cas. Et en tout cas tu ne suis pas > > la doc dans ce cas là. > > Tu parles d'un module livré avec la distribution de Linux ou d'un module > externe comme celui du paquet drm-trunk ? L'un ou l'autre. les seuls que j'ai pu compiler c'était les nvidia. Qui n'utilisent *pas* make-kpkg. Et la doc de make-kpkg passe tout simplemen,t sous silence ce cas là. QUe ce osit un module dont les sources sont packagés ou pas d'ailleurs. -- Erwan
Re: Backport XFree 4.3
Le ven 13/06/2003 à 14:30, Erwan David a écrit : > > Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le > > manuel de la commande ?... > > Arrivé à quoi ? à compiler des modules pour un noyau debian installé > par un paquet kernel-image téléchargé ? Tu devines sans doute mieux > que moi. Parceque ce n'est pas mon cas. Et en tout cas tu ne suis pas > la doc dans ce cas là. Tu parles d'un module livré avec la distribution de Linux ou d'un module externe comme celui du paquet drm-trunk ? -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Fri 13/06/2003, Raphaël SurcouF Bordet disait > Le jeu 12/06/2003 à 20:27, Erwan David a écrit : > > > Le README.moudules commence par "compilez un noyau". Si je dois > > compiler un noyau je n'ai pas besoin de l'usine à gaz. C'est tout. > > Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le > manuel de la commande ?... Arrivé à quoi ? à compiler des modules pour un noyau debian installé par un paquet kernel-image téléchargé ? Tu devines sans doute mieux que moi. Parceque ce n'est pas mon cas. Et en tout cas tu ne suis pas la doc dans ce cas là. -- Erwan
Re: Backport XFree 4.3
Le Fri 13/06/2003, Sven Luther disait > On Thu, Jun 12, 2003 at 08:27:18PM +0200, Erwan David wrote: > > Le Thu 12/06/2003, Raphaël SurcouF Bordet disait > > > Le jeu 12/06/2003 à 15:21, Erwan David a écrit : > > > > Le Thu 12/06/2003, Sven Luther disait > > > > > > > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que > > > > > tu > > > > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > > > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > > > > > > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > > > > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > > > > > > > Et c'est pas la première fois que je récupère des modules en sources > > > > et suis incapable par manque de doc de les installer avec un noyau > > > > debian... > > > > > > Quelle mauvaise foi... As-tu seulement lu la doc de kernel-package avant > > > d'oser dire qu'il n'y a pas de doc ? > > > > Tu veux parler des 15 fichiers différents doj,nt un s'adressant > > apparement uniquement au dévelopeur de la glibc N > > Oui, et comme elle s'appelle probablement README.glibc, tu t'apercoit > immediatement qu'elle ne s'adresse pas a toi. Non, elle s'appelle README.headers > > > Je veux bien admettre que make-kpkg > > > puisse sembler ésotérique de premier abord mais c'est un outil > > > relativement puissant une fois qu'on en maitrise l'essentiel... > > > Il faut quand même prendre le temps de lire la documentation. Si la > > > documentation fournie avec le paquet drm-modules-source fait défaut, > > > d'une, ce n'est pas un paquet officiel, de deux, tu peux te référer à un > > > autre paquet, officiel celui-ci, de modules externes du noyau Linux pour > > > en savoir davantage... En outre, il y a quelques menus exemples dans le > > > Guide de Référence de Debian[1]. > > > > Un exemple n'est *pas* une doc. Ce que je reproche > > à ce bordel c'est justement d'être une collection d'exemples > > incompréhensible quand on ne sais pas ce qu'il y a derrière des > > exemples écris par quelqu'un qui sait comment ça marche pour ceux qui > > savent comment ça marche. > > > > Une doc de programme complexe ça a *un* début, et c'est structuré. 15 > > fichiers en vrac dans un répertoire ça n'est *pas* une doc. > > > > Ensuite il y a ce qu'on troufve dedans. Un paquet noyau n'a *aucune* > > autre utilité que d'être distribuable. Je n'ai pas besoin de > > Faux, cela permet de faire de l'ordre dans ton systeme, si tu a un noyau > installe, et que tu reconfigure, et que tu en installe un autre par > dessus, le package se charge automatiquement de supprimer les fichiers > de l'ancien noyau avant de remplacer le nouveau. Ils fait aussi > automatiquement les trucs Lilo et autre. Mais justement :m je ne *remplace* jamais un noyau. Je teste le nouveau en gardant *toujours la possibilité de revenir à un des anciens. Par ailleus quand j'ai installé le 2.4.20-k7-1 il n'a *pas* supprimé le 2.4.20-k7 précédent... > > > > Or tes 15 fichiers ne me disent même si c'ets simplkement *possible*. > > A, je vois d'ou te viennent les 15 etapes, tu croyais peut etre que en > lisant les noms de ces quinze fichiers, tu allait magiquement comprendre > comment marchait make-kpkg, que que chacun de ces fichiers etait une > etape de compilation ? Dans ce cas, je te conseille la commande more > pour lire le contenu des fichiers en question (man more pour plus de > detail) :))) > > > Le README.moudules commence par "compilez un noyau". Si je dois > > compiler un noyau je n'ai pas besoin de l'usine à gaz. C'est tout. > > Mauvaise volonte, je t'ai deja explique pourquoi il te faut les sources > compile noyau pour compile des modules. ALors que la doc le dise qu'on ne peux pas compiler de module pour un noyau packagé par debian ! -- Erwan
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 08:27:18PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Raphaël SurcouF Bordet disait > > Le jeu 12/06/2003 à 15:21, Erwan David a écrit : > > > Le Thu 12/06/2003, Sven Luther disait > > > > > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > > > > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > > > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > > > > > Et c'est pas la première fois que je récupère des modules en sources > > > et suis incapable par manque de doc de les installer avec un noyau > > > debian... > > > > Quelle mauvaise foi... As-tu seulement lu la doc de kernel-package avant > > d'oser dire qu'il n'y a pas de doc ? > > Tu veux parler des 15 fichiers différents doj,nt un s'adressant > apparement uniquement au dévelopeur de la glibc N Oui, et comme elle s'appelle probablement README.glibc, tu t'apercoit immediatement qu'elle ne s'adresse pas a toi. > > Je veux bien admettre que make-kpkg > > puisse sembler ésotérique de premier abord mais c'est un outil > > relativement puissant une fois qu'on en maitrise l'essentiel... > > Il faut quand même prendre le temps de lire la documentation. Si la > > documentation fournie avec le paquet drm-modules-source fait défaut, > > d'une, ce n'est pas un paquet officiel, de deux, tu peux te référer à un > > autre paquet, officiel celui-ci, de modules externes du noyau Linux pour > > en savoir davantage... En outre, il y a quelques menus exemples dans le > > Guide de Référence de Debian[1]. > > Un exemple n'est *pas* une doc. Ce que je reproche > à ce bordel c'est justement d'être une collection d'exemples > incompréhensible quand on ne sais pas ce qu'il y a derrière des > exemples écris par quelqu'un qui sait comment ça marche pour ceux qui > savent comment ça marche. > > Une doc de programme complexe ça a *un* début, et c'est structuré. 15 > fichiers en vrac dans un répertoire ça n'est *pas* une doc. > > Ensuite il y a ce qu'on troufve dedans. Un paquet noyau n'a *aucune* > autre utilité que d'être distribuable. Je n'ai pas besoin de Faux, cela permet de faire de l'ordre dans ton systeme, si tu a un noyau installe, et que tu reconfigure, et que tu en installe un autre par dessus, le package se charge automatiquement de supprimer les fichiers de l'ancien noyau avant de remplacer le nouveau. Ils fait aussi automatiquement les trucs Lilo et autre. Cela permet aussi facilement d'avoir plusieurs version de noyau aisement identifiable, sans avoir un fouilli pas possible dans ton systeme. Accesoirement il te patch aussi les source si tu a installe l'un des multiples package de patch (comme les patch d'architecture). > distribuer un noyau perso donc je ne vois pas à quoi me sers tout ce > bordel. make bzImage marche *très* bien et est *parfaitement* > documenté. La seule utilité que je voyais à kernel-package était de > compiler des modules distribués uniquement en source pour le noyau > debain standard. > > Or tes 15 fichiers ne me disent même si c'ets simplkement *possible*. A, je vois d'ou te viennent les 15 etapes, tu croyais peut etre que en lisant les noms de ces quinze fichiers, tu allait magiquement comprendre comment marchait make-kpkg, que que chacun de ces fichiers etait une etape de compilation ? Dans ce cas, je te conseille la commande more pour lire le contenu des fichiers en question (man more pour plus de detail) :))) > Le README.moudules commence par "compilez un noyau". Si je dois > compiler un noyau je n'ai pas besoin de l'usine à gaz. C'est tout. Mauvaise volonte, je t'ai deja explique pourquoi il te faut les sources compile noyau pour compile des modules. Amicalement, Sven Luther
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 05:16:44PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Sven Luther disait > > On Thu, Jun 12, 2003 at 03:21:19PM +0200, Erwan David wrote: > > > Le Thu 12/06/2003, Sven Luther disait > > > > > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > > > > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > > > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > > > Oui, make-kpkg --revision 1 modules_image. > > pourquoi --revision 1 ? et pas 2 et pas -k7-3 si j'utilise le noyau > 2.4.20-k7-3 ? Bien sur, tu met ce que tu veut, moi je met 1 la premiere fois, et 2, 3, 4, etc les fois suivantes. Quand au k7, tu peut utiliser le flag -flavour, ou quelque chose comme cela, mais c'est se compliquer la vie inutilement, probablement plus util si tu a plusieurs saveure du meme noyau installe en parallel (un qui marche sur, et un ou tu teste des nouveau trucs). Moi en general je garde l'ancienne version (2.4.20) en cas de besoin et je recompile directement la nouvelle version (2.4.21-pre3 dans mon cas). > > > Et c'est pas la première fois que je récupère des modules en sources > > > et suis incapable par manque de doc de les installer avec un noyau > > > debian... > > > > Et il ne te serait jamais venu a l'idee de lire : > > > > /usr/share/doc/kernel-package/README.modules > > > > (Apres avoir installe kernel-package bien sur). > > Justerment je n'ai *rien* compris à ces docs (cf la question > précédente). Par ailleurs les doncs de dri-trunk-src ne mentionnent > *même* pas kernel-package Et je suppose que tu t'ai empresse d'envoyer un mail a Michel a ce propos. C'est toujours facile de se plaindre, mais il faut avoir l'honnetete d'envoyer des bugreport aussi, se plaindre sur une liste que le mainteneur ne lis pas, c'est completement inutile, du moins lorsqu'on est de bonne foi. > > > (les docs du genre "1) vous avez compilé votre noyau avec make-kpkg 2) > > > vous avez compilé votre noyau à la main et *rien* pour ceux qui n'ont > > > *pas* compilé leur noyau sont loin d'êtres rares). > > > > Si les docs plus haut ne te semblent pas assez clair, tu est libre > > d'envoyer un patch a Manoj ou lui demander de clarifier les choses. > > Bah il faudrait déjà que ce soir une dioc et pas une collection > d'exdemple qui ne différencie pas ce qui est variable de ce qui ne > l'est pas d'une invocation à l'autre. La pluspart des gens n'ont pas de difficulte a comprendre, si tu a quelque chose de mieux, n'hesite pas. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le jeu 12/06/2003 à 20:27, Erwan David a écrit : > Le README.moudules commence par "compilez un noyau". Si je dois > compiler un noyau je n'ai pas besoin de l'usine à gaz. C'est tout. Alors comment se fait-il que j'y sois arrivé, juste avec ces docs et le manuel de la commande ?... -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Thu 12/06/2003, Raphaël SurcouF Bordet disait > Le jeu 12/06/2003 à 15:21, Erwan David a écrit : > > Le Thu 12/06/2003, Sven Luther disait > > > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > > > Et c'est pas la première fois que je récupère des modules en sources > > et suis incapable par manque de doc de les installer avec un noyau > > debian... > > Quelle mauvaise foi... As-tu seulement lu la doc de kernel-package avant > d'oser dire qu'il n'y a pas de doc ? Tu veux parler des 15 fichiers différents doj,nt un s'adressant apparement uniquement au dévelopeur de la glibc N > Je veux bien admettre que make-kpkg > puisse sembler ésotérique de premier abord mais c'est un outil > relativement puissant une fois qu'on en maitrise l'essentiel... > Il faut quand même prendre le temps de lire la documentation. Si la > documentation fournie avec le paquet drm-modules-source fait défaut, > d'une, ce n'est pas un paquet officiel, de deux, tu peux te référer à un > autre paquet, officiel celui-ci, de modules externes du noyau Linux pour > en savoir davantage... En outre, il y a quelques menus exemples dans le > Guide de Référence de Debian[1]. Un exemple n'est *pas* une doc. Ce que je reproche à ce bordel c'est justement d'être une collection d'exemples incompréhensible quand on ne sais pas ce qu'il y a derrière des exemples écris par quelqu'un qui sait comment ça marche pour ceux qui savent comment ça marche. Une doc de programme complexe ça a *un* début, et c'est structuré. 15 fichiers en vrac dans un répertoire ça n'est *pas* une doc. Ensuite il y a ce qu'on troufve dedans. Un paquet noyau n'a *aucune* autre utilité que d'être distribuable. Je n'ai pas besoin de distribuer un noyau perso donc je ne vois pas à quoi me sers tout ce bordel. make bzImage marche *très* bien et est *parfaitement* documenté. La seule utilité que je voyais à kernel-package était de compiler des modules distribués uniquement en source pour le noyau debain standard. Or tes 15 fichiers ne me disent même si c'ets simplkement *possible*. Le README.moudules commence par "compilez un noyau". Si je dois compiler un noyau je n'ai pas besoin de l'usine à gaz. C'est tout. -- Erwan
Re: Backport XFree 4.3
Le jeu 12/06/2003 à 15:21, Erwan David a écrit : > Le Thu 12/06/2003, Sven Luther disait > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > Et c'est pas la première fois que je récupère des modules en sources > et suis incapable par manque de doc de les installer avec un noyau > debian... Quelle mauvaise foi... As-tu seulement lu la doc de kernel-package avant d'oser dire qu'il n'y a pas de doc ? Je veux bien admettre que make-kpkg puisse sembler ésotérique de premier abord mais c'est un outil relativement puissant une fois qu'on en maitrise l'essentiel... Il faut quand même prendre le temps de lire la documentation. Si la documentation fournie avec le paquet drm-modules-source fait défaut, d'une, ce n'est pas un paquet officiel, de deux, tu peux te référer à un autre paquet, officiel celui-ci, de modules externes du noyau Linux pour en savoir davantage... En outre, il y a quelques menus exemples dans le Guide de Référence de Debian[1]. > (les docs du genre "1) vous avez compilé votre noyau avec make-kpkg 2) > vous avez compilé votre noyau à la main et *rien* pour ceux qui n'ont > *pas* compilé leur noyau sont loin d'êtres rares). [1]: http://qref.sourceforge.net/Debian/reference/ch-kernel.fr.html#s-kernel-debian -- Raphaël "SurcouF" Bordet [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Thu 12/06/2003, Sven Luther disait > On Thu, Jun 12, 2003 at 03:21:19PM +0200, Erwan David wrote: > > Le Thu 12/06/2003, Sven Luther disait > > > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > > compiler ces modules drm... une incantation étrange avec make-kpkg ? > > Oui, make-kpkg --revision 1 modules_image. pourquoi --revision 1 ? et pas 2 et pas -k7-3 si j'utilise le noyau 2.4.20-k7-3 ? > > Et c'est pas la première fois que je récupère des modules en sources > > et suis incapable par manque de doc de les installer avec un noyau > > debian... > > Et il ne te serait jamais venu a l'idee de lire : > > /usr/share/doc/kernel-package/README.modules > > (Apres avoir installe kernel-package bien sur). Justerment je n'ai *rien* compris à ces docs (cf la question précédente). Par ailleurs les doncs de dri-trunk-src ne mentionnent *même* pas kernel-package > > (les docs du genre "1) vous avez compilé votre noyau avec make-kpkg 2) > > vous avez compilé votre noyau à la main et *rien* pour ceux qui n'ont > > *pas* compilé leur noyau sont loin d'êtres rares). > > Si les docs plus haut ne te semblent pas assez clair, tu est libre > d'envoyer un patch a Manoj ou lui demander de clarifier les choses. Bah il faudrait déjà que ce soir une dioc et pas une collection d'exdemple qui ne différencie pas ce qui est variable de ce qui ne l'est pas d'une invocation à l'autre. -- Erwan
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 03:21:19PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Sven Luther disait > > > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? > > Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* > compiler ces modules drm... une incantation étrange avec make-kpkg ? Oui, make-kpkg --revision 1 modules_image. > Et c'est pas la première fois que je récupère des modules en sources > et suis incapable par manque de doc de les installer avec un noyau > debian... Et il ne te serait jamais venu a l'idee de lire : /usr/share/doc/kernel-package/README.modules (Apres avoir installe kernel-package bien sur). > (les docs du genre "1) vous avez compilé votre noyau avec make-kpkg 2) > vous avez compilé votre noyau à la main et *rien* pour ceux qui n'ont > *pas* compilé leur noyau sont loin d'êtres rares). Si les docs plus haut ne te semblent pas assez clair, tu est libre d'envoyer un patch a Manoj ou lui demander de clarifier les choses. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Thu 12/06/2003, Sven Luther disait > > Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu > trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur > 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? Non je n'ai pas, et de toute façon il n'est dit nulle part *comment* compiler ces modules drm... une incantation étrange avec make-kpkg ? Et c'est pas la première fois que je récupère des modules en sources et suis incapable par manque de doc de les installer avec un noyau debian... (les docs du genre "1) vous avez compilé votre noyau avec make-kpkg 2) vous avez compilé votre noyau à la main et *rien* pour ceux qui n'ont *pas* compilé leur noyau sont loin d'êtres rares). -- Erwan
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 02:24:41PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Sven Luther disait > > On Thu, Jun 12, 2003 at 01:13:58PM +0200, Erwan David wrote: > > > Le Thu 12/06/2003, Sven Luther disait > > > > On Thu, Jun 12, 2003 at 11:02:14AM +0200, Erwan David wrote: > > > > > Le Tue 10/06/2003, Sven Luther disait > > > > > > > > > > > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent > > > > > > avec le > > > > > > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, > > > > > > Michel > > > > > > qui est a la fois un developpeur debian et tres actif dans le projet > > > > > > DRI, et se donne du mal pour faire des packages dri-trunk qui > > > > > > marchent > > > > > > bien, alors pourquoi ne pas les utiliser ? > > > > > > > > > > apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est > > > > > une bonne raison, non ? > > > > > > > > Parceque je t'ai donner des mauvais noms, raccourci, car on en avait > > > > deja parler par le passe sur cette liste. > > > > > > > > $ more /etc/apt/sources.list > > > > > > > > # Michel's DRI packages > > > > deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ > > > > > > > > # XFree86 4.3.0 > > > > deb > > > > ftp://ftp.skolelinux.no:/debian-unofficial/x4.3/4.3.0/sid/powerpc ./ > > > > > > Je me méfies beaucoup des packages hors debian. En particulier pour > > > les bugreports, ça marche comment ? > > > > Pour les packages DRI, comme c'est indiquer a : > > > > > > http://dri.sourceforge.net/snapshots/README.Debian > > Bon, j'ai regardé : pas de support du xauth dans xdm, et aucune doc > expliquant comment compiler. Donc clairement il faut attendre. Tu n'a pas besoin du serveur X de Michel, uniquement les modules que tu trouvera a drm-trunk-module-src. Je pense que tu a besoin d'un serveur 4.3.0 cependant, mais j'imagine que tu a deja cela, non ? Amicalement, Sven Luther
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 02:19:55PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Sven Luther disait > > Il faut envoyer les bugreport a Michel Daenzer. Il s'agit d'un pakage > > hors debian, mais officielle du projet DRI, de upstream donc. > > > > Sinon, pour les packages 4.3.0, il y aurra bientot des packages > > officiels, donc avec BTS et tout et tout. Bien sur, cela fait un bout de > > temps que Branden et Daniel me disent bientot, mais comme tous les > > autres sources non officielles semblent avoir disparu, je pense que cela > > ne devrait pas tarder maintenant. Bien sur, tu peut toujours recuperer > > le package du server subversion que branden a mis en place et compile > > toi meme, si tu est presse. > > Y'a juste que quand je termine une session X est incapable de refaire > le fond d'écran pour le nouvel xdm. Et que je me demande si c'est pas > lié (via le dri) à mes fuites méméoires dans le noyau... Avec quels packages ? Et sait tu plus exactement pour quel raison X est incapable de refaire le fond d'ecran pour le nouvel xdm ? Est-ce parceque X meurt, ou non, envoie moi (en privee) ton /var/log/XFree86.0.log, quoi que je ne suis pas sur qu'on y voit quelque chose. Mmm, est-tu competent en gdb ? Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Thu 12/06/2003, Sven Luther disait > On Thu, Jun 12, 2003 at 01:13:58PM +0200, Erwan David wrote: > > Le Thu 12/06/2003, Sven Luther disait > > > On Thu, Jun 12, 2003 at 11:02:14AM +0200, Erwan David wrote: > > > > Le Tue 10/06/2003, Sven Luther disait > > > > > > > > > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec > > > > > le > > > > > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, > > > > > Michel > > > > > qui est a la fois un developpeur debian et tres actif dans le projet > > > > > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > > > > > bien, alors pourquoi ne pas les utiliser ? > > > > > > > > apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est > > > > une bonne raison, non ? > > > > > > Parceque je t'ai donner des mauvais noms, raccourci, car on en avait > > > deja parler par le passe sur cette liste. > > > > > > $ more /etc/apt/sources.list > > > > > > # Michel's DRI packages > > > deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ > > > > > > # XFree86 4.3.0 > > > deb > > > ftp://ftp.skolelinux.no:/debian-unofficial/x4.3/4.3.0/sid/powerpc ./ > > > > Je me méfies beaucoup des packages hors debian. En particulier pour > > les bugreports, ça marche comment ? > > Pour les packages DRI, comme c'est indiquer a : > > > > http://dri.sourceforge.net/snapshots/README.Debian Bon, j'ai regardé : pas de support du xauth dans xdm, et aucune doc expliquant comment compiler. Donc clairement il faut attendre. -- Erwan
Re: Backport XFree 4.3
Le Thu 12/06/2003, Sven Luther disait > Il faut envoyer les bugreport a Michel Daenzer. Il s'agit d'un pakage > hors debian, mais officielle du projet DRI, de upstream donc. > > Sinon, pour les packages 4.3.0, il y aurra bientot des packages > officiels, donc avec BTS et tout et tout. Bien sur, cela fait un bout de > temps que Branden et Daniel me disent bientot, mais comme tous les > autres sources non officielles semblent avoir disparu, je pense que cela > ne devrait pas tarder maintenant. Bien sur, tu peut toujours recuperer > le package du server subversion que branden a mis en place et compile > toi meme, si tu est presse. Y'a juste que quand je termine une session X est incapable de refaire le fond d'écran pour le nouvel xdm. Et que je me demande si c'est pas lié (via le dri) à mes fuites méméoires dans le noyau... -- Erwan
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 01:13:58PM +0200, Erwan David wrote: > Le Thu 12/06/2003, Sven Luther disait > > On Thu, Jun 12, 2003 at 11:02:14AM +0200, Erwan David wrote: > > > Le Tue 10/06/2003, Sven Luther disait > > > > > > > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec le > > > > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, Michel > > > > qui est a la fois un developpeur debian et tres actif dans le projet > > > > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > > > > bien, alors pourquoi ne pas les utiliser ? > > > > > > apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est > > > une bonne raison, non ? > > > > Parceque je t'ai donner des mauvais noms, raccourci, car on en avait > > deja parler par le passe sur cette liste. > > > > $ more /etc/apt/sources.list > > > > # Michel's DRI packages > > deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ > > > > # XFree86 4.3.0 > > deb > > ftp://ftp.skolelinux.no:/debian-unofficial/x4.3/4.3.0/sid/powerpc ./ > > Je me méfies beaucoup des packages hors debian. En particulier pour > les bugreports, ça marche comment ? Pour les packages DRI, comme c'est indiquer a : > > http://dri.sourceforge.net/snapshots/README.Debian Il faut envoyer les bugreport a Michel Daenzer. Il s'agit d'un pakage hors debian, mais officielle du projet DRI, de upstream donc. Sinon, pour les packages 4.3.0, il y aurra bientot des packages officiels, donc avec BTS et tout et tout. Bien sur, cela fait un bout de temps que Branden et Daniel me disent bientot, mais comme tous les autres sources non officielles semblent avoir disparu, je pense que cela ne devrait pas tarder maintenant. Bien sur, tu peut toujours recuperer le package du server subversion que branden a mis en place et compile toi meme, si tu est presse. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Thu 12/06/2003, Sven Luther disait > On Thu, Jun 12, 2003 at 11:02:14AM +0200, Erwan David wrote: > > Le Tue 10/06/2003, Sven Luther disait > > > > > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec le > > > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, Michel > > > qui est a la fois un developpeur debian et tres actif dans le projet > > > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > > > bien, alors pourquoi ne pas les utiliser ? > > > > apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est > > une bonne raison, non ? > > Parceque je t'ai donner des mauvais noms, raccourci, car on en avait > deja parler par le passe sur cette liste. > > $ more /etc/apt/sources.list > > # Michel's DRI packages > deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ > > # XFree86 4.3.0 > deb > ftp://ftp.skolelinux.no:/debian-unofficial/x4.3/4.3.0/sid/powerpc ./ Je me méfies beaucoup des packages hors debian. En particulier pour les bugreports, ça marche comment ? > > Le package que tu veut est drm-trunk-module-src pour les packages DRI de > Michel Daenzer, et xlibmesa4-drm-src pour les packages de Daniel. > > Mmm, il me semble que la source apt de skolelinux soit vide, cela est du > au fait qu'il y aura bientot (j'espere) des packages 4.3.0 officiel. > > Tu peut trouver des backport woody de par le web, notament un link > rapide trouver par google est : > > http://www.linuxcompatible.org/print17614.html > > Qui donne reference aux backport de Ralf et Daniel (Mmm, je me demande > si c'est daniel qui a fait les backport ou Marcelo). > > > D'ailleurs on devine comment qu'il faut les récupérer et les utiliser > > ces paquets ? Sacahnt qu'en plus le systèle de paquets ne fait pas > > l'upgrade des noyaux (et là il ya des raisons). > > Je crois que les packages de Michel sont linker directement depuis le > site sourceforge DRI : > > http://dri.sourceforge.net/snapshots/README.Debian > > Et font partie de l'effort du projet DRI pour donner des snapshots > reguliers. > > Les packages de Daniel feront bientot partie de la release 4.3.0, et > devront donc etre recuperer de la meme maniere et au meme endroit que > les packages 4.3.0, backporte ou non. Jusqu'à maintenant je récupère els paquets de X sur ftp.fr.debian.org (pas eu besoin du 4.3). Je verrai donc quand le 4.3 passera dans sid, pas avant. -- Erwan
Re: Backport XFree 4.3
On Thu, Jun 12, 2003 at 11:02:14AM +0200, Erwan David wrote: > Le Tue 10/06/2003, Sven Luther disait > > > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec le > > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, Michel > > qui est a la fois un developpeur debian et tres actif dans le projet > > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > > bien, alors pourquoi ne pas les utiliser ? > > apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est > une bonne raison, non ? Parceque je t'ai donner des mauvais noms, raccourci, car on en avait deja parler par le passe sur cette liste. $ more /etc/apt/sources.list # Michel's DRI packages deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ # XFree86 4.3.0 deb ftp://ftp.skolelinux.no:/debian-unofficial/x4.3/4.3.0/sid/powerpc ./ Le package que tu veut est drm-trunk-module-src pour les packages DRI de Michel Daenzer, et xlibmesa4-drm-src pour les packages de Daniel. Mmm, il me semble que la source apt de skolelinux soit vide, cela est du au fait qu'il y aura bientot (j'espere) des packages 4.3.0 officiel. Tu peut trouver des backport woody de par le web, notament un link rapide trouver par google est : http://www.linuxcompatible.org/print17614.html Qui donne reference aux backport de Ralf et Daniel (Mmm, je me demande si c'est daniel qui a fait les backport ou Marcelo). > D'ailleurs on devine comment qu'il faut les récupérer et les utiliser > ces paquets ? Sacahnt qu'en plus le systèle de paquets ne fait pas > l'upgrade des noyaux (et là il ya des raisons). Je crois que les packages de Michel sont linker directement depuis le site sourceforge DRI : http://dri.sourceforge.net/snapshots/README.Debian Et font partie de l'effort du projet DRI pour donner des snapshots reguliers. Les packages de Daniel feront bientot partie de la release 4.3.0, et devront donc etre recuperer de la meme maniere et au meme endroit que les packages 4.3.0, backporte ou non. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Tue 10/06/2003, Sven Luther disait > > Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec le > X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, Michel > qui est a la fois un developpeur debian et tres actif dans le projet > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > bien, alors pourquoi ne pas les utiliser ? apt-cache ne trouvant ni drm-source ni dri-trunk je pense que c'est une bonne raison, non ? D'ailleurs on devine comment qu'il faut les récupérer et les utiliser ces paquets ? Sacahnt qu'en plus le systèle de paquets ne fait pas l'upgrade des noyaux (et là il ya des raisons). -- Erwan
Re: Backport XFree 4.3
Salut, Le mercredi 11 juin 2003 à 19:16 +0200, Georges Mariano a écrit : [...] > cf l'exemple de zope récent... où il faut installer le paquet, casser son > système, lire le README.Debian et réparer son système... > > Personnellement : GROS malaise... mais bon, passons. Ce n'est que temporaire, des gens sont déjà en train de travailler pour améliorer ces paquets. (je parle des paquet zope) a+ -- Pierre Machard <[EMAIL PROTECTED]> TuxFamily.org <[EMAIL PROTECTED]> techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 11:49:41PM +0200, Georges Mariano wrote: > On Wed, 11 Jun 2003 21:17:00 +0200 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > Rappelle toi que c'est unstable/testing, si ces problemes persiste > > lorsque sarge sera release, alors la tu aurra pleinement raison. > > Euh nan, le cas de zope c'est testing, et pour tetex c'est dans woody > [il me semble] (mais je m'en suis aperçu très tard, j'étais en potato > assez longtemps). Mais là n'est pas vraiment la question... le gros > malaise c'est que ce soit arrivé «jusque là». Cette technique de > récupération d'installation cassée après lecture de README.Debian, je > m'y attendais pas du tout (de la part de Debian). > > > De plus, le travail de packaging ne consiste pas seulement a faire un > > package, mais aussi d'integrer le package dans l'ensemble de debian et > > le faire interagir avec les autres packages au mieux. > > ?? pour moi c'est (effectivement) un tout. > > > Mais biensur, la qualite des packages est relativement inegale, > > dependant de la qualite du packageur, de son temps disponible, etc. > > ben ouai, mais c'est pas ta formulation initiale ... et je vois pas > pourquoi sur les debian-*-users tout serait pour le mieux dans le > meilleur des mondes alors que sur les debian-*-devel c'est une autre > histoire ... > > > Donc, pour en revenir au sujet, et c'est en fait la seule raison pour > > laquelle j'ai poste, c'est tout simplement parceque les packages > ... > > Malheureusement, il n'est pas facile de desactiver > > la compilation de ces packages, > > mais dans certain référentiel de qualité, ne pas pouvoir désactivé > facilement un truc qui a été activé c'est pas très «qualité»... ;-) Comme dis, un patch est bienvenu ... > PS : non, je n'ai pas besoin d'être "mainteneur" Debian pour que mes > remarques soient recevables ;-) Ni pour soumettre des patches :))) Comme dis, Daniel Stone, qui est a la base des packages 4.3.0 n'est meme pas developpeur debian. > > mais tu est bienvenu a fournir un patch > > si le coeur t'en dis. > > je l'attendais celle-là, tellement prévisible ;-) > c'était juste de la curiosité... Et j'espere avoir repondu. > ceci dit, c'est pas la première fois où l'on verrait un debian/rules qui > procède par copier-coller/adapter de règles pour générer ce genre de > paquets dérivés au lieu de s'appeler avec un bon paramétrage ... > > ajoutons une couche avec, très souvent, une gestion à la hache des > cibles de compilation (configure/build/...) qui casse toute la > modularité du processus compilation upstream Oui, peut-etre, mais je ne pense pas que cela soit le cas. Je ne suis absolument pas en bonne relation avec Branden, depuis que j'ai malencontreusement fait un NMU de X en 99 alors que X de debian ne buildait pas sur powerpc, mais que la version upstream n'avait pas de probleme. J'etait jeune developpeur a l'epoque et ne realisait pas reellement la porte de ce que je faissait. Mais bon, malgres cela, j'ai un grand respect pour le travail de Branden, il a fait un travail formidable pour le packaging de XFree86, qui est l'un des packages le plus difficile qui soit, specialement parce que upstream ne supporte que 3 ou 4 des 11 architectures que debian supporte, et qu'il faut plusieurs jours pour compiler X sur m68k par exemple. Donc ton discours plus haut est peut-etre vrai, mais pas dans le cas de X, c'est juste que le systeme de build n'est pas prevu pour realiser la compilation partielle d'un package multi-binaire, c'est tout. Mais comme dis, si cela te gene, les patches sont les bienvenus, ce ne doit pas etre tres difficile a faire d'ailleurs, c'est juste que les personnes qui s'en occupe n'ont pas trouve que cela etait assez prioritaire pour qu'il s'en occupe (a la place de quelque chose de plus urgent). Et de toute facon, cela ne compromet en rien la qualite des packages binaires resultants, c'est completement transparent pour les utilisateurs. Sinon, je suis personnellement en train de travailler avec upstream pour rendre la SDK fonctionnelle, et j'attend la release de 4.3.0-1 pour pouvoir soumettre un patch qui produirait un nouveau package binaire xfree86-sdk, si Daniel ne le fait pas avant moi, qui permettrait de construire les drivers du CVS upstream facilement et de les utiliser avec les packages 4.3.0. Ensuite je construirait un package debian separe de xfree86 qui permettra de construire lesdits drivers et de les installe de maniere conforme au systeme de packaging. Une fois que cela sera fait, l'urgence d'utiliser ou de reconstruire les packages Xfree86 pour stable diminue considerablement, car il suffira de construire le package de drivers et l'installer, ou simplement installer le package que je produirait. De plus, un tel package dependra uniquement du package xfree86, et n'aura donc aucune dependance supplementaire. C'est quand meme une maniere d'utiliser mon (tres limite) temps libre plus interessant et productif a la longue que d'aller faire des choses d'u
Re: Backport XFree 4.3
Georges Mariano écrivait : > On Wed, 11 Jun 2003 21:17:00 +0200 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > Rappelle toi que c'est unstable/testing, si ces problemes persiste > > lorsque sarge sera release, alors la tu aurra pleinement raison. > > Euh nan, le cas de zope c'est testing, et pour tetex c'est dans woody > [il me semble] (mais je m'en suis aperçu très tard, j'étais en potato > assez longtemps). Mais là n'est pas vraiment la question... le gros Je confirme Woody pour tetex : cela m'a cassé les c... avant-hier car je me suis rendu compte de cela qu'à ce moment-là : le fichier tetex.cnf a été modifié (les paths ont été modifiés, ce qui fait que toutes les macros personnelles étaient perdues... à noter que la récupération de l'ancien fichier de conf a tout résolu... Je n'ai pas cherché plus loin). PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
Re: Backport XFree 4.3
On Wed, 11 Jun 2003 21:17:00 +0200 Sven Luther <[EMAIL PROTECTED]> wrote: > Rappelle toi que c'est unstable/testing, si ces problemes persiste > lorsque sarge sera release, alors la tu aurra pleinement raison. Euh nan, le cas de zope c'est testing, et pour tetex c'est dans woody [il me semble] (mais je m'en suis aperçu très tard, j'étais en potato assez longtemps). Mais là n'est pas vraiment la question... le gros malaise c'est que ce soit arrivé «jusque là». Cette technique de récupération d'installation cassée après lecture de README.Debian, je m'y attendais pas du tout (de la part de Debian). > De plus, le travail de packaging ne consiste pas seulement a faire un > package, mais aussi d'integrer le package dans l'ensemble de debian et > le faire interagir avec les autres packages au mieux. ?? pour moi c'est (effectivement) un tout. > Mais biensur, la qualite des packages est relativement inegale, > dependant de la qualite du packageur, de son temps disponible, etc. ben ouai, mais c'est pas ta formulation initiale ... et je vois pas pourquoi sur les debian-*-users tout serait pour le mieux dans le meilleur des mondes alors que sur les debian-*-devel c'est une autre histoire ... > Donc, pour en revenir au sujet, et c'est en fait la seule raison pour > laquelle j'ai poste, c'est tout simplement parceque les packages ... > Malheureusement, il n'est pas facile de desactiver > la compilation de ces packages, mais dans certain référentiel de qualité, ne pas pouvoir désactivé facilement un truc qui a été activé c'est pas très «qualité»... ;-) > mais tu est bienvenu a fournir un patch > si le coeur t'en dis. je l'attendais celle-là, tellement prévisible ;-) c'était juste de la curiosité... ceci dit, c'est pas la première fois où l'on verrait un debian/rules qui procède par copier-coller/adapter de règles pour générer ce genre de paquets dérivés au lieu de s'appeler avec un bon paramétrage ... ajoutons une couche avec, très souvent, une gestion à la hache des cibles de compilation (configure/build/...) qui casse toute la modularité du processus compilation upstream etc etc on peut en ajouter ... tout dépend de ce que l'on appelle qualité ... PS : non, je n'ai pas besoin d'être "mainteneur" Debian pour que mes remarques soient recevables ;-) A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 07:16:09PM +0200, Georges Mariano wrote: > En réponse à Erwan David <[EMAIL PROTECTED]>: > > Le Wed 11/06/2003, Pierre Machard disait > > > moment donné), ton système fonctionne, et que lorsqu'un paquet est > > > installé, on est preque garanti à 100 % que le logiciel fonctionnera > > > sans problème. > > cf l'exemple de zope récent... où il faut installer le paquet, casser son > système, lire le README.Debian et réparer son système... > > Personnellement : GROS malaise... mais bon, passons. > > cf autre exemple, la décision de Debian de gérer le texmf.cnf à sa sauce, > avec > pour conséquence de casser une grade partie des install tetex en place sans > prévenir l'utilisateur (fil édifiant à ce sujet sur debian-devel) > > ... je laisse le soin aux packageurs ici présents de se fatiguer à me > convaincre > que c'est pour la bonne cause... en ce qui me concerne je suis désormais TRES > prudent dans TOUTE mise à jour de paquet. Rappelle toi que c'est unstable/testing, si ces problemes persiste lorsque sarge sera release, alors la tu aurra pleinement raison. > Je garde pour la fin une réflexion perso : quelle que soit la qualité du > packaging Debian pour ... emacs ou xfree ou gnome (au hasard), il faut bien se > rappeler que ce n'est "que" du packaging (parfois complexe certes), et qu'un > respect encore plus grand doit être attribué aux développeurs amont. En > matière > de logiciels libres, on pourrait se passer du packaging Debian mais pas du > développement amont. Oui et non, il y a des cas ou upstream n'existe plus, et ou le packageur debian tient lieu d'upstream. Ou pour reprendre l'exemple de xfree que tu cite, les packages debian de xfree86 sont considere par beaucoup comme les packages xfree86 de meilleures qualite existant, et supportant un certain nombre d'architecture non supporte par upstream. Et la je parle en connaissance de cause, je suis pas implique dans le packaging xfree86, mais je suis upstream xfree86, un upstream mineur mais quand meme. De plus, le travail de packaging ne consiste pas seulement a faire un package, mais aussi d'integrer le package dans l'ensemble de debian et a le faire interagir avec les autres packages au mieux. Mais biensur, la qualite des packages est relativement inegale, dependant de la qualite du packageur, de son temps disponible, etc. Certains packageurs peuvent prendre des decisions controverses, ou faire des bourdes, ou ..., mais dans l'ensemble, les packages sont plutot de bonne qualite, ne serait-ce parceque si ce n'est pas le cas, un autre developpeur ou utilisateur le remarquera, cela le genera, et il interviendra pour faire changer les choses, allant peut etre jusqu'a prendre en charge le package. Et toi tu peut peut-etre te passer du packaging, mais cela n'est pas le cas de l'ensemble des utilisateurs de debian, ni meme d'une tres grande majorite d'entre eux. > Alors bon... ce serait bien de garder les choses "dans l'ordre naturel" et de > na > pas inverser les valeurs et les mérites de chacun. Sur, ... > PS : pour rester dans le sujet du message, j'ai pas vu passé de réponse à la > demande d'explication du pourquoi la recompilation xfree 4.3 Debian demande > 4Go > alors que la même manip upstream demande beaucoup moins... j'ai raté qqchose > ou > alors j'ai mal compris ? Donc, pour en revenir au sujet, et c'est en fait la seule raison pour laquelle j'ai poste, c'est tout simplement parceque les packages construissent la version avec chargement dynamique de modules, et la version statique. De plus une version avec symbole de debugging est aussi construite. C'est surtout ces deux derniers qui prennent enormement de place. Malheureusement, il n'est pas facile de desactiver la compilation de ces packages, mais tu est bienvenu a fournir un patch si le coeur t'en dis. Remarque, les sources upstreams prennent que 700Mo environ, ce qui est deja pas mal. Amicalement, Sven Luther
Re: Backport XFree 4.3
Salut, Bon, ma "BA" du jour, je vais un peu épauler Erwan bien que je sache d'avance l'inutilité de la démarche car chez Debian de toute manière c'est le packageur qu'a raison ... :-( En réponse à Erwan David <[EMAIL PROTECTED]>: > Le Wed 11/06/2003, Pierre Machard disait > > > En revanche, on s'éloigne du sujet, car ta réaction portait sur le > fait > > qu'avoir un paquet debian n'était pas un gage de qualité. Personnellement j'ai résisté, mais la réaction était plutôt envers l'affirmation de Sven, Debian diffuse un packaging "habituellement" meilleur qu'upstream. Je conteste également cette affirmation, sans être aussi radical qu'Erwan (encore que des fois ça démange vraiment) > > moment donné), ton système fonctionne, et que lorsqu'un paquet est > > installé, on est preque garanti à 100 % que le logiciel fonctionnera > > sans problème. cf l'exemple de zope récent... où il faut installer le paquet, casser son système, lire le README.Debian et réparer son système... Personnellement : GROS malaise... mais bon, passons. cf autre exemple, la décision de Debian de gérer le texmf.cnf à sa sauce, avec pour conséquence de casser une grade partie des install tetex en place sans prévenir l'utilisateur (fil édifiant à ce sujet sur debian-devel) ... je laisse le soin aux packageurs ici présents de se fatiguer à me convaincre que c'est pour la bonne cause... en ce qui me concerne je suis désormais TRES prudent dans TOUTE mise à jour de paquet. > cela impose des libs inutiles, alors là je peux dire que le paquet > debian est gage de mauvaise qualité. Sans paquet ça marche mieux. C'est indéniable, il y a AUSSI des cas où ça marche mieux sans paquets, et/ou plus précisément il vaut mieux rechercher des paquets non-officiels. (cf www.apt-get.org)... Je garde pour la fin une réflexion perso : quelle que soit la qualité du packaging Debian pour ... emacs ou xfree ou gnome (au hasard), il faut bien se rappeler que ce n'est "que" du packaging (parfois complexe certes), et qu'un respect encore plus grand doit être attribué aux développeurs amont. En matière de logiciels libres, on pourrait se passer du packaging Debian mais pas du développement amont. Alors bon... ce serait bien de garder les choses "dans l'ordre naturel" et de na pas inverser les valeurs et les mérites de chacun. PS : pour rester dans le sujet du message, j'ai pas vu passé de réponse à la demande d'explication du pourquoi la recompilation xfree 4.3 Debian demande 4Go alors que la même manip upstream demande beaucoup moins... j'ai raté qqchose ou alors j'ai mal compris ? A+ -- mailto:[EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Wed 11/06/2003, Pierre Machard disait > En revanche, on s'éloigne du sujet, car ta réaction portait sur le fait > qu'avoir un paquet debian n'était pas un gage de qualité. Et bien si > justement parce que debian utilise un système de gestion des dépendances > très bien conçu et que justement meme si cela occasionne parfois des > désagréments temporaires (ie. paquet non disponible pour testing à un > moment donné), ton système fonctionne, et que lorsqu'un paquet est > installé, on est preque garanti à 100 % que le logiciel fonctionnera > sans problème. Et je peux te cioter les *emcas où c'est le fait qu'ilks soient pacakgés qui les rend incomptibles avec toutes les explications données hors de debian... Ce ne sont lus des installations de emacs ce sont des installations dee Debian-emacs avec des tas de spécificité qui en rendent la gestion différente des autres emacs. QUand en plus cela impose des libs inutiles, alors là je peux dire que le paquet debian est gage de mauvaise qualité. Sans paquet ça marche mieux. -- Erwan
Re: Backport XFree 4.3
Le mercredi 11 juin 2003 à 13:24 +0200, Erwan David a écrit : > Le Wed 11/06/2003, Pierre Machard disait > > Salut, > > > > Le mercredi 11 juin 2003 à 10:58 +0200, Erwan David a écrit : > > [...] > > > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > > > gage de qulité. Pas plus que de non qualité d'ailleurs. > > > > Au vue du nombre de gens qui utilisent debian et qui font des rapports > > de bogues, la qualité est très bonne dans Debian. > > > > En plus compte tennu du tres grand nombre de personne qui utilisent > > testing (sarge), on peut légitimement penser que les paquets sont de > > qualité. > > > Alors explique moi pourquoi ça fait 3 semaines que par suite de > bidouilles perl il ya des tas de paquests cassés dans testing ? Parce que c'est un automate qui gère le déplacement des paquets de unstable vers sarge. Donc il arrive que des paquets qui dépendent de certaines bibliothèque soient cassés. En revanche, on s'éloigne du sujet, car ta réaction portait sur le fait qu'avoir un paquet debian n'était pas un gage de qualité. Et bien si justement parce que debian utilise un système de gestion des dépendances très bien conçu et que justement meme si cela occasionne parfois des désagréments temporaires (ie. paquet non disponible pour testing à un moment donné), ton système fonctionne, et que lorsqu'un paquet est installé, on est preque garanti à 100 % que le logiciel fonctionnera sans problème. a+ -- Pierre Machard <[EMAIL PROTECTED]> TuxFamily.org <[EMAIL PROTECTED]> techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 01:23:32PM +0200, Erwan David wrote: > Le Wed 11/06/2003, Sven Luther disait > > > > Non, tu te trompe, si tu arrive a compiler le module, rien, absolument > > rien ne t'empeche d'en faire un package source comme j'ai fait pour le > > driver unicorn. J'irai meme plus loin, et je me propose de te > > sponsoriser et de t'aider dans ta demarche si jamais tu te lance pour le > > packager. Pour remonter les problemes upstream, il suffit bien souvent > > de savoir ecrire des mails en anglais, ce qui est a la porte de presque > > tout le monde. Bien sur, upstream peut t'ignorer totalement, mais dans > > ce cas, je boycotterai leur produit (je sais, c'est pas toujours > > possible). > > > > Pour faire un package source, il te suffit de : > > > > 1) installer kernel-package et dh_make. > > Et comprendre commen,t ils marchent. Ça commence mal car > kernel_package est incompréhensible avec une doc qui ne différencie > pas ce qui est exemple et ce qui est commande. il suffit de faire : make-kpkg --revision 1 --bzimage kernel-image pour le noyau, et : make-kpkg --revision 1 modules_image pour les modules, pas besoin de lire des tonnes de docs pas tres comprehensibles. > > 2) faire un dh_make et choisir le kernel-module comme type de package. > >Faut encore passer 3 jours à comprendre la doc de dh_make. Tu fait dh_make, tu repond k lorsqu'il te le demande, et le tour est joue. > > 3) modifier le debian/rules pour qu'il construisse le package source. > >Faut d'abord comprendre à quoi sers ce truc qui s'appelle "rules" >mais semble être un script Il s'agit tout simplement d'un Makefile, (remarque le #!/usr/bin/make -f au debut), qui dispose d'un certains nombre de cibles qui sont utilise par dpkg-buildpackage. J'avoue que c'est la partie la plus difficile de toute, mais c'est quand meme pas la mer a boire. Pour le driver unicorn, j'ai modifie essentiellement les cibles suivantes : binary-modules: ... # Build the module $(MAKE) HPATH=$(KSRC)/include # Install the module $(MAKE) install.debian DESTDIR=$(CURDIR)/debian/$(pmodules) KERNELVERSION=$(KVERS) install: le necessaire pour copier les sources du module dans debian/$(psource)/usr/src/modules/$(package). Et cela doit etre tout si je me souvient bien, le reste etait dans le debian/rules fournit par dh_make. > > 4) essayer le tout. > > > > En general, cela marche bien, des fois il faut faire d'autres modifs > > plus petites, tout depend de la qualite du package upstream. > > > > Et je ne pense pas que faire un package soit irresponsable, au > > contraire, cela permet a d'autres utilisateurs d'en profiter. > > Un boulot énorme qui n'apporte *rien* à personne si je n'ai pas le > même noiyau que les autres. Et en attendant le module il va où si ce N'importe quoi, on voir bien que tu n'a rien compris a comment debian gere les modules. En faissant un package de module, tu genere un package source, qu'un utilisateur pourra alors installer (dans /usr/src/modules_name.tgz) decompresse (dans /usr/src/modules) puis construire en meme temps que _son_ noyau (make-kpkg kernel-image pour le noyau, make-kpkg modules_image pour les modules). Grace a ceci il obtiendra un package de noyau qui lui corresponde, et un ou plusieurs packages de modules qui vont avec. Les packages ont la version du noyau (y compris la flavour eventuelle) comme partie de leur nom, et tu peut donc avoir plusieurs version differentes de noyau et modules correspondant installe en meme temps. > n'est dans /lib/modules ? À quoi ça sers tout ça ? Les source du module vont dans /usr/src/modules, ils sont compile dans un .deb, qui une fois installe va a la place correcte (/lib/modules/version_du_noyau). Amicalement, Sven Luther
Re: Backport XFree 4.3
Hé oh ! Vous avez pas fini de trollé oui ! Package debian ou pas et de bonne ou mauvaise qualité ! FreeBSD distros ou pas ! Chacun à son avis, et une fois de plus le libre permet à chacun de choisir. Inunitile de camper sur vos positions en essayant de convaincre une personne toute décidée à ne pas changer d'avis. Pour revenir à l'utilisation de cette liste, je crois savoir que son but est l'entraide des utilisateurs français d'une distros debian. Pertinence de ce threads 0. Et j'en suis d'autant plus navré que j'en suis à l'origine. Alors SVP reprennez-vous, et donnez plus un coup de pouce à ceux qui en ont besoin. Cordialement, Nicolas.
Re: Backport XFree 4.3
Le Wed 11/06/2003, Sven Luther disait > > Non, tu te trompe, si tu arrive a compiler le module, rien, absolument > rien ne t'empeche d'en faire un package source comme j'ai fait pour le > driver unicorn. J'irai meme plus loin, et je me propose de te > sponsoriser et de t'aider dans ta demarche si jamais tu te lance pour le > packager. Pour remonter les problemes upstream, il suffit bien souvent > de savoir ecrire des mails en anglais, ce qui est a la porte de presque > tout le monde. Bien sur, upstream peut t'ignorer totalement, mais dans > ce cas, je boycotterai leur produit (je sais, c'est pas toujours > possible). > > Pour faire un package source, il te suffit de : > > 1) installer kernel-package et dh_make. Et comprendre commen,t ils marchent. Ça commence mal car kernel_package est incompréhensible avec une doc qui ne différencie pas ce qui est exemple et ce qui est commande. > 2) faire un dh_make et choisir le kernel-module comme type de package. Faut encore passer 3 jours à comprendre la doc de dh_make. > 3) modifier le debian/rules pour qu'il construisse le package source. Faut d'abord comprendre à quoi sers ce truc qui s'appelle "rules" mais semble être un script > 4) essayer le tout. > > En general, cela marche bien, des fois il faut faire d'autres modifs > plus petites, tout depend de la qualite du package upstream. > > Et je ne pense pas que faire un package soit irresponsable, au > contraire, cela permet a d'autres utilisateurs d'en profiter. Un boulot énorme qui n'apporte *rien* à personne si je n'ai pas le même noiyau que les autres. Et en attendant le module il va où si ce n'est dans /lib/modules ? À quoi ça sers tout ça ? -- Erwan
Re: Backport XFree 4.3
Le Wed 11/06/2003, Pierre Machard disait > Salut, > > Le mercredi 11 juin 2003 à 10:58 +0200, Erwan David a écrit : > [...] > > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > > gage de qulité. Pas plus que de non qualité d'ailleurs. > > Au vue du nombre de gens qui utilisent debian et qui font des rapports > de bogues, la qualité est très bonne dans Debian. > > En plus compte tennu du tres grand nombre de personne qui utilisent > testing (sarge), on peut légitimement penser que les paquets sont de > qualité. Alors explique moi pourquoi ça fait 3 semaines que par suite de bidouilles perl il ya des tas de paquests cassés dans testing ? -- Erwan
Re: Backport XFree 4.3
Sven Luther <[EMAIL PROTECTED]> a écrit : > Les BSD sont en fait un noyau BSD ainsi qu'une partie de l'userland > (les ports), Un système BSD est un système complêt noyal+userland. Les ports n'ont rien à voir là dedans. > Dans ce sens on ne peut pas reellement dire que les *BSD sont des > distributions au meme sens que debian l'est. Non, on ne peut vraiment pas le dire. > En fait On peut dire que les differents*BSD sont plus qu'un noyau mais > moins qu'une distrib complete Je ne comprends pas le la pertinence de « distrib complête ». Xavier
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 10:42:02AM +0100, Yves Rutschle wrote: > On Wed, Jun 11, 2003 at 10:25:37AM +0200, Sven Luther wrote: > > Rien a voir, vraiment, freeBSD, c'est un autre noyau surtout, pas une > > distrib. Et je crois qu'il y a un Debian/FreeBSD pas encore officiel > > cependant. En tout cas je sais qu'il y a un Debian/NetBSD. > > Comment ça, FreeBSD pas une distribution? Pour ce que j'en > connais, ça me parait être une distribution au même titre > que NetBSD ou Gentoo? > > Comment definis-tu une distribution et qu'est-ce qui fait > que FreeBSD n'en est pas une? Les BSD sont en fait un noyau BSD ainsi qu'une partie de l'userland (les ports), alors que linux est divise en noyau et userland, et que les distribs (debian, redhat, mandrake, gentoo) packagent le tout. Dans ce sens on ne peut pas reellement dire que les *BSD sont des distributions au meme sens que debian l'est. En fait On peut dire que les differents *BSD sont plus qu'un noyau mais moins qu'une distrib complete, et le fait qu'il y ai un debian/netbsd le prouve (apres tout, pourquoi il y aurrai une distrib debian/netbsd si netbsd etait deja une distribution. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Wed, Jun 11, 2003 at 10:39:41AM +0100, Yves Rutschle ecrivait : > > A propos, ça serait pas mal que ton mailer remplisse le > champ "In-Reply-To", car tu casses tous les fils de il le fait (je viens de vérifier sur les archives de la liste...). David. pgpR3QjocLFuv.pgp Description: PGP signature
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 11:55:12AM +0200, Erwan David wrote: > Le Wed 11/06/2003, Sven Luther disait > > > > > > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > > > gage de qulité. Pas plus que de non qualité d'ailleurs. > > > > Et moi, d'apres mon experience personnelle en tant qu'utilisateur et en > > tant que packageur, et suite a mes echanges avec upstream, je pretend le > > contraire, que du moins dans 2 de mes packages, la qualite du package > > _upstream_ a ete ameliorer suite a mon interaction avec upstream du au > > packaging. > > Encore faut-il que le packageur puisse remonter des infos pertinentes > à l'upstream. Donc il ne sers à *rien* de vouloir à tout pris packager > si on n'est pas dans ce cas. Je prendrai l'exemple du module pour le > chipset réseau broadcom 4400 (c'est ce que j'ai au boulot). Le source > existe, en GPL. Mais n'est pas packagé. Il serait imbécile de ma part > de le packager en étant inbcapable de diagnostiquer quoi que ce > soit. Donc je compile le module avec le makefile de l'upstream et je > le mets dans /lib/modules > > Toute autre attitude de ma part serait doiuteuse voire irresponsable. Non, tu te trompe, si tu arrive a compiler le module, rien, absolument rien ne t'empeche d'en faire un package source comme j'ai fait pour le driver unicorn. J'irai meme plus loin, et je me propose de te sponsoriser et de t'aider dans ta demarche si jamais tu te lance pour le packager. Pour remonter les problemes upstream, il suffit bien souvent de savoir ecrire des mails en anglais, ce qui est a la porte de presque tout le monde. Bien sur, upstream peut t'ignorer totalement, mais dans ce cas, je boycotterai leur produit (je sais, c'est pas toujours possible). Pour faire un package source, il te suffit de : 1) installer kernel-package et dh_make. 2) faire un dh_make et choisir le kernel-module comme type de package. 3) modifier le debian/rules pour qu'il construisse le package source. 4) essayer le tout. En general, cela marche bien, des fois il faut faire d'autres modifs plus petites, tout depend de la qualite du package upstream. Et je ne pense pas que faire un package soit irresponsable, au contraire, cela permet a d'autres utilisateurs d'en profiter. Amicalement, Sven Luther > > -- > Erwan > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Backport XFree 4.3
Le Wed 11/06/2003, Sven Luther disait > > > > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > > gage de qulité. Pas plus que de non qualité d'ailleurs. > > Et moi, d'apres mon experience personnelle en tant qu'utilisateur et en > tant que packageur, et suite a mes echanges avec upstream, je pretend le > contraire, que du moins dans 2 de mes packages, la qualite du package > _upstream_ a ete ameliorer suite a mon interaction avec upstream du au > packaging. Encore faut-il que le packageur puisse remonter des infos pertinentes à l'upstream. Donc il ne sers à *rien* de vouloir à tout pris packager si on n'est pas dans ce cas. Je prendrai l'exemple du module pour le chipset réseau broadcom 4400 (c'est ce que j'ai au boulot). Le source existe, en GPL. Mais n'est pas packagé. Il serait imbécile de ma part de le packager en étant inbcapable de diagnostiquer quoi que ce soit. Donc je compile le module avec le makefile de l'upstream et je le mets dans /lib/modules Toute autre attitude de ma part serait doiuteuse voire irresponsable. -- Erwan
Re: Backport XFree 4.3
Salut, Le mercredi 11 juin 2003 à 10:58 +0200, Erwan David a écrit : [...] > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > gage de qulité. Pas plus que de non qualité d'ailleurs. Au vue du nombre de gens qui utilisent debian et qui font des rapports de bogues, la qualité est très bonne dans Debian. En plus compte tennu du tres grand nombre de personne qui utilisent testing (sarge), on peut légitimement penser que les paquets sont de qualité. Je pense, de plus, que le fait que debian soit porté sur plusieurs architectures est quelque chose de très profitable pour tout le monde (à la fois upsteam et utilisateur) a+ -- Pierre Machard <[EMAIL PROTECTED]> TuxFamily.org <[EMAIL PROTECTED]> techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 10:25:37AM +0200, Sven Luther wrote: > Rien a voir, vraiment, freeBSD, c'est un autre noyau surtout, pas une > distrib. Et je crois qu'il y a un Debian/FreeBSD pas encore officiel > cependant. En tout cas je sais qu'il y a un Debian/NetBSD. Comment ça, FreeBSD pas une distribution? Pour ce que j'en connais, ça me parait être une distribution au même titre que NetBSD ou Gentoo? Comment definis-tu une distribution et qu'est-ce qui fait que FreeBSD n'en est pas une? /Y - on m'aurait menti? -- Marbles should be kept together.
Re: Backport XFree 4.3
On Tue, Jun 10, 2003 at 04:46:45PM +0100, David Cure wrote: > non mais utiliser une liste pour ce qu'elle est serait bien. A propos, ça serait pas mal que ton mailer remplisse le champ "In-Reply-To", car tu casses tous les fils de discussions. Les fils, c'est important pour suivre ce qui se passe sur une liste qu'on veut utiliser pour ce qu'elle est :-) /Y - a puriste, puriste et demi -- Marbles should be kept together.
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 10:58:33AM +0200, Erwan David wrote: > Le Wed 11/06/2003, Sven Luther disait > > On Wed, Jun 11, 2003 at 09:58:06AM +0200, Erwan David wrote: > > > > > que je prends de plus en plus de trucs hors paquets, je suis dubitatif > > > > > sur la qualité engendrée par le packaging... > > > > > Surtout dans le cas d'un module noyau que de toutae façon on devra > > > > > recompiler. > > > > > > > > Tu parle en connaissance de cause, ou est-ce juste un avis gratuit ? > > > > > > En connaissance de cause de qauoi ? Non je n'ai jamais fait de paquet > > > debian, pour la bonne raison que j'ai reculé devanlt la montagne de > > > truc à comprendre pour en faire. > > > > Tu dis que tu est dubitatif sur la qualite des packages debian et en > > particulier des modules noyau. Tu a des examples precis, ou c'est juste > > du blabla en l'air parceque tu ne t'ai pas donne la peine d'essayer de > > comprendre comment cela marche ? > > Non, je dis que le fait que ce soiit un paquet debian n'est pas un > gage de qulité. Pas plus que de non qualité d'ailleurs. Et moi, d'apres mon experience personnelle en tant qu'utilisateur et en tant que packageur, et suite a mes echanges avec upstream, je pretend le contraire, que du moins dans 2 de mes packages, la qualite du package _upstream_ a ete ameliorer suite a mon interaction avec upstream du au packaging. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Wed 11/06/2003, Sven Luther disait > On Wed, Jun 11, 2003 at 09:58:06AM +0200, Erwan David wrote: > > > > que je prends de plus en plus de trucs hors paquets, je suis dubitatif > > > > sur la qualité engendrée par le packaging... > > > > Surtout dans le cas d'un module noyau que de toutae façon on devra > > > > recompiler. > > > > > > Tu parle en connaissance de cause, ou est-ce juste un avis gratuit ? > > > > En connaissance de cause de qauoi ? Non je n'ai jamais fait de paquet > > debian, pour la bonne raison que j'ai reculé devanlt la montagne de > > truc à comprendre pour en faire. > > Tu dis que tu est dubitatif sur la qualite des packages debian et en > particulier des modules noyau. Tu a des examples precis, ou c'est juste > du blabla en l'air parceque tu ne t'ai pas donne la peine d'essayer de > comprendre comment cela marche ? Non, je dis que le fait que ce soiit un paquet debian n'est pas un gage de qulité. Pas plus que de non qualité d'ailleurs. > Rien a voir, vraiment, freeBSD, c'est un autre noyau surtout, pas une > distrib. Et je crois qu'il y a un Debian/FreeBSD pas encore officiel > cependant. En tout cas je sais qu'il y a un Debian/NetBSD. Il y a quand même le système des ports. Et comme mon plus gros est une fuite mémoire dans le noyau qui m'oblige à rebooter tous les 3/4 jours et pour laquelle personne n'a pu me donner d'avis, changer de noyau ne me parait pas un mal. -- Erwan
Re: Backport XFree 4.3
Sven Luther a tapoté : > Rien a voir, vraiment, freeBSD, c'est un autre noyau surtout, pas une > distrib. Et je crois qu'il y a un Debian/FreeBSD pas encore officiel > cependant. En tout cas je sais qu'il y a un Debian/NetBSD. Ouais, enfin ces trucs là ont un intêret plus que limité... Xavier
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 09:58:06AM +0200, Erwan David wrote: > > > que je prends de plus en plus de trucs hors paquets, je suis dubitatif > > > sur la qualité engendrée par le packaging... > > > Surtout dans le cas d'un module noyau que de toutae façon on devra > > > recompiler. > > > > Tu parle en connaissance de cause, ou est-ce juste un avis gratuit ? > > En connaissance de cause de qauoi ? Non je n'ai jamais fait de paquet > debian, pour la bonne raison que j'ai reculé devanlt la montagne de > truc à comprendre pour en faire. Tu dis que tu est dubitatif sur la qualite des packages debian et en particulier des modules noyau. Tu a des examples precis, ou c'est juste du blabla en l'air parceque tu ne t'ai pas donne la peine d'essayer de comprendre comment cela marche ? (Err, meme si le ton semble un peu agressif, ce n'est pas mon but, donc ne le prend pas mal). > > Comme dis, je package le driver unicorn pour les modems ADSL pci st et > > usb de Bewan. J'ai de tres bon contact avec upstream, et je peut > > t'assurer que la qualite _du tarball upstream_ a ete ameliore suite a > > mes interventions, sans parler de la discussion que j'ai eu avec eux a > > propos de la license. Et cela est aussi le cas pour d'autre packages que > > je maintient. Le fait qu'un programme soit packager dans debian est > > souvent un gage de qualite de la version upstream aussi, car le > > mainteneur n'acceptera pas certaines pratiques douteuses qui sont > > presentes dans certains sources upstream, surtout en ce qui concerne les > > modules noyaux. A nouveau, va voir le module pour les modems olitec et > > essaye de les installer lorsque le noyau que tu veut utiliser ne tourne > > pas encore pour le moment, ou encore de les construire sur une machine > > differente de la machine ou le modem est installe. > > > > Et si les packages debian ne te plaisent pas, rien ne t'empeche d'aller > > installer Gentoo. > > Je suis en train de tester freeBSD?. Mais pour une sombre raison de > truc qui ne compile que sous linux (hpoj) je suis bloqué. Rien a voir, vraiment, freeBSD, c'est un autre noyau surtout, pas une distrib. Et je crois qu'il y a un Debian/FreeBSD pas encore officiel cependant. En tout cas je sais qu'il y a un Debian/NetBSD. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Wed, Jun 11, 2003 at 09:58:59AM +0200, Erwan David ecrivait : > > Mais le source n'est *pas* conçu pour être foutu dans > /usr/src/module. Du tout. vivi, je parlais des packages debian des modules (comme celui des modules drm...) David. pgpZy3c5ONoCh.pgp Description: PGP signature
Re: Backport XFree 4.3
Le Wed 11/06/2003, Sven Luther disait > On Wed, Jun 11, 2003 at 08:59:43AM +0200, Erwan David wrote: > > Le Wed 11/06/2003, Sven Luther disait > > > > > > De plus, les exigences liee au packaging debian, si elle sont rapporte > > > upstream, sont la cause d'une package de bien meilleure qualite que se > > > que la plupart des upstreams distribuent habituellement. > > > > Quand je vois ce que donnent certains paquets (les *emacs, mutt, tous > > les trucs qui forcent gnome quand il n'est pas nécessaire), qui font > > Mauvais exemple, prend vim par exemple, il y a soit vim qui ne depend de > pas grand chose, soit vim-gtk qui depend de gtk+, mais pas gnome, mutt > depend seulement de : > > Depends: libc6 (>= 2.3.1-1), libdb4.0, libidn9, libncurses5 (>= > 5.3.20021109-1), libsasl7, exim | mail-transport-agent Pour mutt ce ne sont pas les dépendances mais les options de compil (support du mode corbeau anonyme mais pas enable-buffy-size) plus l'impossibilité de le reconstruireà partir des sources. > Qui ne me parait pas si exagere que cela. > > Et meme emacs21 par exemple ne depend que de : > Depends: emacs21-common (= 21.3-1), libc6 (>= 2.3.1-1), libjpeg62, > libncurses5 (>= 5.3.20021109-1), libpng12-0, libtiff3g, xaw3dg (>= > 1.5-6), xlibs (>> 4.1.0), zlib1g (>= 1:1.1.4) > > Ce qui ne me semble pas si terrible que cela, et xemacs21 depend de : > > Depends: xemacs21-mule (= 21.4.12-1) | xemacs21-mule-canna-wnn (= > 21.4.12-1) | xemacs21-nomule (= 21.4.12-1) | xemacs21-gnome-mule (= > 21.4.12-1) | xemacs21-gnome-mule-canna-wnn (= 21.4.12-1) | > xemacs21-gnome-nomule (= 21.4.12-1) > > Donc, on voit bien que tu peut choisir les version gnome ou pas gnome, > suivant tes besoins. Là encore autre problème : c'est toute la façoin debian de dénaturer les emacs que je ne supporte pas, de charger 50 tionnes de libs inutiles, de rendre inutilisable les paquets Xemacs, et sur les dépendances de forcer ldap et les *sql. > > que je prends de plus en plus de trucs hors paquets, je suis dubitatif > > sur la qualité engendrée par le packaging... > > Cela c'est ridicule, et meprisant pour l'ensemble des developpeurs > debian qui se donnent du mal pour faire des packages de qualite. Sur, > certains developpeurs sont pas tres actifs, et certains packages sont > plutot mal maintenu, mais dans l'ensemble, cela marche plutot bien. Dans l'ensemble ça marchotte. > > Surtout dans le cas d'un module noyau que de toutae façon on devra > > recompiler. > > Tu parle en connaissance de cause, ou est-ce juste un avis gratuit ? En connaissance de cause de qauoi ? Non je n'ai jamais fait de paquet debian, pour la bonne raison que j'ai reculé devanlt la montagne de truc à comprendre pour en faire. > Comme dis, je package le driver unicorn pour les modems ADSL pci st et > usb de Bewan. J'ai de tres bon contact avec upstream, et je peut > t'assurer que la qualite _du tarball upstream_ a ete ameliore suite a > mes interventions, sans parler de la discussion que j'ai eu avec eux a > propos de la license. Et cela est aussi le cas pour d'autre packages que > je maintient. Le fait qu'un programme soit packager dans debian est > souvent un gage de qualite de la version upstream aussi, car le > mainteneur n'acceptera pas certaines pratiques douteuses qui sont > presentes dans certains sources upstream, surtout en ce qui concerne les > modules noyaux. A nouveau, va voir le module pour les modems olitec et > essaye de les installer lorsque le noyau que tu veut utiliser ne tourne > pas encore pour le moment, ou encore de les construire sur une machine > differente de la machine ou le modem est installe. > > Et si les packages debian ne te plaisent pas, rien ne t'empeche d'aller > installer Gentoo. Je suis en train de tester freeBSD?. Mais pour une sombre raison de truc qui ne compile que sous linux (hpoj) je suis bloqué. -- Erwan
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 09:35:59AM +0200, David Cure wrote: > Le Tue, Jun 10, 2003 at 06:15:39PM +0200, Sven Luther ecrivait : > > > > Si tu ne souhaite pas recevoir de doublons, il y a des header que tu > > peut rajouter a ton mail pour que cela n'arrive pas, je suis pas un > > expert de cela cependant. > > je sais, mais on n'est plus sur une liste... > > > Imagine toi que tu change de noyau alors. > > idem, si je passe en 2.4.21, je ne suis pas obligé de recompiler > le module radeon (si je n'ai pas les infos de version dans les modules). > > > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > > bien, alors pourquoi ne pas les utiliser ? > > parce que je n'utilise pas le "kernel package". > OK, j'aurais du marquer dans mon message : "ce qui suit n'est pas > "debian like", il y a une méthode debian mais je ne l'utilise pas" Et bien note que c'est toi qui assurera le support en cas de probleme, je doute que Branden apprecie de recevoir des bug report liee au fait d'utiliser ta methode :))) Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Wed 11/06/2003, David Cure disait > Le Wed, Jun 11, 2003 at 08:59:43AM +0200, Erwan David ecrivait : > > > > Surtout dans le cas d'un module noyau que de toutae façon on devra > > recompiler. > > et qui le mets dans un rep /usr/src/modules... comment je fais > pour classer les modules ? (car je n'utilise pas les memes en fonctions > des machines et de la version du kernel) Mais le source n'est *pas* conçu pour être foutu dans /usr/src/module. Du tout. -- Erwan
Re: Backport XFree 4.3
Le Tue, Jun 10, 2003 at 06:15:39PM +0200, Sven Luther ecrivait : > > Si tu ne souhaite pas recevoir de doublons, il y a des header que tu > peut rajouter a ton mail pour que cela n'arrive pas, je suis pas un > expert de cela cependant. je sais, mais on n'est plus sur une liste... > Imagine toi que tu change de noyau alors. idem, si je passe en 2.4.21, je ne suis pas obligé de recompiler le module radeon (si je n'ai pas les infos de version dans les modules). > DRI, et se donne du mal pour faire des packages dri-trunk qui marchent > bien, alors pourquoi ne pas les utiliser ? parce que je n'utilise pas le "kernel package". OK, j'aurais du marquer dans mon message : "ce qui suit n'est pas "debian like", il y a une méthode debian mais je ne l'utilise pas" David. pgpzIq9SnQfNR.pgp Description: PGP signature
Re: Backport XFree 4.3
Le Wed, Jun 11, 2003 at 08:59:43AM +0200, Erwan David ecrivait : > > Surtout dans le cas d'un module noyau que de toutae façon on devra > recompiler. et qui le mets dans un rep /usr/src/modules... comment je fais pour classer les modules ? (car je n'utilise pas les memes en fonctions des machines et de la version du kernel) David. pgpAVLK5aape4.pgp Description: PGP signature
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 08:59:43AM +0200, Erwan David wrote: > Le Wed 11/06/2003, Sven Luther disait > > > > De plus, les exigences liee au packaging debian, si elle sont rapporte > > upstream, sont la cause d'une package de bien meilleure qualite que se > > que la plupart des upstreams distribuent habituellement. > > Quand je vois ce que donnent certains paquets (les *emacs, mutt, tous > les trucs qui forcent gnome quand il n'est pas nécessaire), qui font Mauvais exemple, prend vim par exemple, il y a soit vim qui ne depend de pas grand chose, soit vim-gtk qui depend de gtk+, mais pas gnome, mutt depend seulement de : Depends: libc6 (>= 2.3.1-1), libdb4.0, libidn9, libncurses5 (>= 5.3.20021109-1), libsasl7, exim | mail-transport-agent Qui ne me parait pas si exagere que cela. Et meme emacs21 par exemple ne depend que de : Depends: emacs21-common (= 21.3-1), libc6 (>= 2.3.1-1), libjpeg62, libncurses5 (>= 5.3.20021109-1), libpng12-0, libtiff3g, xaw3dg (>= 1.5-6), xlibs (>> 4.1.0), zlib1g (>= 1:1.1.4) Ce qui ne me semble pas si terrible que cela, et xemacs21 depend de : Depends: xemacs21-mule (= 21.4.12-1) | xemacs21-mule-canna-wnn (= 21.4.12-1) | xemacs21-nomule (= 21.4.12-1) | xemacs21-gnome-mule (= 21.4.12-1) | xemacs21-gnome-mule-canna-wnn (= 21.4.12-1) | xemacs21-gnome-nomule (= 21.4.12-1) Donc, on voit bien que tu peut choisir les version gnome ou pas gnome, suivant tes besoins. > que je prends de plus en plus de trucs hors paquets, je suis dubitatif > sur la qualité engendrée par le packaging... Cela c'est ridicule, et meprisant pour l'ensemble des developpeurs debian qui se donnent du mal pour faire des packages de qualite. Sur, certains developpeurs sont pas tres actifs, et certains packages sont plutot mal maintenu, mais dans l'ensemble, cela marche plutot bien. > Surtout dans le cas d'un module noyau que de toutae façon on devra > recompiler. Tu parle en connaissance de cause, ou est-ce juste un avis gratuit ? Comme dis, je package le driver unicorn pour les modems ADSL pci st et usb de Bewan. J'ai de tres bon contact avec upstream, et je peut t'assurer que la qualite _du tarball upstream_ a ete ameliore suite a mes interventions, sans parler de la discussion que j'ai eu avec eux a propos de la license. Et cela est aussi le cas pour d'autre packages que je maintient. Le fait qu'un programme soit packager dans debian est souvent un gage de qualite de la version upstream aussi, car le mainteneur n'acceptera pas certaines pratiques douteuses qui sont presentes dans certains sources upstream, surtout en ce qui concerne les modules noyaux. A nouveau, va voir le module pour les modems olitec et essaye de les installer lorsque le noyau que tu veut utiliser ne tourne pas encore pour le moment, ou encore de les construire sur une machine differente de la machine ou le modem est installe. Et si les packages debian ne te plaisent pas, rien ne t'empeche d'aller installer Gentoo. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Wed 11/06/2003, Sven Luther disait > > De plus, les exigences liee au packaging debian, si elle sont rapporte > upstream, sont la cause d'une package de bien meilleure qualite que se > que la plupart des upstreams distribuent habituellement. Quand je vois ce que donnent certains paquets (les *emacs, mutt, tous les trucs qui forcent gnome quand il n'est pas nécessaire), qui font que je prends de plus en plus de trucs hors paquets, je suis dubitatif sur la qualité engendrée par le packaging... Surtout dans le cas d'un module noyau que de toutae façon on devra recompiler. -- Erwan
Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 07:25:13AM +0200, Erwan David wrote: > Le Tue 10/06/2003, Sven Luther disait > > On Tue, Jun 10, 2003 at 07:02:27PM +0200, Erwan David wrote: > > > Le Tue 10/06/2003, Sven Luther disait > > > > > > > Excuse moi, j'avais mal compris, mais meme comme cela, il ne faudrait > > > > pas installer de fichiers dans /lib/modules/ a la main. > > > > > > Et comment faire quand on a un module non supporté par Debian ? On le > > > mets où ? > > > > Hey, j'ai dis on ne devrait pas, pas on ne doit pas. > > > > Sinon, il te suffit de faire un petit package qui le contient, si tu a > > le source bien sur, sinon c'est plus complique. > > Et faire un paquet c'est pas compliqué ? Surtout que ça apporte > quoi ? À part être obligé d'aller trifouiller dans le source et le > makefile ? Sur c'est un peu plus complique que d'installer a la main, et encore, une fois que tu l'a fait, il est en general trivial de l'adapter pour des nouvelles versions. Le reel avantage, c'est que, certe tu fait un peu plus de travail que tu ne le devrait, mais tout le monde en profite si tu distribue le package en question. De plus, les exigences liee au packaging debian, si elle sont rapporte upstream, sont la cause d'une package de bien meilleure qualite que se que la plupart des upstreams distribuent habituellement. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Tue 10/06/2003, Sven Luther disait > On Tue, Jun 10, 2003 at 07:02:27PM +0200, Erwan David wrote: > > Le Tue 10/06/2003, Sven Luther disait > > > > > Excuse moi, j'avais mal compris, mais meme comme cela, il ne faudrait > > > pas installer de fichiers dans /lib/modules/ a la main. > > > > Et comment faire quand on a un module non supporté par Debian ? On le > > mets où ? > > Hey, j'ai dis on ne devrait pas, pas on ne doit pas. > > Sinon, il te suffit de faire un petit package qui le contient, si tu a > le source bien sur, sinon c'est plus complique. Et faire un paquet c'est pas compliqué ? Surtout que ça apporte quoi ? À part être obligé d'aller trifouiller dans le source et le makefile ? -- Erwan
Re: Backport XFree 4.3
On Tue, Jun 10, 2003 at 07:02:27PM +0200, Erwan David wrote: > Le Tue 10/06/2003, Sven Luther disait > > > Excuse moi, j'avais mal compris, mais meme comme cela, il ne faudrait > > pas installer de fichiers dans /lib/modules/ a la main. > > Et comment faire quand on a un module non supporté par Debian ? On le > mets où ? Hey, j'ai dis on ne devrait pas, pas on ne doit pas. Sinon, il te suffit de faire un petit package qui le contient, si tu a le source bien sur, sinon c'est plus complique. Tu peut prendre comme exemple les modules pour le driver v92 olitec et le driver pour les cartes adsl de bewan. Il est bien sur possible d'installer ces deux modules a la main, pour le driver adsl, j'ai fait un package, et ce n'est pas si complique quand upstream est responsif aux besoins de packaging et effectue les modifs necessaire dans leur fichier sources, j'en ai donc fait un package dont tout le monde profite. Par contre le package de module olitec est plus crade a la base, et lorsque je les ai contacter pour effectuer un package debian, j'ai ete totalement ignore, je vais donc desormais boycotter le materiel olitec, comme je boycot deja le materiel nvidia. Amicalement, Sven Luther
Re: Xinerama et XFree 4.3 [Etait: Backport XFree 4.3]
Sven Luther a écrit : On Mon, Jun 09, 2003 at 11:35:51AM +0200, Nicolas CANIART wrote: Sven Luther a écrit : Bonsoir ! (et presque bonjour !?!) Désolé, j'ai mis le temps mais j'été un peu occupé. Bien Tous ce passe désormais super jusqu'à l' étape 8 (merci tout particulièrement à Sven). Super, vous dites que je vais vous laisser en paix ! Navré mais non. J'ai un souci avec le xinerama. Mmm, ... Au début XFree à commencé à me dire dans le log que je devais vraiment être bête pour déclarer de Device pour une seule carte (même bus PCI). Mais il continuait son bonhomme de chemin est démarré. Je me suis apperçu que j'avais oublié de déclarer les Screen dans les section Devices. Je les ajoutent et puis il se contente de faire comme si de rien! Est-ce que tu a deux tetes ou non ? Envoie moi en privee ton /var/log/XFRee86.0.log et ton /etc/X11/XF86Config complet. Au début je croyais que c'etait le DRI qui n'allait pas à cause des messages: Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_clip.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_norm.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_xform.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/fonts/libspeedo.a:spencode.o": No symbols found (ce qui, au passage, semble vouloir dire que les modules trunk sont buggés). Mmm. Mais comme le log indique : (WW) RADEON(0): Direct rendering is not supported when Xinerama is enabled (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Remarqu'il y a des travaux en cours pour ajouter du support DRI meme en multi-head. Il ne devrait pas y avoir de conflit. J'ai tout de même essayé sans charger le dri (et puis sans tous ce qui pourrai se rapporter à l'accéleration matériel) sans plus de résultat. Donc, j'imagine que tu ne voir rien sur la deuxieme sortie. Donne moi (a nouveau) la configuration de tes moniteurs et ta carte, ainsi que les fichiers ci-dessus. A par cela aucune erreur rapportée, seuls quelques warning concernant les polices. Une idée. (C'est promis après je vous laisse tranquille !) Pour avoir une idee, il faut d'abord que tu donne plus d'info. Pour info. ma carte est une ATI Radeon 7000 VE (ça date un peu...). Mais devrait etre bien supporte. Amicalement, Sven Luther Bon c'est fini j'ai réussi à faire en sorte que tous marche. L'astuce : inverser les connexion des deux écrans sur la carte et demander à GDM d'afficher le gretter sur l'ecran 1 (XineramaScreen=1 dans /etc/gdm/gdm.conf sinon j'ai un "Effet Gnome" cf. si après) !!! Bon la solution me semble pas vraiment convinquante, mais voilà ça marche. Merci à ceux qui m'ont aidés. Reste un détails marrant sous gnome (plus exactement avec les panels) il m'affice sur un écran les zones sensibles pour la souris (i.e. des rectangles blanc et gris) et leur contenu (i.e le texte les image etc...) sur le second. Mais bon j'ai pas encore eut le temps de cherché (je viens de rentrer). De plus gnomedesktop.org et gnomesupport.org semblent injoignables (quelqu'un peut confirmer ?) Merci encore et à charge de revanche. Nicolas. P.S. : J'ai malgré tous toujours le warning pour les symboles non résolus des modules trunk.
Re: Backport XFree 4.3
Le Tue 10/06/2003, Sven Luther disait > Excuse moi, j'avais mal compris, mais meme comme cela, il ne faudrait > pas installer de fichiers dans /lib/modules/ a la main. Et comment faire quand on a un module non supporté par Debian ? On le mets où ? -- Erwan
Re: Backport XFree 4.3
On Tue, Jun 10, 2003 at 05:28:35PM +0200, David Cure wrote: > Le Tue, Jun 10, 2003 at 03:51:37PM +0200, Sven Luther ecrivait : > > > > Tu veut une regle procmail pour supprimer les doublons ? > > non mais utiliser une liste pour ce qu'elle est serait bien. Si tu ne souhaite pas recevoir de doublons, il y a des header que tu peut rajouter a ton mail pour que cela n'arrive pas, je suis pas un expert de cela cependant. > > Oui, mais a nouveau, si il y a un probleme avec les backports en > > question, il est relativement facile de faire un nouveau backport, c'est > > mais pourquoi faire ? dingue ça... refaire ce qui est fait, > alors qu'il fallait backporter quelques paquets manquants, ce que j'ai > fait. Ok alors. > > pose plus de probleme que cela n'en resout, surtout si plutard on oublie > > ce que l'on a fait, et que l'on fait une mise a jour (vers les packages > > 4.3.0 officiel par exemple). C'est ce genre de problemes qui sont > > beep, mauvais exemple car le drm *noyau* ne changera pas. et si > on change de version de X, ton paquet drm ne sera pas mis à jour > *automatiquement* de toute façon. Le truc est qu'on pourra avoir Imagine toi que tu change de noyau alors. > l'erreur de version de drm trop ancien. Oui, l'ideal est d'utiliser les packages drm-source qui viennent avec le X 4.3.0 qu'on utilise, ou alors les packages dri-trunk de Michel, Michel qui est a la fois un developpeur debian et tres actif dans le projet DRI, et se donne du mal pour faire des packages dri-trunk qui marchent bien, alors pourquoi ne pas les utiliser ? > > cela entraine. Si a la limite tu avait conseille une install nouvelle > > dans /usr/local ou un tru, je ne dis pas, mais /usr/X11R6 et co sont > > hein quoi ? vi vi : un noyau kernel dans /usr/local ;) Excuse moi, j'avais mal compris, mais meme comme cela, il ne faudrait pas installer de fichiers dans /lib/modules/ a la main. > > Sur, mais a part le ton, il y a aussi l'etat d'esprit du lecteur et de > > nombreux autres criteres, c'est toujours plus facile si on lit ce que > > les autres ecrivent avec un esprit ouvert et de la bonne volonte. > > comme tu dis... Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Tue, Jun 10, 2003 at 03:51:37PM +0200, Sven Luther ecrivait : > > Tu veut une regle procmail pour supprimer les doublons ? non mais utiliser une liste pour ce qu'elle est serait bien. > Oui, mais a nouveau, si il y a un probleme avec les backports en > question, il est relativement facile de faire un nouveau backport, c'est mais pourquoi faire ? dingue ça... refaire ce qui est fait, alors qu'il fallait backporter quelques paquets manquants, ce que j'ai fait. > pose plus de probleme que cela n'en resout, surtout si plutard on oublie > ce que l'on a fait, et que l'on fait une mise a jour (vers les packages > 4.3.0 officiel par exemple). C'est ce genre de problemes qui sont beep, mauvais exemple car le drm *noyau* ne changera pas. et si on change de version de X, ton paquet drm ne sera pas mis à jour *automatiquement* de toute façon. Le truc est qu'on pourra avoir l'erreur de version de drm trop ancien. > cela entraine. Si a la limite tu avait conseille une install nouvelle > dans /usr/local ou un tru, je ne dis pas, mais /usr/X11R6 et co sont hein quoi ? vi vi : un noyau kernel dans /usr/local ;) > Sur, mais a part le ton, il y a aussi l'etat d'esprit du lecteur et de > nombreux autres criteres, c'est toujours plus facile si on lit ce que > les autres ecrivent avec un esprit ouvert et de la bonne volonte. comme tu dis... David. pgpEkLYkd649R.pgp Description: PGP signature
Re: Backport XFree 4.3
On Tue, Jun 10, 2003 at 12:51:38PM +0200, David Cure wrote: > Le Tue, Jun 10, 2003 at 10:32:11AM +0200, Sven Luther ecrivait : > > > > On Tue, Jun 10, 2003 at 09:48:28AM +0200, David Cure wrote: > > > [merci de ne pas me mettre en copie, si j'interviens sur la liste c'est > > > que j'y suis inscrit...r] > > re-rr Tu veut une regle procmail pour supprimer les doublons ? > > Non, c'est la que tu te trompe, ce n'est pas le backport de Daniel > > Stone. Daniel Stone ne fournit (ne fournissait) que des packages > > ok, j'ai été un peu cite, je voulais dire que c'était un > backport des packets de DS. Oui, mais a nouveau, si il y a un probleme avec les backports en question, il est relativement facile de faire un nouveau backport, c'est essentiellement une question d'environement de compilation. > > avez commence a parler de copier radeon.o et drm.o, je n'ai pas pus > > m'empecher d'intervenir, car cela, tu avouera que c'est quand meme autre > > chose que de 'juste' mettre a dispo des paquets manquant pour le > > backport X 4.3.0. > > je suis d'ac mais je préfère toujours ma méthode ;) mais ça ca > doit etre parce que je suis de l'ancienne école et car je n'utilise pas > les outils debian pour les kernel (et non, je ne dirais pas ce que j'en > pense ;)) Sur, mais le risqye avec les 'je copie le fichier untel a tel endroit' c'est de faire des melanges incompatibles, au niveau des environement de compilation, du gcc, de la glibc, de la versiond de XFree86, etc. Cela pose plus de probleme que cela n'en resout, surtout si plutard on oublie ce que l'on a fait, et que l'on fait une mise a jour (vers les packages 4.3.0 officiel par exemple). C'est ce genre de problemes qui sont extremement difficile a diagnotsiquer par la suite, et vers qui pense tu que les gens se tourneront pour resoudre les problemes qui resulteront de cette maniere de faire ? > > fichiers dans tout les sens, c'etait que vous etiez sur la mauvaise > > route, > > je ne pense pas non ;) Voir precedement, il ne faut pas penser seulement a la maniere de resoudre la chose a l'instant, mais aussi comme cela s'integre dans le long terme, et les problemes d'upgradabilite et de support technique que cela entraine. Si a la limite tu avait conseille une install nouvelle dans /usr/local ou un tru, je ne dis pas, mais /usr/X11R6 et co sont exclusivement reserve a dpkg, seul /home/ et /usr/local sont utilisable directement. > > d'ou mon intervention, un peu seche peut-etre, mais partant d'une > > bonne intention quand meme. > > toutes les interventions partent d'une bonne intention, reste le ton... Sur, mais a part le ton, il y a aussi l'etat d'esprit du lecteur et de nombreux autres criteres, c'est toujours plus facile si on lit ce que les autres ecrivent avec un esprit ouvert et de la bonne volonte. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Tue, Jun 10, 2003 at 10:32:11AM +0200, Sven Luther ecrivait : > > On Tue, Jun 10, 2003 at 09:48:28AM +0200, David Cure wrote: > > [merci de ne pas me mettre en copie, si j'interviens sur la liste c'est > > que j'y suis inscrit...r] re-rr > Non, c'est la que tu te trompe, ce n'est pas le backport de Daniel > Stone. Daniel Stone ne fournit (ne fournissait) que des packages ok, j'ai été un peu cite, je voulais dire que c'était un backport des packets de DS. > avez commence a parler de copier radeon.o et drm.o, je n'ai pas pus > m'empecher d'intervenir, car cela, tu avouera que c'est quand meme autre > chose que de 'juste' mettre a dispo des paquets manquant pour le > backport X 4.3.0. je suis d'ac mais je préfère toujours ma méthode ;) mais ça ca doit etre parce que je suis de l'ancienne école et car je n'utilise pas les outils debian pour les kernel (et non, je ne dirais pas ce que j'en pense ;)) > fichiers dans tout les sens, c'etait que vous etiez sur la mauvaise > route, je ne pense pas non ;) > d'ou mon intervention, un peu seche peut-etre, mais partant d'une > bonne intention quand meme. toutes les interventions partent d'une bonne intention, reste le ton... David. pgpXHECBPUWVu.pgp Description: PGP signature
Re: Backport XFree 4.3
On Tue, Jun 10, 2003 at 09:48:28AM +0200, David Cure wrote: > [merci de ne pas me mettre en copie, si j'interviens sur la liste c'est > que j'y suis inscrit...r] > > Le Sun, Jun 08, 2003 at 12:35:43PM +0200, Sven Luther ecrivait : > > > > Si c'est un probleme, tu peut aussi compiler les sources upstream > > je ne veux pas compiler les sources upstream non plus... c'est > dingue ça... (et en plus, je rappelle que ce n'est pas moi qui avait des > problèmes...) Oui, oui, je sais bien, je disait juste que c'etait possible, et pas trop complique par dessus le marche (simple meme en fait). > Et répondre à la question "j'ai un problème avec le backport" > par "compiles le toi meme", c'est pas forcément terrible, car justement, > si quelqu'un veut utiliser le backport c'est parce qu'il ne veut pas le > compiler... Oui, sur, mais bon, le backport c'est quelqu'un qui l'a fait quand meme, et s'il est mal fait, il faudrait que quelqu'un en fasse un nouveau bien fait (pas moi, je n'ai jamais utiliser woody, meme avant que woody soit release, j'utilisait deja quelque chose de plus recent, comme il se doit pour un developpeur debian). > > Bien sur, si le backport est mal fait ... > > voila... tu touches le point qui fait mal ce que j'ai juste > dit au départ (relis aussi tiens) c'est que pour utiliser le backport de > Daniel Stone il manque des paquets que j'ai mis à dispo. C'est tout. Non, c'est la que tu te trompe, ce n'est pas le backport de Daniel Stone. Daniel Stone ne fournit (ne fournissait) que des packages unstable, et powerpc par dessus le marche, qui vont bientot devenir des paquets sid officiel, le bientot etant dependant du temps libre de Branden bien sur. Sinon, effectivement j'ai juste survole ce thread, mais lorsque vous avez commence a parler de copier radeon.o et drm.o, je n'ai pas pus m'empecher d'intervenir, car cela, tu avouera que c'est quand meme autre chose que de 'juste' mettre a dispo des paquets manquant pour le backport X 4.3.0. Et il me semblait que si vous commenciez a copier des fichiers dans tout les sens, c'etait que vous etiez sur la mauvaise route, d'ou mon intervention, un peu seche peut-etre, mais partant d'une bonne intention quand meme. Amicalement, Sven Luther
Re: Backport XFree 4.3
[merci de ne pas me mettre en copie, si j'interviens sur la liste c'est que j'y suis inscrit...r] Le Sun, Jun 08, 2003 at 12:35:43PM +0200, Sven Luther ecrivait : > > Si c'est un probleme, tu peut aussi compiler les sources upstream je ne veux pas compiler les sources upstream non plus... c'est dingue ça... (et en plus, je rappelle que ce n'est pas moi qui avait des problèmes...) Et répondre à la question "j'ai un problème avec le backport" par "compiles le toi meme", c'est pas forcément terrible, car justement, si quelqu'un veut utiliser le backport c'est parce qu'il ne veut pas le compiler... > Bien sur, si le backport est mal fait ... voila... tu touches le point qui fait mal ce que j'ai juste dit au départ (relis aussi tiens) c'est que pour utiliser le backport de Daniel Stone il manque des paquets que j'ai mis à dispo. C'est tout. David. pgplHDxXwKvLN.pgp Description: PGP signature
Re: Xinerama et XFree 4.3 [Etait: Backport XFree 4.3]
On Mon, Jun 09, 2003 at 11:35:51AM +0200, Nicolas CANIART wrote: > Sven Luther a écrit : > Bonsoir ! (et presque bonjour !?!) > > Désolé, j'ai mis le temps mais j'été un peu occupé. > Bien Tous ce passe désormais super jusqu'à l' étape 8 (merci tout > particulièrement à Sven). Super, vous dites que je vais vous laisser en > paix ! > Navré mais non. J'ai un souci avec le xinerama. Mmm, ... > Au début XFree à commencé à me dire dans le log que je devais vraiment > être bête pour déclarer de Device pour une seule carte (même bus PCI). > Mais il continuait son bonhomme de chemin est démarré. > Je me suis apperçu que j'avais oublié de déclarer les Screen dans les > section Devices. Je les ajoutent et puis il se contente de faire comme > si de rien! Est-ce que tu a deux tetes ou non ? Envoie moi en privee ton /var/log/XFRee86.0.log et ton /etc/X11/XF86Config complet. > Au début je croyais que c'etait le DRI qui n'allait pas à cause des > messages: > >Skipping > "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_clip.o": > No symbols found >Skipping > "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_norm.o": > No symbols found >Skipping > "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_xform.o": > No symbols found >Skipping > "/usr/X11R6/lib/modules-dri-trunk/fonts/libspeedo.a:spencode.o": No > symbols found > > (ce qui, au passage, semble vouloir dire que les modules trunk sont buggés). Mmm. > Mais comme le log indique : > >(WW) RADEON(0): Direct rendering is not supported when Xinerama is > enabled >(EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Remarqu'il y a des travaux en cours pour ajouter du support DRI meme en multi-head. > Il ne devrait pas y avoir de conflit. J'ai tout de même essayé sans > charger le dri (et puis sans tous ce qui pourrai se rapporter à > l'accéleration matériel) sans plus de résultat. Donc, j'imagine que tu ne voir rien sur la deuxieme sortie. Donne moi (a nouveau) la configuration de tes moniteurs et ta carte, ainsi que les fichiers ci-dessus. > A par cela aucune erreur rapportée, seuls quelques warning concernant > les polices. > > Une idée. (C'est promis après je vous laisse tranquille !) Pour avoir une idee, il faut d'abord que tu donne plus d'info. > Pour info. ma carte est une ATI Radeon 7000 VE (ça date un peu...). Mais devrait etre bien supporte. Amicalement, Sven Luther
Re: Xinerama et XFree 4.3 [Etait: Backport XFree 4.3]
Sven Luther a écrit : Desole d'intervenir comme cela, mais franchement je ne comprend pas pourquoi vous vous donne tout ce mal. On Sat, Jun 07, 2003 at 03:40:52AM +0200, David Cure wrote: Le Fri, Jun 06, 2003 at 11:53:12PM +0200, Nicolas CANIART ecrivait : Mais j'ai fais un symlink sur le packages des headers !!! Pour commencer, on est pas suppose faire de symlink du tout, ce meme hautement non recommande. mince... bon, je viens de vérifier pp=our drm.o. En fait, j'ai compilé le drm dans le noyau et cela marche. Donc, je pense que tu n'as pas besoin de recopier la nouvelle version, mais cela ne peut pas nuire de remplacer la version du noyau par la nouvelle. Je vais essayer en pechant le package noyaux sur kernel.org. bon courage. Ce qu'il faut faire pour avoir un X correcte qui marche. 1) recuperer le serveur 4.3.0 de daniel stone, ou alors un de ces backport woody. Si il y a un probleme avec libfreetype, il est toujours possible de recompiler les serveurs 4.3.0, mais cela demande 4Go d'espace disque. 2) recuperer un noyau, n'importe lequel, de preference un package 2.4.20 debian. 3) le compiler avec make-kpkg --revision 1 --bzimage kernel-image 4) recuperer les modules drm dri-trunk de Michel Daenzer sur : deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ 5) aller dans /usr/src et decompresser le tarball correspondant. 6) retourner dans le repertoire du noyau, et faire un : make-kpkg --revision 1 modules_image (sous root eventuellement). 7) installer les package noyau et module drm 8) rebooter. Et tout devrait etre bon, surtout pour une carte radeon. Amicalement, Sven Luther Bonsoir ! (et presque bonjour !?!) Désolé, j'ai mis le temps mais j'été un peu occupé. Bien Tous ce passe désormais super jusqu'à l' étape 8 (merci tout particulièrement à Sven). Super, vous dites que je vais vous laisser en paix ! Navré mais non. J'ai un souci avec le xinerama. Au début XFree à commencé à me dire dans le log que je devais vraiment être bête pour déclarer de Device pour une seule carte (même bus PCI). Mais il continuait son bonhomme de chemin est démarré. Je me suis apperçu que j'avais oublié de déclarer les Screen dans les section Devices. Je les ajoutent et puis il se contente de faire comme si de rien! Au début je croyais que c'etait le DRI qui n'allait pas à cause des messages: Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_clip.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_norm.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/extensions/libGLcore.a:m_debug_xform.o": No symbols found Skipping "/usr/X11R6/lib/modules-dri-trunk/fonts/libspeedo.a:spencode.o": No symbols found (ce qui, au passage, semble vouloir dire que les modules trunk sont buggés). Mais comme le log indique : (WW) RADEON(0): Direct rendering is not supported when Xinerama is enabled (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Il ne devrait pas y avoir de conflit. J'ai tout de même essayé sans charger le dri (et puis sans tous ce qui pourrai se rapporter à l'accéleration matériel) sans plus de résultat. A par cela aucune erreur rapportée, seuls quelques warning concernant les polices. Une idée. (C'est promis après je vous laisse tranquille !) Pour info. ma carte est une ATI Radeon 7000 VE (ça date un peu...). Nicolas.
Re: Backport XFree 4.3
Bonjour, Merci beaucoup, cela venait en effet d'un mauvais choix du clavier (104 touches au lieu de 105 touches). ++ et merci encore Arnaud Fontaine
Re: Backport XFree 4.3
On Sun, Jun 08, 2003 at 12:23:31PM +0200, David Cure wrote: > Le Sat, Jun 07, 2003 at 04:37:59PM +0200, Sven Luther ecrivait : > > > > Desole d'intervenir comme cela, mais franchement je ne comprend pas > > pourquoi vous vous donne tout ce mal. > > pour avoir quelque chose qui marche ;) Sur. > > toujours possible de recompiler les serveurs 4.3.0, mais cela demande > > 4Go d'espace disque. > > mais bien sur. Si c'est un probleme, tu peut aussi compiler les sources upstream directement, c'est beaucoup plus accessible en espace disque : [EMAIL PROTECTED]:/usr/local/xf/4.3.0$ du -sk xc 617464 xc Et ne devrait pas poser de probleme majeur. La compilation et l'installation est simple (make World puis make install sous root comme explique dans INSTALL-X.org). Je conseille cependant d'appliquer le patch suivant : -- patch - --- xc/config/cf/site.def 2002-02-27 01:51:12.0 +0100 +++ xc.wildcatvp/config/cf/site.def 2003-01-18 14:29:51.0 +0100 @@ -72,15 +72,15 @@ #ifdef AfterVendorCF #ifndef ProjectRoot -#define ProjectRoot /usr/X11R6 +#define ProjectRoot /usr/X11R6-4.3.0 #endif /* * On some platforms, some things may be installed outside of * ProjectRoot * by default. To disable this, uncomment the following line. * -#define NothingOutsideProjectRoot YES */ +#define NothingOutsideProjectRoot YES /* * Set EtcX11Directory if you want config file links installed under -- patch - pour ne pas polluer les base apt/dpkg, meme que pour bien faire, il faudrait mettre ProjectRoot a /usr/local/X11R6. Ensuite, il faut modifier le lien symbolique /etc/X11/X : $ ls -l /etc/X11/X lrwxrwxrwx1 root root 28 2003-03-23 14:01 /etc/X11/X -> /usr/X11R6-4.3.0/bin/XFree86 Et le tour est joue. A oui, eventuellement il faut placer le repertoire /usr/X11R6-4.3.0/lib dans /etc/ld.so.conf et relancer ldconfig pour les librairies, mais c'est pas obligatoirement necessaire. > > Et tout devrait etre bon, surtout pour une carte radeon. > > dans mon cas : recup du drm.tgz et compiles et copie dans les > modules, plus compliqué ? Relie toute la discussion a propos du deplacement des drm.o et radeon.o et repose toi la question. > Le problème vient du backport de xf4.3 qui comprent de > nombreuses dépendances qui n'existent pas en woody et donc il a fallu > backporter des paquets (et pas seulement libfreetype6..) Oui, je sais bien. Cependant, si ce backport a ete bien fait, alors soit il utilise les packages de woody, soit il inclus aussi les packages backporte qu'il faut, et il suffit alors de les installe. Bien sur, si le backport est mal fait ... Amicalement, Sven Luther > > David.
Re: Backport XFree 4.3
Le Sat, Jun 07, 2003 at 04:37:59PM +0200, Sven Luther ecrivait : > > Desole d'intervenir comme cela, mais franchement je ne comprend pas > pourquoi vous vous donne tout ce mal. pour avoir quelque chose qui marche ;) > toujours possible de recompiler les serveurs 4.3.0, mais cela demande > 4Go d'espace disque. mais bien sur. > Et tout devrait etre bon, surtout pour une carte radeon. dans mon cas : recup du drm.tgz et compiles et copie dans les modules, plus compliqué ? Le problème vient du backport de xf4.3 qui comprent de nombreuses dépendances qui n'existent pas en woody et donc il a fallu backporter des paquets (et pas seulement libfreetype6..) David. pgpKPD6kzifnu.pgp Description: PGP signature
Re: Backport XFree 4.3
On Sun, Jun 08, 2003 at 09:40:47AM +0200, Arnaud Fontaine wrote: > Bonjour, > > Je dispose d'une Sarge et j'ai utilisé les backport de XFree-4.3 [1]. Cela > marche plutôt bien, le seul ennui est que je n'arrive à avoir ces caractères > :"<" ">" sans faire de copier-coller, quelqu'un aurait il une idée ? Cela > pourrait provenir des paquets de fonts ? Non, si tu peut les avoirs en copiant/collant, il ne peut evidement pas s'agir des fonts. Verifie plutot la config de ton clavier. En general pour un clavier francais il faut : Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "fr" Option "XkbVariant""" Option "XkbOptions""" Du moins, moi c'est cela que j'utilise. Amicalement, Sven Luther
Re: Backport XFree 4.3
Arnaud Fontaine a écrit le Sunday 08 June 2003 09:40 :: > Bonjour, > > Je dispose d'une Sarge et j'ai utilisé les backport de XFree-4.3 [1]. Cela > marche plutôt bien, le seul ennui est que je n'arrive à avoir ces > caractères > > :"<" ">" sans faire de copier-coller, quelqu'un aurait il une idée ? Cela > J'ai eu le problème dans le passé (avec une SuSE). Mauvais choix de clavier (dans mon cas un 104 touches au lieu d'un 105) HIH, -- \\|// - ? (o o) /=oOOO=(_)=OOOo===\ Alain DIDIERJEAN Ces mystères nous dépassent Feignons d'en être l'organisateur
Re: Backport XFree 4.3
Bonjour, Je dispose d'une Sarge et j'ai utilisé les backport de XFree-4.3 [1]. Cela marche plutôt bien, le seul ennui est que je n'arrive à avoir ces caractères :"<" ">" sans faire de copier-coller, quelqu'un aurait il une idée ? Cela pourrait provenir des paquets de fonts ? ++ et merci d'avance Arnaud Fontaine --- [1] http://people.debian.org/~mmagallo/packages/xfree86/i386/
Re: Backport XFree 4.3
Desole d'intervenir comme cela, mais franchement je ne comprend pas pourquoi vous vous donne tout ce mal. On Sat, Jun 07, 2003 at 03:40:52AM +0200, David Cure wrote: > Le Fri, Jun 06, 2003 at 11:53:12PM +0200, Nicolas CANIART ecrivait : > > > > Mais j'ai fais un symlink sur le packages des headers !!! Pour commencer, on est pas suppose faire de symlink du tout, ce meme hautement non recommande. > mince... > > bon, je viens de vérifier pp=our drm.o. En fait, j'ai compilé > le drm dans le noyau et cela marche. Donc, je pense que tu n'as pas > besoin de recopier la nouvelle version, mais cela ne peut pas nuire de > remplacer la version du noyau par la nouvelle. > > > Je vais essayer en pechant le package noyaux sur kernel.org. > > bon courage. Ce qu'il faut faire pour avoir un X correcte qui marche. 1) recuperer le serveur 4.3.0 de daniel stone, ou alors un de ces backport woody. Si il y a un probleme avec libfreetype, il est toujours possible de recompiler les serveurs 4.3.0, mais cela demande 4Go d'espace disque. 2) recuperer un noyau, n'importe lequel, de preference un package 2.4.20 debian. 3) le compiler avec make-kpkg --revision 1 --bzimage kernel-image 4) recuperer les modules drm dri-trunk de Michel Daenzer sur : deb http://people.debian.org/~daenzer/dri-trunk-sid/ ./ 5) aller dans /usr/src et decompresser le tarball correspondant. 6) retourner dans le repertoire du noyau, et faire un : make-kpkg --revision 1 modules_image (sous root eventuellement). 7) installer les package noyau et module drm 8) rebooter. Et tout devrait etre bon, surtout pour une carte radeon. Amicalement, Sven Luther
Re: Backport XFree 4.3
Le Fri, Jun 06, 2003 at 11:53:12PM +0200, Nicolas CANIART ecrivait : > > Mais j'ai fais un symlink sur le packages des headers !!! mince... bon, je viens de vérifier pp=our drm.o. En fait, j'ai compilé le drm dans le noyau et cela marche. Donc, je pense que tu n'as pas besoin de recopier la nouvelle version, mais cela ne peut pas nuire de remplacer la version du noyau par la nouvelle. > Je vais essayer en pechant le package noyaux sur kernel.org. bon courage. David. pgpLt0mUaqdFw.pgp Description: PGP signature
Re: Backport XFree 4.3
David Cure a écrit : Le Fri, Jun 06, 2003 at 01:23:27PM +0200, Nicolas CANIART ecrivait : Dans ton article tu indiques qu'il faut copier le fichier radeon.o (si j'ai une radeon, ce qui est le cas :-)) ! Qu'en est il du fichier drm.o ? je n'ai pas la machine sous la main... mais il est sur que je ne l'ai pas recopié de la nouvelle version. Peut-etre avais-je laissé le module dans le noyau je verifierais ça. Error: Could not locate kernel tree in /lib/modules/2.4.20-1-k7/build/include /usr/src/linux-2.4.20-1-k7/include /usr/src/linux/include /usr/include [...] Alors que les sources et les headers du kernel sont installés et que le fichier fautif (modversions.h) est bel et bien là? qu'as-tu dans /usr/src ? il me semble que les paquets debian des headers (je n'en ai jamais installé ;)) mettent les header dans linux-version-header... donc un petit lien devrait résoudre le problème. Par ex: ln -s kernel-2.4.20-header linux (dans /usr/src) David. Mais j'ai fais un symlink sur le packages des headers !!! Je vais essayer en pechant le package noyaux sur kernel.org. Nicolas.
Re: Backport XFree 4.3
Le Fri, Jun 06, 2003 at 01:23:27PM +0200, Nicolas CANIART ecrivait : > > Dans ton article tu indiques qu'il faut copier le fichier radeon.o (si > j'ai une radeon, ce qui est le cas :-)) ! > Qu'en est il du fichier drm.o ? je n'ai pas la machine sous la main... mais il est sur que je ne l'ai pas recopié de la nouvelle version. Peut-etre avais-je laissé le module dans le noyau je verifierais ça. > Error: Could not locate kernel tree in > /lib/modules/2.4.20-1-k7/build/include > /usr/src/linux-2.4.20-1-k7/include /usr/src/linux/include /usr/include [...] > Alors que les sources et les headers du kernel sont installés et que le > fichier fautif (modversions.h) est bel et bien là? qu'as-tu dans /usr/src ? il me semble que les paquets debian des headers (je n'en ai jamais installé ;)) mettent les header dans linux-version-header... donc un petit lien devrait résoudre le problème. Par ex: ln -s kernel-2.4.20-header linux (dans /usr/src) David. pgpADwRnSwgHj.pgp Description: PGP signature
Re: Re: Backport XFree 4.3
David Cure a écrit : Le Thu, Jun 05, 2003 at 09:02:30PM +0200, Nicolas CANIART ecrivait : Je voudrais savoir si quelqu'un à déjà installé un backport de XFree4.3 sur une Woody ou une Sarge ? oui sur woody, le backport de daniel stone ( deb http://people.debian.org/~mmagallo/packages/xfree86/i386/ ./) Le soucis viendrai de la libfreetype6. j'avais eu des soucis effectivement pour finir l'install... et j'ai backporté des paquets donc libfreetype6 ;) Si tu veux les essayer (je rajoutes un "pour moi ça marche" et j'ai aussi testé sur le portable d'un copain et ça marche ;)), ajoutes cette ligne dans ton sources.list : deb http://dc.deb.free.fr/debian/woody/binary-i386 ./ Sinon, j'ai commis un "article" pour mon install (XF4.3+Radeon 9000M+woody) : http://www.finix.eu.org/spip/article.php3?id_article=57 David. Dans ton article tu indiques qu'il faut copier le fichier radeon.o (si j'ai une radeon, ce qui est le cas :-)) ! Qu'en est il du fichier drm.o ? De plus qu'en j'essaie de compiler les module j'obtients l'erreur : % make -f Makefile.linux Error: Could not locate kernel tree in /lib/modules/2.4.20-1-k7/build/include /usr/src/linux-2.4.20-1-k7/include /usr/src/linux/include /usr/include Si je fais : % make -f Makefile.linux radeon.o cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -fno-strict-aliasing -DEXPORT_SYMTAB -I0 -c radeon_drv.c -o radeon_drv.o Dans le fichier inclus à partir de drmP.h:43, à partir de radeon_drv.c:32: /usr/include/linux/module.h:21:34: linux/modversions.h : Aucun fichier ou répertoire de ce type make: *** [radeon_drv.o] Erreur 1 Alors que les sources et les headers du kernel sont installés et que le fichier fautif (modversions.h) est bel et bien là? Une idée ? Merci ! Nicolas.
Re: Backport XFree 4.3
Le Thu, Jun 05, 2003 at 09:02:30PM +0200, Nicolas CANIART ecrivait : > > Je voudrais savoir si quelqu'un à déjà installé un backport de > XFree4.3 sur une Woody ou une Sarge ? oui sur woody, le backport de daniel stone ( deb http://people.debian.org/~mmagallo/packages/xfree86/i386/ ./) > Le soucis viendrai de la libfreetype6. j'avais eu des soucis effectivement pour finir l'install... et j'ai backporté des paquets donc libfreetype6 ;) Si tu veux les essayer (je rajoutes un "pour moi ça marche" et j'ai aussi testé sur le portable d'un copain et ça marche ;)), ajoutes cette ligne dans ton sources.list : deb http://dc.deb.free.fr/debian/woody/binary-i386 ./ Sinon, j'ai commis un "article" pour mon install (XF4.3+Radeon 9000M+woody) : http://www.finix.eu.org/spip/article.php3?id_article=57 David. pgpIHysaoxunX.pgp Description: PGP signature
Backport XFree 4.3
Je voudrais savoir si quelqu'un à déjà installé un backport de XFree4.3 sur une Woody ou une Sarge ? Personnellement quand j'essaye, dselect veux que je désinstalle gnome, mozilla, cups ... Bref presque tout ? Le soucis viendrai de la libfreetype6. D'avence merci ! Nicolas
