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.
Surprise! (enfin... pour moi) Ark ne peut plus compresser et décompresser les archives 7z dans Tumbleweed car les paquets p7zip et p7zip-full ont été remplacés par un nouveau paquet : 7zip.
Les alternatives émergentes dans cette discussion et qui proposent une interface graphique (peazip, et engrampa le gestionnaire d'archives de Mate) ne m'ont pas du tout convaincu personnellement, tout au moins dans l'environnement KDE. Reste la ligne de commande qui change avec un 7zz (interdit de s'endormir!) en lieu et place de 7z qui fonctionne toujours malgré tout. Pas de page de manuel pour la commande 7zz et celle de la commande 7z a disparu. Pour se renseigner il faut taper :
Pour gérer la correction des couleurs des périphériques (et plus communément celle des écrans), il faut ajouter le module Color Corrections à la configuration du système de KDE, avec le paquet colord-kde. Si on veut en plus pouvoir calibrer son écran à l'aide d'une sonde de calibrage, via ce module, il faut ajouter la gestion de la couleur de... Gnome, c'est à dire qu'il faut en plus installer le paquet gnome-color-manager.
Cela fonctionne très bien sur Leap 15.3 si la sonde est reconnue bien sûr. Les experts déplorent un calibrage approximatif avec cet outil intégré à l'environnement de bureau mais il a l'avantage d'être simple et rapide à l'utilisation. Sur mon PC de "bureau", il corrige déjà une petite dérive magenta de mon écran et moi ça me va bien généralement même si je dispose d'un autre outil plus pointu, DisplayCAL, qui me sert entre autres à mesurer de temps en temps l'éclairage ambiant.
Deux problèmes relatifs à tout ceci dans Tumbleweed :
1/ Impossible de calibrer un écran via le module Color Corrections de la configuration du système de KDE. On dirait qu'il ne "voit" pas gnome-color-manager pourtant installé. Apparemment, un problème identique a été rapporté sur d'autres distributions Linux.
2/ DisplayCAL est absent des dépôts. Et c'est normal car DisplayCAL dans sa dernière version repose toujours sur Python 2.7 qui est abandonné dans Tumbleweed comme dans d'autres distributions Linux [EDIT à 22h18 : je dis des bêtises car Python 2.7 est bien dans les dépôts. C'est plus compliqué que ça mais il y a un souci avec Python]. Pour Python, n'étant pas développeur, je retranscris, peut-être mal d'ailleurs [EDIT : certainement], ce que j'ai lu ici ou là et principalement sur le forum de darktable.
Ces deux problèmes pourraient affecter Leap à l'avenir, surtout celui de DisplayCAL car son développeur tarde à se mettre à jour avec Python (la dernière version de DisplayCAL remonte à 2019 je crois).
Alternatives pour étalonner son écran : utiliser ArgyllCMS en lignes de commandes (présent dans les dépôts mais bon casse-tête en perspective) ou installer le flatpak DisplayCAL, ce que j'ai fait même si je préfère éviter d'installer des flatpaks en général.
Le flatpak DisplayCAL fonctionne mais, je m'en doutais, il n'installe pas le profil d'écran issu du calibrage quand bien même on lui demande.
La solution sur KDE : récupérer le profil (xxxxx.icc) dans /home/utilisateur/.var/app/net.DisplayCAL/data/Display/storage/ et le copier dans /home/utilisateur/.local/share/icc/ ou utiliser le module Color Corrections de KDE pour aller chercher le profil là où DisplayCAL l'a déposé.
J'utilise le cloud grand public d'Infomaniak : Kdrive.
Il est proposé une petite AppImage pour la synchronisation. Elle fonctionne bien dans Leap et même dans une VM Windows 10 (là j'ai juste essayé car ça n'a pas d'intérêt pour moi).
Je teste actuellement Tumbleweed dans une VM (VirtualBox) et je voulais donc éprouver cette AppImage dans ce contexte.
Elle se lance, pas de problème, mais quand je veux ajouter mon Kdrive perso pour la synchronisation : page blanche
On dirait que ça coince pour joindre les serveurs d'Infomaniak et se connecter.
J'ai désactivé le pare-feu de Tumbleweed, pas mieux. Celui de l'hôte (Leap), pareil.
Quelqu'un utilise t-il Kdrive avec satisfaction dans Tumbleweed?
Consécutivement à la mise à niveau de Leap 15.2 vers 15.3 (KDE), nous avions constaté un sérieux dysfonctionnement de Discover plus ou moins paralysé par l'absence de connexion internet selon lui (alors que la connexion était effective bien sûr). Cela entraînait aussi un sérieux dysfonctionnement de l'applet des mises à jour de KDE, liée à Discover.
Après les toutes récentes et copieuses mises à jour de Leap, Discover ne me signale plus d'absence de connexion et semble à nouveau fonctionner normalement.
Vous confirmez la même chose chez vous (utilisateurs de Leap KDE)?
Concernant l'applet des mises que j'avais désactivée, je ne suis pas chaud pour la réactiver car la ligne de commande offre quand même une meilleure lisibilité et certainement un fonctionnement moins aléatoire.
Ceci dit le retour de Discover est appréciable pour les nouveaux utilisateurs qui veulent découvrir une partie de la panoplie des logiciels.
J'ai remarqué que le référentiel Packman pour Leap 15.3 est dépourvu d'une version stable de VLC et ne propose qu'un paquet vlc-beta. Un oubli?
En attendant c'est gênant, surtout pour un nouvel utilisateur d'openSUSE car s'il installe VLC, il installe la version stable des dépôts officiels. Et s'il procède à un changement de fournisseur des paquets système vers ceux de Packman avec la commande :
Chargement des données du dépôt... Lecture des paquets installés... Calcul de la mise à niveau de la distribution...
Problème : le/la vlc-3.0.13-bp153.1.1.x86_64 installé(e) nécessite 'vlc-noX = 3.0.13-bp153.1.1', mais cette condition ne peut pas être remplie Solution 1 : Les actions suivantes seront exécutées : conserver l'élément vlc-noX-3.0.13-bp153.1.1.x86_64 obsolète conserver l'élément vlc-qt-3.0.13-bp153.1.1.x86_64 obsolète Solution 2 : désinstallation de vlc-3.0.13-bp153.1.1.x86_64 Solution 3 : casser vlc-3.0.13-bp153.1.1.x86_64 en ignorant certaines de ses dépendances
Choisir une des solutions ci-dessus en tapant son numéro ou bien annuler en tapant 'a' [1/2/3/a/d/?] (a):
Je ne sais pas quoi penser de cette version bêta de VLC mais en tout cas je trouve que ce n'est pas top d'échouer là dessus dans le cadre de Leap. En attendant j'ai remplacé VLC par SMPlayer, pour moi ça peut le faire, mais bon... j'espère que ça va bouger du côté de Packman car ça peut refroidir un nouvel utilisateur qui tient à VLC.
Les nouvelles versions du logiciel darktable sont attendues et sont désormais des événements pour un certain nombre de photographes amateurs mais aussi professionnels, convaincus ou pas par le logiciel libre, darktable étant installable gratuitement sur GNU/Linux, Mac ou Windows.
Ce sont aussi des événements autrement importants et même plus importants pour les utilisateurs d'une distribution Linux qui pour satisfaire leur besoin en matière de traitement d'images photographiques numériques, disposent d'un moindre choix de logiciels. La tentation d'essayer une nouvelle version d'un logiciel phare à notre portée dans le domaine est d'autant accrue.
darktable 3.6, version été 2021, vient donc de sortir. Je n'ai pas encore pris connaissance des nouveautés et je ne pense pas être assez qualifié pour en faire une critique objective, mais j'ai immédiatement été tenté d'installer cette nouvelle version et c'est à ce sujet que je veux mettre en garde, tout au moins sur Leap 15.3.
Version officielle openSUSE Leap 15.3 : darktable 3.4.1
Le dépôt recommandé par les développeurs de darktable : graphics:darktable
L'installation en 1 clic tente de configurer de nouveaux dépôts SLE dont nous n'avons que faire à priori. À éviter dans l'immédiat et à ce jour pour un nouvel utilisateur d'openSUSE.
Si vous cliquez sur openSUSE, il n'y a pas de choix pour openSUSE Leap 15.3.
Il faut cliquer sur SUSE SLE pour atterrir sur ce qui nous parle : un lien One Click Leap 15.3, quand même assez surprenant ici.
Compte tenu de la confusion, je ne sais pas à quelle niveau elle se situe en raison des nouvelles orientations de la distribution, et compte tenu du point 1/ sur l'installation en 1clic, je pense qu'il est recommandé de passer par Ajouter le dépôt et installer manuellement.
Ne vous méprenez pas! je ne suis pas un boxeur qui cherche à monter de catégorie et concernant ce qui nous intéresse principalement sur ce forum, mon intention serait plutôt de jouer dans la catégorie supérieure en restant svelte, quelle folle ambition!
Je m'explique : Après la mise à niveau vers Leap 15.3, ma partition racine a enflé d'un peu plus de 6 Go, passant en gros de 14 Go à 20 Go. C'est beaucoup je trouve, je ne me l'explique pas et je me demande si ma partition racine d'une cinquantaine de Go peut plus ou moins récupérer son poids de forme (?).
Pour installer cette version sur openSUSE, si vous l'estimez incontournable pour vous, darktable FR recommande ce dépôt tiers qui bien que non officiel ne nous est pas étranger (paquets expérimentaux).
La documentation d'openSUSE répond souvent bien à mes questionnements mais elle me paraît parfois trop fragmentée pour saisir la logique globale de la distribution au regard des sources de paquets.
Je n'arrive pas en effet à hiérarchiser les sources additionnelles et leurs impacts respectifs sur la maintenance du système : Paquets communautaires et expérimentaux ou encore paquets provenant des dépôts de l'OBS? Dans quel ordre ça se joue pour garantir au mieux la stabilité (certains mots comme "expérimental" ne signifiant pas forcément plus de risques)?
Des questions analogues me viennent aussi à l'esprit quand j'envisage la mise à niveau future de la distribution (Leap bien entendu)... mais j'ai encore un peu de temps pour ça.
On peut se moquer mais pas me traiter de mytho car oui j'ai déjà réussi à planter Leap en dix jours de temps d'utilisation. Reboot sauvage (c'est pas bien d'où ce nouveau sujet) , expérimentation à l'arrache des snapshots, par bonheur ça fonctionne et je retrouve ma bonne humeur.
Les touches magiques SysRQ nom d'une pipe! Je les avais complètement oubliées celles-là, ne les ayant utilisé qu'une fois du temps de Mandrake ou Mandriva. Petit rappel : Ce sont des séquences et des combinaisons de touches pour essayer de sortir proprement d'un plantage.
Bref, je révise la question, je constaste que ces touches magiques sont bien activées par défaut dans Leap et que par défaut il leur est attribué la valeur 184 (toutes choses vérifiables simplement dans Yast).
Cette valeur est en fait une limitation de l'usage des combinaisons de touches possibles car elles ne sont pas anodines (elles titillent le noyau et le monsieur est rigoureux quand on s'adresse à lui).
Chez Ubuntu par exemple cette valeur est fixée par défaut à 176 et elle autorise trois actions successives à effectuer dans l'ordre.
Comme on peut le lire sur cette page, 176 résulte d'une addition de valeurs équivalentes chacune à une action (attention, toutes les actions possibles ne sont pas listées dans le tableau).
Donc, par défaut chez openSUSE, avec la valeur 184, nous sommes autorisés à effectuer au moins une opération supplémentaire car je suppose qu'il y a une sorte de correspondance avec la politique d'Ubuntu à ce niveau (des opérations basiques à peu près compréhensibles pour un utilisateur lambda).
La question : Par défaut que sommes-nous autorisés à faire pour tenter de sortir d'un plantage, comment et dans quel ordre?
J'ai essayé Alt-Sys-H pour consulter l'aide dans une console (Sys = Impr. Écran chez moi à priori), sans résultat soit dit en passant.
Maintenant, ce n'est pas vital non plus, j'avais fait une grosse boulette complètement idiote dont l'idée ne passe théoriqement pas par toutes les têtes.
Panne nationale du réseau SFR sévissant depuis environ 16h30 et persistante à cette heure (23h) je crois bien.
Des serveurs DNS saturés paraît-il et des solutions de contournement qui émergent... faut changer les serveurs DNS qu'il se dit.
Une panne générale? D'habitude je lache l'affaire et je patiente. Et puis ces histoires de serveurs et de DNS, je ne suis pas trop chaud pour m'en mêler d'ordinaire (bon... vous voyez le niveau maintenant).
Sauf que je viens à peine d'installer Leap sur ma tour en ethernet, c'est rageant. Les DNS? et je fais comment moi avec mon openSUSE toute fraîche (une distribution que je découvre depuis peu sur mon netbook par ailleurs)?
La solution n'a pas tardé à venir dès ma première recherche et à ma très grande surprise ici : SDB:Configure DNS (Méthode 1). Du sur-mesure! clair, concis et qui fonctionne
Bon... je me suis quand même un peu renseigné sur le serveur alternatif proposé par cette documentation (tant qu'à en jouer).
j'ai installé ma multifonction Canon MG6650 en wifi avec le pilote propriétaire pour l'imprimante et finalement avec celui des dépôts pour le scanner (pilote MG6600 Séries, répertorié comme "non testé" mais qui fonctionne).
Si j'active le pare-feu dans Yast, tel qu'il est réglé par défaut, je communique bien avec l'imprimante mais pas avec le scanner. Je crois qu'il y a une raison objective à cela (j'ai vaguement lu un truc à ce sujet)... ceci pour dire que ce n'est pas une anomalie à priori. Et les utilisateurs d'autres distributions rencontrent la même difficulté avec ce matériel.
Bien entendu, le pare-feu désactivé, tout fonctionne à merveille.
J'ai donc fait quelques recherches et trouvé des éléments d'information chez Canon et dans des docs Linux en ligne au sujet de la librairie sane-pixma dépendante du paquet sane-backends.
Bref, pour utiliser le scanner en wifi, il faut ouvrir le port 8612 dans le pare-feu.
Honnêtement, les réseaux, le pare-feu et moi, ca fait vraiment trois. Je ne suis pas du tout à l'aise avec tout ça.
Mais bon, je suis donc retourné voir le pare-feu dans Yast et j'ai ouvert le port 8612 en TCP et UDP dans la zone "public" qui est activée par défaut je crois bien (une zone méfiante si j'ai un peu compris quelques petits trucs). Et ça fonctionne, je communique avec le scanner, le pare-feu étant activé.
Maintenant, je ne suis absolument pas certain de ne pas avoir commis de boulettes.
Si quelqu'un de plus avisé pouvait me donner son avis, je suis preneur.
Sources : Bah en fait, la page de man de sane-pixma donne l'info pour les ports (je viens de m'en apercevoir).
et concernant ce qui nous intéresse principalement sur ce forum, mon intention serait plutôt de jouer dans la catégorie supérieure en restant svelte, quelle folle ambition!
(paquets expérimentaux).
