ok merci
Impossible. Mauvais retour de commande. Ce n’est pas ‹ ± › , mais ‹ +- › , d’où l’importance de rapporter proprement les commandes, soit entre balises code si court, ou fichier texte joint si hyper long. Rien de grave. On continue:
cmd4.txt (3,5 Ko)
Oui, non, ou peut-être, that is the question.
Chaque jour est un jour nouveau puisqu’après la découverte de paquets gelés, dont du qt4, je découvre des paquets i386 dont tu n’as semble-t-il jamais précisé l’existence non plus.
Répondre à ta question sans savoir si tu as besoin d’i386 est impossible.
Ton rythme de réponse étant particulièrement lent, je vais changer un peu de méthode.
Pour ce soir, si ton emploi du temps le permet bien sûr, peux-tu:
1 - fournir une justification claire et précise du besoin d’architecture i386 dans ton système, qui n’y est pas arrivé par hasard;
2 - me fournir 4 fichiers retour1-2-3-4.txt issus des commandes suivantes.
apt -o "Apt::Cmd::Disable-Script-Warning=1" list -u |
awk -F'/| |]' 'NR>1{printf "%-35s %-30s %-30s %s\n",$1,$3,$(NF-1),$2}' > retour1.txt
dpkg -l |awk '(NR>5 && /^ii/){printf "%-3s %-35s %s\n",$1,$2,$3}' > retour2.txt
dpkg -l |awk '(NR>5 && !/^ii|^un/){printf "%-3s %-35s %s\n",$1,$2,$3}' > retour3.txt
{ uname -rv ; awk 'FNR==1 {print "\n"FILENAME} /^d|^U/' /etc/apt/s*{t,d/*[st]} ; } > retour4.txt
Désolé de te mettre autant à contribution.
On m’avait demandé plus haut de les installer:
retour4.txt (840 Octets)
retour3.txt (2,4 Ko)
retour2.txt (88,3 Ko)
retour1.txt (94,4 Ko)
Merci surtout à toi de prendre autant de temps et de ta patience
oui c’est moi
suivre les propositions de debian pour résoudre un pb est souvent la meilleure chose à faire. Comme tu as des paquets i386, avoir l’architecture associée est a priori logique.
Vus tes problèmes, si @verner te propose de l’enlever, n’hésites pas
Si ta seule justification est 'on m’avait demandé", désinstalle moi ces paquets i386 si tu n’en as pas besoin.
On va quand-même pas encore compliquer/embrouiller un sujet inutilement pour une testing.
Et refais ces 4 fichiers retours après nettoyage i386.
Désolé journée chargée le vendredi.
root@eix:/home/francois# dpkg --remove-architecture i386
dpkg: erreur: impossible de supprimer l’architecture « i386 » actuellement utilisée dans la base de données
Bon, je vais la remettre sur pied ta testing, mais pas sans quelques remarques générales.
Quand on a une testing en agonie qui visiblement n’a jamais été entretenue comme un testing, on ne commence pas par rajouter une autre architecture avant la moindre analyse système et aucune justification: non mais sans blague.
On commence par supprimer ce qui est inutile, alléger le système, et non pas rajouter tout et n’importe quoi trouvé dans une doc de migration buster, par exemple…
Le sources.list: un détail mais franchement… remplacer des ‹ ftp.fr.debian › par des ‹ deb.debian › mais ça sert à quoi dans ce sujet ?? A rien ! ‹ ftp.fr.debian › était parfait comme déjà expliqué en long et en large.
Quelle perte de temps.
Quand on ne sait pas, on ne fait pas n’importe quoi dans une testing, sinon ça se termine par un ‹ takarinstaller ›.
Bref, ceci étant dit, je te propose le menu ci-joint.
Les commandes qui passent, ou qui te demandent de rajouter des dépendances, tu fais.
Si une pose problème ou montre un conflit, tu me rapportes ça.
actions.txt (2,3 Ko)
root@eix:/home/francois# awk -F’/| |]’ ‹ NR>1{printf « %-35s %-30s %-30s %s\n »,$1,$3,$(NF-1),$2} › > retour_0517.txt
Il ne se passe rien et le fichier retour_0517.txt est vide ( 0 octets )
Normal… il manque un bout de commande dans mon fichier (édité)
retour pas indispensable (puisque tout va bien).
Que dit ceci :
apt list -u | head
Sinon, tout s’est bien passé ?
root@eix:/home/francois# apt list -u | head
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
En train de lister…
7zip/testing 23.01+dfsg-12 amd64 [pouvant être mis à jour depuis : 23.01+dfsg-8]
accountsservice/testing 23.13.9-6.1 amd64 [pouvant être mis à jour depuis : 23.13.9-6]
acl/testing 2.3.2-2 amd64 [pouvant être mis à jour depuis : 2.3.2-1]
adwaita-icon-theme/testing 46.0-1 all [pouvant être mis à jour depuis : 45.0-2]
aisleriot/testing 1:3.22.32-1 amd64 [pouvant être mis à jour depuis : 1:3.22.23-1]
alsa-ucm-conf/testing 1.2.11-1.1 all [pouvant être mis à jour depuis : 1.2.10-1]
alsa-utils/testing 1.2.11-1 amd64 [pouvant être mis à jour depuis : 1.2.10-1.1]
amule-utils/testing 1:2.3.3-3+b5 amd64 [pouvant être mis à jour depuis : 1:2.3.3-3+b1]
amule/testing 1:2.3.3-3+b5 amd64 [pouvant être mis à jour depuis : 1:2.3.3-3+b1]
Si tu tentes ceci,
apt upgrade
ça coince ou pas ?
Ça me va : GO.
Je réponds oui à « continue » ?
oui… qui sait… ça peut marcher, dès fois.
à priori tout est OK.
Je te suis vivement reconnaissant pour ton aide et ta patience, même si je suis loin d’avoir compris.
Juste une question: tu as dit: « Quand on a une testing en agonie qui visiblement n’a jamais été entretenue comme un testing ». Si je fais des aptitude safe-upgrade, j’ai bon?
‹ aptitude *upgrade › est plus chatouilleux sur du testing/sid vraiment cassé mais maintenant, tu peux tenter pour voir: il doit être bien calmé, je lui ai mis la dose qu’il faut.
Finalement rien de grave, juste quelques petits détails…
Sinon pas compris pourquoi qt4-dev-tools , libqt4-dev libqtgui4 sont gelés et à quoi ils servent. Si pas besoin, dégèle les et supprime les.