Forum

Reprise du message précédent

Jybz :

Nous fais-tu une spec RPM Holly76 ?
On peut t'aider ! Rejoins-nous sur le salon matrix MLO !

Etant juste un autodidacte je ne suis pas assez initié pour pondre un RPM. Tout au plus je peux partager la méthode utilisée pour installer un DT opérationnel à partir des sources.

Bonjour Holly,
Je t'invite à découvrir mock ou iurt (j'ai une préférence pour mock).
Ceci te permet de construire des paquets à partir de la description spec (ce dont jybz te parles), surtout pour les applications qui ont déjà été packagée.
Il se peut que ce soit aussi simple que :
- éditer le fichier de spec pour changer le numéro de version
- exécuter bm -ls pour construire le paquet source qui télécharge au besoin l'archive des sources (si le spec est bien fait, à jour et si l'option de téléchargement est configurée)
- lancer mock pour construire les paquets rpm prévus
- récupérer les paquets et les installer.

Cette méthode à l'avantage de ne pas "polluer" ton système avec tous les outils nécessaires à la construction.

holly76 :

Jybz :

Nous fais-tu une spec RPM Holly76 ?
On peut t'aider ! Rejoins-nous sur le salon matrix MLO !

Etant juste un autodidacte je ne suis pas assez initié pour pondre un RPM. Tout au plus je peux partager la méthode utilisée pour installer un DT opérationnel à partir des sources.

Je ne connais aucune école pour le RPM. Nous sommes tous plus ou moins autodidacte.

Mais j'ai plein d'argument pour motiver à apprendre à faire des RPM

OK, je vais regarder ça (pas gagné).
Bon, il me faut un peu de temps, je prépare aussi l'AG de mon asso de généalogie dont je suis président.

holly76 :

OK, je vais regarder ça (pas gagné).
Bon, il me faut un peu de temps, je prépare aussi l'AG de mon asso de généalogie dont je suis président.

Quand tu peux (et moi aussi), on se prend une heure et je te forme aux bases pour le RPM.

Jybz :

holly76 :

OK, je vais regarder ça (pas gagné).
Bon, il me faut un peu de temps, je prépare aussi l'AG de mon asso de généalogie dont je suis président.

Quand tu peux (et moi aussi), on se prend une heure et je te forme aux bases pour le RPM.

OK, merci. Je me documente dès que j'ai un peu de temps pour me faire une idée, ça fera gagner un peu de temps.

holly76 :

Jybz :

holly76 :

OK, je vais regarder ça (pas gagné).
Bon, il me faut un peu de temps, je prépare aussi l'AG de mon asso de généalogie dont je suis président.

Quand tu peux (et moi aussi), on se prend une heure et je te forme aux bases pour le RPM.

OK, merci. Je me documente dès que j'ai un peu de temps pour me faire une idée, ça fera gagner un peu de temps.

L'idée était de proposer ce début de documentation, permettant d'aller chercher seul les informations les plus poussé.

Grosso-modo, le fichier .spec c'est des variables et du bash dans différentes sections (préparer, compiler, installer) puis se finissant par un listing des fichier à embarquer dans le rpm. Généralement il suffit d'incrémenter la variable version pour proposer un nouveau rpm.

Pour la gestion des dépendances, il y en a nécessaire lors de la compilation (par exemple le compilateur) et d'autre nécessaire à l'utilisations (les bibliothèques graphique comme Qt), on les ajoutes dans la .spec avec buildrequire: gcc et requires: qt.

Lors de la construction, tu peux retrouver les fameuses "undefined _BLABLABLA_", tout comme lorsqu'on fait une compilation manuel. C'est qu'il manque un buildRequire.

Avec de la chance, les section %prep de contient qu'une ligne pour décompresser le tar.gz, la section %build ne contiens qu'une ligne pour compiler (make) et la section %install qu'une aussi pour inslaller (make install).

Voilà seulement qu'on a des règles particulières, par exemple on installe rien dans /usr/local, c'est parfois par défaut avec make. Il y a un jeu de variable d'environnement. Donc on a remplacer la commande make par la macro %make et %make_install (ça manque d'originalité mais c'est bien mieux comme ça), et pour cmake ? %cmake…

Tu peux définir ou réécrire tes propres macros dans ~/.rpmmacros, et les inspecter avec les commandes:
rpm --eval %make_install
rpm --showrc
C'est aussi dans ce .rpmmacros qui te permettra de redéfinir le nom du rpm et éviter de nommer mga9 ces paquets ne venant pas de mga

Il ne manque plus que :
sudo urpmi rpm-build
sudo urpmi --build-requires /home/holly76/rpmbuild/SPECS/dt.spec
bm -ba ~/rpmbuild/SPECS/dt.spec

J'espère avoir été aussi bref et clair que possible

Vu, merci

Bonjour,
Meilleurs vœux à toutes et tous
Vu qu'il n’y a pas de darktable 4.8.1 et 5 comment faire pour avoir la 5 en AppImage en Français, cela est-il possible ? sinon je suis obligé d'aller sur windows.
J'en suis à la 4.6.1 sur ma ma Mageia9.
A+

En l'installant en flatpak avec discover sous KDE ?
En demandant la mise à jour dans bugzilla ?

Bonjour
En l'installant en flatpak avec discover sous KDE ? >>>c'est bon c'est fait

En demandant la mise à jour dans bugzilla ? Désolé je ne sais pas m'en servir
Merci

Bonjour,
La période difficile en terme de dispo est bientôt derrière moi, je vais bientôt m'attaquer à faire le rpm.

Bon on est maintenant à la version 5, ce sera donc ma base de travail.
En attendant, cette fin d'année a été pour moi l'occasion d'avoir un nouveau boitier Lumix G9II et pas reconnu de façon standard avec DT, aussi voici la méthode pour que ça fonctionne (valable aussi pour Canon):

Installer libraw20 version 0.20.2 pour architecture i586 même si on est en x86_64
Editer le fichier darktablerc (dans .config/darktable)
Aller à la ligne libraw_extensions=
Ajouter cr3,rw2

Testé sur la version de développement 5.1.0+37~g1108e69877 et 4.8.1