[git.spip.net] Mise à jour de l'instance

azerttyu · Février 13, 2024, 1:50

Hello

Merci pour tes retours.

Pour l’erreur 500 je vais essayer de regarder les log serveurs. Cette erreur en l’état ne me dit rien.

Pour la seconde erreur, je pense que c’est la mise à jour du thème. J’ai constaté le problème mais n’étant pas systématique et avec des rechargements navigateurs/serveurs j’avais opté pour un problème de mon coté avec un cache mal actualisé. Si c’est constaté par d’autres je vais regarder plus en détail.

Si ce n’est déjà fait peux tu ouvrir 2 tickets sur spip-galaxie/git.spip.net - git.spip.net - SPIP on GIT ? C’est peu être pour la suite l’endroit le plus approprié.

Merci

azerttyu · Février 13, 2024, 4:22

Hello

Je pense que c’est bien le depot spip/spip qui a un truc mal foutu.
Je viens de cloner le dépot en intégralité sur goldstein/spip: Dépôt officiel du core SPIP Les plugins-dist faisant partie de la distribution SPIP sont présents dans https://git.spip.net/spip/[nom du plugin dist] - spip - SPIP on GIT

J’ai mergé un PR en attente #5764 - Réafficher où on se trouve sur la page de login - spip - SPIP on GIT sur master en fast-forward et suppression de la branche
le commit est bien maintenu sur master
fix(5763): amélioration responsive pour moins d'absolute en petits écrans · 943f33b663 - spip - SPIP on GIT

Du coup je serai bien tenté de refaire un clone du dépot spip/spip et remplacer le dépot existant par le clone.
Les issues, PR, … sont maintenues du coup ça ne devrait rien casser à l’existant.

J’ai besoin d’un coupure de service de 40’ environ, le temps que le clone se fasse

marcimat · Février 13, 2024, 4:30

Je serai tenté de dire, évitons de jouer de trop sur le dépot…

Par ailleurs, ce n’est pas systématique non plus sur les merge de PR de spip/spip sinon on te solliciterait tous les jours plusieurs fois…

cerdic · Février 13, 2024, 4:50

@azerttyu s’il te plait, non, on ne touche pas au dépot SPIP, on va perdre des infos historiques

Là quand je compare

et

je vois qu’il manque plein de messages intérmédiaire dans la PR (des messages générés par gitea au fur et à mesure de la vie de la PR comme « @xx a force pushé », « @yy a référencé cette PR », « @zz a fermé cette PR » etc) parce que ce sont des messages générés et pas user et que le clone ne garde pas tout.

Je suis en train de scripter la migration vers gitlab pour récupérer tous ces messsages, et ce serait assez dramatique de saborder le dépot et l’historique des PR et issues avant ça, parce qu’une fois perdu c’est perdu.

azerttyu · Février 14, 2024, 10:19

Ok c’est noté.
Cela clarifie également l’autre sujet Migration de la zone vers un Gitlab , ce n’était donc pas une demande mais une information.

azerttyu · Février 14, 2024, 10:23

@nicod merci pour avoir ouvert les tickets.
Je crains malheureusement que c’était inutile Cela ne semble pas pertinent de consacrer du temps dans une amélioration qui ne servira strictement à rien.
Je mets en attente dans l’immédiat le temps d’avoir une meilleure visibilité sur la suite.

marcimat · Février 15, 2024, 8:20

Quelques remarques

tu as ajouté un clone spip/spip_duplicates qui me complique le suivi des PR parce que Sign In - SPIP on GIT a par conséquent toutes les PR sur spip dupliquées
ce matin je viens d’envoyer 2 commits dans master de spip/spip, sans force…

Et les 2 commits envoyés ne sont plus dans le repository. Il va de soit comme à chaque fois que Shiraz nous a bien notifié des dits commits…

dev git:(master) git push                                                                                                                                                                                                                                                                                                                                                                                      git:(master↑2|⚑12) 
Énumération des objets: 21, fait.
Décompte des objets: 100% (21/21), fait.
Compression par delta en utilisant jusqu'à 10 fils d'exécution
Compression des objets: 100% (12/12), fait.
Écriture des objets: 100% (12/12), 1.25 Kio | 1.25 Mio/s, fait.
Total 12 (delta 9), réutilisés 0 (delta 0), réutilisés du pack 0
remote: . Processing 1 references
remote: Processed 1 references in total
To git.spip.net:spip/spip.git
   224da03f0..62aed1652  master -> master

[09:11:01]  <shiraz> [spip] 2 commits par jluc (Envoyé par marcimat)
[09:11:01]  <shiraz> — https://git.spip.net/spip/spip/commit/a934919b : fix: Ne pas relancer par mail la validation de l'inscription des auteurs sans mail Refs: #5863
[09:11:01]  <shiraz> — https://git.spip.net/spip/spip/commit/62aed165 : docs(Changelog): pour #5863
[09:11:01]  <shiraz> [spip] PR n°5863 : Nouveau commentaire par marcimat | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107804 : C’est intégré.
[09:11:02]  <shiraz> [spip] PR n°5863 fermée par marcimat | https://git.spip.net/spip/spip/pulls/5863 : fix: Pas relancer par mail la validation de l'inscription des auteurs sans mail
[09:11:36]  <marcimat> NAN mais c’est une BLAGUE ?
[09:11:45]  <marcimat> je vais finir par pleurer…
[09:12:01]  <shiraz> [spip] PR n°5863 : Nouveau commentaire par JLuc | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107806 : Ah c'est pas la PR qui compte mais les commits unitaires ?  pfff    Et pourquoi dois je "Actualiser la branche par fusion" (qui ne marche pas / ne change rien)…
[09:14:01]  <shiraz> [spip] PR n°5863 : Nouveau commentaire par marcimat | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107807 : JLuc, touche à rien… Y a Gitea qui fait des siennes de nouveau !

Il y a peut-être quelque chose du côté de la synchronisation des dépots clonés; ici j’avais le repository Jluc/spip en remote pour pouvoir cherry-pick ses commits et reprendre ses logs de commits et en fusitonner 2… bref, c’est pour ça que je n’ai pas utilisé directement l’interface de Gitea de la PR.

azerttyu · Février 15, 2024, 10:52

Hello

Ce sont 2 dépôts séparés que j’ai mis dans la même organisation pour être sur que le traitement de droit soit les mêmes.

Le dépôt spip/spip n’a pas été modifié ou bougé, je ne comprends pas du coup le problème sur l’usage si on regarde les tickets du dépot

Dans tous les cas j’ai rebasculé sur le compte utilisateur spip vu que j’ai un clone iso. Je peux donc faire les diffs qui vont bien.

Le log de master montre bien des retour arrière dans les commits :

224da03f06ad7b290d534ff36d5e66401d551770 8f8026269ac3032bfe0cfc4b8ff0e228e2dbb302 Gitea <gitea@fake.local> 1707870605 +0100     push
8f8026269ac3032bfe0cfc4b8ff0e228e2dbb302 224da03f06ad7b290d534ff36d5e66401d551770 Gitea <gitea@fake.local> 1707870624 +0100     update by push
224da03f06ad7b290d534ff36d5e66401d551770 b707cbe8f657612f29a085b2d012a8c455fd07d8 Gitea <gitea@fake.local> 1707957005 +0100     push
b707cbe8f657612f29a085b2d012a8c455fd07d8 224da03f06ad7b290d534ff36d5e66401d551770 Gitea <gitea@fake.local> 1707957025 +0100     update by push
224da03f06ad7b290d534ff36d5e66401d551770 62aed1652097f18c4b44c88c21dd5c725ed1baf6 Gitea <gitea@fake.local> 1707984603 +0100     push
62aed1652097f18c4b44c88c21dd5c725ed1baf6 224da03f06ad7b290d534ff36d5e66401d551770 Gitea <gitea@fake.local> 1707984624 +0100     update by push

J’ai reforcé master sur 62aed1652 comme indiqué dans ton log.

Je vois 2 commits orphelin liés à Salvatore :
8f8026269ac3032bfe0cfc4b8ff0e228e2dbb302
b707cbe8f657612f29a085b2d012a8c455fd07d8

Est il possible de le relancer pour réaligner ses commits ?

marcimat · Février 15, 2024, 11:06

Je / on regarde l’état des PR de toute l’organisation spip/ (le lien org/spip/pulls) pour avoir un aperçu global ; pas que sur spip/spip/pulls (et oui là c’est bon, je sais bien !)

Ah bah nous n’avions pas vu pour Salvatore également, mais il semble donc que ça fait 2 nuits qu’il commit dans master et que son commit se perd ensuite. Ce qui correspond aux 2 commits indiqués.

Il en fera un 3è demain matin rebasé sur les modifications de master… attendons.

azerttyu · Février 15, 2024, 4:30

Bonjour

En faisant la différence entre le clone de spip/spip qui a géré une PR sans erreur et le dépot spip/spip j’ai vu des différences de paramétrage au niveau du dépôt à proprement parler.
J’ai ajusté la configuration en retirant ce qui me semblait superflu, à voir.

marcimat · Février 15, 2024, 5:03

Hello there…

Alors… je viens d’envoyer 2 nouveaux commits dans master via l’interface de Gitea après un force-push d’une branche, là #5866 - fix: eviter la fuite mémoire de generer_objet_info(). Si le nombres d'objet du même type que celui qu'on traite dépasse 1000, enlever le plus ancien mis dans la static avant d'en ajouter un nouveau - spip - SPIP on GIT qui semblent rester…

Cela dit, après je vais sur mon autre site 4.2 pour faire le report… et je pull d’abord… et là je suis étonné de voir une mise à jour forcée… Et effectivement plus tôt j’avais envoyé 2 commits là bas aussi, qui viennent d’être écrasés localement… en revenant en arrière donc.

git pull                                                                                                                                                                                                                                                                                                                                                                                                                              git:(4.2|⚑2) 
remote: Énumération des objets: 23, fait.
remote: Décompte des objets: 100% (23/23), fait.
remote: Compression des objets: 100% (23/23), fait.
remote: Total 23 (delta 4), réutilisés 0 (delta 0), réutilisés du pack 0
Dépaquetage des objets: 100% (23/23), 89.70 Kio | 5.98 Mio/s, fait.
Depuis git.spip.net:spip/spip
 + cce4c7c11...c0d318622 4.2        -> origin/4.2  (mise à jour forcée)

Comme d’hab shiraz avait notifié les commits, et même l’interface de Gitea est au courant :

Bref, il manque aussi des commits dans la branche 4.2…

les commits fix: Ne pas relancer par mail la validation de l'inscription des auteurs sans mail · fddec98209 - spip - SPIP on GIT et docs(Changelog): pour #5863 · cce4c7c118 - spip - SPIP on GIT donc

Y a aucun moyen de savoir quel vaudou, script, bidule, chose, repasse dans les 20 secondes derrière pour revenir en arrière ?

azerttyu · Février 15, 2024, 5:09

Pour master je vois que le merge s’est bien passé sur master.
Pour 4.2 le log donne ceci ;

6d08d3abe7f21697792bba39a2f0134521a783f7 d3edf41a67148100554729efd833f6547503b469 Gitea <gitea@fake.local> 1706176509 +0100     push
d3edf41a67148100554729efd833f6547503b469 97aa8ffdf8ff483a2755b8edc8bc6842221e7b4d Gitea <gitea@fake.local> 1706784036 +0100     push
97aa8ffdf8ff483a2755b8edc8bc6842221e7b4d c7e8c0f96838ab9cf764fb2664aea1b872cba7e0 Gitea <gitea@fake.local> 1706784288 +0100     push
c7e8c0f96838ab9cf764fb2664aea1b872cba7e0 46de7b3584e33c11eff1903bb0b7595ac910c71b Gitea <gitea@fake.local> 1707400556 +0100     push
46de7b3584e33c11eff1903bb0b7595ac910c71b c0d318622de58c3acb95d501b20bba853b1156c2 Gitea <gitea@fake.local> 1707749133 +0100     push
c0d318622de58c3acb95d501b20bba853b1156c2 cce4c7c11807a5a932fd09bfef4d7e73c45bc259 Gitea <gitea@fake.local> 1707999010 +0100     push
cce4c7c11807a5a932fd09bfef4d7e73c45bc259 c0d318622de58c3acb95d501b20bba853b1156c2 Gitea <gitea@fake.local> 1707999022 +0100     update by push

Je viens de réaligner sur cce4c7c11807a5a932fd09bfef4d7e73c45bc259 la branche 4.2

azerttyu · Février 15, 2024, 5:18

Si je savais quel truc voudou avait lieu on n’en serait pas encore au diagnostic … et le problème serait réglé.

Vu que la fusion sur master s’est passé correctement, on peut espérer que les dernières modifications sur le dépôt sont sur la bonne voie.

Pour ce dépôt spécifique, il y a longtemps on avait activé l’option
bigFileThreshold=1m ce qui est très bas la configuration par défaut est 512m

Cette option n’est pas présente sur le clone réalisé ou sur tout autre dépôt de la forge. Pour rappel on a eu pour diverses raisons eu à faire des configurations très spécifique pour ce projet.
De vague mémoire c’était un problème de charge et un effet de bord sur le cache qui n’arrivait plus à suivre.

Cette option a été retirée avant l’action de fusion précitée. Et je n’ai pas d’autres changements notable autre.

marcimat · Février 16, 2024, 12:46

Et Salvatore a bien essayé de commit, mais le commit n’y est pas

[01:31:01]  <shiraz> [spip] 1 commit par Salvatore | https://git.spip.net/spip/spip/commit/36ab2f7d : i18n: [Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue de i18n: [Salvatore] [source:ecrire/lang/ ecrire] Export depuis…
[01:43:31]  <marcimat> ah https://git.spip.net/spip/spip/ bah il y est pas le commit de salvatore

marcimat · Février 16, 2024, 8:39

Merci @azerttyu d’avoir réparé !