Neutrinet issues
https://gitlab.domainepublic.net/groups/Neutrinet/-/issues
2020-05-16T13:02:27Z
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/34
Yunohost app list migration
2020-05-16T13:02:27Z
HgO
Yunohost app list migration
Alex from Yunohost told us (@ilja and I) that the release of Yunohost 3.8 would make some breaking changes on how the package lists are managed. In short, it won't be possible to manage a custom app list from the web interface or from th...
Alex from Yunohost told us (@ilja and I) that the release of Yunohost 3.8 would make some breaking changes on how the package lists are managed. In short, it won't be possible to manage a custom app list from the web interface or from the cli. The custom app lists that are currently installed on cubes will be removed.
Here is what Alex told us:
> 1. The thing is that there's a big refactoring to the app list management in 3.8 ... Mostly to integrate app categories (which required a change in the way we fetch app list) and because I got fed up of the underlying code that was a total mess.
>
> 2. Also the "multiple app catalog" seemed like a big YAGNI after complaining so many times about it ended up removing it because nobody seemed to use it. It's still available but requires to manually add a line in a .yml file in /etc/yunohost/.
>
> 3. Yunohost is also more and more discouraging user to install "bad quality" apps (c.f. the level key in the json app catalog). In particular anything below level 4 is considered bad quality. I think that's already the case in 3.7 ?
>
>
> Anyway, as said a lot of things would be simplified (well, requires a bit of work but I can help) if :
> - neutrinet_ynh goes into the "official" app catalog
> - but that also means that neutrinet will be tested on the app CI, and it should be level 4 to be easily installable in the app list (otherwise users gotta ask to see 'all apps and not just decent quality' ones)
> - we can run some tests about the package on our dev ci to see what level it goes up to
> - but I can already say that our package_linter.py will block level 4 currently. There are some errors that are easy to fix. Warnings won't block level 4 but ideally they should still be taken care of as much as possible ...
> - it would help if the main branch you work on is "master" (or an alias can be created to stable, idk)
> - once everything is done, you're still independant in the management of the app (nothing to push on apps.json), the only thing that changes is that the CI may warn you about failing tests
>
> (hopefully this makes some sense)
## Questions
It followed some questions from our part.
### What exactly do you mean with the "multiple app catalog"?
The "Custom applications list"
Because of the breaking changes required by 3.8 to have app categories, the format of the apps.json changes.
And because it was assumed that nobody was using custom app list anymore (e.g. La Brique was doing so in the past but not anymore) the 3.8 will agressively resets the app list to just keep Yunohost's default app list ... Now that I think about it and that I found somebody using that system, I could try to implement some compatibility mode for older app lists format but meh...
### We started using a [dev list for testing purpose](https://apps.neutrinet.be/unstable.json). What is the workflow for testing within the official app list?
The usual practice is to tell people to install or upgrade using the testing branch. C.f. an example here for nextcloud : https://github.com/YunoHost-apps/nextcloud_ynh#developers-infos (notice the /tree/testing at the end). Looking at the code in the core, same thing should also work for non-github repo (even though the url goes nowhevere, it's just a quick-and-dirty parsing)
### As you know, we are using a Gitlab repo, with a mirror to Github. Could we keep working on Gitlab, or is Github required to work with the list?
No worries, any git[whatever] is okay as long as repo can be cloned. There already are a couple of apps hosted on framagit or other forges in the list đ . You're free to choose to put the gitlab url or github url in the list.
### We were thinking about using the CI tool provided by Ynh, so that's good :) Do we need to write tests somehow? How is it working?
I'll start a test on the dev CI to see how that looks. (Btw you can probably ask Maniack for an access too, just need an SSH key, c.f. https://yunohost.org/#/packaging_apps_ci )
I think by default it magically finds some dummy default values to use ... But usually project set up a "check_process" file in the repo. The syntax is a bit funky but for example you can look at : https://github.com/YunoHost-Apps/anarchism_ynh/blob/testing/check_process (or any other app that has this file). I see that neutrinet_ynh only ask for a domain + path so maybe not even needed ? Full doc is here : https://github.com/YunoHost/package_check#syntax-of-check_process
### For when is planned the 3.8? In other words, how much time do we have?
There are many fixes to do, at least another testing iteration to validate everything, so would say a good 2~3 weeks.
### Is it still possible to add a custom app list?
Adding a custom list now would look like:
```shell
echo "- id: neutrinet
url: https://.../neutrinet_ynh_list" >> /etc/yunohost/apps_catalog.yml
```
(assuming the actual json is at https://.../neutrinet_ynh_list/v2/apps/json)
Then `yunohost tools update --apps` to refresh the app catalogs cache.
If you wish to build and maintain your own app list, you can have a look at: https://github.com/YunoHost/apps/
Basically you "just" need a cron job that calls rebuild.sh, itself calling list_builder.py
Maybe just a few things to tweak for everything to be smooth on your side
### What will happen with the instances that already have the applist?
The applists will be gone completely, which means you'll have to figure out a way to get the applist back (or better, the new applist in).
The big question is how to properly handle the upgrade so that everything stays consistent... We could also just have some ad-hoc piece of code in Yunohost that says "if there's the neutrinet list, replace it with the new neutrinet list"
### Is it possible to just change our applist to the newer format?
Note that you need to keep serving both the old version and the new version (it's what we already do as you can notice in https://app.yunohost.org/ ... apps.json is the current version (pre-3.8) and default/v2/apps,json is the new version (post 3.8)
In fact you could generate the new version easily by adding a top-level "apps:" key and an empty "categories:" key ... which is easier on the short-term. But on the long-term it might be worth to setup a real list_builder.py + cron job if we do improvements or other migrations in the future...
Also there's in fact a yunohost app to setup the app list system (yup, appception) : https://github.com/YunoHost-Apps/app_ynh_core but I recently yolo-commited without testing, but that can be used as partial doc :/
## Concerns
The question is whether it's easier/better for us to move to the official app list, or still keep our own.
We formulated some concerns to Alex:
- On not allowing custom app-lists:
Although we understand not wanting people to think badly of ynh based on some bad apps that aren't even really part of the project, and we even think that's a valid concern! But this is also a step towards centralization and we dislike that on principle alone... Ynh is already too depended on central services (github, but also things like ip.yunohost.org...), removing the possibility for custom applists just adds to that I think. But that's maybe not relevant here...
- On timing and on the breaking change itself:
There are ynh instances out there with this app list, these should not break. For us this wouldn't be too much of a problem, there aren't big changes planned for the app (we recently did a whole rewrite, but things should be more stable now)
- On the removal of custom app lists already installed:
We COULD add the list back from the app, but if people upgrade ynh before they can upgrade the app then that's a problem...
- On the CI tool:
The app needs an installed and working VPN, so the CI tool might fail (which doesn't mean the app is uninstallable)
## Decision
We asked on [Mattermost](https://chat.neutrinet.be/neutrinet/pl/wmcr9m5u77gixno8inoyg7fi6y) what should we do. The current consensus is (but this could still change ofc):
> The saner approach would be to move to the Yunohost app list. Maintaining a whole list for only one app is quite overkill... Later, if we feel like it, we could upgrade our old list to make it compliant with the new app list system and move back in our own app list.
Install Party 21/06/2019
https://gitlab.domainepublic.net/Neutrinet/neutrinet_ynh/-/issues/27
super-old deprecated packaging practices ?
2022-04-09T16:59:54Z
Thierry Fenasse
super-old deprecated packaging practices ?
```
=================================
Applications (apps)
=================================
[ERROR] An issue was found for app Neutrinet
- This app's installed version still uses some super-old deprecated packaging practices. You shou...
```
=================================
Applications (apps)
=================================
[ERROR] An issue was found for app Neutrinet
- This app's installed version still uses some super-old deprecated packaging practices. You should really consider upgrading it.
```
C'est le truc de diagnostic de Yunohost qui dit çaâŠ
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/33
Make the hotspot install optional
2020-05-09T16:00:31Z
HgO
Make the hotspot install optional
When [the PR on Github is merged](https://github.com/labriqueinternet/build.labriqueinter.net/pull/69), the hotspot install will be optional in the hypercube script.
The install could be disabled with the following setting in the hyper...
When [the PR on Github is merged](https://github.com/labriqueinternet/build.labriqueinter.net/pull/69), the hotspot install will be optional in the hypercube script.
The install could be disabled with the following setting in the hypercube file:
```json
"hotspot": {
"enabled": false,
...
}
```
Install Party 17/05/2020
sohka
sohka
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/1
Rename this project
2020-03-14T08:45:05Z
HgO
Rename this project
Proposals :
- ansible-playbooks
- infra-ansible-playbooks
- infra-ansible
- something else ?
Proposals :
- ansible-playbooks
- infra-ansible-playbooks
- infra-ansible
- something else ?
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/27
Translations workflow
2020-05-05T15:10:16Z
HgO
Translations workflow
We need to define a workflow for the translations, as it leads to conflicts really easily.
For instance, I'm changing the code and some sentences in English, then I generate the translation strings with
```
bash --dump-po-strings neutri...
We need to define a workflow for the translations, as it leads to conflicts really easily.
For instance, I'm changing the code and some sentences in English, then I generate the translation strings with
```
bash --dump-po-strings neutrinet_cube_install.sh | msguniq -o locale/neutrinet.pot
```
And from that template, I start updating the French translation.
The problem is that the template (locale/neutrinet.pot) and the translation file (locale/fr/LC_MESSAGES/neutrinet.po) are generated by a program... The whole files might change even if we add just one line of code...
So, I propose to have a separate branch for translations (called locale-fr, locale-nl, etc.). Each time a new feature is merged, we pull the new changes from unstable branch into the locale branch. Then we push back the translated work into unstable again.
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/26
Documentation about downloading the script
2020-02-16T13:10:18Z
HgO
Documentation about downloading the script
Once #20 is solved, the user would have 5 options to download the script:
```shell
git clone https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install.git
```
Download a zip with the button on the project page (just below the cl...
Once #20 is solved, the user would have 5 options to download the script:
```shell
git clone https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install.git
```
Download a zip with the button on the project page (just below the clone button), or just do:
```shell
wget https://git.domainepublic.net/Neutrinet/neutrinet_cube_install/-/archive/stable/neutrinet_cube_install-stable.zip
```
Download the standalone script (English only) with button on the [main script](https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/blob/stable/neutrinet_cube_install.sh), or just do:
```shell
wget https://git.domainepublic.net/Neutrinet/neutrinet_cube_install/raw/stable/neutrinet_cube_install.sh
```
It would be nice to document some of them :)
Install Party 16/02/2020
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/22
Explain why sudo password is required
2020-02-16T13:53:36Z
HgO
Explain why sudo password is required
When we build the Yunohost image with the hypercube script, the user is asked for its sudo password, without more details. We should add a message that explains to the user why it is required.
When we build the Yunohost image with the hypercube script, the user is asked for its sudo password, without more details. We should add a message that explains to the user why it is required.
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/15
Pass verbose parameter to install-sd script
2020-01-19T11:26:20Z
HgO
Pass verbose parameter to install-sd script
When the user is running the script with the `-v` option (verbose mode), this should also enable debug mode for the other scripts we run (in this case, `install-sd.sh` script)
When the user is running the script with the `-v` option (verbose mode), this should also enable debug mode for the other scripts we run (in this case, `install-sd.sh` script)
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/neutrinet_ynh/-/issues/13
Improve /neutrinet webpage
2020-02-29T11:21:54Z
Ilja
Improve /neutrinet webpage
1. The links are now in bold. This isn't a typical thing to do, so it's not intuitive. These should be either another colour or underlined. Since Neutrinet doesn't really have a 'main' colour, I'd use underlined instead of bold.
2. There...
1. The links are now in bold. This isn't a typical thing to do, so it's not intuitive. These should be either another colour or underlined. Since Neutrinet doesn't really have a 'main' colour, I'd use underlined instead of bold.
2. There is Javascript loaded which isn't used. It looks like this was part of a framework-like thing together with the css. The Javascript should be removed.
3. Add a translations for Dutch. The prefered way is probably to have a second page for Dutch and a link on the pages to switch from fr to nl. The default an remain fr.
* If this proves too difficult, maybe it can be easier to have both translations on one page (but let's try to not go this way).
* If this doesn't prove to be difficult enough, we can also see if we can have nginx load the nl/fr page in case nl/fr preference is detected from the browser. Fr should still be default.
Neutrinet v0.3.0~ynh5
Ilja
Ilja
https://gitlab.domainepublic.net/Neutrinet/frontend/-/issues/3
Move Yunohost package list to a dedicated repo
2019-12-09T18:48:43Z
HgO
Move Yunohost package list to a dedicated repo
We should separate files and scripts related to the Yunohost package list to a dedicated repo.
Code in the `frontend` repo isn't used anymore (we use the [Grav website](https://gitlab.domainepublic.net/Neutrinet/site-neutrinet-beta) now...
We should separate files and scripts related to the Yunohost package list to a dedicated repo.
Code in the `frontend` repo isn't used anymore (we use the [Grav website](https://gitlab.domainepublic.net/Neutrinet/site-neutrinet-beta) now) and should probably be archived.
https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/9
Execute custom script during cube's installation
2019-12-13T20:02:59Z
sohka
Execute custom script during cube's installation
Hi,
A few weeks ago, I opened [a merge request](https://github.com/labriqueinternet/build.labriqueinter.net/pull/66) in the `build.labriqueinter.net` repository to add the possibility to execute a custom script during the `hypercube.sh`...
Hi,
A few weeks ago, I opened [a merge request](https://github.com/labriqueinternet/build.labriqueinter.net/pull/66) in the `build.labriqueinter.net` repository to add the possibility to execute a custom script during the `hypercube.sh` script's execution.
As explained [here](https://github.com/labriqueinternet/labriqueinter.net/issues/66), the idea would be to make easier to add tweaks and specific parameters (like [Neutrinet's ones](https://gitlab.com/Spctrl/neutrinet_cube_install/compare/master...neutrinet_specifics_to_hypercube_sh)) without having to fork the `build.labriqueinter.net` repository.
The merge request is still under review (and after it gets merged, I would also need to create a merge request to adapt the `install-sd.sh` script in consequence), but I already started to work on integrating this change to Neutrinet's cube install script. [Here is the branch](https://gitlab.domainepublic.net/sohka/neutrinet_cube_install/tree/execute-custom-script) where I put my changes. When you have the time, could you have a look and tell me what you think of it ? According to my tests, my changes are working as expected.
I also created [a test branch](https://gitlab.domainepublic.net/sohka/neutrinet_cube_install/tree/testing-custom-script) for adapting the location, revision and checksum variables. Feel free to use it if you already want to test the execution of a custom script.
sohka
sohka
https://gitlab.domainepublic.net/Neutrinet/accounting/-/issues/5
Import du CSV en utf-8
2024-01-24T18:34:15Z
HgO
Import du CSV en utf-8
On a remarquĂ© qu'on ne pouvait pas importer les fichiers CSV quand les en-tĂȘtes sont en français⊠C'est parce que l'importateur ouvre le fichier avec un encodage `ISO-8859-1`⊠Il faudrait ouvrir le fichier en UTF-8.
On a remarquĂ© qu'on ne pouvait pas importer les fichiers CSV quand les en-tĂȘtes sont en français⊠C'est parce que l'importateur ouvre le fichier avec un encodage `ISO-8859-1`⊠Il faudrait ouvrir le fichier en UTF-8.
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/accounting/-/issues/4
Faire en sorte que accounting se déploie automagiquement avec un pipeline
2023-12-02T10:56:47Z
HgO
Faire en sorte que accounting se déploie automagiquement avec un pipeline
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/accounting/-/issues/3
Affichage des mouvements en json
2023-08-30T16:57:16Z
HgO
Affichage des mouvements en json
Est-ce que ce serait possible d'avoir un endpoint qui affiche les mouvements au format json?
Comme ça on pourrait afficher des beaux graphes sur le site web, si un jour on a le temps de le faire :p
Par exemple, quelque chose comme ça:
...
Est-ce que ce serait possible d'avoir un endpoint qui affiche les mouvements au format json?
Comme ça on pourrait afficher des beaux graphes sur le site web, si un jour on a le temps de le faire :p
Par exemple, quelque chose comme ça:
```
> curl "https://accounting.neutrinet.be/movements?year=2023&format=json"
[
{"number": 1, "date": "2023/01/01", "amount": 4.0, "type": "donation"},
...
]
```
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/225
PHP 8.0 déprécié par Nextcloud
2023-08-08T19:53:54Z
HgO
PHP 8.0 déprécié par Nextcloud
Il faudra vérifier les autres applications web, car PHP 8.0 ne sera plus supporté dans 3 mois : https://www.php.net/supported-versions.php
Il faudra vérifier les autres applications web, car PHP 8.0 ne sera plus supporté dans 3 mois : https://www.php.net/supported-versions.php
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/matrix-alertbot/-/issues/10
Permettre plusieurs comptes matrix
2024-01-22T10:29:26Z
HgO
Permettre plusieurs comptes matrix
Permettre au bot de se connecter Ă des comptes matrix de secours, donc sur des serveurs diffĂ©rents, pour Ă©viter d'ĂȘtre coincĂ© parce que le serveur matrix est en panne.
En rÚgle générale, il y aura un compte principal, et si le serveur e...
Permettre au bot de se connecter Ă des comptes matrix de secours, donc sur des serveurs diffĂ©rents, pour Ă©viter d'ĂȘtre coincĂ© parce que le serveur matrix est en panne.
En rÚgle générale, il y aura un compte principal, et si le serveur est down, le bot envoie les alertes sur le second serveur, et ainsi de suite.
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/224
Mettre le header X-Frame-Options Ă SAMEORIGIN
2023-07-22T16:16:36Z
HgO
Mettre le header X-Frame-Options Ă SAMEORIGIN
Nextcloud demande Ă ce que le header X-Frame-Options soit Ă SAMEORIGIN
Nextcloud demande Ă ce que le header X-Frame-Options soit Ă SAMEORIGIN
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/223
Refonte des group vars pour les HAProxy
2023-10-08T07:59:37Z
HgO
Refonte des group vars pour les HAProxy
On commence à avoir beaucoup de serveurs avec un HAProxy, ça devient un peu complexe au niveau des group vars...
On commence à avoir beaucoup de serveurs avec un HAProxy, ça devient un peu complexe au niveau des group vars...
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/222
Fix format clé GPG du dépÎt Ceph
2023-07-01T14:24:01Z
HgO
Fix format clé GPG du dépÎt Ceph
HgO
HgO
https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/221
Configuration de Matterbridge pour envoyer vers Matrix
2023-07-01T21:32:53Z
HgO
Configuration de Matterbridge pour envoyer vers Matrix