Forum

Reprise du message précédent

Je confirme.

Pour Vi, il faut suivre un tutoriel pour apprendre les commandes, c'est un vrai éditeur de texte puissant, deux touches permettent de supprimer une ligne, une touche permet de sauter en début de document, ou à la fin... Mais aucune des touches n'est affichée, il faut les connaitre par cœur. Cependant, vi est le logiciel d'édition de texte installé par défaut dans toutes les distributions Linux.

Nano, permet de faire bien moins de choses ! Mais il fait très bien ce qui est demandé, modifier les fichiers textes. Son avantage, il garde un bandeau en bas d'écran récapitulant les maigres commandes existantes (mais 90% du nécessaire), sauvegarder, quitter, ... Forcément, nano n'est pas installé par défaut. Si nécessaire, il faut l'installer, par exemple " urpmi nano " (qui nécessite d'être exécuté en tant que root).

Jybz

bonjour !
Cool, je me servirai du forum pour creuser tout ça.
Et pour revenir à ma mise à jour, de retour à mon ordi qui s'est arrêté sur un écran avec 10 lignes de :
libQt5Core.so.5(Qt_5.12) est nécessaire pour libqtsingleapplication-qt5_1-2.6.1-19.mga7.i586

Et mon root en dernière ligne.
je dois faire quelque chose j'imagine mais quoi ?
merci pour vos conseils avisés

Ouhlala...
Pourquoi tu as du i586 et du x86_64 en même temps ?
On va compter combien de paquet i586 (les paquets compilé pour un jeu d'instruction 32b) avec la commande suivante :

(rpm le gestionnaire de paquet, -q query pour demander, -a pour avoir tous les paquets, grep pour n'afficher que les lignes contenant le mot suivant 'i586' puis wc pour compter (word count) les ligne avec -l)

Bonjour,

Ici il semble qu' urpmi ne trouve pas une dépendance.

Le relancement de la commande échoue de la même manière ( des fois qu' il y ait eu une interruption lors du téléchargement) ?

Effectivement comme le souligne Jybz, on ne devrait pas avoir de paquets 586 si la machine était installée en 64bits.

Si des paquets 586 et x86_64 se sont installés en même temps, ce n' est pas bon, encore plus sur ce type de paquets(paquets entrants en conflits et s' excluant mutuellement). Si le nombre de paquets 586 est important, il faudra probablement faire du ménage...

@Jybz : un rpm -qa liste l' architecture du paquet (je ne peux pas vérifier pour le moment) ?
Si la mise à jour a été lancée par mgaapplet, il n' y a aucune raison qu' elle désactive automatiquement les dépots 32 bits non ?

Édité par nic80 Le 10/02/2020 à 19h23

J'ai tout tapé sur la même ligne avec les barres verticales
rpm -qa | grep i586 | wc -l

Réponse 0

Bonsoir,
Non, rpm -qa ne fournit pas l'architecture. Bien vu nic80.
Un moyen de contourner :


Pour aller plus loin, tu peux déjà désintaller le paquet qui pose problème :

// - > Pourquoi tu as du i586 et du x86_64 en même temps ?
cela peut-il avoir un rapport avec le passage de mageia 6 à 7 ?
car il me semble que cette mise à jour correspondait à ce passage mais je n'en suis pas sûre.... je ne faisais pas attention j'avais juste à cliquer.

Du coup si 0 signifie qu'il n'y a pas d'i586, c'est bon signe ?!
Je retape urpmi --auto-update ?

rpm -qa --last| grep i586 | wc -l
203

Réponse à la désinstallation
urpme libqtsingleapplication-qt5_1 :
Pour satisfaire les dépendances, les 2 paquetages suivants vont être désinstallés (3.9Mo):
libqtsingleapplication-qt5_1-2.6.1-16.mga6.i586
libqupzilla2-2.2.5-1.mga6.i586
(en raison du manque de libQt5Solutions_SingleApplication-2.6.so.1)
Supprimer 2 paquetages ? (o/N)

Ah tout de même ! 203 mauvais paquets...

Comment vérifie-t-on l'arch du BIOS et s'assurer qu'aucun paquet 32b ne soit nécessaire ?
Apascale, utilises tu le logiciel Steam (pour jouer) ? (car ce logiciel nécessite un paquet 32b il me semble, c'est une raison d'activer les paquets 32bits).

Avant toute progression, il faut sauvegarder cette liste de paquet !
rpm -qa --last | grep 586 >~/liste_paquet_32b.txt

Remarque : ton système est installé en 64 bits, comme le montrent les extensions x86_64 des noms des paquets.
Il est aussi possible d'avoir des paquets en 32 bits, comme le montrent les extension i586, cependant ceci n'est ni requis ni souhaitable pour les logiciels fournis par Mageia. On rencontre ces cas uniquement pour des programmes fournis par des tiers sous forme compilée et sans le choix de l'architecture. Typiquement c'est le cas pour :
des applications Google, comme Google Earth
Skype
Wine
...
Les dépôts 32bits ont pu être désactivés et ce serait pour cela que la mise à niveau de paquets 32 bits pose problème.

Bonsoir,

Je n'utilise pas Steam pour jouer. J'avais Skype mais je ne m'en sers pas ou plus.

J'ai désinstallé en répondant Oui

La commande rpm -qa --last | grep 586 >~/liste_paquet_32b.txt
me redirige vers grep help
Mon sigle ~ sur l'ordi n'est pas au milieu mais en haut de la ligne, ça ne fait rien ?

Bref je viens de refaire urpmi --auto-update et j'ai à l'écran sur plusieurs lignes
libQt5Core.so.5(Qt_5.12) est nécessaire pour plein de libqt5........mga7.i586
Dernière ligne mon root

Bonjour,

@Jybz :



Par la présence du flag "lm" dans le resultat d' un cat /proc/cpuinfo ? ( par exemple en faisant un "cat /proc/cpuinfo | grep --color \ lm" ; oui je sais c' est moche, mais je ne maitrise ni sed ni awk ! )

Si quelque chose apparait en rouge dans le résultat de la commande, alors le processeur supporte le "long mode" donc le 64 bits apparemment.

Juste une question idiote...

Comment fait on pour savoir si le paquet 586 est bien à Mageia 7 avec la commande "rpm -qa --last | grep 586" ? Par exemple, j' ai fait un
"rpm -qa --last | grep x86_64 | grep mga6 | wc -l" sur une Mageia 7 qui m' a retourné le chiffre 34 !

@Papoteur :



Oui mais sur les bibliothèques Qt, j' ai comme un doute !

@Apascale: que donne un "cat /etc/release" et un "cat /etc/product.id" , si la version installée est une version 64 bits, il doit faire être mention d' un "Mageia release 7 (Official) for x86_64" pour le premier et un "vendor=Mageia.Org,distribution=Mageia,type=Basic,version=7,branch=Official,release=7,arch=x86_64,product=Default" pour le second (présence de x86_64).

Le tilde est bien au milieu chez moi ( sous konsole), mais il est effectivement en haut quand je fais la commande depuis un terminal obtenu par ctrl+alt+f2 .

En revanche il ne devrait pas y avoir de message d' erreur sur la commande...

A tout hasard que donne la commande "rpm -qai | grep -C6 lib64qt5core | grep Archi" ?

Édité par nic80 Le 10/02/2020 à 22h38

J'ai fait les deux "cat" et j'ai bien les deux réponses prévues

La réponse de la dernière commande "...grep Archi" :
Archi est en rouge dans la réponse (=les 3 premières lettres de la réponse)
Architecture: x86_64

Bonjour,

J' ai fait la même erreur que Jybz !

Pour la dernière commande, on sait que le paquet est en architecture 64 bits mais on ne sait pas si c' est pour Mageia 7 ou Mageia 6 !

En fait la commande "rpm -qai | grep -C6 lib64qt5core" devrait retourner la ligne "Release:2.mga7" ( ou du moins quelque chose en .mga7 à la fin).

Pour savoir combien de paquet Mageia 7 ont été installé en version 586, je pense que ce serait plutôt
"rpm -qa --last | grep x86_64 | grep mga7 | wc -l"

Ici les paquets libqt5........mga7.i586, cherchent une version 586 du paquet lib64qt5core, qu'ils ne peuvent pas trouver puisque potentiellement c' est la version 64 bits qui est installé.

Les dépots 64 bits ne se seraient pas désactivé quand même !

Pour savoir les dépots utilisé, il faudrait faire la commande suivante:

"urpmq --list-media active --list-url"

Cela devrait retourner une liste de ce type( la mention x86_64 est ce qui est recherché pour confirmer un dépot 64 bits):

Core Release http://magie.remi.lu/distrib/7/x86_64/media/core/release
Core Updates http://magie.remi.lu/distrib/7/x86_64/media/core/updates