J’ai simplifié le sources.list. C’est bon comme ça?
deb http://ftp.fr.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://ftp.fr.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb https://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb https://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
les tiennes sont bien aussi
oui mais ça mouline toujours… 
le apt-get --only-upgrade dist-upgrade n’a pas marché donc
ce que tu peux faire :
tu prends ta liste de paquets et tu essaie de les mettre à jour un par un:
cat /tmp/aptget |while read fich;do sudo apt-get -y install "$fich";donetu peux regarder cette page avec des conseils : Chapitre 4. Mises à niveau depuis Debian 11 (Bullseye)
en particulier :
Il est parfois nécessaire d’activer l’option d’APT APT::Force-LoopBreak pour pouvoir temporairement retirer un paquet essentiel à cause de boucles « Conflicts/Pre-Depends ». apt vous alertera à ce propos et interrompra la mise à niveau. Vous pouvez contourner ce problème en passant l’option -o APT::Force-LoopBreak=1 sur la ligne de commande d’ apt .
Il est possible que la structure de dépendances d’un système soit tellement défectueuse qu’elle requière une intervention manuelle. Habituellement, cela signifie qu’il faut utiliser apt ou :
dpkg --remove nom_du_paquet
pour éliminer certains des paquets en cause, ou :
apt -f install
dpkg --configure --pending
Dans certains cas extrêmes, vous pourriez devoir forcer une réinstallation à l’aide d’une commande comme :
dpkg --install /chemin/vers/nom_du_paquet.deb
est aussi utile :
script -t 2>~/upgrade-bookwormétape.time -a ~/upgrade-bookwormétape.script
rejouer la session entière :
scriptreplay ~/upgrade-bookwormétape.time ~/upgrade-bookwormétape.script
dpkg --purge --force-all sane-utils
apt-get --purge remove sane-utils
apt-get -s upgrade
apt-cache policy sane-utils
apt-get -s autoremove --purge
dpkg --configure -a
dpkg -r sane-utils
dpkg -P sane-utils
dpkg -r sane-utils --ignore-depends
Ce n’est pas une bonne idée de geler des paquets quand on utilise une Debian Sid, car des paquets gelés, c’est champion pour bloquer les mises à jour de Sid : apt-listbugs / Wiki / Debian-facile
Quels sont ces paquets gelés ?
apt-mark showhold
Oui c’est actuellement ‹ normal ›, à condition d’utiliser la même ‹ norme › et de bien préciser relativement à quoi. Le cycle d’une testing n’est pas celui d’une stable. Et avec en plus des paquets ‹ on hold ›, il est ‹ normal › qu’aptitude tourne en rond à chercher une solution qui n’existe peut-être pas sans intervention ‹ manuelle ›.
Comme il y a déjà beaucoup de monde depuis 4 jours et que c’est parti dans tous les sens, je ne vais pas perturber les échanges, mais si ça coince, j’interviendrais si nécessaire, ne voyant rien d’insurmontable. Juste un peu de méthodologie devrait suffire, ce sujet m’en rappelant un autre:
→ testing-bloquee-depuis-quelques-semaines
Un logiciel de recuperation de dessin DXF et les librairies QT4, pour des problemes de compatibilité avec des applications
root@eix:/home/francois# apt-mark showhold
libqt4-dev
libqt5core5a
libqtgui4
librecad
librecad-data
qt4-dev-tools
Aie, tu comprends que tu vas devoir choisir :
Soit garder les paquets gelés et ne pas réussir à mettre à jour.
Soit débloquer ces paquets et mettre à jour.
Ils sont gelés depuis que je suis sous Trixie, j’ai jamais eu de problème de mise à jour
Même si du qt4 dans une testing, c’est quand-même faire du grand-écart, je n’ai pas la perception que les paquets gelés soit « le » problème, en supposant qu’il existe un réel problème. Pour vérifier s’il existe réellemement un problème ou non, je propose quelques commandes pour me fairer un avis.
Peux-tu exécuter la liste de commandes ci-jointe, successivement, dans l’ordre, une commande étant une ligne complète qui ne doit pas être coupée.
cmds.txt (20,7 Ko)
Je donnerai mon verdict ensuite.
Voici le résultat de apt install:
suite:
root@eix:/home/francois# apt install -f
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :Non, il n’y avait pas une ligne ‹ apt install ›, mais deux.
« apt install 7zip » était la deuxième.
J’avais bien précisé que la chronologie est importante.
Je veux bien être patient, mais ça ne me semble pas insurmontable de juste donner proprement le retour de commandes.
Si tu n’as pas confiance, tu peux rajouter ‹ -s › (= simulation) pour voir ce que ça dit.
Peux-tu éditer tes messages pour supprimer des longs retours difficilement exploitables et incomplets, et joindre un fichier texte avec exactement le retour des commandes, ce qui m’évite d’avoir à perdre du temps et essayer de recopier tous ces blocs pour analyse.
Ou plutôt, on va faire plus simple.
Peux-tu juste donner le retour complet, sans aucune modification de ceci dans un fichier texte:
cmd1.txt (2,8 Ko)
Rien à signaler. Toujours pas de problème en vue. On continue:
cmd2.txt (9,1 Ko)
ps: tu peux nettoyer des gros blocs codes précédents qui me sont inutiles, ou les transformer en fichier si tu veux les garder, pour éviter du scrolling inutile.
On fait une pause. Problème de libs avec ‹ + ›.
Je suis ça ce soir plus tard.
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)