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.
Sinon on peut calibrer sans, en RVB, avec gnome-color-manager, mais avec peut-être une précision moindre.
Oui, c'est ce que je fais le plus souvent sur Leap (simple et rapide, même si moins précis). Par contre, je le signalais dans mon premier message, l'appel à gnome-color-manager (ou plus exactement je pense à /usr/bin/gcm-calibrate) par Color Corrections de KDE, ne fonctionne pas sur Tumbleweed. Et je ne vois rien à ce sujet sur Bugzilla.
J'avais essayé Antix (Full) sur un Eee-PC (HP Compaq Mini CQ10-130sf). Antix était très à l'aise sur cette petite machine. Je ne me souviens plus par contre avoir connu un souci avec la francisation du système. L'Eee-PC étant un peu à l'abandon mais toujours chez moi, je l'ai ressorti du coup, dans l'idée de retrouver Antix et vérifier si cette distribution était bien, peu ou mal traduite en français.
Pas de chance, Antix n'est plus là mais... je retrouve à la place Sparky Linux (Nibiru 5.13) que j'avais totalement oubliée.
Je revisite vite fait, ça m'a l'air bien réactif (peut-être pas autant qu'Antix, faut voir), bien fichu (base Debian), elle est bien documentée (en anglais), le projet a l'air bien vivant, et le français est présent à tous les étages ou presque une fois installée (tout au moins pour la version que j'ai sous les yeux). Cette distribution d'origine polonaise je crois pourrait peut-être aussi t'intéresser.
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 :
Cela deviendra inquiétant quand elle changera sur Win. et pas sur Leap...
Si tu veux mais pour ma part je commence déjà à m'inquiéter quand ça ne fonctionne plus sur Debian stable (11 "Bullseye"). Cela va nous tomber sur le coin du nez comme aux autres il y a déjà au moins presque un an.
Oui, il n'y a pas de souci avec DisplayCAL sur Leap 15.3. Mais qu'en sera t-il à l'avenir sur Leap? Peut-être même dans un futur proche (Leap 15.4)? encore que je reste assez confiant dans cette perspective rapprochée.
La dernière version de DisplayCAL (3.8.9.3) date du 14/12/2019, c'est inquiétant. Et il ne me semble pas qu'elle résolve le problème avec Python soulevé ici ou là.
Deux discussions postérieures à cette dernière mise à jour, l'une de septembre 2020 et l'autre de janvier 2022 :
Oui, je veux bien le croire, la version DisplayCAL des dépôts sur Leap fait le boulot jusqu'au bout, jusqu'à l'installation du profil dans l'environnement de bureau. Le flatpak non d'après mon expérience même si les paquets colord-kde et gnome-color-manager sont installés.
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é.
Dans le cas présent,zypper laisse le choix et il n'y a aucun problème à accepter le changement de fournisseur,ce ne sont pas des dépôts exotiques.
D'accord merci Il faut le prendre à la cool. Je poursuis mon installation de TW... mine de rien c'est long de remettre les choses en place (je fais plus ou moins une copie de mon PC principal qui est sur Leap, pour comparer et conserver une référence, et je prends des notes).
Tu les passes sous opensuse pour le moment. Il arrive en effet que Packman soit en retard. Tu pourras les passer ensuite sous Packman quand ils seront mis à jour.
Bonjour,
Que Packman soit parfois en retard, je comprends. Mais je m'interroge sur le sens du changement de fournisseur et de la priorité 90 collée à Packman quand on met à jour TW. Dans ma compréhension des choses, les paquets attribués à Packman ne devraient être mis à jour que par l'intermédiaire de ce dépôt. Maintenant, un zypper dup rebat peut-être systématiquement les cartes?
Lorsque je lance un Zypper dup sur ma TW j'ai l'erreur de dépendance ci-dessous : Mes plugins sont chez Packman et il voudrait me les foutre chez OPENSUSE... ça est déjà arrivé et j'attendais quelques jours et le problème se réglait seul (magie...) Mais là ça fait plus d'une semaine que c'est comme ça... Suis-je le seul ?
Bonjour,
J'ai constaté la même chose dans une VM Tumbleweed et j'ai accepté à l'arrache car c'était une VM. Là j'installe TW en dur sur mon PC portable, je suis plus prudent, et la question m'intéresse beaucoup car elle bouscule ma compréhension des choses d'après mon expérience sur Leap.
Je m'explique : dès lors que les mises à jour se font via zypper dup, le changement de fournisseur (opéré pour Packman) perd-il son sens?
Enfin de façon plus générale, sur TW, quelle attitude adopter, quelle décision prendre dans le cas de figure que tu présentes. Visiblement, d'ordinaire, tu attends c'est à dire que tu diffères la mise à jour. C'est la bonne stratégie?
Les noyaux, je ne savais pas que j'en avais autant Je pensais n'en avoir que deux.
Apparemment, quand on purge les kernels, ce que je ne manque pas de faire à chaque maj du kernel, ça ne fait pas le ménage dans les modules car j'ai la même chose que toi dans /lib/modules/
Il y a peut-être une raison à cela même si ça ne me paraît pas logique.
J'ai bien failli abandonné l'affaire mais l'idée que le problème se reproduise peut-être dans la future Leap (15.4), m'a poussé à insister. Je n'ai ni envie d'abandonner kDrive pour une solution plus coûteuse (je mets des limites financières à ce petit confort), ni envie de changer de distribution (à part Debian si j'y étais contraint, je ne vois pas).
Quelques questionnements déjà comme tu peux t'en rendre compte. Mais on reprend tout.
Étape 1 : nouvelle machine virtuelle Tumbleweed avec un Gnome tout propre. Problème identique.
Étape 2 : je détruis et je refais une machine virtuelle Tumbleweed avec KDE. Le problème demeure.
Étape 3 : je contacte enfin le support technique d'Infomaniak par mail, en étant le plus précis possible et en joignant des copies d'écran. C'était ce midi. Réponse obtenue dans l'après-midi, pas mal non?!
Copie de la réponse :
Citer
Merci pour votre message.
Concernant votre demande, il semblerait qu'un bug se soit glissé dans la dernière version de glibc sur certaines distributions de Linux :
En lançant l'app via le Terminal avec la commande : export QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox"
Devrait permettre de lancer le logiciel de manière saine.
Merci pour votre confiance. Nous restons à votre disposition.
Je ne savais pas trop comment associer cette commande avec celle de l'app et après quelques échecs je m'en suis sorti en collant un point virgule entre les deux (comme s'il s'agissait de deux commandes successives) :
Résultat : J'ai enfin pu me connecter via l'AppImage, configurer une synchronisation (minimale pour un test), vérifier que l'app est bien configurée pour se lancer au démarrage (elle se charge d'informer KDE), et tout compte fait, ça fonctionne et c'est pérenne (même après un redémarrage s'entend).
Maintenant il faut avoir à l'esprit que c'est une solution de contournement à propos de laquelle on peut s'interroger (no-sandbox?) même si c'est un bel effort du support technique d'Infomaniak. Peut-être à surveiller cette histoire de glibc et plus précisément de glibc 2.34 qui est bien dans Tumbleweed? Mais je n'ai rien vu de parlant à mon niveau sur Bugzilla à ce sujet.
Il faut le prendre à la cool. Je poursuis mon installation de TW... mine de rien c'est long de remettre les choses en place (je fais plus ou moins une copie de mon PC principal qui est sur Leap, pour comparer et conserver une référence, et je prends des notes).
