Cette espace vous permet de voir toutes les Sujets réalisées par ce membre. Vous ne pouvez voir que les Sujets réalisées dans les espaces auxquels vous avez accès.
Gros souci hier qui s'est d'abord manifesté comme suit quand j'ai voulu me connecter :
Des popups en pagaille du même style pour tout un paquet de fichiers du type xxxxrc.
Deux hypothèses dans ma tête : une corruption de mon compte utilisateur et/ou une défaillance du SSD sur lequel est installé le système (un SSD de moins d'un an).
De quelque manière je n'ai pas pu créer un nouvel utilisateur afin d'identifier si seul mon compte personnel était affecté.
J'ai aussi basculé sur un snapshot mais le résultat était toujours le même.
Enfin j'ai bricolé avec smartctl pour vérifier l'état de mon SSD. Un peu de littérature aidant j'ai fini par conclure qu'il était sain.
Pour un certain nombre d'opérations je me suis placé dans un terminal virtuel (tty1) mais ce faisant j'ai aussi été abreuvé d'une foule de messages dont le dénominateur commun était en gros que j'avais des erreurs BTRFS et que mon système était passé en lecture seule (du coup, c'est logique, les snapshots... tintin! ils ne servaient à rien).
Que faire? réinstaller? la barbe!
Un peu désorienté j'avoue, je me suis inspiré de cette page du support de SUSE :
Et j'ai donc essayé de réparer en utilisant une clé usb bootable de TW (dans les Options -> Rescue, puis à l'invite rescue login : inscrire root, pas de mot de passe). Aucune crainte de tout foutre en l'air si au final je dois malgré tout réinstaller.
Petite précision quand même : sur cette tour (mon ordi principal) les données sont sur deux HDDs dont l'un est la copie exacte de l'autre et j'ai aussi des sauvegardes externes. Ne tenter aucune réparation sans avoir une sauvegarde de ses données!
En dépit du WARNING sur ma page SUSE de référence, je n'ai pas finassé (mon système est sur /sda2):
Ceci-dit je n'avais pas de souci de démontage du système de fichier.
Au reboot j'ai finalement récupéré mon système (ouf!) mais je ne connais pas l'origine du problème. Qu'est-ce qui a bien pu causer tout ce bazar? Cette récupération est-elle solide?
J'ai seulement remarqué que la prise en compte d'un profil ICC pour mon écran avec X11 dans KDE6 générait successivement et à n'en plus finir des lignes dans le journal, du genre :
J'ai désactivé la prise en compte du profil et ces lignes n'apparaissent plus. Rien de tout ça avec Wayland, pas de bourrage du journal, mais mon affichage se dégrade avec la prise en compte du profil ICC (ce n'est pas fluide, le menu disparaît et réapparaît par exemple).
Cela n'a peut-être rien à voir avec le problème que j'ai rencontré ceci-dit.
L'idée de ce projet est de délivrer des systèmes prêts à l'emploi avec tout ce qu'il faut d'entrée (codecs, noyaux spécifiques pour les jeux, ect) et ne nécessitant à priori aucune maintenance, à l'instar d'un Chromebook, mais avec la flexibilité et la puissance d'un bureau Linux traditionnel (Extrait de la présentation d'Universal Blue).
Personnellement je ne sais pas encore quoi en penser. Hier soir j'ai essayé de me faire une VM VirtualBox d'Aurora, la saveur équivalente à Fedora Kinoite, avec les codecs et d'autres choses en plus. Ça moulinait trop longtemps à l'installation et j'ai laissé tomber.
Toujours est-il que ça avance visiblement à grands pas dans la lignée des Fedoras atomiques.
Edit : Je ne sais pas trop quoi penser du résultat en fait car je n'ai pas pu tester un minimum mais l'idée d'un bureau traditionnel Linux s'administrant tout seul comme un Chromebook et avec tout ce qu'il faut d'emblée pour le multimédia ou le jeu, est intéressante. Peut-être pas pour tout le monde ou pour les bidouilleurs (encore que des moyens sont offerts pour qu'ils se bricolent leur propre système sur cette base) mais pour des utilisateurs qui n'ont aucun intérêt à comprendre un système ou qui n'ont pas le temps de s'y consacrer, faut voir. Il m'est arrivé une fois de conseiller un Chromebook et j'avais de bonnes raisons de le faire. Cela fait trois ans je crois et je n'ai jamais eu de mauvais retour du genre : "Marche pas ton truc" ou "Je n'y comprends rien". J'aurais bien sûr largement préféré conseiller quelque chose qui ne soit pas complètement piloté par Google.
Mises à jour impossibles et plusieurs services de la distribution qui sont inaccessibles. L'origine du problème se situe au niveau du data center de Prague.
J'ai utilisé les résolveurs DNS de FDN, puis ceux de Cloudflare suite à des soucis avec le premier je crois et après avoir consulté le wiki d'openSUSE : SDB:Configure DNS.
À la "faveur" de la nécessité de changer de téléphone portable j'ai découvert Quad9 et Quad9 Connect. Je n'avais jamais pensé à mon smartphone jusque là en ce qui concerne ces DNS...
Passons. Ce Quad9 me semble pas mal du tout, pour ne pas dire franchement intéressant. J'ai tout basculé dessus, smartphone et ordis. Et hop! encore un truc en Suisse!
Je viens de constater un bug de VirtualBox sur TW (virtualbox 7.0.14-9.2)
Quand je passe le système invité en plein écran je perds l'usage de la souris et cela sur deux machines virtuelles (Windows 10 et Leap 15.6 RC).
J'ai un peu fouillé et ce n'est visiblement pas la première fois que ce bug survient.
La parade en attendant que ce soit réglé avec une mise à jour ultérieure du paquet : dans la configuration de la machine virtuelle -> Interface utilisateur, il faut désactiver l'affichage de la Mini-ToolBar (décocher).
Pour les photographes passionnés (dont je fais de moins en moins partie même si le sujet m'intéresse quand même), la prise en compte par les environnements graphiques du ou des profils (icc) résultant du calibrage d'un moniteur, est importante.
Je ne refais pas toute l'histoire mais nous avons un logiciel bien connu pour calibrer nos écrans, DisplayCAL, qui n'est plus disponible dans les dépôts (flatpak donc car je doute que sa compilation soit possible ou simple en raison de la version de python dont nous disposons).
Du fait que KDE Plasma 6 pousse en quelque sorte à l'utilisation de Wayland, je me suis posé la question de l'utilisation de DisplayCAL avec ce serveur graphique, ce que je n'avais jamais essayé de faire jusque là.
J'ai donc tenté de calibrer mon écran avec DisplayCAL sous Wayland.
Le logiciel se lance mais un message d'erreur a bloqué ma tentative de calibrage. À confirmer par d'autres utilisateurs du logiciel en question.
Qu'à cela ne tienne je suis donc allé calibrer sous X11 et j'ai obtenu un profil icc.
Avec X11 sur KDE, la prise en compte de ce profil par l'environnement graphique se fait grâce au Gestionnaire de couleurs dans la Configuration du système, à condition d'avoir installé le paquet colord-KDE.
Avec Wayland, ce n'est pas là que ça se passe. Il faut se rendre dans la Configuration de l'affichage.
Cela pose un petit problème. Avec X11, dans le Gestionnaire de couleurs, il est possible d'enregistrer plusieurs profils à ce niveau (un destiné à l'affichage sur le Web et un autre pour l'impression par exemple) et de basculer rapidement de l'un à l'autre.
C'est beaucoup moins simple avec Wayland comme vous pouvez le voir sur la capture d'écran ci-dessus.
Je m'interroge à présent sur DisplayCAL dont le développement est l'arrêt depuis un moment. S'il se confirme qu'il ne fonctionne pas avec Wayland, les photographes, les vidéastes et les graphistes auront des soucis à l'avenir. Argyll CMS en lignes de commande, sur lequel repose d'ailleurs DisplayCAL, ce n'est pas la joie
Ça pour KDE car Gnome dispose d'une solution rudimentaire, mais d'une solution quand même (gnome-color-manager) pour faciliter le calibrage.
KDE Plasma 6 est passée en 6.0.2 ce matin. Et si nous centralisions dans un fil unique, ici par exemple, tous les bugs et toutes les petites pétouilles que nous rencontrons?
Passage à KDE 6 foireux et je n'ai pas de trucs spécialement exotiques. Des soucis au niveau du thème et du wallpaper SDDM, qui étaient ceux par défaut chez moi.
C'était prévisible, Latte Dock est supprimé des dépôts de Tumbleweed avec la mise à niveau d'aujourd'hui (20240306).
Il a d'ailleurs déjà disparu dans l'offre logicielle de quelques autres distributions. L'auteur a abandonné le projet semble t-il.
Peu compatible avec Wayland pour ce que j'ai personnellement constaté, cela annonce t-il la livraison prochaine de KDE Plasma 6 dont le serveur graphique par défaut est justement Wayland? Probablement, mais pour très bientôt? je n'en sais rien.
À titre personnel, pour remplacer Latte Dock que j'utilisais, je vais peut-être bien me contenter d'un simple panneau Plasma... ou rien.
Ça commence à dater un peu et je ne l'avais pas constaté jusque là car je n'utilise pratiquement pas Discover (souvent sujet à des dysfonctionnements il me semble).
Je viens de remarquer que les annotations portées sur un document pdf grâce à Okular ne sont pas toujours forcément visibles ou sont parfois mal déchiffrées par un autre lecteur pdf (ou LibreOffice Draw) si nous nous contentons de faire un simple enregistrement dans Okular du document transformé.
À qui la responsabilité? Okular ou le lecteur tiers? Va savoir!
On cherche alors une fonction d'export adéquate mais pour le moment il n'en existe qu'une vers du texte brut.
Reste alors à imprimer... dans un fichier (PDF), pour rendre notre transformation du document original, universellement visible et/ou lisible.
Ça ne tombe pas sous le sens avec un lecteur pdf offrant quelques fonctions d'édition.
C'est une autre question mais pour l'aperçu d'impression avec Okular, cela a déjà été discuté ici, il faut installer le paquet okular-spectre.
Mauvaise surprise pour la nouvelle année, quelques éléments de la configuration du bureau Plasma ont été amputés chez moi.
Le menu contextuel amputé :
L' original attendu :
Le panneau de configuration du bureau amputé :
L'original attendu :
Il manque pas mal d'options dans les deux cas, non?
La solution que j'ai mise en œuvre :
J'ai créé un nouvel utilisateur et je suis allé copier son fichier ~/.config/plasma-org.kde.plasma.desktop-appletsrc que j'ai ensuite collé en lieu et place de son équivalent dans mon dossier personnel (en aillant préalablement modifié le propriétaire de ce fichier bien sûr).
J'ai retrouvé le menu contextuel et le panneau de configuration du bureau dans leurs états originaux et il m'a juste fallu remettre en place deux ou trois petites choses.
Mais je me demande s'il n'aurait pas été plus simple de supprimer directement ce fichier dans mon dossier perso, de me déconnecter et de me reconnecter pour obtenir le même résultat?
Voilà, au cas où quelqu'un aurait à subir le même désagrément un peu perturbant.
xxxxxx@localhost:~> sudo zypper dup [sudo] Mot de passe de root : Chargement des données du dépôt... Lecture des paquets installés... Avertissement : Vous êtes sur le point d'exécuter une mise à niveau de distribution avec tous les dépôts activés. Assurez-vous que ces dépôts sont compatibles avant de continuer. Reportez-vous à 'man zypper' pour obtenir plus d'informations sur cette commande. Calcul de la mise à niveau de la distribution... 5 problèmes : Problème : l'élément python311-PyQt6-6.5.2-1.2.x86_64 installé nécessite 'libQt6Core.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', mais cette exigence ne peut pas être remplie Problème : l'élément calibre-6.27.0-1.3.x86_64 installé nécessite 'libQt6Gui.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', mais cette exigence ne peut pas être remplie Problème : l'élément python310-PyQt6-6.5.2-1.2.x86_64 installé nécessite 'libQt6Network.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', mais cette exigence ne peut pas être remplie Problème : l'élément libQt6Network6-6.5.3-2.1.x86_64 installé nécessite 'libQt6DBus6 = 6.5.3', mais cette exigence ne peut pas être remplie Problème : l'élément libQt6Network6-6.5.3-2.1.x86_64 installé nécessite 'qt6-network-tls = 6.5.3', mais cette exigence ne peut pas être remplie
Problème : l'élément python311-PyQt6-6.5.2-1.2.x86_64 installé nécessite 'libQt6Core.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', mais cette exigence ne peut pas être remplie fournisseurs supprimés : libQt6Core6-6.5.3-2.1.x86_64 Solution 1 : désinstallation de python311-PyQt6-6.5.2-1.2.x86_64 Solution 2 : conserver l'élément libQt6Core6-6.5.3-2.1.x86_64 obsolète Solution 3 : casser python311-PyQt6-6.5.2-1.2.x86_64 en ignorant certaines de ses dépendances
Choisir une des solutions ci-dessus par son numéro ou bien sauter, recommencer ou annuler [1/2/3/s/r/a/d/?] (a):
Je suis donc allé à la pêche aux infos sur le forum officiel puisque rien n'a été signalé ici et parce que je ne suis pas fichu de choisir parmi les solutions qui me sont proposées.
Bref, la solution recommandée par Karlmistelberger, un intervenant d'expérience, serait de désinstaller python311-PyQt6 et python310-PyQt6, ainsi que leurs dépendances, puis de relancer la mise à niveau :
À priori la casse - les deux paquets virés n'étaient pas installés par hasard j'imagine - devrait être réparée ultérieurement lors de prochaines mises à niveau.
J'ai pris le parti de faire confiance, d'appliquer cette solution, et tout semble fonctionner normalement après un redémarrage.
Cette petite opération m'a quand même aussi désinstallé Calibre (ainsi que ses dépendances, j'ai vérifié). J'aurais pu le verrouiller semble t-il pour continuer à l'utiliser (trop tard). Bon... du coup je suis passé à sa version en Flatpak car Calibre a beaucoup de dépendances python qui peuvent poser problème.
Aujourd'hui j'ai reçu une proposition de mise à niveau très importante de Tumbleweed. Une mise à jour de 2222 paquets à laquelle devait s'ajouter l'installation de plus de 400 nouveaux paquets (la même chose sur trois installations de TW sur trois machines).
Ce n'est pas la première fois que je suis confronté à ça, sauf que là je me suis rendu compte qu'allaient s'installer en plus des choses dont je ne veux pas et dont je ne connais même pas l'utilité (ex : Accerciser, Jupyter Lab, Jupyter NBClassic et Jupyter Notebook, pour ce qui serait visible dans les menus).
Si en plus après on fait un simple zypper dup, l'histoire des paquets additionnels est oubliée et il n'y a rien à faire.
Je ne sais pas ce qui provoque ça mais voici une liste de ces paquets qui auraient du être ajoutés (sur ma plus récente installation de TW, le nombre est un peu inférieur sur les autres) :
)