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.
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) :
Je viens de récupérer une tour sur laquelle j'ai installé TW. Je dois utiliser une clé wifi pour cette tour qui prend place à l'autre bout de mon appartement (éloignée de ma box fibre donc). J'en ai une (Belkin N300 Micro Adaptater) qui fonctionne mais en 2,4 GHz seulement. Précisions : la tour n'a que de l'USB 2 et la clé est aussi en USB 2. Je plafonne en moyenne à environ 10 Mbps en débit descendant même en bricolant sur les canaux (mais ça peut être bien plus faible). C'est suffisant souvent pour une petite utilisation d'internet (cette tour n'a pas vraiment d'autre vocation) mais je crains les grosses majs de TW (j'aurais peut-être du installer Leap ).
Avec une clé wifi dual-band ça pourrait être beaucoup mieux (j'ai 2 portables qui tournent en wifi sur du 5GHz et ça le fait bien en étant assez éloigné de la box, à l'emplacement de cette nouvelle tour par exemple).
Je me suis renseigné mais c'est le souk au niveau des clés wifi avec Linux (mon impression). Quelqu'un pourrait-il me conseiller une clé wifi dual-band pas trop chère (genre nano) qui est bien reconnue et immédiatement fonctionnelle avec openSUSE, sans complication?
Le Livre Photo Cewe propose un logiciel de création pour composer des livres ou réaliser différents types de tirages photo à commander via son interface. On trouve souvent par ailleurs plus ou moins le même logiciel chez des partenaires de Cewe. Bien entendu, l'intérêt ici est que ce logiciel fonctionne également sur Linux.
Il m'arrive parfois de l'utiliser sauf que dernièrement, consécutivement à une de ses mises à jour, il ne fonctionnait plus (on clique et rien). Désinstallation, nettoyage des fichiers de configuration et réinstallation de la nouvelle version fraîchement téléchargée, rien n'y faisait.
J'ai un peu galéré pour trouver ce qui n'allait pas.
Il lui manquait une bibliothèque partagée, libtiff.so.5, ce qui signifie en gros que ce logiciel n'est plus très en phase avec bon nombre de distributions Linux qui utilisent à présent libtiff.so.6 (et même libtiff.so.6.0.1 pour Tumbleweed actuellement).
Il existe une solution de contournement. Il faut copier le fichier /usr/lib64/libtiff.so.6 (ou libtiff.so.6.0.1) dans le dossier d'installation du logiciel et créer dans ce même dossier un lien symbolique libtiff.so.5 pointant vers le fichier copié (libtiff.so.6 ou libtiff.so.6.0.1, selon) :
Aucune de ces deux opérations, que ce soit la copie de la bibliothèque partagée ou la création du lien symbolique, ne nécessite d'être en root ou d'invoquer sudo.
L'idéal serait bien sûr que Cewe corrige et actualise son logiciel pour Linux. Cette société allemande est avisée du problème depuis un bon moment déjà et y a répondu avec une solution " temporaire" un peu lourde à vue de nez (pas testée) :
Je ne suis volontairement pas rentré dans le détail de l'installation de ce logiciel qui se niche dans le répertoire de l'utilisateur mais cela n'a rien de bien méchant ceci-dit. Au cas donc seulement où l'un ou l'autre membre de notre forum rencontrerait le même souci que moi une fois ce logiciel installé.