Forum

Reprise du message précédent

J'ai fait les mises à jour MageIA où il y avait du php et du kernel, j'ai mis à jour en NC 16.0.4 (ce qui m'a écrasé le base.php) et l'erreur est revenue.
J'ai remis le commentaire et tout est rentré dans l'ordre: donc statut quo

Une petite news du jour :
En voulant tester mon application, j'ai mis des caractères accentués et j'ai poussé le vice à mettre des caractères asiatiques dans un second temps. Je ne sais pas lequel des 2 à généré les erreurs, mais toujours est-il que le dossier est bloqué en erreur de synchronisation avec un nom qui n'est pas celui de mon dossier : l'interface affiche un nom de fichier "écô" (qui est le nom que j'ai tapé dans l'explorateur de fichiers de Windows avant de mettre les caractères asiatiques à la fin) mais le client de synchronisation cherche "cô". Si dans l'interface WEB je cherche à supprimer le dossier "écô", il m'indique que le fichier "cô" n'existe pas, renommer ne fonctionne pas non plus.

"occ files:scan mon_nom" n'a pas résolu le problème
"occ files:cleanup" n'a pas résolu le problème
"delete from oc_file_locks where 1;" sous mysql n'a pas résolu le problème
"occ maintenance:repair" n'a pas résolu le problème

de retour dans mysql :
"select * from oc_filecache where name like 'cô';" : je trouve une entrée avec mon nom de fichier
"delete from oc_filecache where fileid=id_trouvé_dans_la_commande_précédente;", je tremble un peu (j'aime pas les DELETE en SQL) et 1 row supprimé, ma synchronisation est repartie normalement.

Je ne sais pas si c'est un bug avec un caractère accentué au début (ou peu importe sa position), si c'est en rapport avec le problème de locale qui nous occupe (possible puisque dans la base codée en utf8mb4 il me semble, le dossier s'affiche correctement) ou autre.

Si quelqu'un à un environnement de tests ?

Note : j'avais un fichier avec des caractères Japonais qui lui n'a pour le moment pas de souci (mais il était déjà là avant que le problème ne se présente).

Bonjour,
Je viens de trouver un problème avec le code PHP dans Mageia 7.
Je l'ai remarqué depuis la mise à jour avec une application qui fait des fusion de documents. Les dates restent en anglais.
En regardant mon code, j'ai vu qu'il y avait pourtant une instruction explicite d'utiliser le format français.
Du coup, j'ai fait un test circonscrit, avec un bout de code PHP à mettre dans un fichier test.php :


Résultat :

alors que le dernier devrait être "31 août 2019".
Je n'ai plus de Mageia 6 pour faire le test. Ceci n'a rien à voir directement avec Nextcloud, mais j'ai l'impression que c'est la même source de problème.
J'ai déposé un rapport de bug.

Je confirme le même résultat sur ma machine MIA7

Pourrais-tu compléter le rapport avec ton résultat et une indication concernant Nextcloud ?

Ne nous emballons pas :

j'ai voulu utiliser une VM en 6.1 mais pas moyen d'installer php dessus il cherche des dépendences, bref...

par contre j'ai aussi une VM en 7.0 et là ton script me retourne :
2019-08-31
31 August 2019
31 août 2019
cette V7 a été installée from scratch il me semble, contrairement à celle qui ne fonctionne pas et qui était une MAJ

J'ai comparé mes 2 php.ini et à part un paramètre conseillé par nextcloud sur la mémoire, ils sont identiques

Pareil pour moi, c'est une migration.

Une idée de quoi chercher entre les 2 vm ?

Bonjour,

Comme il s'agit d' un problème de locale, j'aurais pencher pour quelque chose dans le genre, mais cette partie a déjà été explorée (est ce que les répertoires installés par les paquets locales contiennent des différences (la mise à jour laissant peut être des fichiers en trop ?) ?

On peut aussi comparer les environnements de l'utilisateur Apache (commande "env"), voir regarder si un fichier rpm.new n' aurait pas été crée pour Apache, voir mysql)

env : à part des références à QT, pas de différence notable
locales.conf et 70_mod_php.conf : identiques

/etc/locale : uniquement le dossier fr sur la config qui fonctionne (le script php, nextcloud non installé), contre toute attente.

Tu as quoi papoteur ?

Édité par HomeBoy38 Le 09/09/2019 à 22h59

Dans /etc/locale, un max de truc, je dois avoir toutes les langues, et en particulier, fr, fr_FR, fr_FR.UTF8

Visiblement, une fausse piste : j'ai cherché le paquet qui installe ces fichiers et aucun résultat. J'ai renommé le répertoire pour le désactiver et relancé httpd, mais le script php retourne toujours August.

La vérité est ailleurs... : /usr/share/locale ?

Ce dossier est bien plus volumineux et incomparable :S

En passant, la modification de mon fichier lib/base.php me retourne une erreur d'intégrité dans le scan périodique de NextCloud.

hors sujet : le temps de rédaction d'une de mes réponses prend parfois un certain temps et même si le jeton expire, ce forum retrouve la rédaction de ce post et je n'ai plus qu'à le renvoyer au lieu de le retaper entièrement, qu'est-ce que c'est appréciable !!!

Édité par HomeBoy38 Le 10/09/2019 à 19h07

Bonsoir,

Sur le hors sujet : en effet, c'est appréciable vu le nombre de fois que j'ai du me retaper toute la réponse ... Mais on fait comment car si je reload, je perds ce que j'avais écris.

Xuo.

On pleure très fort auprès des développeurs de PHPBOOST. J'ai déjà fait des remarques à ce sujet, sans qu'on puisse avoir d'amélioration.
Voir https://www.mageialinux-online.org/forum/topic.php?id=25812#m247713
Vous pouvez en rajouter une couche.

Je viens de valider le script php sous MageIA6, j'ai fait une migration en 7 et le script marche toujours.

comment faire le debug de la ligne setlocale(LC_TIME, "fr_FR.utf8"); ?

EDIT :

$locale_result=setlocale(LC_TIME, "fr_FR.utf8");
le résultat est fr_FR.utf8
$locale_result=setlocale(LC_TIME, "fr_FR");
le résultat est fr_FR
$locale_result=setlocale(LC_TIME, "fr_FR.UTF-8");
le résultat est fr_FR.UTF-8
$locale_result=setlocale(LC_TIME, "fr_FR.utfZ8");
le résultat est vide

donc, je pense que si la locale est inconnue du système, elle n'est pas retournée comme prévu, donc, cette ligne fonctionne

Édité par HomeBoy38 Le 15/09/2019 à 20h21

Sans suprise avec le 16.0.5 (la vérité est ailleurs)