PrimTux 3 pour Raspberry Pi - développement

[Philippe Dpt35]

Dans les paquets à reconstruire, il y a
accueil-primtux2_1.1.8_i386.deb
administration-eleves-primtux_1.0.8_i386.deb

Pour le premier, il faut une version différente pour le RPI, puisque nous serons amenés à modifier les scripts d'installation des logiciels complémentaires en fonction de ce qu'il sera possible ou non d'installer.

Pour le second, comme il ne s'agit que de scripts bash, y a-t-il une raison particulière pour laquelle tu l'as mis en architecture i386 plutôt qu'en all ? Cela éviterait de devoir refaire le paquet pour armhf à chaque modification.

[Steph]

Non je ne crois pas.

[Philippe Dpt35]

Pour la 64 bits, tu avais fait un autre paquet marqué amd64 ?

On pourrait peut-être harmoniser tout cela en faisant un seul paquet marqué "all".
Pour la version précédente sur RPi, il me semble que je m'étais contenté de reconstruire le paquet sans autre modification que le changement d'architecture.

[Philippe Dpt35]

Dans le paquet accueil-primtux2, fichier

Code :

/usr/local/bin/accueil

je suggère de remplacer la commande

Code :

/home/administrateur/seamonkey/seamonkey

par

Code :

sensible-browser

comme suggéré dans cette discussion: https://forum.abuledu.org/viewtopic.php?...6df4161383

C'est ce que j'ai dû faire pour l'adapter au RPi, et cela éviterait de devoir refaire le paquet si l'on devait changer de navigateur (sans compter sur le fait d'oublier de le faire dans ce cas !).

[Steph]

Ben là du coup non, comme on a seamonkey en admin non filtré je ne vois pas pourquoi on utiliserait firefox filtré...

Et ça ne m'embête absolument pas de refaire un petit paquet pour une commande. La gestion des fichiers est tellement aléatoire que j'aime vraiment mieux qu'on utilise seamonkey par défaut en admin, non filtré, que firefox ou autre. Tu vas installer un autre navigateur il va vouloir être le défaut, et rebelote, franchement j'aime mieux en imposer un pour l'ouverture des docs du site (parce que ça ne concerne que l'ouverture via l'accueil).

[Philippe Dpt35]

Selon moi cela n'a guère d'importance que ce soit tel ou tel navigateur qui soit utilisé pour ouvrir une doc. Il me semble préférable qu'un navigateur soit "trouvé" par le système, plutôt que d'avoir une doc qui ne s'ouvre pas parce que la commande est obsolète suite à des changements.
Mais ça n'est que mon avis !

Edit: il faut aussi envisager le cas où un administrateur souhaite utiliser un autre navigateur que seamonkey et vire ce dernier devenu inutile.

[Steph]

Ça n'est manifestement pas encore arrivé. Je maintiens ma position, trop de problèmes avec les xdg-open et compagnie, d'ailleurs si on utilise les 2 (xdg-open et sensible-browser), qui prend le dessus?
Voilà un exemple tout bête de la complexité qu'engendre ces associations avec un "multi-environnement graphique", à savoir fluxbox, rox, lxde, xfce => https://forums.archlinux.fr/viewtopic.php?t=17842 (dans ce cas précis il s'agit d'openbox).
Si on ne met pas qu'on est sous xfce, les associations sont tronquées.
Le jour où on passera complètement sous un seul environnement, oui, mais dans ce cas de figure, je ne trouve pas cette solution judicieuse, a fortiori quand on parle d'ouvrir quelques pages via un seul appel.

[Philippe Dpt35]

@mothsart
J'ai tenté de compiler Word Search Creator, mais sans succès.
Il semblerait qu'on se trouve dans le cadre d'une inclusion multiple ou circulaire, et qu'il faille modifier le code source pour mettre en place des déclarations anticipées (C++ et qt). Mais cela dépasse mes compétences !

Tes compétences de développeur te permettront peut-être de résoudre le problème bien que ce ne soit pas des langages que tu maîtrises.

Les sources sont ici: https://sourceforge.net/projects/wsc/files/

[Philippe Dpt35]

@Steph
Peux-u mettre à jour les sources de PrimTux3, notamment pour le paquet accueil-primtux2 (version 1.1.9), afin que je le reconstruise pour le RPi ?

[Steph]

C'est bon.

[mothsart]

Philippe : je veux bien t'aider mais je ne trouve pas de sources sur le lien donné : que des .exe et des .deb

[Philippe Dpt35]

Il semble que les sources de la version 1.1 aient disparu depuis que je les ai téléchargées la semaine dernière. Elles étaient dans un tar.gz téléchargeable. Elles sont d'ailleurs toujours présentes pour la version 1.0.
Peut-être le développeur s'est-il aperçu d'un problème et les a-t-il supprimées ? Auquel cas il conviendrait peut-être de travailler sur la version 1.0. Du coup je vais tenter la compilation de la version 1.0.

A toutes fins utiles, voici les sources de la version 1.1 que j'ai téléchargées: http://www.primtux.fr/Documentation/foru...1.1.tar.gz

[Philippe Dpt35]

J'ai le même problème avec la version 1.0

[Philippe Dpt35]

J'ai retrouvé un autre lien pour le téléchargement des sources de Word Search Creator: http://wordsearchcreator.org/downloads/
Contrairement à ce que j'écrivais précédemment, il est davantage probable que j'ai téléchargé depuis cette source, et que le lien donné précédemment ne les contenait pas !

[mothsart]

Ca serait bien de mettre toutes les sources quelque part pour éviter ce genre de recherche à l'avenir.

[Philippe Dpt35]

Ca serait bien de mettre toutes les sources quelque part pour éviter ce genre de recherche à l'avenir.

Oui, bonne idée, une liste de liens vers les sources utilisées pour PrimTux. Pas directement les sources elles-mêmes, car elles peuvent changer.
Je vais commencer ça.

[mothsart]

Je dirais que si possible, les 2 car certaines sources peuvent disparaîtres : genre les sources d'un logiciel plus maintenu ou une vielle version.

[mothsart]

Et puis, c'est aussi tout ce qu'il y a dans le dossier debian qui est important pour pouvoir reconstruire les sources facilement.
Je sais pas si c'est dure d'avoir un dépôt pour les sources que l'on peut récup via : apt-get source monpaquet ?

[Steph]

Le plus simple c'est quand même de tout balancer sur un git si on parle de sources.

[Philippe Dpt35]

Il me semble compliqué et peu pratique de gérer des sources en plus de celles des développeurs !
Je propose la chose suivante:

une liste des logiciels pour lesquels nous avons besoin des sources, avec

• un lien vers la page des sources officielles
  
• un lien vers une archive de la dernière version existante que l'on placera sur l'hébergement de PrimTux, au cas où les sources disparaîtraient.
  

Si cela vous convient, je veux bien m'en charger

[Philippe Dpt35]

Bonne nouvelle !
Je viens de trouver sur un site, probablement japonais , comment installer et faire fonctionner DrGeo sur le Raspberry Pi !

[Steph]

Et si les sites contenant les sources disparaissent?

[Philippe Dpt35]

Et si les sites contenant les sources disparaissent?

C'est pour cela que mothsart suggérait de mettre de côté une copie de chaque source dans sa dernière version.

J'ai ouvert une discussion avec un premier jet de liste avec une copie de la source, et j'ai oublié d'en donner le lien ici. ça a donc dû passer inaperçu:
http://forum.primtux.fr/viewtopic.php?id=1258

[Steph]

Ok tu as fait des copies.

[Philippe Dpt35]

J'ai automatisé la construction d'une PrimTux sur Raspberry Pi à l'aide d'un script qui s'appuie sur les sources de la PrimTux pour PC. Outre la facilité que cela me procure pour réaliser cette tâche, cette solution présente d'autres avantages considérables:

• d'autres que moi pourront le faire aisément, assurant la pérennité de PrimTux sur RPi en cas d'indisponibilité de ma part ;
  
• l'image obtenue sera plus propre qu'une image réalisée par manipulations et corrections successives ;
  
• tout à chacun aura la possibilité de construire sa propre PrimTux RPi s'il le désire plutôt que de télécharger l'image existante ;
  
• il sera possible de construire beaucoup plus rapidement les nouvelles versions de PrimTux, quelques adaptations du script devant suffire.
  

Je réaliserai un tutoriel détaillant la procédure qui est très simple. Il suffira de partir d'une Raspbian lite installée sur une carte SD et démarrée sur le Raspberry Pi pour construire une PrimTux. Après avoir configuré la localisation, tout se fait automatiquement par Internet. Une liaison par câble ethernet est pour l'instant requise. Il faudra que je vérifie la possibilité de le faire en Wifi ou par SSH quand je serai un peu plus disponible. Pour le WiFi cela sera un peu plus compliqué, en raison d'une incompatibilité du RPi avec mon routeur.