[Debian] Paquet cassé?

apt complètement bloqué

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour.

J’utilise Debian 9 depuis quelques mois. Il y a quelques jours, j’ai décidé de me renseigner à propos des "153 paquets non mis à jour", car ça commençait à dater. J’ai trouvé la réponse: ces paquets ont introduit une nouvelle dépendance dont je n’ai pas autorisé l’installation et cela peut être résolu avec apt dist-upgrade. Problème: le paquet uim (pour Universal Input Methods) semble brisé dans le sens où il requiert des dépendances ne pouvant pas être installées. Aussi, la mise à jour a échoué, et dès que je demande à apt d’installer / supprimer / mettre à jour un paquet, je reçois le message d’erreur:

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Vous pouvez lancer « apt --fix-broken install » pour corriger ces problèmes.
Les paquets suivants contiennent des dépendances non satisfaites :
 anthy : Dépend: libanthyinput0 mais il n'est pas installé
 libuim-custom2 : Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 libuim-plugins : Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 libuim-scm0 : Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 libuim8 : Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim : Dépend: uim-common (= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim-anthy : Dépend: libuim-data (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
             Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim-fep : Dépend: uim (>= 1:1.8.8-2) mais 1:1.8.6+gh20161003.0.d63dadd-2 est installé
           Dépend: uim-data (>= 1:1.8.8-2) mais il n'est pas installé
 uim-gtk2.0 : Dépend: libuim-data (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
              Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim-gtk3 : Dépend: uim (= 1:1.8.8-2) mais 1:1.8.6+gh20161003.0.d63dadd-2 est installé
            Dépend: uim-gtk3-immodule (= 1:1.8.8-2) mais il n'est pas installé
            Dépend: uim-data (>= 1:1.8.8-2) mais il n'est pas installé
 uim-qt : Dépend: libuim-data (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
          Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim-qt5 : Dépend: uim (= 1:1.8.8-2) mais 1:1.8.6+gh20161003.0.d63dadd-2 est installé
           Dépend: uim-qt5-immodule (= 1:1.8.8-2) mais il n'est pas installé
           Dépend: uim-data (>= 1:1.8.8-2) mais il n'est pas installé
 uim-utils : Dépend: libuim-data (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
             Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
 uim-xim : Dépend: uim-common (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
           Dépend: libuim-data (>= 1:1.8.6+gh20161003.0.d63dadd-2) mais il n'est pas installé
E: Dépendances non satisfaites. Essayez « apt --fix-broken install » sans paquet
   (ou indiquez une solution).

J’ai évidemment tenté la solution indiquée, mais apt --fix-broken install plante à 0%…

Ma question est donc le paquet est-il cassé (ce qui implique que je signale le bug) ou est-ce dû à une erreur de ma part, et dans ce cas, comment réparer mon système?

Merci d’avance.

+0 -0

Tu as le résultat de apt --fix-broken install ?

Ça ressemble à une installation non terminée. Tu dis que apt-get purge anthy uim échoue ? Tu risques de devoir les réinstaller à la main. Et donc de les désintaller avec dpkg puis de les réinstaller avec apt-get

Sinon, perso j’utilise fcitx avec la méthode mozc pour ça. Ça marche plutôt bien ^^

Édité par ache

ache.one                 🦹         👾                                🦊

+1 -0
Auteur du sujet

Tu as le résultat de apt --fix-broken install ?

C’est un plantage de dpkg:

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Correction des dépendances... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  gcj-6-jre-lib libgcj-common libgcj17 libgcj17-awt libmariadbclient18
  libqt4-designer libqt4-network libqt4-qt3support libqt4-script libqt4-sql
  libqt4-sql-mysql mysql-common
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés : 
  libanthyinput0 libuim-custom2 libuim-scm0 libuim8 uim uim-anthy uim-data
  uim-gtk2.0 uim-gtk2.0-immodule uim-gtk3-immodule uim-plugins
  uim-qt5-immodule uim-xim
Les paquets suivants seront ENLEVÉS :
  libanthy0 libuim-plugins uim-qt uim-utils
Les NOUVEAUX paquets suivants seront installés :
  libanthyinput0 uim-data uim-gtk2.0-immodule uim-gtk3-immodule uim-plugins
  uim-qt5-immodule
Les paquets suivants seront mis à jour :
  libuim-custom2 libuim-scm0 libuim8 uim uim-anthy uim-gtk2.0 uim-xim
7 mis à jour, 6 nouvellement installés, 4 à enlever et 149 non mis à jour.
7 partiellement installés ou enlevés.
Il est nécessaire de prendre 0 o/1 642 ko dans les archives.
Après cette opération, 4 270 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
dpkg: tentative de déconfiguration de uim-anthy, qui serait cassé par l'installation de uim-data...
dpkg: oui, déconfiguration de uim-anthy (cassé par uim-data).
(Lecture de la base de données... 287159 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../uim-data_1%3a1.8.8-2_all.deb ...
Déconfiguration de uim-anthy (1:1.8.6+gh20161003.0.d63dadd-2) ...
Error: in load: file "/usr/share/uim/lib/sigscheme-init.scm" not found
dpkg: erreur de traitement de l'archive /var/cache/apt/archives/uim-data_1%3a1.8.8-2_all.deb (--unpack) :
 installed uim-anthy package pre-removal script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/uim-data_1%3a1.8.8-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ça ressemble à une installation non terminée. Tu dis que apt-get purge anthy uim échoue ? Tu risques de devoir les réinstaller à la main. Et donc de les désintaller avec dpkg puis de les réinstaller avec apt-get

Je ne peux pas modifier la liste des paquets installés (mises à jour, installations, désinstallations…). Le message d’erreur est le même que dans mon premier poste.

Sinon, perso j’utilise fcitx avec la méthode mozc pour ça. Ça marche plutôt bien ^^

Perso, je ne savais même pas qu’est ce qui gérait les inputs, je pensais que c’était mon environnement de bureau lui-même. fcitx est pourtant bien installé (j’ai une entrée de manuel, je le trouve dans le menu de cinnamon, etc…).

+0 -0

Salut,

Que te retourne les deux commandes suivantes ?

# aptitude search ~b
# aptitude why-not anthy

Également, utilises-tu des dépôts particuliers que tu aurais ajouté dans ton fichier /etc/apt/sources.list (ou le dossier /etc/apt/sources.list.d) ou bien emploies-tu un fichier /etc/preferences (ou un ou des fichiers dans le dossier /etc/apt/preferences.d) ?

+1 -0
Auteur du sujet

Salut,

Que te retourne les deux commandes suivantes ?

# aptitude search ~b
# aptitude why-not anthy

Si je remplace aptitude par apt, ça donne:

boris@boris~$ apt search ~b
En train de trier... Fait
Recherche en texte intégral... Fait
libghc-monad-control-dev/testing 1.0.2.3-1 amd64
  Monad transformers to lift control operations

libghc-monad-control-doc/testing 1.0.2.3-1 all
  Monad transformers to lift control operations; documentation

libghc-monad-control-prof/testing 1.0.2.3-1 amd64
  Monad transformers to lift control operations; profiling libraries

r-cran-epi/testing 2.30-1+b1 amd64
  analyse épidémiologique GNU R

tthsum/stable,testing 1.3.2-1+b1 amd64
  génère ou vérifie des résumés de message TTH

Et je ne peux pas utiliser apt why-not anthy (ni aptitude d’ailleurs).

Également, utilises-tu des dépôts particuliers que tu aurais ajouté dans ton fichier /etc/apt/sources.list (ou le dossier /etc/apt/sources.list.d) ou bien emploies-tu un fichier /etc/preferences (ou un ou des fichiers dans le dossier /etc/apt/preferences.d) ?

J’utilise la distribution testing depuis que je me suis rendu compte que le C++17 était mal supporté par g++ "stable", et j’ai ajouté les dépôts non-free de Debian. Sinon, rien de particulier.

#/etc/apt/sources.list
deb http://security.debian.org/debian-security stretch/updates main contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

#/etc/apt/sources.list.d/base.list
deb http://deb.debian.org/debian/ stretch main
deb http://ftp.us.debian.org/debian testing main contrib non-free
+0 -0

Cette réponse a aidé l’auteur du sujet

J’utilise la distribution testing depuis que je me suis rendu compte que le C++17 était mal supporté par g++ "stable", et j’ai ajouté les dépôts non-free de Debian. Sinon, rien de particulier.

BorisD

Mmm… Alors il y a fort à parier que le souci vient de là. Si la version testing de Debian est relativement stable, ce n’est pas spécialement une bonne idée de la suivre, encore plus si tu mélanges des paquets de la version stable et de la version testing (ce qui semble être le cas au vu du retour de la commande apt search ~b).

Si tu as vraiment besoin de paquets de la version testing, mieux vaut employer un fichier /etc/apt/preferences qui t’assure que sauf si tu le demandes expressement, aucun paquets de cette version ne sera installé.

Ce que je te conseille pour retrouver un système en bon état, c’est de rétrograder tous les paquets installés vers la version stable, puis de mettre à jour ceux qui te sont nécessaires vers la version de testing.

Pour remettre tout à la version stable, tu peux créer un fichier /etc/apt/preferences avec le contenu suivant.

Package: *
Pin: release a=stable
Pin-Priority: 1001

Ensuite, exécute apt-get update et apt-get upgrade. Vérifie bien à ce moment qu’il est programmé de rétrograder des paquets. Une fois cela fait, tu peux modifier ton fichier /etc/apt/preferences comme suit.

Package: *
Pin: release a=stable
Pin-Priority: 999

Package: *
Pin: release a=testing
Pin-Priority: 1

Ensuite, exécute apt-get update et apt-get install g++/testing

+1 -0
Auteur du sujet

J’ai retiré les lignes indiquant la distribution testing de mes fichiers de configuration, mais je ne peux toujours pas mettre mes paquets à jour. En faisant des recherches, j’ai trouvé une commande décrite comme sale mais efficace:

dpkg --remove --force-remove-reinstreq uim

Dans mon cas, pensez-vous qu’il vaille mieux l’utiliser?

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut :)

apt ~b te permet de savoir quels sont les paquets cassés. @Taurre note à raison que c’est probablement le mélange stable/testing qui en est la cause, tu as fabriqué une frankendebian.

Cela risque de ne pas casser qu’un seul paquet, mais le système entier (la commande du dessus montre qu’il y en a déjà plusieurs).

L’utilisation de dpkg te réglera peut-être un problème lorsque tu n’en as qu’un seul, mais, là, ce n’est pas le cas.

La moins pire des solutions me semble être celle proposée par Taurre (fichier préférence avec stable en priorité 1001), mais je pense qu’il faut utiliser apt dist-upgrade, puisque il y a des chances qu’il y ait des paquets à supprimer.

Le downgrade general n’étant pas une opération prévue et réfléchie par Debian, ça à des chance de finir de tout casser. De ce fait, sauvegarde tes données personnelles avant de tenter quoique ce soit, parce-que les chances que le système soit à réinstaller totalement est non négligeable.

+2 -0
Auteur du sujet

Salut :)

apt ~b te permet de savoir quels sont les paquets cassés. @Taurre note à raison que c’est probablement le mélange stable/testing qui en est la cause, tu as fabriqué une frankendebian.

Ah oui, je comprends mieux. Le problème est que comme je le disais plus tôt, je ne peux pas modifier la liste des paquets installés, donc je ne peux pas non-plus rétrograder! :(

Cela risque de ne pas casser qu’un seul paquet, mais le système entier (la commande du dessus montre qu’il y en a déjà plusieurs).

L’utilisation de dpkg te réglera peut-être un problème lorsque tu n’en as qu’un seul, mais, là, ce n’est pas le cas.

La moins pire des solutions me semble être celle proposée par Taurre (fichier préférence avec stable en priorité 1001), mais je pense qu’il faut utiliser apt dist-upgrade, puisque il y a des chances qu’il y ait des paquets à supprimer.

Le downgrade general n’étant pas une opération prévue et réfléchie par Debian, ça à des chance de finir de tout casser. De ce fait, sauvegarde tes données personnelles avant de tenter quoique ce soit, parce-que les chances que le système soit à réinstaller totalement est non négligeable.

Bon, je crois que je n’ai que deux choix:

  • me tuer à la tache pour restaurer un système endommagé
  • en réinstaller un nouveau avec uniquement les paquets nécessaires (ce qui me permettra au passage de me débarrasser de certains paquets installés dont je ne connais plus le nom, des fichiers de configuration que je n’ai pas supprimés avec apt --purge remove <packageName>, etc…)

La question se pose-t-elle?

Édité par BorisD

+1 -0

Cette réponse a aidé l’auteur du sujet

Si apt ne veux plus rien savoir, c’est effectivement cuit :(

Je ne suis pas un pro, mais, si tu veux utiliser Debian Stable, tout en compilant avec Debian Testing, voire Sid, tu peux peut-être regarder du coté de chroot, voire d’un conteneur LXC ?

En tant qu’amateur, je n’ai pas trop d’idée sur ce que ça impact dans le workflow d’un développeur, mais je suis certain que certains ici pourront te dire si c’est pertinent ou pas :)

+1 -0
Auteur du sujet

Je viens de finir l’installation et la restauration des données (pratiques ces ~/.<appname> qui permettent la restauration immédiate des paramètres :) ).

Je ne suis pas un pro, mais, si tu veux utiliser Debian Stable, tout en compilant avec Debian Testing, voire Sid, tu peux peut-être regarder du coté de chroot, voire d’un conteneur LXC ?

Je viens de jeter un coup d’oeil au man de chroot et à la page wikipédia LXC. Ça peut être sympa, mais je pense que c’est un peu excessif de cloisonner un second système dans le mien (juste pour un logiciel). Je vais plutôt utiliser la solution proposée par @Taurre mais ça pourrait être intéressant le jour où j’aurais besoin de plus de logiciels à jour, donc je garde cette solution dans un coin de ma tête.

En tant qu’amateur, je n’ai pas trop d’idée sur ce que ça impact dans le workflow d’un développeur, mais je suis certain que certains ici pourront te dire si c’est pertinent ou pas :)

Je suis moi aussi un amateur voire un débutant, et ça me paraît pertinent pour un usage non-professionnel (où peut-être même professionnel).

@Taurre j’ai suivi ta méthode mais je reçois le message d’erreur:

E: La version « testing » de « g++ » est introuvable

Qu’est-ce que je peux faire?

+0 -0

@Taurre j’ai suivi ta méthode mais je reçois le message d’erreur:

E: La version « testing » de « g++ » est introuvable

Qu’est-ce que je peux faire?

BorisD

Ça reste une méthode à créer des Frankendebian à mon avis. Pour ma part, je commencerais par faire une simulation avec l’option -s. Normalement, la syntaxe donnée par Taurre évite de mettre à jour les dépendances qui ne doivent pas forcement l’être, mais ça peu toucher à des clés de voutes du système. Par ailleurs, ça peut fonctionner aujourd’hui et casser la semaine prochaine à l’occasion d’une modification de Testing.

Avant de se lancer la dedans, il est préférable de bien maîtriser les outils apt, genre, apt policy qui te renseignerait sur la source de ton message d’erreur.

+1 -0
Auteur du sujet

Je comprends. Après avoir posté ce message, j’ai lu un peu plus en détail le lien sur les Frankendebian et j’ai finalement remarqué que les mainteneurs de Debian recommandent la virtualisation. C’est donc sûrement la meilleure option.

Merci de votre aide à tous :) .

+0 -0

@Taurre j’ai suivi ta méthode mais je reçois le message d’erreur:

E: La version « testing » de « g++ » est introuvable

Qu’est-ce que je peux faire?

BorisD

Mmm… Peut-être que c’est le nom qui doit être utilisé, dans ce cas ci stretch et non testing ? Sinon, peut être ai-je suggéré des préférences trop strictes ? A priori, tu peux en fait te contenter d’un fichier /etc/apt/preferences rédigé comme suit afin d’éviter l’installation non souhaitée de paquet testing.

Package: *
Pin: release a=testing
Pin-Priority: 100

Édit : sinon, comme l’a dit @bendia, suivant les dépendances de g++, il est possible que la stabilité de ta Debian soit impactée. Dans le cas de g++, j’ai un doute vu qu’il dépend de gcc qui lui-même dépend de libc6-dev et ça, ça risque de lançer pas mal de mise à jour… À voir, donc.

Édité par Taurre

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte