Bonsoir à {toutes,tous}

Après avoir pu récupérer les sources de la suite « Setup » à mon domicile, j'ai entrepris d'utiliser le-dit logiciel en m'appuyant sur la documentation nouvellement retapée (si j'ai bien suivi). J'ai rencontré quelques soucis, que je m'empresse de faire remonter ici… En effet il n'y a pas de stand de discussion associé a la doc (à l'image de l'onglet « discussion » sur la célèbre wikipédia #MYTODO : faire une demande sur le bugtracker), je me permet donc de squatter le forum.

Ça se passe donc par ici : wiki-test-setup.fr.html

Compilation

je ne vois pas l'intérêt de ces deux lignes :

1
2

mkdir build
cd build

puisque

1

cmake .. -DCMAKE_INSTALL_PREFIX=/usr

ensuite, crée le Makefile à la racine du projet… Et on n'indique pas à l'utilisateur de descendre d'un niveau avant de faire tous les « make [TARGET] ».

Ça porte à confusion du coup, de ne pas avoir de « ./configure » pour gérer la destination de l'installation avec « --prefix=path ». Je ne connais pas du tout CMake, pourrais-tu me dire (sans que je remette ce choix en question) ce qui a motivé son adoption vis à vis des GNU Autotools ? (Notamment au sujet de la cross-compilation si tu sais)

Tu as surement prévu d'y revenir, le README mentionne encore le nom « Setup ». Il manque néanmoins les fichiers suivants (si tu veux suivre la p'tite convention GNU)

• INSTALL
• ChangeLog
• NEWS
• AUTHOR

Personnellement le « INSTALL » m'aurait été utile parce que j'ai du installer les dépendances suivantes :

• lib-archive-dev
• gpgme-dev
• libelfutils-dev

'Fin bref' l'output de CMake aide =)

Configurer LPM

Je me suis permis de simplifier les lignes successives de « mkdir » par deux « mkdir -p », l'option « p » pour « parent » créant les répertoires parents si ceux ci n'existent pas.

Je me suis aussi permis d'ajouter un commentaire, ne comprenant pas à quoi servait le fichier « weight.qs » ... Après lecture du fichier j'ai capté.

Ensuite :

1

mv /tmp/lpm/etc/lgrpkg/sources.list{.sample,}  # Renomme sources.list.sample en sources.list

Cette commande ne marche pas, il manque un espace ? C'est ça que tu voulais faire ?

1

cp /etc/lgrpkg/sources.list.sample /tmp/lpm/sources.list

Enfin seules les 3 premières étapes de l'update fonctionnent, avant un seqfault (signatures à False dans le sources.list) dont on a déjà parlé la dernière fois que j'ai tenté le coup. Tu as besoin de main d'oeuvre pour mettre à jour les paquets ? Le lpm sur git est-il synchrone avec ce que tu aschez toi en local ?

Ce n'est pas dramatique que cette doc ne soit pas entièrement accessible au néophyte, mais c'est dommage que les cmd n'aient pas été vérifiées (les gens pressés survolent les phrases et copient/collent tout ce qui bouge). De mon côté j'ose pas vraiment intervenir sur le document, parce que tu connais mieux ton logiciel que moi ;)

C'était Jokester en direct de son clavier Bépo relou

Bonjour,

Retour intéressant .

Tout d'abord, l'absence de page de discussion sur le wiki est volontaire, au presque. En rajouter serait possible, mais ça éclaterait encore un peu plus le forum et les commentaires. Quoique, c'est possible, je verrai si j'ai le temps d'y réfléchir .

Tester Setup est assez difficile pour le moment, du fait que le dépôt n'est pas du tout à jour. Si tu as un segfault, relance la commande dans gdb "gdb --args ./lpm ...", attend que ça segfault, puis tape "bt" et colle sa sortie ici ou dans un bug report. Si ça marche sous GDB, alors c'est que c'est un problème de mémoire. Installe Valgrind et lance "valgrind --tools=memcheck ./lpm ...".

Toutes les commandes se trouvant sur cette page ont été testées, elles marchent toutes. Vérifie que tu utilises la dernière version de Bash. La commande avec les accolades déplace un fichier vers un autre. En effet, bash change "a{b,c}" en "ab ac", et "a{b,}" en "ab a", ce qui permet ici de se séparer du .sample. Si tu as une erreur comme quoi le fichier n'existe pas, alors vérifie que tu l'as bien copié quand c'était demandé (quoiqu'un bug dans le système d'installation est aussi possible).

Pour CMake, c'est une simple question qu'il est plus ou moins fait pour Qt, alors que les Autotools l'aiment moins. De plus, les autotools sont d'une complexité atroce et sont petit à petit abandonnés (de plus en plus de projets passent à CMake, comme KDE, XMoto, SuperTux, etc). Setup a un système de build assez complexe, avec des dépendances spéciales, des opérations lancées durant la compilation, et l'utilisation de Qt. CMake était le seul choix envisageable (si on exclu QMake, qui était d'ailleurs utilisé à une époque).

Les lignes créeant un dossier build et allant dedans permettent justement de séparer les fichiers compilés des sources, ce qui permet de facilement supprimer ce dossier, de le recréer, pour nettoyer tout ce que CMake a créé. C'est bien plus propre et conseillé.

Pour installer dans un dossier : cmake -DCMAKE_INSTALL_PREFIX=/usr. Malheureusement, Setup ignore cette option, mais plus pour longtemps.

Ah, pour finir (désolé, je répond dans le désordre), les dépendances sont mentionnées sur le wiki, c'est plus facile à mettre à jour. S'il en manque, je t'encourage à les ajouter . Simplement, pas de nom de paquets Debian sur ce wiki, seulement du générique (libgpgme-dev ==> fichiers de développement de GPGME, libelfutils-dev ==> Paquet fournissant elf.h (ELF-utils ou LibElf)).

Merci d'avoir testé en tous cas .

Salut ! Je suis de retour pour continuer mon retour d'expériences.

Le souci du répertoire BUILD

Je comprend très bien le principe, et j'y adhère pleinement. Lors de mon premier test seulement, j'avais obtenu un ./build vide, et l'ensemble des fichiers Makefile étaient bien générés, mais pas de le répertoire build. D'où la teneur critique de mon message !

Après avoir fait un "git pull" pour mettre à jour ma version locale de Setup, j'ai procédé à un nouveau test, et cette fois-ci je constate que le ./build est bien peuplé... Peu importe pourquoi, ce ce petit souci n'en est plus un.

Version de bash incompatible

La distribution de mon laptop est maintenant à jour (mais je vous passe de commentaires polémiques sur ladite distribution, dès que Maegia fournit une release j'y passe ), et voici ma version de bash :

1
2

$ /bin/sh --version
GNU bash, version 4.1.5(2)-release (i586-mandriva-linux-gnu)

et effectivement les instructions du type :

1

$ mkdir ~/{Musique,Photos}

sont bien interprétées.

Note toutefois que cette commande ne fonctionne pas :

1

mv /tmp/lpm/etc/lgrpkg/sources.list{.sample,}  # Renomme sources.list.sample en sources.list

pour la bonne raison qu'il n'y a pas de sources.list.sample dans /tmp/lpm/etc à ce stade En revanche il est présent dans /etc/lgrpkg

D'ailleurs pourquoi utiliser le nom "lgrpkg" ? Et non pas "lpm", "lpmpkg" ou "lpm-package" ? (je suis un peu chiant sur les détails, pardonne moi :p)

Segfault

Impossible d'obtenir de nouveau le segfault, le update fonctionne, mais pas cool pour toi si tu as résolu le souci de robustesse sans le savoir :/

Les signatures de paquets ne sont pas encore présentes sur le serveur de Logram d'après ce que j'ai pu constater, j'ai donc désactivé l'option dans le sources.list. Ok.

En revanche j'ai le problème suivant lors de l'install :

1
2
3
4
5
6
7

$ sudo lpm -I 1 -D 1 -R /tmp/lpm add initng-plugins
Installation des paquets...
[1/6] Téléchargement de initng-plugins
[1/6] Installation de initng-plugins~0.6.90~2
[2/6] Téléchargement de libinitng0
[3/6] Téléchargement de libc6
ERREUR : Impossible d'ouvrir le fichier /tmp/lpm/var/cache/lgrpkg/db/pkgs/initng-plugins~0.6.90~2.xml            ]    2.81 Kio 351.56 Kio/s

En fait le dossier /tmp/lpm/var/cache/lgrpkg/db/pkgs semble avoir été renommé en "packages".

Je note aussi que l'ordre des opérations est assez aléatoire pour le mode "parallèle" (c'est à dire quand -I et -D sont pas à 1)

1
2
3
4

[1/6] Téléchargement de initng-plugins
[2/6] Téléchargement de libinitng0              
[1/6] Installation de libinitng0~0.6.90~2                
[3/6] Téléchargement de libc6

Mais j'ose imaginer que c'est le genre de choses pas simple à fixer !

Et pour finir

Si KDE utilise CMake, effectivement, ça justifie que Logram tende à suivre l'exemple.

Je vais maintenant me pencher un peu plus sur le code source de Setup, dans tous les cas merci pour ton excellent travail =)

Jk.

Bonjour,

L'ordre des opérations est parfaitement normal . C'est le principe des choses en parallèle : on commence à installer un paquet dès qu'il est arrivé (et qu'il reste de la place dans la file d'attente, dont tu ne fais que définir la taille avec -I). C'est normal que les communications s'emmêlent un petit peu. En mode graphique, avec Pkgui, tout va très bien.

Cez moi, /setup/var/cache/lgrpkg/db/pkgs existe bien. C'est comme cela que doit s'appeler le dossier. J'espère que la page de wiki n'est pas fausse. Ce dossier contient des informations sur les paquets déjà installés, dont leurs métadonnées. Si tu as une fois installé init-ng, et que tu as supprime le dossier pkgs, LPM continuera d'essayer d'aller y chercher des métadonnées. Si tu as effacé le dossier pkgs, supprime /tmp/lpm/var/cache/lgrpkg/installed_packages.list et re-lance lpm update.

Pour le lgrpkg, c'est pour "Logram Package". Le principe de ce nom était d'éviter, du temps de Setup, d'appeler ce dossier setup, sachant déjà à cette époque que d'autres outils y accéderaient. D'ailleurs, tu peux constater l'existence de /usr/lib/liblgrpkg.so, ainsi que /usr/bin/lgrpkg. Tous ces noms vont ensemble .

Le répertoire build contient les Makefiles. En fait, quand tu as récupéré les sources, du crées build, tu vas dans build, et tu lances "cmake ..". Cette commande lit ../CMakeFile.txt et génère des fichiers, ici donc dans build. Ainsi, tu ne pollues pas tes sources de Makefiles, CMakeFiles.dir et fichiers objets (CMake a comme petit défaut de générer plein de fichiers). De plus, pour repartir de zéro et tout recompiler, il te suffit d'effacer build.

Il se peut que le segfault était produit par une version trop vieille d'un de tes outils ou bibliothèque. Ça peut arriver.

A plus.

Cette page du wiki ne contient rien qui se rapporte au /tmp/lpm/var/cache/lgrpkg/db/pkgs. Effectivement mon « lpm add » fonctionne après un :

1
2

$ mkdir /tmp/lpm/var/cache/lgrpkg/db/pkgs
$ wget -o /tmp/lpm/var/cache/lgrpkg/db/pkgs http://archive.logram-project.org/pool/i/initng-plugins/initng-plugins~0.6.90~2.i686.lpk

J'ai bêtement suivi la doc, et n'ai pas ajouté ni supprimé de paquets avant de constater cela. Le update n'a relevé aucune erreur.

Ciao

Le mkdir devrait suffire, il me semble qu'il est dans la doc, sauf si une édition l'a supprimé par erreur.

En effet, LPM n'accède à ce fichier qu'en écriture. Il essayait en fait de le télécharger. Le dossier n'existant pas, une erreur était levée.

Je viens d'éditer la doc, c'est dedans maintenant.