Je capitule sur Plone: toujours le même pb et pas le temps d'apprendre à utiliser pdb, avec plusieurs processes a forciori.

Donc, pour installer depuis un emplacement du serveur, il faut encore comprendre comment s'est censé fonctionner: le truc attend un répertoire en guise de paramètre, et le pack downloadé est un zip (de l'arborescence modifiée par le pack, à ce que j'en comprend).

J'ai quand même eu une minute d'espoir en trouvant deux paramètres ('debug' et 'error reporting', respectivement passés à 'enabled' et à 'maximum'), jusqu'à ce que j'en vois l'effet époustouflant: j'ai donc la liste des requêtes SQL exécutées pour produire chaque page, et toujours pas plus d'info concernant mon 'can't move blablabla...'. Magnifique.

Fini, au moins pour ce soir.

shes wrote on 29. Jun 2006 at 19:07:

Oui, j'avoue que je suis un peu découragé: j'ai passé une ou deux journées à essayer de porter gnash dans pkgsrc, et ça m'a rappellé pourquoi je déteste les gnuseries, les gnomeries et toute ces m... d'automachins qui vont bien avec. Et deux jours de plus à essayer de faire fonctionner Plone pour l'abandonner au final, faute de connaitre un minimum de Python.

(Au passage, piqûre de rappel sur ma question dans 'flash': quelqu'un a-t-il un glibgl.h sur sa machine ? si oui, de quel port provient-il, svp ? (pkg_info -W abs_filename ou peut-être -F sur FBSD, je sais plus))
shes wrote on 29. Jun 2006 at 19:07:

C'est activé chez moi, mais ça ne change rien. La bulle d'aide précise par ailleurs que ça ne concerne que le flux servi. Côté PHP (via System Info), zlib est activée aussi.
shes wrote on 29. Jun 2006 at 19:07:

Peut-être une question de droits: et si un fichier de log pouvait le préciser, ce serait bien. Je ne comprends pas qu'un soft de cette envergure ne logge rien. C'est aberrant.
D'ailleurs, s'il s'agissait d'un pb de permissions, pourquoi tant les vérifications initiales durant le setup, que celles effectuées à l'entrée du module d'installation affirment que tout va bien ? Tout est vert: c'est juste pour faire joli ?
Pour répondre à ta question: l'utilisateur 'www' a bien les droits qu'il lui faut, où il faut (toujours en me fiant aux vérifs initiales). Ce n'est pas la première install d'un machin PHP que je fais, et je crois avoir pigé les permissions unix relativement bien. Je n'ai pas l'intention de tout passer en 777 pour masquer le pb.
shes wrote on 29. Jun 2006 at 19:07:

Je vais regarder ces options, mais je persiste à penser que le port devrait installer les répertoires avec des users/groups/permissions correctes pour fonctionner 'out of the box' (il y a un +MTREE_DIRS, après tout).
Pour ce qui est de configuration.php, il n'y a pas à proposer d'alternative: pas d'accès pour 'others', point. Le programme devrait forcer ça sans demander l'avis de l'utilisateur.
shes wrote on 29. Jun 2006 at 19:07:

Pas tout à fait d'accord. Il y a quand même des avantages indéniables à utiliser un système de paquets: les mises à jour et security/portaudit notamment.
Après, que le port ait besoin de correctifs, c'est possible. Si c'est le cas (on verra si je trouve la solution à mes petits problèmes), je le ferai remonter au mainteneur concerné.
shes wrote on 29. Jun 2006 at 19:07:

Moi non plus
Merci en tout cas pour tes indications. Je vais continuer à chercher.

C'est un point de vue biaisé n'étant pas programmeur, et ayant subi ces derniers temps les effets de bord de la portabilité façon GNU, mais:

• je ne suis pas sûr qu'un shell de 5000 lignes soit nécessaire pour 'configurer' un package aussi simple que dtach. Et les 15000-20000 lignes sont monnaie courante.
• je ne suis pas non plus certain de l'efficacité ni de la rationalité qu'il peut y avoir à tester la présence d'un compilo fortran 77 presqu'à tous les coups
• je trouve bizarre que cette 'auto'configuration nécessite souvent de petits coups de pouce de la part du porteur d'un logiciel vers un environnement non-GNU

Bref, question portabilité, j'avais l'idée naïve que c'était les standards qui devaient le permettre (ANSI pour le C, SUS pour les OS, etc.) Je sais bien que personne ne prend la peine de les respecter, mais quitte à utiliser une couche supplémentaire, pourquoi ne pas essayer de faire mieux. J'y connais pas grand'chose, mais il y a des alternatives (cmake par exemple). Quelqu'un a-t-il déjà utilisé autre chose que la suite autotools et nous ferait partager son expérience ? Ca m'intéresse, et puis ça animerait un peu les forums qui semblent bien morts ces derniers jours.

Sinon, j'avais l'impression d'avoir trouvé la réponse à mon problème mais 'choux blanc'. Néanmoins, ça soulève une question sur PHP: lorsque upload_tmp_dir n'est pas spécifié dans php.ini, quelle valeur par défaut prend-il ? Le commentaire dans le fichier n'aide pas trop:
Code:

; Temporary directory for HTTP uploaded files (will use system default if not specified). 

Le truc rigolo, c'est que je pensais que le 'system default' était justement donné par ce fichier de config (/usr/local/etc/php.ini). Je deviens cinglé ? Je mange du bois ?

Oui, c'est bien ça. Le language pack étant assez gros (2.5Mo), ça m'a laissé le temps d'apercevoir un /tmp/phpZP..., ce qui confirme que l'upload en tant que tel fonctionne.
Dans le même temps, en trussant les httpd, j'ai pu voir que les permissions sur le répertoire de destination (/www/joomla/media) sont OK (access(2) avec modes 0 puis 2, succès les deux fois).
Maintenant, il faudrait que j'arrive à tracer ce qu'il se passe du côté de PHP... Et là, je suis dans les choux

A part ça, j'ai testé les deux paramètres évoqués plus haut (chmod'er les nouveaux fichiers/répertoires), sans succès.

fgudin wrote on 30. Jun 2006 at 16:41:

Oui, scons fait bien son boulot aussi. Mais les autotools possèdent un tas d'outils, de macros bien pratiques, car largement utilisés.