Page 1 sur 2

[COMPIZ] Probleme à l'installation avec mesa (résolu)

Publié : lun. 10 mars 2008, 15:53
par JackDaniels93
Bonjour à tous

Déjà, je tiens à préciser que je débarque fraichement sous Arch. Je viens de Mandriva et Ubuntu.

Je voudrais installer compiz, mais j'ai un message d'erreur à l'installation d'une des dépendances :

Code : Tout sélectionner

error : could not prepare transaction
error: failed to commit transaction (conflicting files)
mesa: /usr/include/GL/gl.h exists un filesystem
mesa: /usr/include/GL/glext.h exists un filesystem
mesa: /usr/include/GL/glx.h exists un filesystem
mesa: /usr/include/GL/glxext.h exists un filesystem
Je ne sais plus quoi faire... :cry:
Please, help me !

Publié : lun. 10 mars 2008, 16:47
par tuxce
salut, regarde à quel paquet appartiennent ces fichiers:

Code : Tout sélectionner

pacman -Qo /usr/include/GL/gl.h
(je crois que c'est à nvidia)

Publié : lun. 10 mars 2008, 16:50
par JackDaniels93

Code : Tout sélectionner

erreur: aucun paquet ne contient /usr/include/GL/gl.h
:cry:

Au fait, pour info, je suis sous gnome, et j'ai installé les drivers propriétaires Nvidia depuis www.nvidia.com

Je viens d'éditer ce fameux fichier, et c'est bien un fichier de nvidia

Publié : lun. 10 mars 2008, 17:00
par tuxce
pourquoi tu n'as pas tout simplement installé le paquet "nvidia"!
mais bon tu peux les écraser sans problème, "pacman -Sf"

Publié : lun. 10 mars 2008, 17:09
par JackDaniels93
En fait j'ai pris les drivers nvidia depuis le site, car sous mandriva c'est la meilleure chose à faire ! lol

Je vais tenter d'installer les drivers comme tu me le conseille dans ce cas. Je te tiens au courant.

Publié : lun. 10 mars 2008, 17:29
par tuxce
meme sous mandriva, tu peux utiliser le paquet nvidia ou dkms-nvidia des dépots non libres (plf-non-free), mais bon la n'est pas la question :)

l'avantage d'installer depuis les paquets est de pouvoir suivre les évolutions et en théorie, l'interaction avec les autres paquets est testée :)

Publié : lun. 10 mars 2008, 17:48
par JackDaniels93
tuxce a écrit :meme sous mandriva, tu peux utiliser le paquet nvidia ou dkms-nvidia des dépots non libres (plf-non-free), mais bon la n'est pas la question :)
Il y a un bug en ce moment sous mandriva qui empeche d'installer correctement les drivers des dépots. Concretement, ce bug créé un conflit de version entre les drivers et le noyau. Ce bug ne touche pas les utilisateurs de cartes nvidia pas trop récentes, mais j'ai une 8800GT...

Publié : lun. 10 mars 2008, 17:55
par wain
salut JackDaniels93 :)
oublies tout ce que tu as appris sous mandriva et comme le dit tuxce, sous archlinux on installe jamais rien sans passer par un paquetage :o

Publié : lun. 10 mars 2008, 17:59
par FredBezies
Si tu le dis, Wain, si tu le dis ;)

/me est toujours autant un fan des compilations nocturnes "maisons" des versions de développements de Firefox, Thunderbird et SeaMonkey ;)

:enfuit:

Publié : lun. 10 mars 2008, 18:11
par JackDaniels93
Je vous remercie de vous pencher sur mon problème. Je vous tiens au courant mon avancé ;)

Publié : lun. 10 mars 2008, 18:51
par wain
FredBezies a écrit :Si tu le dis, Wain, si tu le dis ;)
/me est toujours autant un fan des compilations nocturnes "maisons" des versions de développements de Firefox, Thunderbird et SeaMonkey ;)
Je suis moi-même un adepte de la compilation, mais quand on a la chance d'avoir un système de compilation très propre et simple à utiliser (ABS) je ne vois pas pourquoi on s'en priverait. Comme peut-on savoir où sont dispersés les fichiers installés par un "make install sauvage" ? Comment être sûr qu'on ne va pas oublier ces fichiers et qu'ils ne poseront pas de problème par la suite (conflit avec d'autres paquetages, désinstallation approximative) ?

Franchement, il n'y a aucun arguement valable pour faire une compilation en dehors du système de paquetages sous archlinux.

Publié : lun. 10 mars 2008, 18:58
par tuxce
wain a écrit : Franchement, il n'y a aucun arguement valable pour faire une compilation en dehors du système de paquetages sous archlinux.
j'en vois quand meme un :P
si on veut tester (ou utiliser) un soft dont la provenance peut etre douteuse ou alors qui n'utilise pas les memes librairies (ou versions) que celle installés, on peut le compiler et l'installer en simple utilisateur en définnissant les bonnes variables d'environnement.

Publié : lun. 10 mars 2008, 19:27
par wain
tuxce a écrit :
wain a écrit : Franchement, il n'y a aucun arguement valable pour faire une compilation en dehors du système de paquetages sous archlinux.
j'en vois quand meme un :P
si on veut tester (ou utiliser) un soft dont la provenance peut etre douteuse ou alors qui n'utilise pas les memes librairies (ou versions) que celle installés, on peut le compiler et l'installer en simple utilisateur en définnissant les bonnes variables d'environnement.
L'argument serait valable pour moi si:
1. c'était un truc un minimum courant
2. on ne pouvait pas le faire avec makepkg

Mais bon, je te laisse le dernier mot, je cherche pas à troller :-D
Tout le monde aura compris combien il est préférable de passer par un pkgbuild.

Publié : lun. 10 mars 2008, 19:43
par marc[i1]
wain a écrit :Tout le monde aura compris combien il est préférable de passer par un pkgbuild.
:daccord:

Publié : lun. 10 mars 2008, 20:01
par tuxce
:chinois:

Publié : mar. 11 mars 2008, 08:19
par FredBezies
wain a écrit :
FredBezies a écrit :Si tu le dis, Wain, si tu le dis ;)
/me est toujours autant un fan des compilations nocturnes "maisons" des versions de développements de Firefox, Thunderbird et SeaMonkey ;)
Je suis moi-même un adepte de la compilation, mais quand on a la chance d'avoir un système de compilation très propre et simple à utiliser (ABS) je ne vois pas pourquoi on s'en priverait.
Je suis d'accord, mais le fichier mozconfig du paquet instable firefox3 est une horreur : options obsolètes,-with assez inutile, etc...
Comme peut-on savoir où sont dispersés les fichiers installés par un "make install sauvage" ? Comment être sûr qu'on ne va pas oublier ces fichiers et qu'ils ne poseront pas de problème par la suite (conflit avec d'autres paquetages, désinstallation approximative) ?
Dans le cas précis de mozilla, il n'y a pas de make install, mais un make -C browser/installer (pour firefox) permets d'avoir un paquet tout-en-un en tar.bz2, facile à copier et qui ne se disperse pas aux quatre vents.
Franchement, il n'y a aucun arguement valable pour faire une compilation en dehors du système de paquetages sous archlinux.
J'en vois une : avoir un logiciel comme Mozilla Firefox en version de développement sur une architecture non officiellement supporté par les binaires de la fondation mozilla.

C'est surement l'exception qui confirme la règle ;)

Publié : mar. 11 mars 2008, 09:43
par marc[i1]
FredBezies a écrit :C'est surement l'exception qui confirme la règle ;)
Nop !
Je vois pas ce qui t'empeche de faire un PKGBUILD !
On se sert des PKGBUILD pour compiler des Noyaux issu de Git ... :wink:

et hop !
http://aur.archlinux.org/packages.php?ID=15172
:D

Publié : mar. 11 mars 2008, 10:34
par JackDaniels93
Eh bien, j'ai lancé à un mon insu un joli petit débat !

Mais dites-moi, et je m'excuse d'avance si je passe pour un abruti, mais c'est quoi un pkbuild ?? :oops:

Publié : mar. 11 mars 2008, 11:11
par tuxce
c'est le fichier de description de la construction d'un package sous arch linux:
http://wiki.archlinux.fr/arch:pkgbuild

Publié : mar. 11 mars 2008, 12:16
par FredBezies
marc[i1] a écrit :
FredBezies a écrit :C'est surement l'exception qui confirme la règle ;)
Nop !
Je vois pas ce qui t'empeche de faire un PKGBUILD !
On se sert des PKGBUILD pour compiler des Noyaux issu de Git ... :wink:

et hop !
http://aur.archlinux.org/packages.php?ID=15172
:D
Surtout que c'est une HÉRÉSIE technique d'employer system-cairo.

Cf le mozconfig d'archlinux pour le paquet "officiel" de Firefox 3 :

http://cvs.archlinux.org/cgi-bin/viewcv ... cvs-markup

"# TODO we cannot use the system cairo until we go to a version >= 1.5.2
#ac_add_options --enable-system-cairo"

Et on pourrait virer la quais-totalité des --with utilisés...

Simple expérience datant de 8 années d'utilisation de version de développement faite maison, aussi bien sous Windows, que linux que MacOS-X.