Sous environnement Manjaro Linux
Depuis la version 3.1.0+2309 je ne peux plus importer dans dt une ou plusieurs images.
J’en parle sur github ici
Avez-vous ce même comportement ?
Non, j’ai pu importer depuis le boitier pour ma part (v2338) enfin la sd.
Non plus avec la 3.1.0~git2336.2a3aef537
@ Hgmarty,
Importer une ou des images du boîtier (testé avec deux différents) ou un dossier fonctionne (testé avec différents dossiers, type image, avec ou sans .xmp présents.
C’est importer une image individuelle, ou plusieurs, présentes sur le disque du PC qui ne fonctionne pas.
En fait la fenêtre « importer image » est sans fond, transparente, ou dans le meilleur des cas (après un reboot du PC") il y a bien l’affichage mais dans la zone de recherche l’arborescence de mon disque n’est pas visible aucun dossier et a fortiori les fichiers avec.
De toutes façons à ce stade dt freeze, il faut tuer le process pour en sortir.
Je ne sais si c’est lié à mon système ou un bug apparu après la 3.1.0+2309, toutes celles que j’ai compilé depuis plantent, jusqu’à la 3.1.0+2338
[hr]
@ manu
Non plus avec la 3.1.0~git2336
Ça viendrait de mon système alors, si ça fonctionne avec ta 3.1.0+2336
On a eu un problème similaire décrit sur la newsletter darktable-dev hier (freeze non reproduit par personne d’autre ; par contre ce n’était pas via le module d’import) et apparemment le gars a fini par résoudre le problème en utilisant un autre gestionnaire de fenêtre de ce que j’ai compris. Il dit avoir constaté une mise à jour de mutter récemment, sur Ubuntu 20.04, et en changeant de session donc pour avoir un autre gestionnaire, ça fonctionne de nouveau. Bon, je n’ai pas répondu mais j’utilise Ubuntu 20.04 avec Gnome 3.36 et mutter, et aucun problème de mon côté.
Quel environnement de bureau et gestionnaire de fenêtre utilise-tu ? En as-tu un autre d’installé pour tester si le fonctionnement est différent ?
Ca fonctionne de mon coté. Debian Buster Gnome et mutter.
Ah, voilà qui donne une piste, effectivement de ce que j’ai recensé les debian et dérivées n’ont pas le problème.
Je suis sous Manjaro 20.0.3 et Xfce 4.14.4 et donc avec Xfwm4 comme gestionnaire de fenêtre.
M’enfin quel changement est intervenu depuis la 3.1.0+2309 coté darktable, si je downgrade à cette version je n’ai pas de problème et je n’ai pas plus mutter pour autant.
Je vais essayer dans un autre contexte le temps de monter une VM.
Ubuntu est dérivé de Debian et comme décrit, le gars dont je parle est sur Ubuntu 20.04 avec mutter (comme moi, et je n’ai ni son problème ni le tien). Par contre, je n’utilise pas Xfce. Donc rien à voir avec ça (et à mon avis pas non plus avec mutter comme il le décrit).
Ensuite, la question de ce qui a pu changer dans dt, c’est pas forcément aussi simple que ça, surtout si le problème n’affecte que quelques utilisateurs dans certaines conditions. Il peut y avoir eu un léger changement sur dt et un autre sur un gestionnaire de fenêtre, une librairie, qui ne vont pas ensemble. Et du coup en changeant un paramètre, ça fonctionne de nouveau. Bref, ça peut parfois être complexe comme être très simple, mais pas forcément lié directement à dt (ou pas que). Et là, ça peut être compliqué de trouver l’origine du problème.
Enfin, 2 choses :
- peux-tu préciser le numéro de commit plutôt que le nombre de commits (2309, 2336 c’est le nombre de commits depuis la 3.0.0 ici) ? Faire le calcul pour savoir sur quel commit tu es, c’est chiant. Le commit est affiché juste après: gxxxxxxxxx.
Avec ça, tu peux aller voir Github les commits entre les 2 et même tester avec les commits intermédiaires (via git bisect) pour trouver lequel aurait pu introduire le problème (s’il y a vraiment lieu) voir même quelle partie du code peut être concernée.
- Pour ce dernier point du coup, je te recommande de préciser sur ton issue Github que ça fonctionne bien de ton côté avec la 2309 (ou plutôt en précisant le commit) et être aidé si besoin pour faire les tests avec git bisect. Je ne suis pas le meilleur pour git bisect, je l’ai utilisé qu’une fois et en étant guidé sur une issue qui a permis de trouver l’origine du problème (ça n’est pas une option systématique pour trouver l’origine d’un bug évidemment mais parfois ça aide).
- peux-tu préciser le numéro de commit plutôt que le nombre de commits (2309, 2336 c’est le nombre de commits depuis la 3.0.0 ici) ? Faire le calcul pour savoir sur quel commit tu es, c’est chiant. Le commit est affiché juste après: gxxxxxxxxx.
Comme je travaille maintenant uniquement avec la master je garde en général le paquet d’installation après compilation, au cas où afin de pouvoir downgrader.
Le n° y est inscrit.
J’ai un peu d’écart entre la dernière fonctionnant bien et la première qui plante .
Je vais essayer de voir les commits passés depuis.
Je vais me renseigner pour git bisect… je ne connais pas.
Arhhhhhh.
Je garde aussi de temps à autre une copie de mon ~/.config/darktable/ en revenant à une version antérieure tout fonctionne bien.
Actuellement avec la 3.1.0+2340~gcfb884133
Mon problème était donc local… rien à voir avec un bug de dt.
L’essentiel est que tu ais trouvé, ça me semblait étrange aussi que ça vienne de darktable vu les évolutions récentes. Bizarrement, je pense souvent à conseiller aux gens de tester sans le dossier config/darktable… mais là…
Pour info, le commit se trouve dans le « A propos » de darktable (pas besoin du paquet). Tu cliques sur le logo en droite de darktable pour afficher ce « A propos ».
Constatant qu’il n’y avait pas eu grand chose entre la dernière qui fonctionnait et celle qui plantait et qu’en plus les commits n’avaient rien à voir de près ou de loin avec mon dysfonctionnement j’ai investigué de mon coté en commençant par renommer mon config/darktable.
M’enfin je ne suis pas malin j’aurais pu y penser aussi plus tôt.
Ok pour le « A propos », mais là du coup je les avais tous sous l’œil d’un seul coup.
Merci pour ton aide, toujours bien venue.