Reprise du message précédent :

 
Franchement un snapshot btrfs c'est tellement plus rapide, simple, et sans risque, c'est la modernité, c'est pour ça que ce fs a été inventé, et en plus il te fait le raid 1.
Avant il fallait une couche mdraid plus une couche lvm, c'était un peu suicidaire, mais bon, c'est pour la maison, et avec btrfs on fait tout avec un seul fs.
 
Tu peux aussi faire un "btrfscat | ... " pour sauvegarder l'image en local ou en distance.
 
Après en enterprise les versions sont conservées longtemps, et les platres bien essuyés avant une upgrade, et surtout pour les trucs sensibles, tu as carrément une machine de backup.
 

 
Je parle d'un usage domestique aussi, mais comme mentionné par qqun, quand tu veux te faire ta séance xbmc/kodi, t'as juste envie que ça marche dans la seconde.
 
 

 
ouais bah faut avoir 1 ou 2 heures à cramer à des moments très inopportuns quoi

Bon, pouvez-vous me confirmer un problème ?
 
D’abord, il vous faut ça :

• GIMP 2.10.30
• gvfs 1.50 (sorti sur Arch stable mercredi)

Ouvrez GIMP et allez sur ces pages :
https://yande.re/post/show/809497
https://konachan.net/post/show/240145
 
Sur chacune, à gauche, vous allez voir deux liens « Download larger version » et « Download PNG ».
Glissez chacun de ces liens dans la fenêtre de GIMP : est-ce que les images s’affichent, ou est-ce que ça s’arrête tout de suite ?
 
Idem avec https://safebooru.org/index.php?pag [...] id=3928241 (glissez le lien « Original image ») : ça marche, ou pas ?
 
Perso, je dirais que depuis que j’ai mis gvfs à jour en 1.50, il n’est plus possible d’ouvrir dans GIMP des liens contenant des espaces (caractère « %20 ») dans l’URL, alors que ça marchait avant, avec gvfs 1.48. Si vous confirmez ça (via un retour vers gvfs 1.48 où toutes les images glissées dans GIMP devraient s’y ouvrir), il va falloir signaler ça sur le GitLab de gvfs (parce que je pense pas que le bugtracker d’Arch sera d’une grande aide…).
 
Comment je sais que ça vient pas de GIMP lui-même, ou d’autre chose ? Les URL sans espaces fonctionnent toujours dans GIMP, il n’a pas été mis à jour depuis un moment, et rien d’autre ne dysfonctionne.
 
Merci d’avance (en espérant que ce message ne reste pas lettre morte).

, han, je ne savais pas qu'on pouvait faire ça dans GIMP.
 
Pour les 2 premières images, oui, ça ne fonctionne pas le glissé-déposé des liens, il ne se passe rien. Le glissé-déposé des images fonctionne en revanche.
 
Pour la 3ᵉ, ça fonctionne, le lien "Original image" ouvre l'image quasi instantanément dans GIMP.
 
Je n'ai pas fait le test en 1.48, je ne sais pas revenir en arrière, et j'aurai bien tout effacer de toute façon.  

Tu peux faire du glisser-lâcher pratiquement partout : une vignette Youtube dans un bloc-notes (Mousepad, Pluma…) ou dans un lecteur vidéo (MPV ), des URL dans un fichier texte vers un lecteur vidéo ou vers GIMP…
 

Bon, tu confirmes…
 
Tu entends quoi, par « Le glissé-déposé des images fonctionne en revanche » ?
 

Comme c’était le cas jusqu’à la semaine dernière avec les deux autres sites (qui n’ont pas changé depuis des lustres).
 

Soit tu réinstalles le paquet en version 1.48 depuis le cache de Pacman (si tu l’as pas purgé depuis, c’est le paquet « /var/cache/pacman/pkg/gvfs-1.48.1-3-x86_64.pkg.tar.zst »). Sinon, faut aller le chercher dans les archives d’Arch Linux :
https://archive.archlinux.org/packa [...] kg.tar.zst).
 
Perso, je suis pas encore allé réinstaller cette ancienne version, mais je suis à peu près sûr que rétrograder en 1.48 « corrigerait » le bug. Sauf que c’est pas la meilleure des solutions à terme (car il faudrait bloquer ses mises à jour), et va falloir plutôt le signaler aux développeurs, pour qu’ils trouvent un moyen de corriger ça (je vais pas demander aux sites testés où ça ne marche plus, parce que c’est eux les fautifs).

Oui j'ai purgé.
 
Pour le glissé-déposé de l'image, dans Firefox, tu affiches l'image dans un onglet avec le clic droit, puis tu la prends et la dépose dans GIMP

J’aime pas que ça ouvre l’image dans un nouvel onglet si c’est pas ce que je veux, c’est pour ça que j’ai fait ajouter la fonction « Ouvrir l’image » (dans le même onglet) à Vivaldi pour sa version 1.7 (et installé l’extension qui remet ce comportement dans Firefox)…
 
Oui, ouvrir l’image et faire Ctrl-C dans le navigateur et Ctrl-V dans GIMP marche. Mais il arrive que j’ouvre plusieurs pages de ces imageboards, pour ensuite glisser les liens vers les versions complètes dans Mousepad (une URL par ligne), puis sélectionner le bloc d’URL ainsi collectées et les ouvrir dans GIMP pour ouvrir toutes les images en une fois (quand je veux les recadrer lorsqu’elles ont des marges dont je ne veux pas, vu que je fais une collection de ces images pour me servir de fonds d’écran et de diaporama d’écran de veille). Ben, ça, c’est plus possible depuis ces deux sites de cette manière. Et ça m’embête.
 
Je pourrais aussi toutes les enregistrer via wget et les ouvrir ensuite localement pour les traiter, mais comme je leur donne un nom personnalisé, là, je préfère les nommer directement quand je les enregistre, soit depuis le site, soit depuis GIMP.
 
Mais quoi qu’il en soit, il s’agit quand même d’une régression par rapport à la version 1.48, et faut dans tous les cas la signaler et espérer qu’elle sera corrigée rapidement.
 
EDIT : en fait, plutôt que gvfs, je pense que le fautif pourrait plutôt être glib-networking : c’est un paquet requis par GIMP, alors que gvfs ne l’est pas. Et lui aussi a été mis à jour mercredi (de 2.70.1 à 2.72.0)… Du coup, je pense que je vais plutôt signaler un bug en rapport avec lui, pour commencer.

Pas de fait de mise à jour depuis une semaine, le glisser-déplacer des liens fonctionne pour gimp,

faudrait lancer gimp depuis une console, puis regarder la sortie console s'il y a des messages d'erreurs quand le glisser déplacer ne marche pas.

Testé en rétrogradant glib-networking et gvfs{,-smb}, et ça marche toujours pas…

Ah, mais j’ai essayé ça ! Sauf que GIMP n’est pas mon ami, car rien du tout ne s’affichait… Supeeer…

Ça aide beaucoup, ça ! ↑ Et oui, j’ai encore essayé d’ouvrir un des liens problématiques entre ces deux lignes (j’ai même changé le mode de débogage, des fois que).

Peut-être tu auras plus de chance avec strace.

Il faudrait tester aussi en se connectant depuis un compte de test, afin d'avoir les fichiers de configuration par défaut dans home.

Ça fait pareil avec un profil vierge de GIMP, sur un autre PC qui n’a pas le même historique d’usage, et même chez un autre testeur (voir plus haut). À partir de là, on peut en déduire que ça sera pareil dans tous les cas…
 
Non, mais même si je me suis pas penché sur le problème depuis, j’ai quand même trouvé une issue dans le GitLab qui ressemble beaucoup à ce bug (qui viendrait donc de GIMP lui-même, même si ce rapport de bug se passe avec la version Windows).

Je viens de faire un "pacman -Syu", le drag and drop ne marche plus pour Gimp.

Lors de la mise à jour j'ai vu que le paquet gtk3 a été mis à jour, il est utilisé par gimp, peut-être que des fonctions ont été modifiées dans gtk3 pour le drag and drop,

je remarque aussi que le paquet gimp est assez vieux, il date de décembre dernier, peut-être qu'il faudrait recompiler le paquet pour être certain qu'il prend bien en compte les dernières versions de librairies, et voir si ça plante à la compilation (cela voudrait dire alors que des noms de fonctions, ou leurs paramètres ont peut-être changé dans ces dépendances).

On est gâtés ce matin, mise à jour de Plasma 5.24.4, de Mesa 22.0 et du noyau Linux 5.17.
 
Apparemment la combinaison de cette version de Mesa et de Linux améliorent pas mal les perfs en jeux sur certaines configurations.

Heu, GIMP est toujours en GTK2. Seule la préversion 2.99 est en GTK3, mais je suis sur la version stable. Et GTK3 est en mode de maintenance uniquement : seules des corrections de sécurité ont encore lieu dessus, ce qui ne devrait pas casser le montage d’un lecteur virtuel pour ouvrir des URL contenant des espaces dans le nom des fichiers à ouvrir (car même sans faire de glisser-lâcher, on ne peut pas non plus ouvrir via la fonction « Ouvrir suivant l’emplacement », où on peut coller l’URL du fichier distant à ouvrir).

Les 35 dépendances de gimp :
 
 

 
Recompiler le paquet gimp risque de prendre du temps, mais ça permettrait de vérifier l'hypothèse du besoin de recompilation.

J'ai un problème étrange mais je sais pas si je dois poster ça ici ou sur le topic Plasma, car à première vue c'est plutôt un problème de distro car cela concerne l'extinction du PC, mais le problème semble n'apparaître qu'avec Plasma, pas avec Gnome.

La plupart du temps, quand j'éteins le PC depuis Plasma, ça quitte bien la session, mais je reste bloqué sur un écran noir et le PC portable ne s'éteint pas.

Mais voila les deux bizarreries :

- le problème semble n'apparaître qu'avec Plasma ET avec deux moniteurs. Si j'ai seulement l'écran du portable branché, et pas mon moniteur externe, le PC s'éteint correctement.

- le système ne semble pas bloqué en vérité, car si je fais un appui long (~5 secondes) sur le bouton d'allumage / extinction du portable, le PC va finalement s'éteindre correctement. Attention, je ne parle pas de laisser le doigt appuyé sur le bouton pour forcer l'extinction à la barbare, je parle de le laisser appuyé seulement quelques secondes puis de le relâcher, et là le PC va s'éteindre proprement de lui-même quelques secondes après.

Vous avez déjà eu ça ?

Après un peu d'investigation, en fait le PC s'éteint correctement, sauf que c'est très long, et le problème semble venir de SDDM qui ne s'éteint pas, et systemd le kill au bout de 90 secondes (longueur définie par défaut dans le fichier de conf).

Ça semble être le problème décrit ici : https://www.reddit.com/r/archlinux/ [...] _shutdown/

Edit : et c'est un problème qui semble être exclusif à Wayland.

Le workaround qui semble fonctionner, je verrai dans la durée si c'est bien le cas (en tout cas là ça vient de marcher) : éditer le fichier /etc/systemd/system/display-manager.service et y ajouter la ligne : TimeoutSec=10 dans la section [Service].

Donc je pense que le fait d'appuyer sur le bouton Power annule le timeout et kill immédiatement les processus.

Mettre "DefaultTimeoutStopSec=15s" dans le fichier /etc/systemd/system.conf aidera aussi pour les autres unités systemd qui mettraient trop de temps à s'arrêter à l'extinction,

il arrive parfois que systemd décide de ne pas respecter ce réglage, en attribuant un temps d’extinction beaucoup plus long à l'unité systemd récalcitrant, sur la console on voit un message "A stop job is running for User Manager for UID 1000".

https://bbs.archlinux.org/viewtopic.php?id=261530
https://bbs.archlinux.org/viewtopic.php?id=261390

Oui, je sais qu'on peut le mettre globalement, mais j'ai voulu volontairement limiter ce paramètre à SDDM.

Je relance vu que j'ai pas eu de réponse

De mon côté, j’ai poursuivi mes tests avec une image que j’ai mise sur un espace FTP que je loue à l’année à un pote (donc, ça exclut un problème venant des sites précédemment liés). Trois fois le même fichier : seul le nom change.
 
TestSansEspaces.jpg → s’ouvre dans GIMP via glisser-lâcher.
 
Test avec espaces.jpg → ne s’ouvre pas.
 
Test%pourcent.jpg → ne s’ouvre pas non plus (ce qui confirme l’idée que j’ai eue ce matin, que ça pouvait être simplement le caractère « % » qui pose désormais problème).
 
La dernière fois, j’avais rétrogradé séparément glib-networking et le duo gvfs + gvfs-smb. Est-ce que les rétrograder tous en même temps donnera un résultat positif ? À voir.

Il nous a fait une sale blague de Poisson d’avril, Antonio Rojas : regardez la liste des paquets du dépôt Community qu’il a rétrogradés sur AUR (toutes les lignes « Commit in (« nom-du-paquet ») ») :
 
https://lists.archlinux.org/piperma [...] html#start
 
Bon, pour des paquets qui ne bougeaient pas trop comme abcde ou celestia (encore que, pour ce dernier…), je peux comprendre. Mais Stellarium ??! Dont la dernière version est sortie il y a seulement une semaine ??! Il se fout de notre gu×ule, ou quoi ?!!
 
Non, parce que le paquet Stellarium, il pesait quand même dans les 250 Mio, une fois compilé et compressé ! J’ose donc pas imaginer combien de temps ça mettrait à compiler, même avec le Core 2 Quad du PC familial… Heureusement qu’il existe un AppImage officiel, mais zut, à la fin ! C’est quoi, ce « nettoyage de printemps » à la noix ??!
 

En tout cas sous Endeavour aussi ce matin recompilage de Stellarium, je n'ai pas souvenir que c'était du AUR

Bouger un paquet sur AUR veut souvent dire qu'aucun TU ne voulait plus s'en charger.
Ca reste une distro de communauté Arch, personne n'est payé pour compiler des paquets et les maintenir.

Je te dirai bien de t'inscrire pour t'en charger, mais quand j'ai voulu bouger un de mes paquets d'AUR vers communauté j'ai envoyé des emails a 3 devs et n'ai jamais eu une seule réponse (pas meme un non ou faut demander cela d'une autre façon), donc ca ne m'a pas eu l'air si facile au final...

Alors, entre l’AppImage qui ne veut pas se lancer (car il détecte pas Qt 5.15, pourtant bien installé de son côté) et le PKGBUILD qui ne compile pas car Pacman prétend que certaines dépendances n’ont pas pu être trouvées, c’est la mouise !

Toutes les fois où j’ai essayé, la procédure a foiré à cause de la question de vérification qui n’a jamais voulu accepter ma réponse. Pourtant, c’est juste une commande à entrer qui devrait normalement donner une réponse valide !

Peut-être certaines des dépendances sont aussi sur AUR, donc introuvables pour Pacman? Est-ce pareil avec un outil pour AUR du type de YAY ou autre?
 
Sinon si tu as besoin d'aide pour créer un compte, je veux bien aider, m'enfin je suppose que je n'aurais pas le meme problème.

Oui, mais même là, c’est bizarre, parce que s’il y en a bien une qui est en effet sur AUR, il avait aussi bloqué sur cmake. Pourquoi avoir tout arrêté, plutôt que simplement demander à l’installer avec les autres dépendances de compilation qu’il m’avait fait télécharger juste avant ?
 

Créer un compte toi-même pour me le refiler après ?

Un compte AUR?

Mesa 22.0.1 vient de m’apporter des glitchs graphiques intermittents (ou, pour donner un exemple plus précis : j’ai une corruption d’affichage à un endroit donné, mais si je fais défiler, que je redimensionne la fenêtre, que j’en affiche une autre à la place, il disparaît), surtout sur le PC portable (pilote radeon, CG ATI Radeon Mobility HD 4530).
 
Entre ça et le fait que j’ai maintenant un bug d’affichage des images dans le nouveau Vivaldi 5.2 (à cause d’un bug dans Chromium), on peut pas dire que la fournée des MAJ d’hier ait été particulièrement bonne, en termes de qualité…

Pareil ici, dire que j'ai abandonné mesa-git pour ce genre de choses.

On peut faire du BTRFS sur un disque simple ? Si oui, on perd certaines fonctionnalités ? (par ex : les checksums)
 
 
 
 

Tu peux, et tu ne perds rien hors RAID je pense.
Je crois bien que meme sur un seul disque tu peux avoir des copies des données ou des métadonnées.

 
j'ai aussi parfois un affichage corrompu (en partie et qui dure parfois une demi-seconde, ou bien il faut que je bouge une fenêtre pour faire disparaitre la corruption d'affichage),
 
j'utilise le pilote libre radeon, avec une vieille carte graphique amd radeon HD4650 Pcie, ce problème existe depuis des années.

Ça a l'air d'être le bug de Libre Office dont je parlais l'autre fois, résolu :

https://bugs.documentfoundation.org [...] 144585#c28

Hâte de tester !

 
Savez-vous comment créer un fichier edid d'écran ?
 
Je m'explique : J'ai un 34" IIyama PL3466WQ branché en DP sur une 6900XT.
Sous Windows aucun souci, au repos en 144Hz sur le bureau le gpu et la mémoire s'underclock automatiquement pour limiter conso et chauffe.
Sous Arch par contre, avec Xorg, en 144Hz j'ai été obligé de créer un modeline perso, sinon la mémoire restait à fond (1000Mhz). Avec ce modeline dans la conf de xorg, ça fonctionne très bien.
Mais j'aimerai tester Wayland sous plasma, hors avec wayland le seul moyen que j'ai trouvé pour l'instant est de créer un fichier EDID et de le mettre en paramètre du kernel (car pour l'instant la mémoire reste bloquée sur 1000Mhz sous Wayland dès que je passe en 144Hz sur le bureau).
 
Mais comment créer ce fichier EDID ? Ou y'aurait-il un autre moyen d'appliquer ce modeline sous Wayland ?
 
Merci d'avance

Salut,
 
j'avais déjà joué avec ça y a quelques temps.
De mémoire y a les outils du projet read-edid pour lire/parser et j'avais réutilisé le code pour faire une version quick&dirty qui remplaçait la table des modes de mon EDID par une ligne arbitraire que je spécifiais.
J'utilisais gtf pour générer la modeline en entrée puis j'utilisais mon vrai EDID comme base pour le patcher.
 
C'était sûrement très spécifique à mon EDID et marcherait probabalement pas direct sur un autre EDID... mais si jamais ça t'intéresse je peux te retrouver le code.

Ah oui ça m'intéresse, je pourrais sûrement m'en inspirer
 
Merci

J'ai un souci depuis que j'ai décidé d'installer un kernel LTS en supplément de mon kernel standard. Systématiquement, quand il y a une mise à jour de kernel, j'ai le message d'erreur suivant au prochain boot :

[FAILED] Failed to start Load Kernel modules.
[FAILED] Failed to mount /sysroot.
Suivi d'autres messages de dependencies failed...

Heureusement, l'autre kernel fonctionne toujours, ça ne m'a jamais empêché de booter car si le message apparait alors que je tente de booter sur le LTS, le kernel standard fonctionne, et vice-versa. Une idée ? J'utilise Refind en bootloader.

Je pense à un problème lors du rebuild du mkinitcpio...

Edit : pourtant, les entrées du kernel standard et du LTS sont identiques dans refind.conf :

"Boot with standard kernel" "root=PARTUUID=b5f45c1f-6630-9c45-ae6f-2f05f2793c37 rw add_efi_memmap quiet acpi=force i915.fastboot=1 initrd=\boot\intel-ucode.img initrd=\boot\initramfs-linux.img resume=UUID=0e870c5e-b3a3-40f7-8ead-d75451c7bb6b"
"Boot with LTS kernel" "root=PARTUUID=b5f45c1f-6630-9c45-ae6f-2f05f2793c37 rw add_efi_memmap quiet acpi=force i915.fastboot=1 initrd=\boot\intel-ucode.img initrd=\boot\initramfs-linux-lts.img resume=UUID=0e870c5e-b3a3-40f7-8ead-d75451c7bb6b"