La publication de la dépêche était bloquée à cause d'un segfault sur la bibliothèque qui gère le markdown, RDiscount, lors de la génération de la table des matières.
En attendant, j'ai remonté la taille à atteindre pour qu'une table des matières soit générée. Du coup, la dépêche en question n'aura pas de table de matières mais a pu être poussée dans l'espace de modération pour être publiée demain ou après-demain.
Je garde cette entrée ouverte pour penser à suivre les changements de RDiscount, et à redescendre la limite quand ce bug sera corrigé.
Bon, après investigation, je penche pour un processus Ruby (un des workers Unicorn) qui serait devenu "fou" : plus de connexion à la base de données et ne répond plus au master sur les restarts. L'explication ne me plaît que moyennement : j'aurais bien aimé connaître les raisons qui ont permis d'en arriver là. Mais je crois que je vais me résoudre à en rester là.
J'ai fait le ménage dans les unicorns et je ne vois plus passer d'erreurs 500 dans les logs. Je garde encore un peu l'entrée ouverte au cas où le bug réapparaitrait, mais si ça reste stable pendant 24h, elle sera fermée.
Les seuils de modération suivent exactement la même règle que pour la version templeet. Il semblerait surtout que l'équipe des AMR soit moins active ces derniers temps.
Vu que les premières questions n'ont pas apportées d'éléments de réponses, on va en essayer d'autres :
Est-ce que vous bloquez l'envoi du REFERER ?
Est-ce qu'olcc envoie bien un REFERER en linuxfr.org ?
Si vous ouvrez deux sessions, disons une dans firefox pour naviguer normalement et une dans un autre navigateur qui va servir pour la tribune, est-ce que vous avez encore ce problème de déconnexion ? Pour quelle(s) session(s) : celle de firefox ou celle de la tribune ?
pourquoi B et C ont été cachés mais pas G et H ?
Parce que G et H ne sont pas sur le chemin entre le curseur (F) et sa racine (A)
il se passe quoi quand on clique sur [<-] ? la même chose que pour [->] ?
Pour [<-] il se passe la même chose que pour [->].
On redéplie tout et on redonne le focus au curseur mémorisé i.e F.
C'est juste pour différencier le curseur et tous les commentaires qui sont sur le chemin réduit; mais l'effet est le même .
Bon, je reprend mon commentaire pour expliciter ma proposition en ASCII art
Imaginons le thread suivant dans un journal:
A
|-B
|-C
|-D
| |-E
| |-F
|-G
|-H
Dans ce thread, si F et H sont 2 nouveaux commentaires, lorsqu'on clique sur ">", le focus se retrouve sur F avec "Nouveau commentaire: 1/2"
Si on veut relire le fil on doit cliquer sur [^] pour sauter E et pour voir D, puis recommencer jusqu'à A. (Imaginons avec une dizaine de niveaux)
Ma proposition est la suivante:
Lorsqu'on clique sur [^] de F, l'arbre ressemble à ca:
A [->]
|-D [->]
| |-F [<-]
|-G [^]
|-H [^]
L'arbre est replié, le commentaire F a le sticker ([<-]) et le commentaires qui ne sont des ancêtres masqués.
Le focus est donné à D, le commentaire au dessus, ou à A, la racine (à tester).
Ainsi, on voit tout le fil en condensé (A-D-F) rien qu'en faisant défiler l'ascenseur.
Une fois qu'on s'est replacé dans le contexte, on clique sur [->] du commentaire qu'on visualise et on se retrouve dans la situation antérieure avec le focus sur à nouveau sur F et le mode "sticky" désactivé.
On peut aussi cliquer sur commentaire suivant ">" pour sauter sur H et si on n'a pas encore enlevé le sticker sur F, on peut quand même le déplacer sur H et l'arbre se retrouve sous cette forme
A [->]
|-H [<-]
Les boutons [+] seraient toujours présents pour dérouler l'arbre progressivement (ou récursivement à voir)
Je ne rencontre pas ce problème et je n'ai pas trop d'idées de quoi ça peut venir, donc ça risque d'être compliqué à corriger.
Quelques questions pour essayer de trouver une piste :
Quel navigateur utilises-tu ?
Est-ce que tu passes par un proxy ?
Est-ce que cela arrive juste quand tu fais une action (poster un commentaire, pertinenter, poster sur la tribune) ou aussi juste en navigant sur le site ?
Utilises-tu la version http ou https du site ?
Est-ce que tu pourrais noter l'heure à laquelle ça arrive ?
Non, faut aussi que le proxy n'envoie pas le header X-Forwarded-For, et un proxy qui ferait ça (envoyer Client-IP mais pas X-Forwarded-For) est un proxy mal configuré.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pb de cache HTTP sur load.png. Évalué à 2 (+0/-0).
Cf https://github.com/nono/admin-linuxfr.org/commit/2503f7368191bf8ede4ddf1da78088fe5af081c2
# Segfault sur rdiscount :/
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi 500 lors de la publication d'une dépêche collaborative. Évalué à 3 (+0/-0).
La publication de la dépêche était bloquée à cause d'un segfault sur la bibliothèque qui gère le markdown, RDiscount, lors de la génération de la table des matières.
J'ai essayé de corriger le problème mais sans y arriver. Le bug a donc été remonté à RDiscount : https://github.com/rtomayko/rdiscount/issues/36
En attendant, j'ai remonté la taille à atteindre pour qu'une table des matières soit générée. Du coup, la dépêche en question n'aura pas de table de matières mais a pu être poussée dans l'espace de modération pour être publiée demain ou après-demain.
Je garde cette entrée ouverte pour penser à suivre les changements de RDiscount, et à redescendre la limite quand ce bug sera corrigé.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Liens relatifs dans le flux atom des commentaires du suivi. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/a228aad0cf20b77111b440bb7c0b9488acf8dbfa
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Retour au contenu associé.. Évalué à 2 (+0/-0).
https://github.com/nono/linuxfr.org/commit/f6e8fd6f1f7f9fb3433976dd1c86bd52d8cd1029
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Trier les entrées. Évalué à 2 (+0/-0).
https://github.com/nono/linuxfr.org/commit/bff52c4744b8cb77b7aa5f21741db37329c191e5
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi tri du suivi. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/trier-les-entr%C3%A9es
# Invalide
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Réouverture de ticket. Évalué à 2 (+0/-0).
C'est déjà le cas : les AMR et l'auteur d'une entrée peuvent la réouvrir en cliquant sur le lien Modifier et en changeant son état.
[^] # Re: Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Haut/bas de page. Évalué à 2 (+0/-0).
Axioplase, est-ce que la réponse (utiliser
g
etG
) te convient ?[^] # Re: titre
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Désactiver markdown. Évalué à 2 (+0/-0).
Précisions : il faut mettre des lignes vides entre les citations de différents niveaux :
# Pas de compte facebook
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Reprendre des images des liens url. Évalué à 2 (+0/-0).
Je n'ai pas de compte facebook, donc j'aimerais bien avoir une capture d'écran pour voir à quoi ça ressemble.
# Humpf
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi plein d'erreur 500 ce matin. Évalué à 4 (+0/-0).
Bon, après investigation, je penche pour un processus Ruby (un des workers Unicorn) qui serait devenu "fou" : plus de connexion à la base de données et ne répond plus au master sur les restarts. L'explication ne me plaît que moyennement : j'aurais bien aimé connaître les raisons qui ont permis d'en arriver là. Mais je crois que je vais me résoudre à en rester là.
J'ai fait le ménage dans les unicorns et je ne vois plus passer d'erreurs 500 dans les logs. Je garde encore un peu l'entrée ouverte au cas où le bug réapparaitrait, mais si ça reste stable pendant 24h, elle sera fermée.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Quelques Oops. Évalué à 2 (+0/-0).
C'est un doublon de http://linuxfr.org/suivi/plein-derreur-500-ce-matin
[^] # Re: Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi erreur 500 lors de l'accès au tableau de bord. Évalué à 2 (+0/-0).
Oui, je ferme cette entrée.
# Pas convaincu
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Seuil de validation des dépêches. Évalué à 2 (+0/-0).
Les seuils de modération suivent exactement la même règle que pour la version templeet. Il semblerait surtout que l'équipe des AMR soit moins active ces derniers temps.
# 2ème lot de questions
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Déconnexions intempestives. Évalué à 2 (+0/-0).
Vu que les premières questions n'ont pas apportées d'éléments de réponses, on va en essayer d'autres :
# 2 bugs remontés par Lineplus à propos de grayscale
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Feuilles de style mobile et impression. Évalué à 2 (+0/-0).
PS : J'ai découvert deux bugs, il faudrait remplacer :
Par :
Et ajouter à la fin du code :
Merci d'avance.
[^] # Re: Explications
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Navigation avancée dans les commentaires. Évalué à 2 (+0/-0).
Le Cancre Las :
pourquoi B et C ont été cachés mais pas G et H ? Parce que G et H ne sont pas sur le chemin entre le curseur (F) et sa racine (A)
Pour
[<-]
il se passe la même chose que pour[->]
. On redéplie tout et on redonne le focus au curseur mémorisé i.e F. C'est juste pour différencier le curseur et tous les commentaires qui sont sur le chemin réduit; mais l'effet est le même .Merci de t'intéresser à cette demande
[^] # Re: Explications
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Navigation avancée dans les commentaires. Évalué à 2 (+0/-0).
NoNo :
Même avec l'ascii art, je ne suis pas sûr de tout comprendre :
[<-]
? la même chose que pour[->]
?# Explications
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Navigation avancée dans les commentaires. Évalué à 2 (+0/-0).
Le Cancre Las :
Bon, je reprend mon commentaire pour expliciter ma proposition en ASCII art
Imaginons le thread suivant dans un journal:
Dans ce thread, si F et H sont 2 nouveaux commentaires, lorsqu'on clique sur ">", le focus se retrouve sur F avec "Nouveau commentaire: 1/2" Si on veut relire le fil on doit cliquer sur
[^]
pour sauter E et pour voir D, puis recommencer jusqu'à A. (Imaginons avec une dizaine de niveaux)Ma proposition est la suivante: Lorsqu'on clique sur
[^]
de F, l'arbre ressemble à ca:L'arbre est replié, le commentaire F a le sticker (
[<-]
) et le commentaires qui ne sont des ancêtres masqués. Le focus est donné à D, le commentaire au dessus, ou à A, la racine (à tester). Ainsi, on voit tout le fil en condensé (A-D-F) rien qu'en faisant défiler l'ascenseur. Une fois qu'on s'est replacé dans le contexte, on clique sur[->]
du commentaire qu'on visualise et on se retrouve dans la situation antérieure avec le focus sur à nouveau sur F et le mode "sticky" désactivé.On peut aussi cliquer sur commentaire suivant ">" pour sauter sur H et si on n'a pas encore enlevé le sticker sur F, on peut quand même le déplacer sur H et l'arbre se retrouve sous cette forme
Les boutons
[+]
seraient toujours présents pour dérouler l'arbre progressivement (ou récursivement à voir)# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Retrouver les options de filtres pour les entrées du suivi. Évalué à 2 (+0/-0).
C'est fait.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Filtrer les catégories de suivi. Évalué à 2 (+0/-0).
C'est fait.
# Hum....
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Déconnexions intempestives. Évalué à 4 (+0/-0).
Je ne rencontre pas ce problème et je n'ai pas trop d'idées de quoi ça peut venir, donc ça risque d'être compliqué à corriger.
Quelques questions pour essayer de trouver une piste :
# Véto
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Levée de l'anonymat des (plus/moins)sage. Évalué à 3 (+0/-0).
Ce genre de fonctionnalité encourage les réactions épidermiques et les gueguerres inutiles et ne sera pas donc pas implémenté.
[^] # Re: Ça vient de Rails
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Login impossible avec extension IPFuck. Évalué à 3 (+0/-0).
Non, faut aussi que le proxy n'envoie pas le header X-Forwarded-For, et un proxy qui ferait ça (envoyer Client-IP mais pas X-Forwarded-For) est un proxy mal configuré.
# Un volontaire ?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des citations dans la CSS color. Évalué à 2 (+0/-0).
Ça serait bien d'avoir un volontaire pour s'occuper de la CSS color et proposer des patchs.