Forum

Bonjour.
A titre d'information:

Depuis plus d'une semaine, les mises à jour via le ccm ou par la console n'aboutissent pas: une dizaine de paquets ne peuvent être installés, du coup aucune mise à jour est possible.

Voici un exemple de message d'erreur, 10 paquets sont concernés, même type de message d'erreur pour chacun.

L'installation a échoué :
package thunderbird-0:60.6.1-9.mga7.x86_64 does not verify: Payload SHA256 digest: BAD (Expected a3e5a47ac6963398296cff78ef4100b12c217feaf0c2ec0126c7e1dad14db339 != a2a708dfd75cdc68c77e1cd0bb06d93e043699755746906ac849b0a8e8cfe5d2)

J'ai d'abord cru que c'était un problème de serveur,
Changer les sources n'y a rien fait.


Du coup, j'ai essayé avec dnf dragora, toutes les mises à jour (+ de 200) sont passées sans problème...


(pc intel E5700 4Go ram, bureau mate)

Bonjour,

J'ai ce genre de messages lorsqu'il y a un problème lors du téléchargement des paquets.
Lorsque relancer urpmi --auto-update ne récupère pas le fichier entier correctement, généralement je supprime le fichier fautif dans /var/chache/urpmi/rpms/, et ensuite je relance la première commande : il est de nouveau récupéré, et l'installation se fait sans problème.

Bonjour,

Thunderbird n'a pas pu s'installer chez moi il y a 3 ou 4 jours, en raison du manque de "thunderbird.fr". Le lendemain c'était réglé.
A signaler que les autres mises à jour qui accompagnaient thunderbird s'étaient faites normalement.

Je remarquais en même temps, que je n'ai jamais eu de problème de mise à jour sur cette B2/3, et c'est assez remarquable, vu qu'il y en a tous les jours et qu'on est encore en version beta.

Sinon, lorsqu'un paquet bloque une mise à jour (sur Mageia ou autre), je le désinstalle tout simplement avec urpme, et tout s'installe absolument normalement.

"dnfdragora" même pas installé chez moi. Sur une autre distribution qui a supprimé "rpm", et qui oblige donc à l'utiliser, je ne l'apprécie pas du tout, surtout en graphique.

Merci

Édité par Visiteur Le 28/04/2019 à 11h53

Quels sont les soucis que tu rencontres ?
Ce programme reste sujet à améliorations.

je ne sais pas ce que certains reprochent à dnf et à dnfdragora;
mais, ce n'est pas la première fois que je rencontre ce genre de commentaires négatifs;
moi, j'utilise tantôt l'un tantôt l'autre sans avoir remarqué de soucis graves;

petits détails :
- dans la version de fedora, de dnfdragora, il y a une option "historique" pratique pour visualiser aisément les mises à jour et installations et la possibilité de faire un "undo", donc de désinstaller en un clic; sans savoir, j'imagine que c'est sûrement mieux, question gestion des orphelins qu'une désinstallation; dans ce cas, ça défait la transaction, donc ça remplace avantageusement les snapshots en btrfs;
dans mageia6 la version de dnfdragora, il n'y a pas cette fonctionnalité, et sur mageia7 j'ai pas pensé à vérifier;
(actuellement je suis sur mageia6)
- dans fedora, il y a un paramètre de configuration, "installonly_limit" (dans /etc/dnf/dnf.conf) qui limite le nombre de noyaux, ce qui fait qu'à chaque nouveau kernel, ça supprime automatiquement le plus vieux, il n'y a donc jamais à faire le ménage, ça se fait tout seul;
sur mageia6 j'ai essayé de mettre la même chose, c'est sans effet, même en faisant les mises à jour en terminal avec dnf, les noyaux continuent de s'accumuler au fil des mises à jour; et du coup, "osprober" met un certain temps a régénérer le menu de boot à chaque mise à jour;
- il manque aussi sur dnfdragora de mageia la possibilité de configurer les médias de façon durable (si on veut); actuellement, la seule façon de faire c'est de les modifier directement avec un éditeur; ils sont dans /etc/yum.repos.d;

"la seule façon de faire c'est de les modifier directement avec un éditeur; ils sont dans /etc/yum.repos.d" euh surement pas ça c'est le faire à l'arrache (donc a eviter) quand on ne sait pas le faire avec la ligne de commande

Lister tous les repos installés

Activer un repo

Déactiver un repo

Ajouter un dépôt


trifouiller dans les fichiers de configuration c'est la derniere chose à faire vraiment quand tu n'as pas d'autres choix et surtout bien savoir ce qu'on fait
pour plus d'info sur DNF, le gestionnaire de paquets

Édité par Bidulle Le 29/04/2019 à 11h01

si vous tenez tant à vous servir de dnfdragora pensez à installer le paquet dnfdragora-updater

Bonjour,

@ Papoteur,
Non, je ne rencontre plus vraiment de soucis, c'est plus une affaire de détails.
Les lenteurs insupportables de mise à jour de listes, les renseignements absents sur les paquetages, et je ne me souviens plus trop quoi, puisque je ne l'utilise pas depuis pas mal, sont bien réglés à présent, ce qui met ce programme à peu près au niveau de "drakrpm".

Il le met tellement au niveau de drakrpm qu'on peut se demander d'ailleurs, pourquoi il devrait le remplacer... Une affaire de rpm5 et de maintient en Perl, à ce que je pense avoir compris.

Donc, avec ses progrès, je dois dire que dnfdragora n'est plus aussi repoussant qu'avant. Si on le compare à drakrpm, il faut chipoter pour voir des boutons sur l'un, là où l'autre a un menu, et des bricoles du genre.

Ce que je pourrais rajouter c'est que c'est du GTK3 ! Je ne suis pas fanatique de QT, mais j'ai depuis longtemps adopté "qtcurve" comme style des composants graphiques, et là, ben le remplaçant de drakrpm qui était du GTK, est aussi du GTK, ce qui ne laisse de me décevoir, puisque sur du KDE, je suis "condamné" à me passer encore et toujours de l'interface QTCurve.

Après, comme j'aime bien séparer ce qui est utilisateur et ce qui est root => quant drakrpm est dans le ccm et que dnfdragora est indépendant, ça me rappelle les conneries de Rosa de mettre les réglages root dans le systemsettings de KDE ...ou de Mageia, de permettre les mise à jour avec le mot de passe utilisateur par défaut ...ou de Suse avec son mastodonte.
Ma femme tourne aussi avec du Linux, mais je ne lui laisse pas faire les mises à jour, parce que si l'une d'elles foire, elle reste en carafe si je ne suis pas là.

Sinon, j'ai remarqué la chose suivante.
Ce soir, je compare drakrpm et dnfdragora, que je viens d'installer pour ne pas raconter des vieilles impressions d'avec Fedora ou OpenMandriva(Beta). Et, je constate des différences dans les mises à jour à faire.
Pour être clair, les dépôts de ma Mageia7 beta2 se sont automatiquement habilités à l'installation de celle-ci (je n'ai que coché pour les tainted en plus), or, les dépôts sur dnfdragora ne sont pas les mêmes !
Ce qui fait que, j'ai des nouveaux kernels (rc7) signalés sur drakrpm et pas sur dnfdragora !
Au contraire, j'ai GoogleEarth sur dnfdragora, et pas sur drakrpm ...plus deux ou trois différences entre les deux, originées par les dépôts en 32 bits.

Ce que je trouve "bizarre", sans parler des différences de dépôts habilités automatiquement, c'est que, GoogleEarth, je l'avais installé à partir d'une archive que j'avais dans un disque avec une autre distribution, sans passer par les sites Google ou autre. La question est donc : "Comment dnfdragora peut-il habiliter une mise à jour de Googleearth à partir du dépôt GoogleEarth, alors que je n'ai jamais installé ce dépôt ?

Je sais bien que le passage de Cauldron à une quasi release(b3 aujourd'hui), entraîne des changements de dépôts, ce qui peut expliquer pourquoi les kernels n'apparaissent pas dans dnfdragora (installé ce soir), mais pour GoogleEarth, je ne pige pas, et ce n'est pas fait pour me plaire, puisque si on m'installe des dépôts "en douce" je ne peux plus confier en rien.

Encore un détail, la dénomination de ces dépôts n'est pas claire dans dnfdragora.
=> "cederom - core - non-free - tainted" avec chacun "release - update - backport" sur drakrpm ça me parle, mais sur dnf dragora le classement par "backport - cauldron - mageia - update" suivi en accolé du dépôt particulier je ne trouve pas ça net.
Il y manque de plus, la possibilité d'avoir l'adresse du dépôt.

Pour terminer, une remarque sur ce que dit marc-andre :

Et bien je ne suis pas pour cette option.
Pas pour, parce que si une version de kernel nouvelle ne convient pas, ça peut devenir compliqué s'il faut faire marche arrière, parce que je ne sais pas si le "undo" de l'historique peut jouer son rôle après reboot, car c'est après reboot que l'on s'aperçoit que ne nouveau kernel bloque quelque chose.
D'une manière générale j'aime garder le contrôle plutôt que me fier à des trucs automatiques.

Ma conclusion est que dnfdragora est un doublon (et une copie ?) de drakrpm, qui ne m'apporte personnellement absolument rien ! De plus, il me force à apprendre (pour la konsole) de nouvelles commandes que j'oublie très rapidement, puisque je continue à utiliser le ccm pour les mise à jour, car j'aime bien pourvoir sélectionner/déselectionner des paquets parfois (il m'est arrivé de n'installer que des mise à jour système et rebooter, avant de finir le reste).
...Mais c'est la mode de tout changer pour avoir la même chose qu'avant ...ou parfois moins bien. Je vous en reparlerai, ça concerne les systèmes.

Merci

salut
dnf nous rend bavards, je continu donc;

Bidulle
tu as raison, je viens de relire le post de mai 2018, je m'étais affolé pour rien et avais utilisé dnf " à l'arrache" comme tu dis;
sur la mageia6 sur laquelle je suis actuellement, issue d'une migration récente depuis mageia5, il n'y avait pas dnf; donc je l'ai installé tranquillement et ai fait les commandes que tu donnes;
dnf config-manager --set-enabled le nom du repo
Ok ça a marché sans problème
je sais que c'est la bonne pratique que d'utiliser les commandes quand elles existent;
mais je me rappelle, que "en situation", ça m'avait apparu plus facile de modifier directement le fichier que d'utiliser la commande;
notamment, à cause de la confusion que souligne Nulix concernant l'organisation qui est différente d'avec urpmi;
et donc, changer un booléen "enabled" de 0 à 1 m'avait paru une opération beaucoup plus sereine que de batailler avec la syntaxe de cette commande, pour laquelle il n'y a pas de page "man" me semble-t-il, ou alors je l'ai pas trouvé;
en fait pour l'utiliser, il faut d'abord faire
dnf repolist all
et faire un copier collé des id
c'est pas si pratique que ça cette commande ....

bonne nouvelle sur mageia7, il y a l'historique et l'option "defaire" dans dnfdragora;
donc dnf est en progrès sur mageia.

Nulix
pour ce qui concerne la limitation des noyaux et le ménage automatique, libre à toi de mettre la valeur que tu veux;
par défaut sur fedora, c'est à 3, et sur un an et quelques que je l'ai, avec deux montées (27 -> 28 -> 29) c'est sans problème et largement suffisant;
et sur mageia j'ai plus de recul, sur les versions stables, je n'ai jamais eu besoin de revenir en arrière avec les noyaux en 3 ans;
la première fois que ça arrive, c'est actuellement avec la mageia7 béta, mais avec le précédent noyau, ça marche;
par contre sur la mageia sur laquelle je suis actuellement issue de mageia5 depuis 2015, quand j'ai fait la migration, j'avais pas moins d'une quarantaine de noyaux (à l'époque je m'en préoccupais pas), et c'est une corvée de faire le ménage à la main;

Bonjour,
Merci pour ces retours.
dnfdragora utilise la librairie libyui, qui a comme particularité de proposer trois interfaces avec le même code : Qt, Gtk et ncurses. Par défaut, c'est le Qt.
Isodumper utilise aussi cette bibliothèque.

Concernant GoogleEarth, je ne sais pas trop quoi dire. Ça me semble en tout cas étonnant.

Bonjour,

@Papoteur,

Non. Il faut cocher le paquet QT, sinon c'est du GTK ...mais merci du tuyau, je ne l'avais pas vu.

Pour GoogleEarth, je suppose que le programme lui-même envoie les données à son propre serveur qui interagit avec dnf (et pas avec drakrpm).
Pourquoi je dis cela ? => Un soir, alors que je jouais sans réseau, j'observe mon GKRELLM sur le bureau m'indiquant du trafic internet... Tiens ?!
Le "TOP" de ce Gkrellm, affiche un processus "AT" inhabituel.
Un coup de "KSysGuard" et je kill ce processus "at", et la conexion internet s'arrête aussitôt !
C'est quoi ce truc qui trafique dans mon dos(?) ...je décide de le désinstaller ...mais c'est tout GoogleEarth qui doit être viré !
Donc GoogleEarth, à notre insu, envoie ce qu'il veut à son serveur. ...Et dnfdragora doit donc, être lié d'une manière ou d'une autre à l'espionite généralisée Google !

@ marc-andre
Je note ta remarque sur les noyaux.
...Mais j'espère pour toi, que tu connais la commande équivalente en TTY, parce que si au premier reboot, le nouveau kernel te laisse sans graphique du départ, tu vas être mal pour le undo, quel que soit son Nº...

Le problème de "OSprober" (ton message d'hier 11 H) qui liste un tas de kernels dans le grub, je l'ai résolu de la manière suivante :
J'ai modifié le "/boot/grub2/grub.cfg" à la main de la manière suivante :
1- En indiquant la définition réelle de mon écran (=> Ligne 74 avec kwrite/affichage/bordures/Afficher les Nº de lignes);
2- En supprimant tous les submenus - de { en } - et en ne laissant que mes distribs principales;
3- En archivant ce "grub.cfg" plus sa copie "grub-bis.cfg".
Donc, lors d'un changement de noyau ou archive qui modifie le grub2 et re-liste des tas de trucs inutiles, j'ouvre simplement (Kwrite en root) le "grub-bis.cfg" et change simplement le nouveau Nº de kernel, puis le sauvegarde à la fois en "grub-bis.cfg" et en "grub.cfg".
Ainsi je retrouve mon grub du départ de boot, avec ma définition d'écran et mes lignes habituelles.
...Comme en plus j'ai modifié /boot/grub2/themes/maggy/ => pour avoir "mon" fond d'écran, "mes" polices, "mes" couleurs et "ma" mise en page, j'ai toujours, très facilement, mon grub2 personnalisé, identique, et avec mes seules distribs principales.


Merci

Nulix
"Je note ta remarque sur les noyaux.
...Mais j'espère pour toi, que tu connais la commande équivalente en TTY, parce que si au premier reboot, le nouveau kernel te laisse sans graphique du départ, tu vas être mal pour le undo, quel que soit son Nº..."

j'ai du mal à saisir ton problème avec cette fonctionnalité de l'installonly_limit";
as tu déjà concrètement eut plus de trois noyaux consécutifs qui ne bootent pas?
dans ce cas là, éventuellement, il suffirait de changer la valeur du paramètre;

merci pour ta manip du grub mais ça me paraît compliqué de faire ça à chaque fois, surtout qu'à voir ton écran, entre fedora, opensuse tumblewed, rosa et mageia, c'est tous les jours que tu dois la faire ta manip du grub.cfg;
j'ai pas envie de ça!