Forum

Reprise du message précédent

Je n'ai pas essayé de supprimer les packages car comme dit précédemment, ça risque de me désinstaller plus que je ne le désire.
Mes répertoires ressemblent aux tiens quand tout est installé, je n'ai pas d'erreur

J'ai utilisé le gros script de ce site : https://stackoverflow.com/questions/10073425/is-there-a-way-to-get-the-list-of-available-locales-in-php et j'ai également fait un locale -a dans le php, le résultat trouve bien le français et j'ai bien un retour avec les locales désirées.

Donc, je pense que le problème n'est pas système, mais c'est bien une instruction dans le code de nextcloud (mais laquelle ?!?) qui retourne un résultat non désiré, si j'arrive à trouver cette instruction, je pourrais peut-être la reproduire dans un fichier de test et avoir un code d'erreur, un code de retour ou un message explicite

EDIT : j'ai édité le fichier base.php du répertoire nextcloud pour mettre en commentaires (sans besoin de redémarrer apache) :
// $errors = OC_Util::checkServer(\OC::$server->getSystemConfig());
Nextcloud fonctionne à nouveau normalement, le client a même synchronisé mes fichiers en attente.

Reste à savoir comment/pourquoi...

Édité par HomeBoy38 Le 11/07/2019 à 09h18

Bonjour,

Je ne sais pas si le test qui est fait se trouve dans le /var/www/html/nextcloud/lib/private/legacy/util.php (en tout cas dans ce fichier, on retrouve le message d' erreur en anglais).

Ensuite dans le fichier lib/base.php, on trouve aussi reférence à issetlocaleWorking()

Et dans 3rdparty/patchwork/utf8/src/patchwork/utf8/Bootup.php, on trouve encore une référence à cette fonction.Mais je ne sais pas si cela peut aider.

Édité par nic80 Le 11/07/2019 à 09h15

lib/private/legacy/util.php : la fonction isSetLocaleWorking appelle "initLocale" du fichier 3rdparty/patchwork/utf8/src/Patchwork/Utf8/Bootup.php

Si je force cette fonction a retourner True, alors mon serveur est à nouveau fonctionnel.

Donc soit , soit (voire les 2) est responsable du problème.

Dans les commentaires, on peut lire :
et

Pour autant, sur mon système :
sudo -u apache locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
sudo -u apache echo $LANG
fr_FR.UTF-8

Je continue de chercher de mon côté. Ce pourrait-il que ce soit un bug php au niveau de setlocale et/ou basename ?

Bonjour,

Que contient l' unité systemd httpd ?

Il me semble avoir vu une ligne LANG=C dedans ( je ne peux pas vérifier pour le moment)

Bonsoir,

Effectivement dans le fichier /usr/lib/systemd/system/httpd.service, il y a :
Environment=LANG=C
Dans celui de mageia6 en tout cas.

Xuo.

Dans la v7, idem, mettre autre chose ne change rien

https://help.nextcloud.com/t/locale-issue-prevents-login/55984/4 : dans mon post, il semblerait que ce problème se retrouve dans un environnement différent, donc, ça confirme que MageIA n'a rien à voir, peut-être php?

Si tu as encore la v6, tu utilises quelle version de php? La 7.2 et la 7.3 ont le souci ?

Bonsoir,

Non, je suis encore en php 5.6.40. D'ailleurs, c'est la raison pour laquelle je ne peux pas passer à la version 14 de NextCloud.

Xuo.

Dans les backports de Mageia 6, tu as PHP 7.2

Bonjour,

Oui, j'avais déjà fait la manip je crois mais j'avais cassé autre chose (Joomla ou tiny tiny rss ou ???). Du coup, j'avais préféré attendre Mageia 7 en me disant que tout serait bien intégré. Mais là, c'est Nextcloud et le gui de BackupPC qui ne marchent pas.
Ce n'est pas un long fleuve tranquille ...
Je passe les autre PC sous Mageia7 petit à petit mais je crois que le serveur attendra encore un peu.

Xuo.

Bonjour,

Est-ce que quelqu'un a pu avancer sur ce problème, sans aller bidouiller dans le code de NextCloud ? Je voulais profiter du week-end du 15 août pour passer mon serveur en Mageia7.

Merci.

Xuo.

Pour l'instant, j'ai toujours le fichier modifié, je n'ai pas vu de mise à jour nextcloud, PHP ou autre qui me ferait penser que je peux remettre le fichier originel. Je n'ai pas vu d'effet de bord mais je n'ai pratiquement pas changé de fichier depuis et très certainement aucun qui aurait pu contenir un accent dans le nom...

Bonsoir,

Merci pour le retour. Je vais essayer d'installer NextCloud en partant de zéro sur un autre PC avec une version lamp (Apache) locale pour voir si en partant de zéro ça passe où si c'est lié à tout l'historique que l'on peut avoir (apache, nextcloud avec des modules ajoutés, je sais que j'avais modifié le fichier /etc/php.ini, ...).

Xuo.

Salut,

Alors, cette installation du 15 Août ?

Nicolas

Bonsoir,

Pas de bonnes nouvelles.
Même en partant de scratch, j'ai le même problème.
Si je mets en commentaire la ligne $errors = OC_Util::checkServer(\OC::$server->getSystemConfig()); du fichier nextcloud/lib/base.php, ça passe.

J'ai essayé de voir où était définie la fonction getSystemConfig. Elle est dans 2 fichiers :
lib/private/AllConfig.php
lib/private/Server.php

Mais là, je ne sais plus quoi faire. Il faudrait pouvoir rediriger dans le fichier le résultat de \OC::$server->getSystemConfig() pour avoir toutes les variables et pas seulement celles en erreur. Mais je ne sais pas comment faire.

J'ai fait un phpinfo et à priori, j'ai les bonnes valeurs :



J'ai plutôt l'impression que le problème vient de Mageia car il n'y a quasiment personne qui a ce problème. Si c'était général à php ou à nextcloud, je pense qu'il y aurait beaucoup plus de retours.

Mais ça ne fait pas avancer les choses ...

Xuo.

Tu peux ajouter la commande dd($ma_variable); dans le programme. Il s'arrêtera là et fera une sortie de $ma_variable (il faut y mettre ce que tu veux).

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