Congratulations with getting Cesium distributed as a Mozilla app!
Mozilla criteria for acceptance is independent of Debian criteria for acceptance, however.
When we met in France, I looked at the Cesium code and it seemed to be acceptable for inclusion in Debian. So (if I am correct - if no non-free parts or other blocking issues are discovered) Cesium was acceptable in Debian back then, and is still acceptable today.
What is needed to get Cesium into Debian is someone doing the work involved.
Cesium uses libraries which are not in Debian, so those libraries need to be packages first.
Most notably, the Cordova libraries.
I would be very happy to help anyone volunteering to help package and maintain Cesium and its dependent libraries. Those volunteering need not be a formal member of Debian, and need not be an expert in Debian packaging to help. What is needed is a bit of patience, and a bit of understanding in the code involved - i.e. Nodejs in this case.
Yes, one way (the most robust way) to get Cesium into Yunohost is by getting it into Debian.
Maybe there are other easier (but less robust) ways too - you will need to discuss that with the Yunohost developers.
Surement qu’un redémarrage du nœud est nécessaire.
C’est mis à jour dans WS2P mais pas dans la PoW.
Il me semble que ce comportement incorrect est connu du projet Duniter.
En effet ! Après redémarrage de Yunohost (obligé, parce que faire “stop”, ou “redémarrer” depuis l’UI Web de Duniter ne fonctionne pas) et relance avec duniter webstart, il apparaît :
2020-06-09T13:22:54+02:00 info Matched 3 zeros 000E20A44C2A6DD78E1202432FD582EB535BCEB3A0CCE17EF9C877CDDD3D7255 with Nonce = 10099900000088 for block#288696 by Ds1z6W
2020-06-09T13:23:00+02:00 warn WS2P request timeout
2020-06-09T13:23:00+02:00 warn WS2P request timeout
2020-06-09T13:23:00+02:00 info Block resolution: 1 potential blocks after current#288695...
2020-06-09T13:23:00+02:00 info Block #288696 added to the blockchain in 281 ms
2020-06-09T13:23:00+02:00 info [done] worker c#0#w#1
2020-06-09T13:23:00+02:00 info Block resolution: 1 potential blocks after current#288696...
2020-06-09T13:23:00+02:00 info [done] worker c#0#w#0
2020-06-09T13:23:00+02:00 info No engine found the proof. It was probably cancelled.
2020-06-09T13:23:00+02:00 info GIVEN proof-of-work for block#288696 with 5 leading zeros followed by [0-5]! stop PoW for Ds1z6W
2020-06-09T13:23:00+02:00 warn The proof-of-work generation was canceled: Proof-of-work computation canceled because block received
Pardon ?! C’est une affirmation totalement fausse…
Jonas parlais uniquement d’un blocage avec Cesium, je ne me souviens pas qu’il est parlé de Duniter.
Duniter est entièrement libre, et peut tout a fait être intégré dans Debian, nous ne l’avons pas fait car Duniter évolue trop vite par rapport a l’inertie des dépôts officiels de debian, ce serait donc une mauvaise idée de le faire.
En revanche, on pourrais créer notre propre dépôt debian tiers pour les logiciel de l’éco-système Duniter/Ğ1, ça n’a simplement jamais été fait parce que personne n’a pris le temps de le faire…
J’ai dû confondre en effet ! Mais désormais avec l’intégration Mozilla Cesium a dû passer ce cap !
Je propose donc comme thème central des prochaines RML16 de Perpignan “intégrer Debian” ! Ce serait magnifique qu’on arrive à une telle réalisation non seulement pour Duniter, mais aussi comme contribution au libre en général, en effet quelle belle communication en faveur du libre ce serait !
Dans ce contexte, les RML16 ne se tiendrais qu’au printemps 2021, il me semble donc judicieux de ré-ouvrir les candidatures pour les RML16 à minima jusqu’à l’automne 2020
Techniquement je suis plutôt défavorable a l’intégration de Duniter dans les dépôts officiel de debian, a minima pour les 5 ans a venir. Duniter va beaucoup évoluer et de façon non rétro-compatible (changements de protocoles) dans prochains mois/années, le paquet debian de Duniter dans les dépôts officiels serait donc rapidement inutilisable.
Je préférerai que nous créions notre dépôt debian personnel, ainsi nous pourrons y maintenir nos paquets a jour, et ça on peut déjà le faire maintenant sans demander quoi que ce soit a debian :
C’est pas comme ça que marchent les RML, je ne dis pas qu’elles ne peuvent pas être reportées, mais une annulation ne présuppose en rien la possibilité d’une reconduction, c’est pas la foire à papa, il y a un fondateur organisateur (facilement démontrable), et des organisations déléguées je l’ai déjà expliqué maintes fois.
Ceci étant dit je ne suis pas contre un report mais j’ai pas d’information sur le sujet encore, faudra attendre courant Août certainement de toute façon pour se décider si RML15 ou RML16 directement.
Je choisis de ne pas nommer RML15 les prochaines RML si cette édition n’est pas reportée.
En cas de report, pour les RML16 on peut en effet considérer qu’il est préférable d’attendre le 30 Septembre 2020 comme nouvelle date limite de candidature. Si pas de report, heureusement que Perpignan est déjà positionné !
Tu veux dire que l’application Duniter pour YunoHost n’est pas dans le catalogue d’applications. Elle l’est, mais n’est pas affichée dans la section principale, car elle est qualifiée de “non working”. On peut l’afficher que quand on sélectionne “Toutes les apps”. Elle est en “non working”, car elle ne passe pas la CI. Il faut que quelqu’un s’en occupe.
Il faut lancer Duniter avec l’utilisateur root, car c’est géré ainsi par le paquet, sinon tu rencontreras des problèmes pour les manipulations d’installation, suppression et mise à jour faites par le paquet.
Pareil, il faut que quelqu’un s’occupe de lancer Dunier avec un utilisateur non-root, étant donné que c’est une mauvaise pratique.
Tout ça pour dire, que le paquet a besoin d’amour et que j’échoue dans cette tâche, car j’ai d’autres priorités et que ne souhaite pas trop me disperser. Si ça sonne à l’oreille de quelqu’un, je veux bien l’aider à faire ses premiers pas. Sinon, il faudra attendre que je m’y penche de nouveau.
Non. YunoHost lançait les scripts des apps avec un utilisateur non-root et il fallait préfixer avec sudo les commandes qui nécessitait les droits root tel dpkg. Aujourd’hui, les scripts sont lancés avec root, et sudo n’est plus nécessaire. Il faut à présent utiliser un autre utilisateur Unix.
Il faut remplacer ces lignes dans le script install :
# Check the admin exists in YunoHost users
ynh_user_exists $admin
par ça :
# CREATE DEDICATED USER
ynh_script_progression --message="Configuring system user..."
# Create a system user
ynh_system_user_create --username=$app --home_dir=$final_path
Oui, li faut créer un utilisateur Unix, lancer les commandes qu’il faut avec cet utilisateur, et faire la transition…
Je pense que la dernière étape sera à faire manuellement par tout le monde, ou sinon, copier le dossier /root/.config/duniter dans $USER/.config/duniter dans le script d’upgrade de manière conditionnelle.
Bonjour,
je voulais vous faire des retours sur l’utilisation de duniter_ynh.
L’application installée par défaut était accessible publiquement ainsi que son administration, j’ai réglé cela via l’interface admin de Yunohost => régler les permissions, retirer l’app des permissions visitors et all_users pour ne la rendre accessible que par un utilisateur en ajoutant une permission pour cet user.
Sinon, je constate que l’application s’arrête toute seule par moment sur mon serveur auto-hébergé et qu je dois la relancer èn console avec un duniter start… Je n’ai pas encore trouvé pourquoi, peut-être parce qu’il lance tous les soirs une sauvegarde distante avec Borg Server d’un autre serveur, il se peut que d’un coup trop de ressources soient demandées au serveur et ce serait la raison pour laquelle il se coupe ??
@roodinux seul duniter v1.8.2 est fonctionnel, donc tant qu’un paquet yunohost à jours n’est pas disponible, les nœuds duniter sous yunohost ne peuvent pas fonctionner.
mais voilà mes quelques PR