Avertissements v2 #17

Closed
opened 1 year ago by otyugh · 26 comments
otyugh commented 1 year ago
Collaborator

Je me demandais, ça serait pas aussi malin de faire un avertissement pour :

  • Si jamais on tombe sur deux release de patch de retard (ça voudrait dire que le PC n'a pas été allumé depuis longtemps et en ce cas ça sera réglé au prochain démarrage - mais si apt est cassé, l'avertissement reviendra tout le temps au démarrage et poussera l'utilisateur à questionner !)
  • Quand le support de la version de debian installé n'est plus maintenue, il faudrait un avertissement

Bien entendu la vérification se ferait via un p'tit curl, et ne serait pas ennuyeux si déconnecté d'internet (parce que les màj de sécurité c'est pour internet).

Niveau mise en oeuvre, j'ai un doute sur comment automatiser la verif pour savoir si la version est maintenue. Comment apt sait qu'il y a plus de MàJ à venir ? x)

Je me demandais, ça serait pas aussi malin de faire un avertissement pour : * Si jamais on tombe sur deux release de patch de retard (ça voudrait dire que le PC n'a pas été allumé depuis longtemps et en ce cas ça sera réglé au prochain démarrage - mais si apt est cassé, l'avertissement reviendra tout le temps au démarrage et poussera l'utilisateur à questionner !) * Quand le support de la version de debian installé n'est plus maintenue, il faudrait un avertissement Bien entendu la vérification se ferait via un p'tit curl, et ne serait pas ennuyeux si déconnecté d'internet (parce que les màj de sécurité c'est pour internet). Niveau mise en oeuvre, j'ai un doute sur comment automatiser la verif pour savoir si la version est maintenue. Comment apt sait qu'il y a plus de MàJ à venir ? x)
Collaborator

un petit utilitaire dans le menu DF avec un script + zenity pour afficher les infos utiles genre :

  • version de debian avec précision stable / oldstable / oldoldstable
  • date de la dernière mise à jour
  • nombre de paquets installés
  • préconisations en matière de mise à jour des versions
  • ...
    ??

l'outil demanderait les droits admins et pourrait ainsi procéder à toutes les vérifications.

l'outil pourrait être appelé de manière systématique le 1er de tous les mois (via .config/autostart) et ainsi habituer le user à vérifier son système régulièrement ?

un petit utilitaire dans le menu DF avec un script + zenity pour afficher les infos utiles genre : - version de debian avec précision stable / oldstable / oldoldstable - date de la dernière mise à jour - nombre de paquets installés - préconisations en matière de mise à jour des versions - ... ?? l'outil demanderait les droits admins et pourrait ainsi procéder à toutes les vérifications. l'outil pourrait être appelé de manière systématique le 1er de tous les mois (via .config/autostart) et ainsi habituer le user à vérifier son système régulièrement ?
Poster
Collaborator

Je pensais plutôt ça comme un avertissement de problème sous-jacent.

J'en ai parlé parce qu'une personne demandait sur IRC pourquoi un truc marchait pas (et un apt upgrade qui lui a pris une éternité a réglé le souci, il avait juste jamais mis à jour buster depuis >3-4 ans !)

Je pensais plutôt ça comme un avertissement de problème sous-jacent. J'en ai parlé parce qu'une personne demandait sur IRC pourquoi un truc marchait pas (et un apt upgrade qui lui a pris une éternité a réglé le souci, il avait juste jamais mis à jour buster depuis >3-4 ans !)
Poster
Collaborator

Pour trouver la fin de support j'ai trouvé un paquet debian dédié qui fournit un CSV \o/

https://www.baeldung.com/linux/csv-parsing

Le script est trivial à faire en partant de là o/

release=$(lsb_release -cs)
eol=$(curl https://debian.pages.debian.net/distro-info-data/debian.csv | grep "$release" | grep -o "[^,]*$")
eol_days=$(($(date -d $eol +%s)-$(date +%s)/60/60/24))

test $eol_days -le 0 && notify-send -i dialog-warning -u critical "ATTENTION
Votre $release est en fin de vie
depuis ${eol_days#-} jours.
Mettez votre système à niveau !"
Pour trouver la fin de support j'ai trouvé un paquet debian dédié qui fournit un CSV \o/ https://www.baeldung.com/linux/csv-parsing Le script est trivial à faire en partant de là o/ ``` release=$(lsb_release -cs) eol=$(curl https://debian.pages.debian.net/distro-info-data/debian.csv | grep "$release" | grep -o "[^,]*$") eol_days=$(($(date -d $eol +%s)-$(date +%s)/60/60/24)) test $eol_days -le 0 && notify-send -i dialog-warning -u critical "ATTENTION Votre $release est en fin de vie depuis ${eol_days#-} jours. Mettez votre système à niveau !" ```
Poster
Collaborator

Pour le cas de mises à jour non-faites j'ai cherché un peu... Et en fait l'idée serait soit de vérifier l'intégrité de apt (mais faut être root pour ça), soit de demander à unattended-upgrade de nous dire si quelque chose s'est mal passé.

Sauf que fonctionnellement il n'envoie des avertissements que par mail, ils n'ont malheureusement pas prévu de "si echec, executer un script" :(

Sinon on pourrait parser ses logs dans /var/log/unattended-upgrades et le remonter quand y a eu une ligne d'erreur. ...Mais ça semble pas très solide comme montage.

Pas de solution idéale en vue !

Pour le cas de mises à jour non-faites j'ai cherché un peu... Et en fait l'idée serait soit de vérifier l'intégrité de apt (mais faut être root pour ça), soit de demander à unattended-upgrade de nous dire si quelque chose s'est mal passé. Sauf que fonctionnellement il n'envoie des avertissements que par mail, ils n'ont malheureusement pas prévu de "si echec, executer un script" :( Sinon on pourrait parser ses logs dans /var/log/unattended-upgrades et le remonter quand y a eu une ligne d'erreur. ...Mais ça semble pas très solide comme montage. Pas de solution idéale en vue !
Collaborator

bon après, pour DFiso, vu que les mises à jour sont automatiques, les utilisateurs de DFiso ne devraient pas rendontrer ce genre de problèmes ;)

bon après, pour DFiso, vu que les mises à jour sont automatiques, les utilisateurs de DFiso ne devraient pas rendontrer ce genre de problèmes ;)
Poster
Collaborator

J'ai eu quelques retours ou apt étant cassé, unattended upgrade échouait à mettre à jour.

M'enfin c'est marginal.

Mais à la fois j'aurai trouvé ça sympa d'avoir un avertissement pour ce genre de cas. Avoir son apt cassé devrait au moins valoir une notification. :<

J'ai eu quelques retours ou apt étant cassé, unattended upgrade échouait à mettre à jour. M'enfin c'est marginal. Mais à la fois j'aurai trouvé ça sympa d'avoir un avertissement pour ce genre de cas. Avoir son apt cassé devrait au moins valoir une notification. :<
Collaborator

vrai que dans le principe, le système fait des trucs dans le dos du user, la moindre des choses, c'est de le prévenir si ça merdouille :P

vrai que dans le principe, le système fait des trucs dans le dos du user, la moindre des choses, c'est de le prévenir si ça merdouille :P
Poster
Collaborator

Juste pendant que je cherchais j'ai appris deux trois chips.

Les Màj par défaut de unattended upgrade c'est (tous les jours 6:00 et 18h ?)

OnCalendar=*-*-* 6,18:00

Et juste le update (tous les jours à 6h ?)

OnCalendar=*-*-* 6:00

Mais du coup... Ahm. Ça me semble bizarre comme timings. "Tous les jours", ça me semblerai mieux, mais bon °o°

Juste pendant que je cherchais j'ai appris deux trois chips. Les Màj par défaut de unattended upgrade c'est (tous les jours 6:00 et 18h ?) ``` OnCalendar=*-*-* 6,18:00 ``` Et juste le update (tous les jours à 6h ?) ``` OnCalendar=*-*-* 6:00 ``` Mais du coup... Ahm. Ça me semble bizarre comme timings. "Tous les jours", ça me semblerai mieux, mais bon °o°
Poster
Collaborator

J'ai regardé de plus près avec

systemctl status apt-daily.timer

Ça m'a l'air ok de ce côté.

Nan juste à défaut de mieux, je ferai un script qui à chaque démarrage (il se trouve que apt list --upgradable est lançable en utilisateur simple... Ça aurait été SUPER COOL qu'on puisse aussi le faire avec apt check)

  1. enregistre dans un fichier le nombre de mise à jour disponibles s'il y en a
  2. si le fichier existait déjà, vérifier si unattended upgrade a été executé récemment (avec systemctl status apt-daily-upgrader.timers)
  3. si c'est le cas, alors ça veut dire que des màj ont pas été faites automatiquement : lancer une notif "X màj disponibles"

Cela devrait arriver dans deux cas : quand unattended-upgrade est cassé, ou quand la personne a rajouté des repo (vu qu'unattended upgrade ne fait que la liste restreinte qu'on lui a donné).

J'ai pas de meilleur idée - mais je pense que si on le fait pas (de cette manière ou d'une autre) on laisse un angle mort dangereux sur les màj.


J'ai vite fait regardé "mon" et j'y retrouve pas trop mes petits, je sais pas pour toi. Du genre trop sac de noeud, et qui se base sur le retour des services (et je pense que unattended upgrade n'échoue pas en tant que service quand il le fait).
L'idéal serait qu'unattented ait un petit "si échoue, alors execute ce script". Mais on a pas apriori :(

J'ai regardé de plus près avec > systemctl status apt-daily.timer Ça m'a l'air ok de ce côté. Nan juste à défaut de mieux, je ferai un script qui à chaque démarrage (il se trouve que `apt list --upgradable` est lançable en utilisateur simple... Ça aurait été SUPER COOL qu'on puisse aussi le faire avec `apt check`) 1. enregistre dans un fichier le nombre de mise à jour disponibles s'il y en a 2. si le fichier existait déjà, vérifier si unattended upgrade a été executé récemment (avec `systemctl status apt-daily-upgrader.timers`) 3. si c'est le cas, alors ça veut dire que des màj ont pas été faites automatiquement : lancer une notif "X màj disponibles" Cela devrait arriver dans deux cas : quand unattended-upgrade est cassé, ou quand la personne a rajouté des repo (vu qu'unattended upgrade ne fait que la liste restreinte qu'on lui a donné). J'ai pas de meilleur idée - mais je pense que si on le fait pas (de cette manière ou d'une autre) on laisse un angle mort dangereux sur les màj. ----- J'ai vite fait regardé "mon" et j'y retrouve pas trop mes petits, je sais pas pour toi. Du genre trop sac de noeud, et qui se base sur le retour des services (et je pense que unattended upgrade n'échoue pas en tant que service quand il le fait). L'idéal serait qu'unattented ait un petit "si échoue, alors execute ce script". Mais on a pas apriori :(
Collaborator

j'avoue ne pas avoir investigué plus que ça ...

j'avoue ne pas avoir investigué plus que ça ...
Poster
Collaborator

Après, la plupart des distros previennent pas plus que ça quand tout est cassé, on serait pas inexcusables :<

Après, la plupart des distros previennent pas plus que ça quand tout est cassé, on serait pas inexcusables :<
Poster
Collaborator

Bon j'ai cherché un peu, et voilà mon essai concret le moins sale possible.

1/ Je détermine la dernière date de démarrage
2/ Je détermine la dernière fois ou un paquet a été mis à jour
3/ S'il existe des mises à jour disponnibles, qu'on avait démarré avant (et ça implique que le apt-get update était passé, sinon il y aurait pas màj dispo - donc il y avait internet) : je mets un avertissement "il y a X paquet non à jour"

Ça ressemble à ça :

last_boot=$(date +%s -d"$(last reboot | head -n2 | tail -n1 | grep -Eo '[a-Z]+ [a-Z]+ +[0-9]+ [0-9:]+')")
last_up=$(date +%s -d"$(tac /var/log/apt/history.log | grep -B1 Upgrade -m1 | head -n1 | grep -Eo '[0-9-]* +[0-9:]*$')")
upgradable=$(apt list --upgradable 2>/dev/null | wc -l); upgradable=$(($upgradable-1))

if test $upgradable -gt 0 && test $last_boot -gt $last_up
then
	notify-send -i dialog-warning -u critical "\
ATTENTION
Votre système a $upgradable paquets non à jour !
La dernière MàJ date de $((($(date +%s)-$last_up)/60/60/24)) jours
"
fi

Je vais désactiver unattended upgrade chez-moi et voir si ça marche.

(au passage "last reboot" ? La commande la plus effrayante du monde)

Bon j'ai cherché un peu, et voilà mon essai concret le moins sale possible. 1/ Je détermine la dernière date de démarrage 2/ Je détermine la dernière fois ou un paquet a été mis à jour 3/ S'il existe des mises à jour disponnibles, qu'on avait démarré avant (et ça implique que le apt-get update était passé, sinon il y aurait pas màj dispo - donc il y avait internet) : je mets un avertissement "il y a X paquet non à jour" Ça ressemble à ça : ``` last_boot=$(date +%s -d"$(last reboot | head -n2 | tail -n1 | grep -Eo '[a-Z]+ [a-Z]+ +[0-9]+ [0-9:]+')") last_up=$(date +%s -d"$(tac /var/log/apt/history.log | grep -B1 Upgrade -m1 | head -n1 | grep -Eo '[0-9-]* +[0-9:]*$')") upgradable=$(apt list --upgradable 2>/dev/null | wc -l); upgradable=$(($upgradable-1)) if test $upgradable -gt 0 && test $last_boot -gt $last_up then notify-send -i dialog-warning -u critical "\ ATTENTION Votre système a $upgradable paquets non à jour ! La dernière MàJ date de $((($(date +%s)-$last_up)/60/60/24)) jours " fi ``` Je vais désactiver unattended upgrade chez-moi et voir si ça marche. (au passage "last reboot" ? La commande la plus effrayante du monde)
Collaborator

et à coller au lancement de la session comme pour le spacenotifier alors ? me semble bien :)

et à coller au lancement de la session comme pour le spacenotifier alors ? me semble bien :)
Poster
Collaborator

Sauf que j'y ai pensé pendant une insomnie et ça marche pas si le système de màj est cassé vu que "/var/log/apt/history.log" ne laisse des logs qu'après màj réussie !

Cela dit j'ai aussi pensé à la solution, et je crois que j'ai une méthode qui marche : regarder les timers d'execution de "update/upgrade" fournis par systemctl. Je pense que ceux-là sont fiables, faut juste les deux bouts de bricolage pour les parser !

Mais oui je vois le truc comme spacenotifier. Rester simple quoi. Je me vois pas programmer un vrai logiciel, c'est vraiment pas l'idée. ^^'
D'autant que même sur des choses aussi simples on fait ce genre d'erreur, donc autant limiter la surface de fautes !

Sauf que j'y ai pensé pendant une insomnie et ça marche pas si le système de màj est cassé vu que "/var/log/apt/history.log" ne laisse des logs qu'après màj réussie ! Cela dit j'ai aussi pensé à la solution, et je crois que j'ai une méthode qui marche : regarder les timers d'execution de "update/upgrade" fournis par systemctl. Je pense que ceux-là sont fiables, faut juste les deux bouts de bricolage pour les parser ! Mais oui je vois le truc comme spacenotifier. Rester simple quoi. Je me vois pas programmer un vrai logiciel, c'est vraiment pas l'idée. ^^' D'autant que même sur des choses aussi simples on fait ce genre d'erreur, donc autant limiter la surface de fautes !
Poster
Collaborator

Finalement j'arrive pas à m'en sortir sans avoir la date où l'on sait pour sûr que des mises à jour sont disponibles (sinon à chaque fois que j'y pense y a des exceptions possibles. Si jamais t'as une fulgurance... J'ai pas eu !

Je vois pas comment obtenir cette information autrement qu'en utilisant un fichier temporaire quand apt s'en rend compte (ça donne 24h+un reboot de retard avant le premier avertissement, j'ai pas trouvé comment mieux faire !). À ce que je sache aucune commande apt ne permet de savoir "ce paquet a une mise à jour dispo depuis le XXX" ! T_T

#!/bin/sh
n_upgrade_available=$(apt list --upgradable 2>/dev/null | wc -l); upgradable=$(($upgradable-1))
indicator="$HOME/.local/available_upgrade"
last_upgrade=$(date +%s -d"$(systemctl show apt-daily-upgrade.timer | grep LastTriggerUSec= | grep -Eo '[^=]*$')")

if test $n_upgrade_available -gt 0
then
	if test -f "$indicator"
	then
		upgradable_since="$(date +%s -r $indicator)"
		if test $upgradable_since -lt $last_upgrade
		then
			notify-send -i dialog-warning -u critical \
"ATTENTION
Votre système a $n_upgrade_available paquets non à jour
Depuis au moins $((($(date +%s)-$upgradable_since)/60/60/24)) jours"
		fi
	else
		touch "$indicator"
	fi
else
	rm -f "$indicator"
fi
Finalement j'arrive pas à m'en sortir sans avoir la date où l'on sait pour sûr que des mises à jour sont disponibles (sinon à chaque fois que j'y pense y a des exceptions possibles. Si jamais t'as une fulgurance... J'ai pas eu ! Je vois pas comment obtenir cette information autrement qu'en utilisant un fichier temporaire quand apt s'en rend compte (ça donne 24h+un reboot de retard avant le premier avertissement, j'ai pas trouvé comment mieux faire !). À ce que je sache aucune commande apt ne permet de savoir "ce paquet a une mise à jour dispo depuis le XXX" ! T_T ``` #!/bin/sh n_upgrade_available=$(apt list --upgradable 2>/dev/null | wc -l); upgradable=$(($upgradable-1)) indicator="$HOME/.local/available_upgrade" last_upgrade=$(date +%s -d"$(systemctl show apt-daily-upgrade.timer | grep LastTriggerUSec= | grep -Eo '[^=]*$')") if test $n_upgrade_available -gt 0 then if test -f "$indicator" then upgradable_since="$(date +%s -r $indicator)" if test $upgradable_since -lt $last_upgrade then notify-send -i dialog-warning -u critical \ "ATTENTION Votre système a $n_upgrade_available paquets non à jour Depuis au moins $((($(date +%s)-$upgradable_since)/60/60/24)) jours" fi else touch "$indicator" fi else rm -f "$indicator" fi ```
Collaborator

... on va finir par juste coller le apt-config-auto-update + une notification et ce sera à l'utilisateur de faire ses mises à jour ...

à trop vouloir macher le travail, on finit par faire de la bouillie :P

... on va finir par juste coller le apt-config-auto-update + une notification et ce sera à l'utilisateur de faire ses mises à jour ... à trop vouloir macher le travail, on finit par faire de la bouillie :P
Poster
Collaborator

Suffirait d'avoir un bout d'information "quand y a eu la dernière MàJ buster" sur un serveur officiel ou via apt, ça résouderai tellement tout ! :(

Suffirait d'avoir un bout d'information "quand y a eu la dernière MàJ buster" sur un serveur officiel ou via apt, ça résouderai tellement tout ! :(
Collaborator

re ... bon, faudrait tout de même la sortir notre DFiso Stable non ? ;)

alors comme on ne trouve pas de bonne solution propre pour régler ce soucis de possible mise à jour en attente sur un apt "cassé", on pourrait tout simplement revenir à la configuration initiale Debian + message si il y a des mises à jour dispo et hop.

on a tenté de rendre le truc facile et viable, mais les mises à jours automatiques n'apportent pas réellement de bonus au vu du silence du système en cas de soucis.

bref .... on colle unattended-upgrades sans config + apt-auto-config-update + un message d'avertissement comme le space-notifier en ébut de session ?

et après on sort cette DFiso-Stable ! :D

re ... bon, faudrait tout de même la sortir notre DFiso Stable non ? ;) alors comme on ne trouve pas de bonne solution propre pour régler ce soucis de possible mise à jour en attente sur un apt "cassé", on pourrait tout simplement revenir à la configuration initiale Debian + message si il y a des mises à jour dispo et hop. on a tenté de rendre le truc facile et viable, mais les mises à jours automatiques n'apportent pas réellement de bonus au vu du silence du système en cas de soucis. bref .... on colle unattended-upgrades sans config + apt-auto-config-update + un message d'avertissement comme le space-notifier en ébut de session ? et après on sort cette DFiso-Stable ! :D
Poster
Collaborator

un message d’avertissement comme le space-notifier en ébut de session ?

Pis les gens utiliseraient synaptics ou le terminal ?

....Je ne pense pas que j'arriverai à le faire faire à ma mère. Tel quel, je crois qu'il vaut mieux un truc qui peut casser mais rarement, que des mises à jour faites par personne.

Pour moi autant laisser en automatique. Si on ne trouve pas un bon système d'avertissement, tant pis (mais mon script marche je le test depuis que je l'ai écrit, et j'ai pas encore eu de faux positif, donc meh).

Sinon je vois comment faire en 10 lignes un service systemd qui "touch" un fichier quand apt est cassé, et le supprime quand il est pas cassé. Ensuite au démarrage, si le fichier existe, envoyer une notif à l'utilisateur.

M'enfin dans tous les cas, je pense que ça ne devrait pas bloquer "la release stable". Ça me semble important, mais c'est peut-être pas à nous d'inventer un truc qu'existe pas encore si on a pas la confiance de bien le faire.

> un message d’avertissement comme le space-notifier en ébut de session ? Pis les gens utiliseraient synaptics ou le terminal ? ....Je ne pense pas que j'arriverai à le faire faire à ma mère. Tel quel, je crois qu'il vaut mieux un truc qui peut casser mais rarement, que des mises à jour faites par personne. Pour moi autant laisser en automatique. Si on ne trouve pas un bon système d'avertissement, tant pis (mais mon script marche je le test depuis que je l'ai écrit, et j'ai pas encore eu de faux positif, donc meh). Sinon je vois comment faire en 10 lignes un service systemd qui "touch" un fichier quand apt est cassé, et le supprime quand il est pas cassé. Ensuite au démarrage, si le fichier existe, envoyer une notif à l'utilisateur. M'enfin dans tous les cas, je pense que ça ne devrait pas bloquer "la release stable". Ça me semble important, mais c'est peut-être pas à nous d'inventer un truc qu'existe pas encore si on a pas la confiance de bien le faire.
Poster
Collaborator

Sinon encore plus simple

dpkg -l | grep ^..r

semble lister, en tant qu'utilisateur, tous les paquets cassés.

Du coup un simple dpkg -l | grep -q ^..r && notif "APT est cassé !"

Sinon encore plus simple `dpkg -l | grep ^..r` semble lister, en tant qu'utilisateur, tous les paquets cassés. Du coup un simple `dpkg -l | grep -q ^..r && notif "APT est cassé !"`
Poster
Collaborator

Je viens de trouver mieux dpkg --audit

Je viens de trouver mieux `dpkg --audit`
Poster
Collaborator

Gah, j'arrive pas à casser des paquets T_T

Gah, j'arrive pas à casser des paquets T_T
Collaborator

installe openshot et coupe ton ordi en plein milieu :D

installe openshot et coupe ton ordi en plein milieu :D
Poster
Collaborator

Tu me dira - ça résoud pas le souci de dépendance non-résolues. Mais ça part du principe que la personne a installé des trucs, et donc qu'elle est responsable d'avoir tout éventuellement tout cassé ? :p

Moi je dis, on mets un avertissement sur dpkg --audit au démarage et c'est marre.

On peut aussi faire l'avertissement EOL sans utiliser curl en utilisant les données du paquet distro-info-data au chemin /usr/share/distro-info/debian.csv.

Je commit ça, ou on fait rien et tant pis ? x)

Tu me dira - ça résoud pas le souci de dépendance non-résolues. Mais ça part du principe que la personne a installé des trucs, et donc qu'elle est responsable d'avoir tout éventuellement tout cassé ? :p Moi je dis, on mets un avertissement sur dpkg --audit au démarage et c'est marre. On peut aussi faire l'avertissement EOL sans utiliser curl en utilisant les données du paquet distro-info-data au chemin /usr/share/distro-info/debian.csv. Je commit ça, ou on fait rien et tant pis ? x)
Collaborator

je te laisse commit pour un avertissement simple avec dpkg --audit, merci pour tous ces essais :)

je te laisse commit pour un avertissement simple avec dpkg --audit, merci pour tous ces essais :)
Poster
Collaborator

Pas fan de l'idée sur la notif de fin de support du coup ? Meh, c'est facile à intégrer dans un script, donc je pousse pas :D

Pour "dpkg --audit" ma seule réserve c'est que j'ai pas réussi à le déclencher en faisant n'importe quoi. Mais si j'en crois internet il retourne parfois des choses, donc amen. Au pire, il fera rien de toute façon, et il s'execute instantanément chez moi.

Pas fan de l'idée sur la notif de fin de support du coup ? Meh, c'est facile à intégrer dans un script, donc je pousse pas :D Pour "dpkg --audit" ma seule réserve c'est que j'ai pas réussi à le déclencher en faisant n'importe quoi. Mais si j'en crois internet il retourne parfois des choses, donc amen. Au pire, il fera rien de toute façon, et il s'execute instantanément chez moi.
otyugh closed this issue 1 year ago
otyugh referenced this issue from a commit 1 year ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.