Bonjour à tous !
J'ai un soucis lors de la mise à jour de Steam, qui me demande d'installer les paquets libgl1-mesa-dri:i386 et libgl1-mesa-glx:i386, que je ne peux installer.
Voila le résultat quand j'essaye d'installer tout ça:
user@debian:~$ sudo apt install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
libgl1-mesa-dri:i386 : Dépend: libdrm-amdgpu1:i386 (>= 2.4.63) mais ne sera pas installé
Dépend: libdrm-intel1:i386 (>= 2.4.48) mais ne sera pas installé
Dépend: libdrm-nouveau2:i386 (>= 2.4.66) mais ne sera pas installé
Dépend: libdrm-radeon1:i386 (>= 2.4.31) mais ne sera pas installé
Dépend: libdrm2:i386 (>= 2.4.66) mais ne sera pas installé
Dépend: libelf1:i386 (>= 0.142) mais ne sera pas installé
Dépend: libllvm3.9:i386 (>= 1:3.9.1-6~) mais ne sera pas installé
libgl1-mesa-glx:i386 : Dépend: libdrm2:i386 (>= 2.4.66) mais ne sera pas installé
Dépend: libglapi-mesa:i386 (= 13.0.6-1+b2) mais ne sera pas installé
Dépend: libx11-xcb1:i386 mais ne sera pas installé
Dépend: libxcb-dri2-0:i386 (>= 1.8) mais ne sera pas installé
Dépend: libxcb-dri3-0:i386 mais ne sera pas installé
Dépend: libxcb-glx0:i386 (>= 1.8) mais ne sera pas installé
Dépend: libxcb-present0:i386 mais ne sera pas installé
Dépend: libxcb-sync1:i386 mais ne sera pas installé
Dépend: libxshmfence1:i386 mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».
Quand j'essaye avec aptitude, il veut m'enlever quelques 600 paquets donc pas possible (si vous voulez la liste n’hésitez pas, je ne l'ai juste pas mise la car trop long).
Je sais que ce sujet à déjà été traité de nombreuses fois mais aucunes des solutions proposées n'a résolu mon soucis…
Voila quelques infos utiles:
Je suis sous Debian 9 (Stretch) avec KDE.
Contenu de /proc/version :
Linux version 4.16.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)
Mon système est à jour (update, upgrade, dist-upgrade, autoremove, clean et autoclean).
Contenu de /etc/apt/sources.list:
deb http://deb.debian.org/debian/ stretch main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
Contenu de /etc/apt/sources.list.d/:
playonlinux.list skype-stable.list steam.list teamviewer.list.save vivaldi.list.save playonlinux.list.save skype-stable.list.save teamviewer.list vivaldi.list
J'ai déjà essayé de désinstaller (purge) et de réinstaller, via les sources et le deb, rien n'a fonctionné.
Merci d'avance.
# sources.list.d
Posté par Exosta . Évalué à 1.
Sans trop y croire : peut-être au niveau de ton fichier de sources steam.list ? Steam est déjà dans les dépôts officiels, j'essayerais en le supprimant.
Il n'est fait mention d'aucun conflit pour justifier le fait que les dépendances ne seront pas installées ?
[^] # Re: sources.list.d
Posté par lxtrem . Évalué à 1.
Ici le steam.list est la car j'avais tenté l'install depuis le .deb, mais depuis les depots (en supprimant le steam.list) et c'est pareil, sauf que le soucis survient direct à l'installation, et plus au lancement.
Pour ce qui est des conflits, j'ai essayé d'approfondir le truc, et a chaque fois je tombe sur des conflits, et quand j'essaye avec aptitude, il me propose de dégager plus de 600 paquets donc je suppose que c'est en conflit avec une lib essentielle.
# tu as fait des modifications à la main ?
Posté par NeoX . Évalué à 3.
le message semble dire que tu as bloqués les mises à jour de certains paquets
du coup le gestionnaire de paquet ne veut plus les mettre à jour de maniere automatique
il faut donc debloquer ces paquets, au risque de casser autre chose.
[^] # Re: tu as fait des modifications à la main ?
Posté par lxtrem . Évalué à 1.
Euh, je ne me souviens pas d'avoir réglé cette option pour certains paquets et pour avoir regardé plus précisément quelles libs posent problème, elles bloquent un peu toutes, donc c'est étrange.
Et ce message apparaît a chaque conflit et jamais je n'ai eu de soucis qui venait de là, donc c'est vrai que je ne me suis pas penché la dessus, mais je suis preneur d'une idée pour fouiller cette piste !
[^] # Re: tu as fait des modifications à la main ?
Posté par Anonyme . Évalué à 1.
Voici un petit lien vers une doc Debian que gardais en marque-page avec un paragraphe qui indique comment vérifier si tu as des paquets gelés.
Par contre ça n'indique que le dégel au cas par cas, pas de commande pour débloquer tous les paquets.
Par curiosité, ton système est une installation de Stretch ou une dist-upgrade depuis Jessie ?
[^] # Re: tu as fait des modifications à la main ?
Posté par lxtrem . Évalué à 1.
Visiblement, aucun paquet n'est gelé, on peut donc exclure cette hypothèse.
Sinon c'est une installation de Stretch de base.
# est-tu bien en multiarch ?
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
A priori steam n'est dispo que pour les archi i386, est-ce que tu as bien activé le multiarch sur ta machine ?
Essaye:
$ sudo dpkg --add-architecture i386
$ sudo apt install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386
[^] # Re: est-tu bien en multiarch ?
Posté par lxtrem . Évalué à 1.
J'avais déjà essayé, ça ne change rien…
# sans titre
Posté par Anonyme . Évalué à 1.
Est-ce que tu utilises le pilote Nvidia pour ta carte graphique ? si c'est le cas, aucune raison d'installer les paquets mesa.
Ensuite, c'est étrange d'avoir un "vieux" noyau 4.16 et un sources.list qui n'indique pas le dépot backport.
Enfin, tu indiques que tu as testé des solutions mais lesquelles ?
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Mince, je viens de me rendre compte que j'ai oublié de préciser ça dans mon post, voila mon matos :
C'est un laptop Lenovo, avec un processeur Intel core I5, un SSD 120 GO et un HDD de 1TO, et 4GO de ram.
Je n'ai pas de carte graphique donc j'utilise (normalement) les drivers pour l'IGP de mon proco.
Ah ? Je devrais donc ajouter les dépôts backport à mon sources.list ?
Je pourrais pas toutes les lister, mais pas mal de celles sur lequel on tombe en cherchant sur internet des problèmes qui ressemblent aux miens, comme le
sudo dpkg --add-architecture i386, la création de certains liens symboliques (ou je n'avais pas les fichier à lier), ou l'installation de certains paquets (impossible à installer ou non trouvés en général).[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Edit: Après ajout des dépôts backports et mise à jour, j'ai retenté une installation de steam via les dépôts officiels, et voila le résultat.
J'ai par la suite pu installer le paquet libudev1:i386 avec
sudo apt-get -t stretch-backports install libudev1:i386mais pas libgl1-mesa-dri:i386 ni libgl1-mesa-glx:i386, toujours a cause des soucis de dépendances, respectivementPour libgl1-mesa-glx:i386 et
Pour libgl1-mesa-dri:i386.
Ça avance, c'est déjà ça !
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
Si c'est une installation Debian Stretch standard, tu ne devrais pas avoir un noyau 4.16 mais le 4.9 donc je présume qu'à un moment tu as utilisé les backports pour l'obtenir. J'imagine que tu as eu une bonne raison de ne pas rester avec le noyau 4.9 mais dans ce cas il vaut mieux réactiver ce dépot pour mettre à jour ta version de noyau parce que la 4.16 n'est plus prise en charge même dans backports.
Ça indique que ça n'est pas en rapport avec backports vu que ces paquets sont présents dans les dépots stables.
Il y a bien un truc avec ton installation et comme l'a dit NeoX ça a certainement rapport avec des paquets marqués onhold.
[^] # Re: sans titre
Posté par NeoX . Évalué à 3.
ou comme tu le suggerais, il a installé des paquets backports (noyau 4.16 par exemple), et fait un upgrade, puis supprimé le depot.
il a alors des lib plus recentes que necessaires et les dependances sont alors cassées
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
Effectivement il est peut-être en mesa 18 dans ses paquets AMD64 mais le apt-get -t stretch-backports sur le paquet libgl1-mesa-glx:i386 auraient dû résoudre la situation si ce n'était qu'une question de dépot manquant. Il y a quelque chose dans les dépendances de libgl1-mesa-dri:i386 qui bloque, ÀMHA vu les erreurs de sortie il y a blocage avec libdrm2 et zlib1g (et ce dernier n'est même pas un paquet backports).
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
C'est possible que j'ai un jour utilisé les dépôts backports, mais je ne me souviens pas avoir volontairement changé la version de mon noyau…
Après j'ai installé cette distrib en Avril 2018, et je débutais sur linux et encore plus sur Debian, donc j'ai pu faire un truc sans m'en rendre compte, même si ça m’étonnerais.
Dans ce cas, aptitude ne me proposerait-il pas de retrograder les paquets en question ? Car là il ne le fait pas.
Au passage, j'avais déjà eu un problème de ce type avec Wine et j'avais fini par abandonner, mais comme steam comprend maintenant Proton, basé sur Wine, il pourrait y avoir un rapport ?
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1. Dernière modification le 23 octobre 2018 à 19:25.
J'utilise aptitude en interface ncurses depuis des années et son système de résolution de conflits est parfois tordu, surtout quand ça implique backports. Il m'arrive régulièrement de devoir fouiller dans l'arbre de dépendance et d'installer manuellement un ou deux paquets pour arriver à mes fins parce qu'aucune des solutions trouvées par aptitude ne le fait.
En ligne de commande c'est encore pire vu que bien souvent aptitude ne propose que sa première suggestion qui, quand ça bloque, se résume à ne pas installer les nouveaux paquets ou à remplacer la moitié de ceux installés.
Pour ton problème, tente de voir si tu arrives à quelque chose avec le TUI d'aptitude en simulant les installations manuelles des paquets que j'ai cité à la fin de mon message précédent. Cherche jusqu'à ce qu'il n'y ait plus de message d'erreur. Tu peux revenir en arrière dans le menu Action (Ctrl+t) > Annuler les actions en attente (raccourci en touche l)
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Désolé, j'ai vraiment du mal avec le TUI de aptitude, je préfère amplement la version en ligne de commande !
J'ai bien essayé de bidouiller quelques trucs, mais à chaque fois je retombe sur un conflit d'une lib qui ne peut être en 32 bits et en 64 bits à la fois…
Je dois avouer que je sèche complètement là !
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
Oui la TUI est spéciale mais pratique pour avoir une vue d'ensemble et le détail de chaque versions de paquets disponibles via les dépots.
Sinon avec l'option -t de apt-get, est-ce qu'installer la version de steam présente dans stable pose problème ? même question pour la version backports.
Quelles lib ? version stable ou backports ?
Le conflit entre les lib 32 et 64 peut arriver parce que aptitude cherche à installer la version stable de la 32 bits alors que tu as la version backports de la 64 ou vice versa.
Après ça peut arriver d'avoir des paquets mal fichus vu que backports est un court-circuit de testing/sid. Je me souviens d'avoir laché l'affaire sur le paquet backports de VLC.
On va regarder avec une dépendance qui ne dépend pas de backports :
Donne moi la sortie de la commande sudo apt-get install zlib1g:i386
puis si ça veut pas s'installer, même chose avec libc6:i386
puis libgcc1:i386
puis ces deux dernières dans la même commande
De ce que je vois il y a une boucle de dépendance entre ces deux libs, ça pourrait éventuellement mettre le souk dans la résolution de apt et aptitude. Vu que ce sont des libs indispensables à beaucoup de programmes ça pourrait tout résoudre d'un coup.
Si elles ne veulent pas s'installer, il va falloir forcer leur installation.
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Rien avec apt-get -t stretch-backports…
Pour le conflit, j'ai essayé de remonter aux sources, en essayant d'installer la première lib qui casse au fur et à mesure : libgl1-mesa-dri:i386 puis libdrm-amdgpu1:i386 puis libdrm2:i386 et c'est la que ça coince.
Les versions 32 et 64 bits ne peuvent pas coexister, et je doute que ça soit la seule lib qui pose problème ainsi.
Les trois libs en questions étaient déjà installées, donc pas d'erreurs à ce niveau la.
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
OK, du coup le truc qui bloque c'est que en 64bits tes libs mesa, drm et wayland sont toujours en version stable, il faut les upgrader en backports pour que ça passe.
Je viens de tester chez moi et ce n'est pas trivial, aptitude a bien du mal parce que effectivement c'est pas la seule lib à casser, mais à force d'insister manuellement ça fonctionne.
Paquets à mettre à jour :
libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server0
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Bonjour et désolé du délai.
Malgré un
Rien n'a été mis à jour et Steam bloque toujours…
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
c'est apt-get , pas apt ;)
Pas de problème pour le délai, par contre ici tu ne me donnes pas plus d'infos pour continuer à t'aider donc tout ce que je peux dire c'est qu'il faut que tu persistes à chercher pourquoi libdrm2 64bits en version backports ne veut pas s'installer sur ta Debian.
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Même avec apt-get, il me dit que les paquets sont à jour.
libdrm2 64bits était bien installée, c'était la version 32 bits qui coincait, mais pour une raison inconnue, après une mise à jour, un simple
sudo apt install -t stretch-backports libdrm2:i386a eu raison de lui.Malgré ca, le paquet Steam bloque toujours au même endroit, et si je remonte aux paquets sources qui posent problème, il y en a beaucoup.
Voici un schéma de la situation:
J'ai pas tout essayé en 64 bits mais a chaque essai, la lib était bien installée en 64 bits.
Le soucis vient peut être d'un problème plus global du support multi-arch sur mon ordi !
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
"Après une mise à jour" ça veut dire quoi ? apt-get upgrade ou update ? Et ça a mis à jour quels paquets ?
En version backports ? et quelle version de Steam : stable, backports ou celle du dépot tiers de Valve ? parce que le schéma que tu montres c'est typiquement ce qu'il se passe avec une dépendance backports qui veut pas se mettre à jour.
Un paquet comme libdrm-amdgpu1:i386 ne dépend que de libdrm2:i386 donc maintenant tu devrais pouvoir l'installer en backports si tu as bien le paquet amdgpu1 64bits qui est installé en backports.
Le support du multi-arch n'a pas de soucis particuliers, c'est plutôt backports qui pose généralement des problèmes de résolution de conflits même sans multi-arch (et pour preuve : rien qu'installer les paquets backports 64bits rend fou le gestionnaire de paquets).
Continue de creuser les dépendances et conflits, je suis certain que tu retomberas à peu près sur la liste que j'avais eu avec aptitude (et franchement c'est bien plus simple à gérer avec le TUI ou un bon GUI). Après je n'ai pas KDE donc ça pourrait aussi ajouter des conflits supplémentaires.
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Oui, après un update & upgrade.
Je ne me souviens plus des paquets mis à jour mais après ca, l'installation de libdrm2:i386 via backports ca bien fonctionné.
J'ai compris comment fonctionnait le TUI de aptitude, ce qui simplifie grandement les choses !
Voici un screenshot pour libgl1-mesa-dri:i386:
Certaines libs sont disponibles en backports et d'autres non, ca pourrait venir d'ici ?
C'est assez similaire pour libgl1-mesa-glx:i386, sauf que une des lib est dispo en backports et pas en stable.
Je précise que ces images sont prises sur la version backports de ces paquets.
J'ai beau tenter et chercher partout, backports ou pas, à chaque fois un conflit 32/64 bits…
[^] # Re: sans titre
Posté par Anonyme . Évalué à 1.
En partie oui. backports a une priorité basse par rapport aux dépôts stable donc la résolution ne fonctionne pas bien quand il y a plusieurs paquets backports à installer ou mettre à jour automatiquement. Avec un paquet simple en dépendance, le gestionnaire de paquets trouve facilement et propose l'installation des nouveaux paquets backports. Ici tu as plusieurs paquets avec de multiples dépendances profondes à résoudre, c'est trop compliqué pour le gestionnaire.
Remarque bien que là sur tes screenshots ce ne sont pas les dépendances elles-mêmes qui bloquent (si tu regardes le numéro de version des dépendances disponibles, il est bien supérieur ou égal à celui exigé par le paquet) mais ce sont des paquets encore en-dessous. En descendant plus profond tu vas trouver les coupables.
Oui tu arrives à des paquets avec des conflits non pas dans la partie Dépend mais dans la partie Casse, probablement en 64bits et restés en stable. C'est une partie de la difficulté de l'opération qui contribue à mettre en défaut la résolution automatique. Les lib graphiques en multiarch doivent être de même version. C'est pour ça que j'insiste sur les paquets 64bits. :)
Tente de simuler l'installation d'un de ces paquets avec aptitude, regarde à chaque manipulation ce qu'il propose comme solutions de résolution (parfois il faut faire suivant jusque sa quatrième ou cinquième solution pour avoir quelque chose qui convient), regarde ce qu'il indique comme conflits et creuse jusqu'à ce qu'un paquet propose la bonne solution de résolution. C'est comme ça que j'ai fait pour libdrm2:i386
Il y a de fortes chances qu'il faille faire ça à plusieurs endroits mais tu vas aussi avoir des sous-dépendances communes qui débloquent plusieurs paquets supérieurs. Et comme tu l'as supposé, ça va fortement aider à résoudre ton problème similaire avec Wine.
C'est un travail de détective. Avec l'habitude de l'outil, tu finiras par régler ce genre de problème en quelques minutes. Surtout qu'après avoir résolu des grosses lib graphiques, toi et le gestionnaire auront beaucoup moins de conflits à résoudre, jusqu'à la prochaine dist-upgrade.
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Super, je vais continuer de chercher avec aptitude, je vous tiens au courant !
[^] # Re: sans titre
Posté par syntaxerror . Évalué à 1.
aptitude donne les explications pour les conflits sur chaque paquet dans le panneau du bas: "e" pour examine, et se balader dans la liste des paquets. "." (point) permet d'explorer les différentes hypothèses de résolution.
N'aurais tu pas utilisé le pinning (voir /etc/apt/preferences.d/*)?
On peut ajouter la provenance d'un paquet dans l'affichage de aptitude (stable, oldstable, etc…) via
options -> préférences, dans "Format d'affichage pour la vue des paquets".
Par exemple "%c%a%M%S %p %Z %v %V %t %i %m"
[^] # Re: sans titre
Posté par lxtrem . Évalué à 1.
Je n'ai pas utilisé le pinning non, le dossier preferences.d n'existe même pas.
Sinon je n'ai pas trouvé grand chose d’intéressant via le TUI d'aptitude.
# Attention à la target-release
Posté par Jean-Denis Vauguet (site web personnel) . Évalué à 1.
J'avais un problème similaire sous Stretch, et j'ai bien galéré. Puis ce post m'a aidé à réaliser un truc et à résoudre mon problème, donc si jamais ça peut aider quelqu'un…
Dans mon cas, c'était tout bête : j'avais oublié que j'avais installé, il y a de ça plusieurs mois, le nvidia-driver depuis Sid (testing). Pour résoudre le problème, il m'a suffit de faire de même pour steam, avec
sudo apt install -t testing steam.Ma config pour la target-release testing :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.