Compilation sous Linux Mint en échec

Je vois 3 choses à essayer :

  1. Vérifier que dans ~/.config/il y a bien 2 dossiers distincts ART car là tu as 2 versions d’ART sur ton ordinateur, si ils utilisent les même dossier config ça peut poser problème
  2. Effacer tout dossier ART dans ~/.cache
  3. Si tu confirmes que les fichiers .xml de lensfun dans /usr/share/lensfun/version_1 sont bien anciens et ne contiennent pas ton APN, tu peux directement copier l’intégralité des fichiers .xml du dossier lensfun de ART-1.24.5 dans /usr/share/lensfun/version_1 , ça fera une mise à jour manuelle de la base de données lensfun.
1 « J'aime »

Merci pour le nouvel éclairage, et désolé d’avance pour les aléas que je rencontre à chaque étape… car c’est encore le cas !

Je n’ai a priori pas de dossier “art” ni dans “config” ni dans “cache”, d’après le gestionnaire de fichiers (Nemo) :

Pour la forme, vu les versions différentes que j’avais noté entre celles de mon système et celles indiquées par @alain_gre pour les paquets, j’ai relancé des sudo comme suit :


et cela me dit que c’est la version la plus récente, 0.3.2-6 alors que c’est 0.3.4-1 pour @alain_gre !

j’ai continué pour la forme toujours avec quelques autres paquets :
sudo-lib*_update_250917
et tout est bien à jour selon le système :

Au cas où : j’utilise l’université de Nantes pour je-ne-sais-plus-quoi (rires) !

Enfin, comme le gestionnaire de fichiers ne me permet pas de changer les fichiers entre les deux dossiers “lensfun”, je suis passé par des terminaux pour voir…

  • j’ai ouvert un terminal dans le dossier d’ART 1.24.5 pour copier ne serait-ce qu’un fichier vers l’autre dossier dans lequel ART compilé vient chercher les données…

    …et même résultat : je ne peux même pas passer les fichiers d’un dossier à l’autre pour faire la mise-à-jour manuelle ! Je ne peux même pas créer un dossier “test” non plus.

Bref, je suis bloqué, pour la version compilée - toujours, de sorte que je doive me rabattre sur l’autre en attendant.

Tout ce qui n’est pas dans ton dossier “home” doit être accédé avec les privilèges Root grâce à la commande “sudo”. Donc pour copier des choses vers “/usr/share” tu dois taper “sudo cp…”.

Ensuite, les dossiers “/.cache” et “/.config” sont des dossiers cachés (c’est le rôle du ".” devant le nom), normal que tu ne les voies pas ton navigateur de fichiers, sauf si tu actives l’option “afficher les fichiers et dossiers cachés”.

1 « J'aime »

Merci @sguyader pour le message ci-dessus à m’accompagner donc plus sur Linux que sur ART !

Pour revenir aux 3 choses listées

  1. malheureusement, il n’y a bien qu’un dossier “ART” dans ~/.config, comme le montre le gestionnaire de fichiers (en ayant pris soin de montrer les fichiers cachés :slight_smile: )


    (ou même en allant vérifier dans ce dossier s’il y a éventuellement 2 dossiers “ART”)
    Mais si je ne me trompe pas, Carafife disait bien dans un de ses tutos que plusieurs versions de ART pouvaient coexister sur notre ordinateur, donc - à part gros écart de configuration, je ne vois pas en quoi je ne pourrais pas avoir la version compilée d’un côté et une autre, téléchargée en zip et lancée dans un terminal par ./ART de l’autre.

  2. j’ai bien supprimé le dossier “ART” qu’il y avait dans ~/.cache
    Cela dit, dès qu’on lance ART, un tel dossier est recréé.

  3. j’ai bien réussi (désolé encore pour mes lacunes en commandes Linux) à remplacer les fichiers “lensfun” dans le dossier dans lequel semble aller ART compilé ~/usr/share/lensfun/version_1 par ceux qui sont opérationnels pour ART 1.24.5 dans ~/Programmes/ART-1.24.5-linux64/share/lensfun
    Pour être sûr, en plus d’avoir remplacé les fichiers sous ~/usr/share/lensfun/version_1 ,j 'ai même mis juste mes fichiers “pentax” sous ~/usr/share/lensfun/

Puis j’ai redémarré l’ordinateur, mais rien n’y fait : toujours pas de détection de mon APN dans ART compilé.

Nota : l’opération de remplacement des fichiers me pose également question pour une autre raison
=> la date de création du fichier ne suit pas : c’est celle du jour qui apparaît, de ce fait, pas simple de s’y retrouver plus tard, puisqu’on parle exactement des mêmes fichiers (28/12/2024), juste copiés d’un endroit à un autre, mais qui prennent une autre date (17/09/2025).

Double snif !

Oui on peut avoir 2 installations d’ART, mais à mon avis il vaut mieux que chaque installation ait son propre dossier .config pour éviter les soucis. Quand je compile ART je précise dans le script “build-art” de créer le suffixe “-dev” de sorte que dans les dossiers .config et .cache la version compilée créera les dossiers “ART-dev” que lui seul utilisera même si j’installe un autre ART.

Pour le dossier .cache qui se recrée c’est normal. Au moins tu es parti d’un cache propre.

Concernant le dossier .config, à l’intérieur tu dois trouver un fichier nommé “options”. Renomme-le en “option.bak” et relance ART compilé. Ça va recréer un nouveau fichier “options” tout propre, et dis moi ce que ça donne.

1 « J'aime »

J’ai l’impression que mes déboires sont plus liés à ma config Linux qu’à ART, et j’aimerais bientôt pouvoir plutôt publier des sujets plus liés au coeur même de ce forum : la photo, plutôt que de remonter des problèmes autres rencontrés

“Ma Linux Mint 21.2 Cinnamon 5.8.4 est à jour à ceci près “ ….

que tu n’es pas encore passé à la dernière version de Mint !

Bonsoir

A l’identique de windows (mais pas toujours) les passages entre versions (mineures ou majeures) peuvent être plus ou moins délicats (parfois à cause du matériel) mais désormais il rarement nécessaire de réinstaller tout son système.

Si linux mint facile le passage entre version (voir écran il suffit d’accepter et de patienter ) c’est aussi pour cela qu’on la conseille à des utilisateurs qui ne veulent pas trop se poser de questions -

Cela dit c’est sans aucune certitute que le passage de version puisse arranger ton problème.

Mais justement et - même avec du recul - j’aurais certainement déjà “laché l’affaire” depuis bien longtemps, , sauvegardé mes fichiers persos sur un support externe et fait table rase par une nouvelle installation de la dernière version de mint (cinamon de préférence).

Cela peut choquer mais il faut parfois être pragmatique - 15 minutes d’installation (guidée) + 15 minutes de fnalisation par remise en place de ses logiciels préférés valent toujours mieux que des heures à essayer comprendre pourquoi, dans ma situation, ce qui devrait fonctionner, ne fonctionne toujours pas.

Même si l’on aime l’informatique le but premier c’est de passer plus de temps à utiliser ART et faire de la photo qu’à “bricoler” sur son PC :slight_smile:, C’est mon avis personnel

1 « J'aime »

Ou alors passer à une distribution en “rolling release” comme ma Manjaro, et ne plus jamais avoir à se soucier de grosses mises à jour de Linux :wink:

1 « J'aime »

Bonjour,

@sguyader : OUI ! tu as trouvé ! Trop bien.

image

=> effectivement, le simple renommage en options.bak fait en sorte qu’un nouveau fichier options se crée et permet de retrouver mon APN.

De ce fait, on peut considérer que ce sont les doubles actions suivantes qui permettent la résolution :

  • remplacer les fichiers lensfun
  • forcer ART à générer un nouveau fichier options

Merci beaucoup pour ton aide aux petits oignons.

Cela dit, c’est un mystère pour moi :

  • pourquoi les fichiers lensfun issus de la compilation ne sont pas les bons
  • pourquoi la demande de mise-à-jour sudo apt install liblensfun* ne fonctionne pas non plus
  • et surtout : comment savoir s’il n’y a pas autre chose de ce type qui serait à découvrir encore entre ma version compilée et la version 1.24.5 lancée via son dossier de téléchargement ?

@alain_gre, cela m’a fait rire et plaisir que tu écrives que tu aurais “lâché l’affaire depuis bien longtemps” : j’étais en effet prêt à aller dans ce sens, mais d’un autre côté j’ai appris beaucoup grâce à nos échanges, que ce soit sur Linux ou ART, et sans cette déconvenue je n’aurais pas appris autant et serais resté ignare des quelques manips et autres compréhensions qu’il y a derrière. Donc, oui, c’est du temps passé, mais de mon point de vue, même s’il n’a pas été des plus efficaces, il a créé une valeur ajoutée.

@sguyader & @alain_gre je suis prêt à refaire d’autres essais, justement, histoire de comprendre un peu mieux, parmi :

  1. recompilation de ART, avec ajout de suffixe comme indiqué adroitement par @sguyader
    => c’est bien au début du script, qu’il faut faire cet ajout ?

    changer prog="art" et exe="ART" par prog="art-suffixe" et exe="ART-suffixe" ?

Pour recompiler, y-a-t-il quelque chose à faire de particulier, comme une désinstallation comme sous windows, ou bien je peux tout simplement supprimer le dossier programs créé pour ce faire ?

  1. mise-à-jour de ma distri Mint

Pour les besoins d’un “plan d’expérience” pouvant être également utile à d’autres, j’hésite juste dans l’ordre, à savoir :

  • faire 1) (dans ma config de distri actuelle donc) et voir si ça marche, et 2) serait juste un bonus encore derrière
  • faire 2) direct, ce qui revient à devoir recompiler ART dans tous les cas, c’est bien cela ?

Rem : les commandes sous Manjaro sont bien les mêmes que sous Mint ?
(dans le tuto de compilation de Carafife, il précise par exemple que Mint, Arch, Fedora n’ont pas les mêmes commandes). Cela dit, vu les justes quelques rudiments que je connais, s’il faut en apprendre directement d’autres, cela me changera peu (rires)

Ca fait beaucoup de question !

La c’est une question de distribution et/ou de version de distribution Linux je pense. Pour quoi ta version avait elle encore une vieille version de la base lensfun malgré une mise à jour, je ne sais pas, mais comme l’a pointé @alain_gre il semble que ta version de Linux Mint ne soit pas la toute dernière. Entre le fait que Mint ne soit pas à la version actuelle, et que tu utilises sans doute les entrepôts “stables” pour les paquets, ça peut conduire à avoir des versions de logiciels un peu dépassées. Et autre question que je me pose, c’est pourquoi ton installation Linux et Lensfun ne dispose pas du script “lensfun-update-data”.

Non, il faut aller au bloc de commandes “cmake” plus bas dans le script build-art et ajouter la ligne : -DCACHE_NAME_SUFFIX=“-dev” \ (par exemple en ligne 155 après la commande -DCMAKE_BUILD_TYPE=“$buildType” \).

Je ne sais plus quel mécanisme utilise le script build-art, mais il est possible que par défaut s’il ne détecte aucun changement il peut te répondre que ton ART installé est déjà à la dernière version. Dans ce cas pour forcer la recompilation tu peux en effet supprimer le dossier dans lequel ART compilé a été installé.

Je ne peux pas répondre à cela, un “pro” de Linux Mint pourra te dire si la mise à jour de Linux Mint supprime l’installation d’ ART. Je suppose que non, car ART compilé est installé dans le dossier utilisateur ($HOME) qui ne devrait pas être touché par une mise à jour de Linux Mint.

Je ne sais pas de quelles commandes il parle. Les commandes de base de Linux restent les mêmes pour toutes les distributions, par contre pour la gestion et l’installation de paquets de logiciels en effet chaque grand type de distribution utilise son propre système. Par exemple là où on utilise “apt-get install" pour les distributions basées sur Debian/Ubuntu, on utilise “pacman -S" pour les distributions basées sur Arch telles que Manjaro. Mais il y a aussi un gestionnaire graphique de logiciels/paquets (par défaut c’est Pamac pour Manjaro) qui permet de faire l’essentiel des installations et mises à jour sans taper de lignes de commande.

1 « J'aime »

Bonsoir - si tu veux comprendre ce qui se passe derrière cet état de fait ou comment fonctionne une distribution linux c’est tout à “ton honneur”

Je suis passeé du côté du “monde libre” au début des années 2000, déjà par l’usage de logiciels libres (alors que beaucoup d’utilisateurs de windows utilisaient des logiciels commerciaux en versions piratée ou craquée) puis je suis passé sur un système d’exploitation libre (linux) déja en version live-cd (avec Knoppix, une dérivée débian) puis ubuntu lorsque celle-ci à rendu l’installation et l’administration d’une distribution debian bien plus facile : une blague de linuxien étant de dire qu”ubuntu signifie en langage bantou “je ne suis pas arrivé à configurer ma debian”

Plaisanterie mise à part Ubuntu ou debian ne sont pas les seules distributions accessibles au grand public : fedora (folk de red hat) ou Open-suse existent toujours- mais Maegia (*) qui avait succèdée à Mandrake linux à disparue, Celle qui m’a appris le plus c’est encore Archlinux du temps ou l’on devait l’installer en ligne de commande et qui reste ma distribution préférée même si je préfère me simplifier la vie avec une distribution dérivée d’arch linux qui n’est pas Manjaro mais Endeavours. Et je ne parle que de linux pas de BSD et d’autres systèmes exotiques “non linux”
Si je fais ce long détour c’est pour expliquer deux ou trois choses qu’il faut savoir :

linux est né du rêve et de l’intelligence d’un étudiant “fauché” qui à construit un noyaux (kernel) sous licence libre autour duquel des applications ont été developpées par une communauté pour constituer un système d’exploitation : Gnu Linux.

Ce que l’on sait moins c’est que système linux est orienté réseau - autrement dit ce qui alimente et “maintient en vie” ta distribution ce sont des dépôts logiciels, duppliqués en mirroirs, régulièrement mis à jour, dans lesquels ton systeme va pouvoir trouver et mettre à jours ses composants sous forme de paquets. Je simplifie et reste dans l’essentiel.

L’action sudo apt-get install .. est donc la commande par laquel l’ utilisateur (qui dispose des pouvoirs d’administrateur) va demander à recevoir un paquets logiciel par l’intermédiaire d’une source (distante ou locale) : un dépot, et l’installer non sans avoir vérifié son origine (signature) et son intégrité (somme de contrôle pour vérifier que ce paquet n’a pas été modifié. Sauf que si ce paquet n’est pas dans les dépôts officiels de la distribution (sous le même nom que celui demandé) il ne trouvera pas. Voila c’est tout bête ! et je peux te confirmer que les dépôts officiels de mint ( voir les paramêtres dans le gestionnaire de paquet) ne comportent pas de paquet liblensfun ou un nom approchant (l’astérisque étant un moyen de demander les paquets dont le nom commence par liblensfun

Ce qui “énerve” des habitués de Windows c’est qu’il n’y pas un seul “dépôt universel” pour toutes les distributions linux et que l’ajout de dépôts n’est pas une opération anodine (la sécurité est la grande force des systèmes linux mais on peut la compromettre par l’ajout de paquet logiciels provenant de dépôt tiers - ce pourquoi il faut être prudent et savoir à qui l’on peut faire confiance ou pas.

Le principe consistant à récupérer les sources d’un logiciel pour le compiler est différent et peut être difficile si la compilation nécessite des dépendances qui ne sont pas satisfaites. Ce pourquoi ce mode d’installation ne se passe pas de la même manière selon le système (linux) ou même la version de son système. Ce qui peut énerver également mais qui à déjà compilé les sources d’un logiciel sous windows ? ( si si c’est possible)

Un long discours également pour rappeler que si l’on choisi un système parmis d’autres ce n’est pas pour des critères d’esthétique de l’environnement de bureau mais pour la richesse de ses dépôts, pour la communauté qui la maintien ( elle doit être sûre et perenne) et l’aide qu’on peut trouver auprès d’elle lorsqu’on en à besoin. Mais je te laisse les critères d’un vrais spécialiste :

(*) Réssusitée avec avec Open Mandriva (en rollin release) mais avec un suivi de mise à jour qui laisse à désirer.

4 « J'aime »

Compilation sous debian sid réussie sans problème avec cette méthode. Merci @alain_gre

Ce sujet a été automatiquement fermé après 29 jours. Aucune réponse n’est permise dorénavant.