Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Comme je l'avais précisé, le téléchargement s'est fait depuis le site de Displaycal et ouvert avec Discover. Le logiciel est installé dans var/lib/flatpak. Je n'ai eu a m'occuper de rien.
Bah voilà, tu as installé un flatpak, la seule solution pour DisplayCAL que j'envisageais plus haut dans le fil de discussion.
Un flatpak s'installe dans un coin avec toutes ses dépendances, indépendamment du système hôte pour reprendre les termes du Wiki openSUSE. Tu peux chercher DisplayCAL dans Yast Software, tu ne le trouveras pas.
Discover a installé le flatpak, pas le rpm. Pourquoi? je ne sais pas et tu as peut-être négligé une notification ou un avertissement, sinon il faut absolument se méfier de Discover et de toute façon son utilisation n'est pas du tout recommandable sur Tumbleweed.
Si Discover avait installé le rpm, DisplayCAL serait dans Yast Software (j'ai installé le rpm du pilote propriétaire de mon imprimante Canon et ce pilote est bien dans Yast Software).
Je crois que Flatpak est pré-configuré dans Discover sur Tumbleweed et je crois me souvenir que ça m'avait surpris.
Et pourtant , on peut l'installer, en témoigne cette capture :
Je te crois, la question n'est pas là, mais comment as-tu pu l'installer quand les dépendances, tout au moins la majorité, sont absentes des dépôts officiels?
Tu peux par exemple chercher python-psutil sur ces dépôts, moi je ne l'ai pas trouvé :
Donc voilà, il n'est dans l'absolu pas impossible d'installer ce rpm, mais pour moi ce n'est pas possible sans que la conformité de la distribution n'ait été bousculée accidentellement ou qu'elle le soit volontairement pour parvenir au résultat escompté (et ça je ne m'y risque pas).
Je veux dire que le dépôt du média d'installation me semble inutile, pas le média lui même. S'il est possible de réparer avec, très bien, je n'ai encore jamais pratiqué, mais dans un premier temps, au besoin, j'essaierais d'utiliser un instantané (ça j'ai déjà fait, et ça a bien fonctionné).
A moins que quelqu'un en ait déjà eu l'idée, il est possible de télécharger displaycal 3.9.3 pour Tumbleweed sur le site displaycal.net et en l'installant par l'intermédiaire de Discover. J'ai essayé sur une Vm, ça fonctionne.
J'ai téléchargé et j'ai testé.
Ouverture du rpm avec Yast Software :
Je veux en savoir plus et je simule l'installation avec la commande rpm :
thierry@thinkpad-tw:~/Téléchargements> sudo rpm -ivh --test DisplayCAL-3.8.9.3-1.45.x86_64.rpm attention : DisplayCAL-3.8.9.3-1.45.x86_64.rpm: Entête V3 RSA/SHA256 Signature, clé ID e5567198: NOKEY erreur : Dépendances requises: libSDL2_mixer-2_0-0 est nécessaire pour DisplayCAL-3.8.9.3-1.45.x86_64 python-gobject est nécessaire pour DisplayCAL-3.8.9.3-1.45.x86_64 python-numpy >= 1.0 est nécessaire pour DisplayCAL-3.8.9.3-1.45.x86_64 python-psutil est nécessaire pour DisplayCAL-3.8.9.3-1.45.x86_64 python-wxWidgets >= 2.8.11 est nécessaire pour DisplayCAL-3.8.9.3-1.45.x86_64
Il manque du monde à l'appel et je vérifie dans l'ordre l'existence ou non de ces dépendances :
1 ok, présent mais non installé 2 nous avons python-gobject2 et pas python-gobject 3 python-numpy est absent des dépôts 4 python-psutil est absent des dépôts 5 python-wxWidgets est absent des dépôts
Donc l'installation du rpm Dispcal ne fonctionne pas chez moi et à priori je pense que c'est normal (mais au moins nous en savons un peu plus).
P7zip aurait pu être supprimé d'office et remplacé par 7zip sans que vous vous en aperceviez. De mon côté je persiste à passer par Yast et je me serais aperçu de la moindre suppression. Un solution : si vous avez le dvd d'installation vous pouvez faire une mise à niveau et en profiter pour remplacer 7zip par p7zip. Ensuite avec Yast, vous le cochez comme "protégé-ne pas modifier" et ce jusqu'à ce qu'il y ait une version fonctionnelle de 7zip.
Oui p7zip a été supprimé d'office et je m'en suis bien rendu compte justement Je regrette seulement que son remplaçant, 7zip, ne soit pas encore bien intégré à KDE (ça viendra je pense). Sinon 7zip fonctionne très bien en ligne de commande (et si on tient à procéder via une interface graphique, il y a Peazip). Je ne vais donc pas remplacer 7zip ou le faire cohabiter avec un p7zip considéré comme obsolète.
Oui je fais mes mises à jour avec zypper et personnellement je supprime les médias d'installation dans les dépôts (clé usb ou dvd, ils ne servent plus à rien après l'installation).
Faire une mise à niveau à partir du dvd ou de la clé d'installation renfermant une image très ancienne de TW, je le sens moyen quand même.
Comment se fait-il qu'il soit présent sur ma distribution alors même que j'ai procédé à la dernière mise à jour disponible ? P.S : on trouve toujours P7zip dans les dépôts communautaires : https://software.opensuse.org/package/p7zip même pour Tumbleweed.
D'où ma question sur les infos de ton paquet p7zip pour savoir quel dépôt le fournit.
Oui p7zip se trouve dans les dépôts communautaires et expérimentaux mais cela ne m'intéresse pas car 7zip peut faire le même travail en étant plus récent. Il manque juste d'être pris en compte par Ark pour qu'il soit bien intégré dans KDE (et ce n'est pas encore le cas dans le dernier snapshot de Tumbleweed : 20220210).
Il ne se manifeste pas puisqu'il purge au démarrage ...
C'est le comportement qui me semble logique, en rapport avec le service tel qu'il est défini par défaut. La curieuse impression que ça ne se passe pas comme ça sur ma Leap pourtant configurée à l'identique. Faut que je vois ça à la prochaine maj du kernel sur Leap.
thierry@thinkpad-tw:~> zypper se 7z Chargement des données du dépôt... Lecture des paquets installés...
S | Name | Summary | Type --+-----------------+-----------------------------------------------------+------- i | 7zip | File Archivier | paquet | J7Z | Java-based P7Zip GUI for data compression and bac-> | paquet | J7Z-kf5 | KF5 service menu for J7Z | paquet | python310-py7zr | Library and utility to support 7zip | paquet i | python38-py7zr | Library and utility to support 7zip | paquet | python39-py7zr | Library and utility to support 7zip | paquet
Pour ne conserver que les deux derniers kernels. Et cette commande me supprime en effet le plus ancien (ou les plus anciens si j'en ai laissé traîner par mégarde).
Si je fais de même sur Tumbleweed, rien ne se passe mais après vérification je constate que je ne conserve que les deux derniers kernels, comme si la procédure de suppression des plus anciens kernels était automatique.
Je sais que purge-kernels est un service. Or, aussi bien sur Leap que sur Tumbleweed je vois ceci dans le Gestionnaire de services de Yast :
et par ailleurs les fichiers /ect/zypp/zypp.conf respectifs sont identiques (tout au moins pour ce qui se rapporte à purge-kernels).
Quel est le comportement par défaut de purge-kernels, et comment doit-il se manifester?
Du coup on risque d'avoir le même soucis avec leap 15.4 vu que ça switch sous plasma 5.24. Espérons que ça soit réglé avant la sorti de leap 15.4 pour le coup.
TW 20220205 : Plasma 5.23.5 (de mémoire), TW 20220207 de ce soir : Plasma 5.24.0 et le problème demeure.
Je ne sais pas comment ça se goupille, à quel niveau le boulot doit être fait (à priori du côté de KDE?), et je ne vois aucune réclamation sur Bugzilla à ce sujet. Je ne mesure pas non plus l'importance du manque ou le degré de gravité de l'affaire (moi ça me fait défaut mais à qui d'autre? je ne mesure pas).
Donc j'espère aussi que ce sera réglé pour Leap 15.4.