Primtux6

[mothsart]

Je parcours ton script (que j'ai pour l'instant consommé à l'aveugle et qui a toujours bien marché ) https://framagit.org/philippe-dpt35/prim...x4-rpi4.sh
et envisager la Primtux6.

Le but n'est bien sur pas de faire doublon mais de pouvoir te seconder et mutualiser nos efforts si besoin.

J'ai pour le coup plusieurs questions et remarques. (pas des critiques : la review de code et le paire programming est selon moi le meilleur moyen de faire des softs matures car la relecture et l'expertise de chacun permet de faire avancer le projet)

1. Ligne 14, tu récupères des sources du dépôt de Steph. Est-ce toi ou Steph qui a créé ses archives et quel est le process pour les créer.

2. Tu utilises une variable pour stocker le temps d'exécution du script. En soit, c'est une super idée mais vu que je lance en règle général le script le soir, je me retrouve avec un temps mort car le script s'arrête sur un prompt : "mot de passe de ctparental" et le lendemain mat (voir le soir après le boulot), je me remets dessus.

3. Tu fais des rm de fichiers/dossiers dans tmp alors que après le script tu invites à redémarrer : tmp est vidé à ce moment précis. Du coup, c'est pas des lignes de code parasites ?

4. Ligne 112, tu récupères une archives du dépôt log2ram issus de la branche master.
Or, celle-ci change régulièrement et avoir des bugs potentielles. J'encourage plutôt à partir sur une version définit :
par exemple https://github.com/azlux/log2ram/archive/1.6.0.tar.gz

5. qu'est-ce qui se passe si le md5 n'est pas bon, si github est down (ça c'est produit plusieurs demi-journée cette année) ou si le dépôt n'existe plus ?
Le script passe à la suite ?
La question peut se rapporter à tous les wget.

6. Il manque une icône pour gSpeech que tu rajoutes dans ton script.
Je pense qu'il faudrait sans doute mieux envisager un upgrade de gSpeech pour disposer de ça correctement.

D'ailleurs la version de gSpeech est très vielle. (mais c'est peut-être lié à mon soucis de source.list)

[Philippe Dpt35]

Déjà, sur un plan global, je n'ai pas travaillé la gestion d'erreurs, notamment lors de la récupération de sources externes, car le script, je le rappelle, a été d'abord conçu à usage interne (autrement dit pour moi ou l'équipe) : permettre de construire rapidement une image pour mettre à disposition du grand public.

Mais on peut profiter du travail sur la version 6 pour en faire un outil plus grand public.

Sur les points spécifiques :

pour les sources du dépôt de Steph, il s'agit de deux dossiers, que Steph est obligé de nous proposer à part, tel qu'il l'a fait dans son tuto de construction pour la PrimTux ubuntu. Il me les forunit et je les place sur le serveur de PrimTux. En effet, gitlab ne semble pas permettre de ne télécharger qu'un dossier spécifique, contrairement à github. En tout cas j'ai longuement cherché et pas trouvé !

Pour le temps d'exécution du script, si j'ai bonne mémoire, je l'ai rajouté lors d'un précédent script de construction (sur la 3 je pense) parce que tu l'avais suggéré !
Mais la coupure liée à l'attente d'intervention de l'utilisateur pour CTparental ne devrait plus se produire lors de la prochaine version. En effet il conviendrait de ne plus installer CTparental par défaut car celui--ci s'installe depuis la fenêtre d'accueil. Beaucoup d'écoles n'ont pas besoin de CTparental.

Pour les divers correctifs, tel que l'icône gspeech par exemple, ça correspond à des correctifs faits à un instant T, tels que Steph avait dû les faire lui-même pour la version PC, pour répondre à ce moment-là au problème. Cela a pu être corrigé par la suite lors d'une mise à jour de paquet.

Je prends en compte tes remarques pour travailler sur la version suivante. N'hésite pas si tu as d'autres améliorations à proposer.

[mothsart]

Déjà, sur un plan global, je n'ai pas travaillé la gestion d'erreurs, notamment lors de la récupération de sources externes, car le script, je le rappelle, a été d'abord conçu à usage interne (autrement dit pour moi ou l'équipe) : permettre de construire rapidement une image pour mettre à disposition du grand public.

Mais on peut profiter du travail sur la version 6 pour en faire un outil plus grand public.

En soit, ce qui me dérange c'est plus que si je lance le script aujourd'hui et dans 2 mois, je vais me retrouver avec 2 img avec des md5 diff et il sera juste impossible de savoir ce qui diffère.
Le but du script c'est d'arrivé à une assurance qualité et pas de dire à tous de l'utiliser. Nous on fourni les img clé en main pour le "grand public".
L'avantage d'un script c'est qu'il fasse des tâches ingrates à notre place. L’inconvénient c'est qu'on peut un peu trop se reposer sur lui.

Après, nos dépôts sont publics et donc ça veut dire que n'importe qui peut les scruter. Ça témoigne d'une certaine maturité d'un projet et permettra aussi (je l'espère) de gagner de nouveaux contributeurs.

Comme Rome ne c'est pas construit en 1 an, je sais bien que plein d'étapes intermédiaires sont souvent nécessaires.

pour les sources du dépôt de Steph, il s'agit de deux dossiers...

Ok, je n'arrive plus à mettre la main sur son tuto de construction et je n'arrive pas à déterminé si ces archives sont communes à plusieurs archis ou spécifique à la rpi.

Pour le temps d'exécution du script ...

ah, peut-être, sans doute, lol.
Si l'on installe plus CTParental, ça me va... le script fera son job dans les temps.
Peut-être (mais c'est caviar) différencier les temps de download (propre à la bande passante) et le temps d'installation (qui lui devrait être sensiblement le même si on utilise la même version de la rpi)

Pour gSpeech, la vrai raison de ma question c'est que le paquet installé correspond à une version très ancienne et vu que le paquet est tagué "all" (c'est du python donc pas de compil spécifique), j'ai du mal à comprendre pourquoi la dernière version n'est pas disponible...

[Philippe Dpt35]

Pour gSpeech, la vrai raison de ma question c'est que le paquet installé correspond à une version très ancienne et vu que le paquet est tagué "all" (c'est du python donc pas de compil spécifique), j'ai du mal à comprendre pourquoi la dernière version n'est pas disponible...

Je viens de vérifier et c'est tout simplement parce la dernière version de Gspeech n'a pas été mise dans le dépôt armhf. Il faut demander à Steph de le faire.

[Steph]

Je prends votre discussion en cours là:

1. Ligne 14, tu récupères des sources du dépôt de Steph. Est-ce toi ou Steph qui a créé ses archives et quel est le process pour les créer.

Ce n'est pas un dépôt, mais les répertoires et fichiers qui viennent s'ajouter à la suite de l'installation des paquets .deb, les skel par exemple qui contiennent les environnements.

Ok, je n'arrive plus à mettre la main sur son tuto de construction et je n'arrive pas à déterminé si ces archives sont communes à plusieurs archis ou spécifique à la rpi.

Ben là: https://framagit.org/Steph/primtux6
Mais c'est forcément spécifique à une architecture et même à une version (alors peut-être pas l'archive includes.chroot qui contient des paramètres plus qu'autre chose) parce qu'entre Buster, une 18.04 et une 20.04, des noms de paquets diffèrent, j'ai même du refaire un paquet en i386 non accepté en all par la 18.04 alors qu'il passe très bien sous la 20.04... Même les comportements peuvent différer...

Gspeech c'est en stand-by pour l'instant, le temps d'avoir une version qui fonctionne sous PrimTux.

[Philippe Dpt35]

Les archives de la PrimTux PC utilisées pour le RPi sont les répertoires includes.choot et hooks.

Comme l'indique Steph, le premier ne contient que des paramètres communs aux différentes versions.
Le second des scripts de configuration, lancés dans les lignes 145 à 161 du script pour ceux qui sont communs.

[mothsart]

La raison c'était : si je me base sur la dernière rpi os et que je change le script de Philippe pour utiliser des tar.gz des dossiers "hooks" et chroot" présent ici https://framagit.org/Steph/primtux6/-/tr...386/config, ça suffirait pour marcher ?

Ben là: https://framagit.org/Steph/primtux6

Oui, mais y'a juste des sources, pas le process dans le README (tu avais communiqué un .odt de souvenir)

Gspeech c'est en stand-by pour l'instant, le temps d'avoir une version qui fonctionne sous PrimTux.

J'ai peut-être pas été clair mais j'ai forcé une dépendance dans une nouvelle version (tag git), ce qui devrait régler le soucis.
A toi de me dire si c'est tout bon : j'ai testé sur la rpi (ptx 4 forcément) et une vm en ptx6 et ça à l'air de résoudre le soucis.

[Philippe Dpt35]

La raison c'était : si je me base sur la dernière rpi os et que je change le script de Philippe pour utiliser des tar.gz des dossiers "hooks" et chroot" présent ici https://framagit.org/Steph/primtux6/-/tr...386/config, ça suffirait pour marcher ?

En partie oui, sur tout ce qui concerne les paramètres, mais pas pour ce qui est du contenu qui a varié entre les Ptx4-5 et la PTx6.
Et il y aura forcément quelques adaptations à faire, au cas par cas : paquets manquants pour RaspiOS, configurations spécifiques, etc.

C'était aussi l''idée du script : faciliter le passage d'une version à l'autre.

Je dirais que le plus gros du travail, c'est dans l'identification des paquets à installer ou à éliminer. Pour cela je me suis fait des scripts permettant de comparer les listes de paquets entre distributions. Je compare ainsi la PrimTux Debian à la Rapsbian (raspios) lite et examine au cas par cas ce qui doit être installé ou non.

[Philippe Dpt35]

J'ai commencé le travail de construction de la PrimTux6 pour RPi. J'ai fait à peu près le tour des paquets à installer, de base et en logiciels complémentaires. Il me faudra refaire plusieurs paquets.

Il restera par ailleurs quelques logiciels qui nécessiteront d'être compilés pour armhf par nos soins si nous souhaitons avoir une version RPi pratiquement identique à la version PC.

Ce sont les logiciels suivants :

abuledu-microtexte
abuledu-minitexte
abuledu-puzzle
jclic-reports
leterrier-chronosphere
leterrier-contour
leterrier-mulot

Les logiciels abuledu et leterrier ont leurs sources ici : http://redmine.abuledu.org/projects

openboard-buster
sugarizer
xournalpp --> sources https://github.com/xournalpp/xournalpp

Il faudrait :

• décider si tous ces logiciels valent le coup d'être compilés
  
• faire la compilation des logiciels retenus.
  

Ceux qui veulent donner un coup de main ont là l'occasion de le faire.

[ThierryM]

Adieu Philippe,
Merci pour le boulot.
Personnellement, je ne connais pas tous les logiciels dont tu parles ci-dessus.
Openboard et Xournalpp me semblent important pour les enseignant⋅e⋅s avec un TBI (mais je n'ai jamais testé avec un Rpi).
Sugarizer est une interface à lui tout seul.
Je veux bien aider à la compilation mais en étant guidé .

[Philippe Dpt35]

Tu peux tenter xournalpp, le process est assez bien détaillé :
https://github.com/xournalpp/xournalpp/b...uxBuild.md
à faire sur Raspberry Pi OS en suivant la méthode Debian.

Pour les abuledu et leterrier, c'est beaucoup plus compliqué. Déjà la récupération des sources par les liens git donnés aboutissent à un échec.
@mothsart : toi qui es plus expérimenté que nous avec git, peux-tu nous indiquer la nature du problème et surtout la manière d'y remédier si c'est possible ?

[ThierryM]

Adieu a totes,

J'ai compilé Xournalpp (très facile avec les instructions). Par contre, il est en anglais : l'instruction

Code :

cmake --build . --target translations

retourne :

"make: *** Aucune règle pour fabriquer la cible "translations". Arrêt.

Pourtant il y a le dossier "po" dans les sources.

J'ai cependant empaqueté en .deb. Comment je vous le transmets ?
Cordialement,

Thierry

EDIT : Il manquait le paquet "gettext" (alors que "gettext-base" était bien installé) qui permet la génération des fichiers de traduction.

[mothsart]

Je pense également participer à l'effort de guerre.
Philippe : est-ce qu'on a déjà la possibilité d'utiliser le script pour avoir une PTX6 ?
Le mieux est de le faire directement sur la rpi avec la bonne version. Dans le cas contraire, je le ferais à partir de la raspios.

Je pense que je vais commencer par Openboard (De souvenir, j'avais mis l'ensemble de ma démarche pour PTX4) et je suivrais avec les softs du terrier s'il en reste.


Pour les dépôts git d'AbulEdu, voici la démarche de récupération pour "contour". (ça devrait être pareil pour les autres)

1. Passer par le lien https (et non git qui semble cassé) :

Code :

git clone https://redmine.abuledu.org/leterrier/leterrier-contour/leterrier-contour-git.git leterrier-contour
cd leterrier-contour

2. par défaut, quand on récupère une branche git, on est placé sur la branche "master".

3. Je vérifie si il y a des tags (qui devrait être la seul méthode propre pour versionner un soft) :

Code :

git tag --list

Ca ne me renvoi rien donc j'en déduis que le versionning se fait via des branches.

4. Je regarde l'ensemble des branches présentes sur le dépôt git sans downloader l'ensemble des sources de celle-ci. (sur certains projets, ça peut peser très lourd)

Code :

git branch --remote

Ca me renvoi :

Code :

origin/HEAD -> origin/master
  origin/master
  origin/version-1.0
  origin/version-1.1-dev
  origin/version-1.1-exemples
  origin/version-1.1-rc
  origin/version-1.1-stable

ne tenez pas compte de "origin", c'est une distinction quand on utilise plusieurs dépôts distants ce qui ne nous importe pas.

La 1ère ligne me précise que j'ai bien le pointeur sur la branch "master" et je vois qu'il y a un version 1.1 "stable".

5. Je déplace mon pointeur sur la branche "version-1.1-stable"

Code :

git checkout version-1.1-stable

Mon terminal (config zsh) m'indique "constamment" sur quel branche je suis mais ce n'est pas forcément le cas.
Pour le savoir, il suffit de faire :

Code :

git status

qui va me renvoyer :

Code :

Sur la branche version-1.1-stable
Votre branche est à jour avec 'origin/version-1.1-stable'.
rien à valider, la copie de travail est propre

Le message est explicite : on est sur la branche stable et on est en phase avec le serveur (ni en retard ni en avance).
On peut passé à l'étape de compilation !

[Philippe Dpt35]

J'ai cependant empaqueté en .deb. Comment je vous le transmets ?
EDIT : Il manquait le paquet "gettext" (alors que "gettext-base" était bien installé) qui permet la génération des fichiers de traduction.

Si tu peux compiler avec traduction, ce sera mieux.
Si le .deb n'est pas trop volumineux, tu peux me l'envoyer par mail. Sinon place-le sur un cloud pour lequel tu pourras m'envoyer un lien de téléchargement.
Après test, s'il ne pose pas de problème, on le mettra directement dans les dépôts armhf.

Philippe : est-ce qu'on a déjà la possibilité d'utiliser le script pour avoir une PTX6 ?
Le mieux est de le faire directement sur la rpi avec la bonne version. Dans le cas contraire, je le ferais à partir de la raspios.

Le script est en cours de construction, mais ne sera pas dispo avant quelques jours, le temps de m'assurer qu'il produit quelque chose d'un minimum acceptable. En attendant tu peux effectivement travailler sur une Raspi OS Desktop, c'est ce que je fais pour les tests de paquets.

[mothsart]

En attendant tu peux effectivement travailler sur une Raspi OS

Je vais faire ça et comme ça no pression de ton côté.

@ThierryM : merci de ton aide !
Sympa de te joindre à nous.

Tu parles de .deb : tu l'as créé comment ?
Je vois que le projet a directement ce qu'il faut pour compiler un .deb (https://github.com/xournalpp/xournalpp/t...ter/debian) donc une fois les libs de dev installés, un :

Code :

debuild

devrait suffire à produire le paquet .deb correspondant, non ?

[Philippe Dpt35]

ça ne se pose pas pour xournalpp qui dispose de ce qu'il faut pour construire directeement un paquet .deb, mais j'en profite pour rappeler que j'avais donné un process détaillé pour ce faire si besoin :
http://forum.primtux.fr/viewtopic.php?pid=21261#p21261

[ThierryM]

Adieu a totes,
@Philippe : le lien donné ci-dessus renvoie vers une page d'erreur.

Concernant la compilation de Xournalpp, ça fonctionne (en lançant à partir de /src) mais sans pouvoir disposer des traductions : cela semblerait être dû à l'absence de /usr/local/share/locale (message d'erreur dans la console quand on va dans les préférences).

Pour l'empaquetage, le paquet .deb ne veut pas s'installer. Avec gdebi ça ne semble pas fonctionner et avec dpkg -i, on a un message d'erreur :

Code :

dpkg: erreur de traitement de l'archive :
analyse du fichier "var/lib/dpkg/tmp.ci/control" vers la ligne 3:
le nom de champ "flexibility, " doit être suivi de deux points (:)

EDIT :
Il n'y a qu'à l'empaquetage que ça ne fonctionne pas. Si l'on installe directement sans empaqueter (comme c'est indiqué en bas des instructions de compilation dans github), tout fonctionne correctement : le logiciel est bien en français (et on peut changer de langue).
Il y a quand même un léger bug d'affichage qui fait qu'on ne voit pas la page à l'ouverture de Xournalpp : il faut modifier le zoom (passage de 274% à moins de 100%). Bug signalé ici : https://github.com/xournalpp/xournalpp/issues/2514

[Philippe Dpt35]

Pour le lien, c'est parce que c'est dans une partie du forum qui est privée. Tu peux demander à Steph de t'y donner accès.

Envoie-moi le tar.gz obtenu après compilation. J'essaierai de l'empaqueter autrement. On verra si ça passe.

[Steph]

Voilà.

[ThierryM]

Merci Steph !

[mothsart]

Vu que tu galères @ThierryM, j'ai décidé de tester la compilation du paquet .deb de Xournalapp et j'ai réussi (et en français).

Pour ça, j'ai fait :

Code :

git clone https://github.com/xournalpp/xournalpp.git

Puis je mets mon pointeur git sur le tag de la version stable la plus récente (important car si tu te bases sur master, c'est un peu la roulette car tu peux tomber sur une version instable et qui changera de md5 régulièrement) :

Code :

git checkout 1.0.19

Je build (en évitant d'utiliser une clé gpg car mon mail n'existe pas sur le changelog) :

Code :

debuild -us -uc

Le script s'arrête car il me manque une liste de dépendances.
Je la copie colle en la préfixant de ma commande d'installation :

Code :

sudo apt-get install libgtk-3-dev, libpoppler-glib-dev, libxml2-dev, portaudio19-dev, libsndfile-dev, liblua5.3-dev, libzip-dev

Je relance le debuild et paf, il replante un peu plus loin : oubli dans le fichier debian/control de forcer l'install de cmake (apt-get install cmake)

Ca plante une 3ème fois sur https://github.com/xournalpp/xournalpp/b...rce/format
Je supprime purement et simplement ce fichier.

Puis le debuild va jusqu'au bout !
Le .deb est là : https://drive.google.com/drive/folders/1...sp=sharing

J'espère que mes explications t'aiderons pour d'autres tentatives !

[ThierryM]

Merci Mothsart d'avoir pris le temps de bien détailler !
Philippe avait récupéré l'archive tar.gz pour l'empaqueter mais vu que tu as fait le boulot .
Je vais tester (je n'irai pas sur le drive de Google ).
Par contre, Xournalpp (la version que j'ai compilée : 1.1.0) souffre d'un bug signalé ici à propos du zoom : https://github.com/xournalpp/xournalpp/issues/2514 et en l'état, il ne me semble pas utilisable.
Mais souffres-tu de ce bug toi aussi ?
Cordialement,

Thierry

[mothsart]

Oui, je souffre du même bug, @Thierry.
Peut-être forcer la taille au lancement en attendant le correctif ?

En tout cas, c'est cool d'avoir créer l'issue (+ une pull request sur le process d'installation) !

[ThierryM]

Adieu a totes,

Merci pour votre aide. Ça y est j'ai réussi à empaqueter xournal++ en .deb. Téléchargeable ici : https://cloud-montpellier.beta.education...QFRay2TN3a
Du coup, je me suis fait un aide-mémoire ici : https://lofurol.fr/joomla/logiciels-libr...s-derivees

Par contre, le nommage du paquet .deb ne correspond pas à la version récupérée (la compilation initiale indiquait 1.1.0 et là 1.0.6) : je pense que ça doit avoir un lien avec le fichier supprimé xournalpp/debian/source/format. À creuser...
Cordialement,

Thierry

[mothsart]

@ThierryM : ça n'a aucun lien avec le fichier supprimé. Le versionning d'un paquet .deb est fait à partir du fichier https://github.com/xournalpp/xournalpp/b.../changelog du bas vers le haut => cqfd : la 1ère ligne indique la version en cours.

Malheureusement, ce versionning est indépendant du versionning de l'app en question (et de git de surcroit), du coup, il faut penser à l'éditer à chaque fois.
Si ça ne te dérange pas de l'éditer et de refaire un .deb, ça sera bcp plus cohérent !

Du coup, je me suis fait un aide-mémoire ici

Oui, c'est une bonne chose pour toi (l'apprentissage de la création de paquet peut être long et semé d’embûches), pour les francophones (je trouve qu'il manque pas mal de contenu de cet ordre en français sur le net) et pour nous quand on remettra le nez dedans.