Re: recherche sponsor pour nouveaux paquets [OBM]
Yves-Alexis Perez wrote: On Wed, May 07, 2008 at 11:29:48AM +0200, Sylvain Garcia wrote: Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. […] Actuellement les paquets proposés ne configurent pas tout un OBM, mais seulement la BD, et la configuration d'apache. On a donc accès à beaucoup de fonctionnalité d'OBM dans un premier temps. Mon but est d'intégrer le reste petit à petit; la gestion de l'annuaire LDAP, de Samba, et surtout de la messagerie. Où ça en est, au final ? Cheers, Pour l'instant, rien n’est fait, c'est toujours au point mort. En fait, j'ai eu pas mal de discussion sur la ml debian mentors (et aussi sur celle-ci ;-) ). Nous ne sommes pas parvenus à nous mettre d'accord sur le découpage des paquets, des deux cotés nous comprenions les points de vue, mais on a rien fait ensemble.Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 OBM - La messagerie collaborative - http://www.obm.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Quoting Yves-Alexis Perez: On jeu, 2008-11-13 at 14:18 +0100, Sylvain GARCIA wrote: Pour l'instant, rien n’est fait, c'est toujours au point mort. En fait, j'ai eu pas mal de discussion sur la ml debian mentors (et aussi sur celle-ci ;-) ). Nous ne sommes pas parvenus à nous mettre d'accord sur le découpage des paquets, des deux cotés nous comprenions les points de vue, mais on a rien fait ensemble. Et en gros le statut final c'était quoi ? Et quelles étaient les dissensions ? (un rapide résumé des discussions éparpillées, genre) Alors, pour commencer tu trouveras l'architecture tous les paquets (de deb.obm.org) sur cette page: http://www.obm.org/doku.php?id=debian_etch Le problème vient de l'utilisation du paquet de obm-conf avec obm-storage qui utilise dbconfig-common. J'explique le topo: * L'architecture des paquets (au complet) permettent dinstaller un OBM sur un seul serveur mais aussi sur plusieurs serveur répartis. Le but étant de répondre correctement au questions et hop! j'ai un OBM installé sur 4,5,.. serveurs qui fonctionne out of the box. Dans le schéma tu remarqueras que chaque paquets (ou presque) dépend de obm-conf, car nous avons centraliser la conf dans un paquets. Le problème et que dbconfig-common est capable de générer le fichier de conf, mais je ne l'utilise pas. * pourquoi je ne l'utilise pas? tu remarquera que obm-storage dépend de obm-core qui est en fait le code php d'OBM. Cela est necessaire lors d'upgrade de BD. Lors d'upgrade il arrive que nous utilisions les API ou je devrait dire des bouts de code d'OBM afin de manipuler les datas du calendrier, des contacts, du CRM ou autres. *si je génère la configuration avec obm-storage alors j'aurais obligatoirement a installer tout le code php sur tous les serveur, ainsi que le SGBD... *une solution possible: jouer avec le type de dépendances, mais cela oblige a devoir installer au préalable le SGBD, et donc le simple aptitude install obm ne fonctionnera pas out of the box petite précision le paquet obm est un meta paquet qui tire le tout. Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. À un moment il faudrait prendre une décision aussi :) Si c'est rapport à la policy Debian c'est sur que y'a pas vraiment moyen de transiger (pour de bonnes raisons). Pour le reste… Non, a priori pour la policy debian je respecte (enfin j'espère) ;) Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Donc ceux de deb.obm.org il vaut mieux pas les utiliser, ils sont « crapy » ? Ceux de Ubuntu sont comment ? (je veux bien qu'ils aient des règles moins strictes mais tout de même) hummm.. j'ai vu passé un troll.. passons.. (ps: je suis utilisateur de la sid ;-) ) Attention, petite méprise :D une partie des paquets sur obm.org ne respecte pas la policy debian et j'en suis conscient et je ne peux pas faire autrement pour l'instant, petit aperçu: - j'explose des fichiers de conf - le vhost par défaut d'apache et dégager, j'en met un en https.(il me semble que dans la lenny ou la ubuntu on a maintenant un site-enable pour https, donc se sera a corriger) - lintian m'insulte et ça déjà c'est pas bien. Il y a des pistes pour améliorer tous ça, et je le fait petit a petit, exemple du vhost,. il y a aussi openldap qui par exemple dans ubuntu passe par défaut en cn=config (je sais pas pour debian) Le travail que j'effectue sur les paquets d'ubuntu est réparcuter sur les paquet d'obm.org, et vis versa. Cependant le paquet Ubuntu ont donc été alléger de tout les truc crapy que j'ai fais ( enfin j'espère qu'il en reste pas :D) Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. Argh. De mon côté je serais intéressé éventuellement intéressé par OBM, mais ça serait clairement sous réserve d'avoir des paquets propres et bien intégrés à la distrib. Donc pas des paquets « crapy » et pas des paquets Ubuntu à peine remodelés :) sauf si les paquet ubuntu sont correcte non? ou a remodeler? :-D Cheers, -- Yves-Alexis Mon but est d'intégrer au fur et a mesure dans les distribs (Debian ET Ubuntu) tous les composants d'OBM. Cela est difficile a gérer car OBM a besoin d'une configuration spécifique pour chaque services, et je n'ai pas trouver d'exemple d'autres logiciels (dans Debian) qui utilise par exemple cyrus avec une conf spécifique, et c'est un peu la même chose pour tous les services qu'obm a besoin. Je suis pas DD, je ne suis pas non plus MOTU, juste un membre de la team OBM qui souhaite diffuser au mieux OBM pour tous le monde. voilà :D -- Sylvain Garcia [EMAIL PROTECTED
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : OoO En cette soirée bien amorcée du jeudi 29 mai 2008, vers 22:08, Sylvain GARCIA [EMAIL PROTECTED] disait: Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un ensemble d'API ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les API disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D ) Tous ces scripts de mise à jour peuvent être exécutés à distance, non ? Il y a bien une partie d'OBM qui constitue le coeur et qui va être le composant central de la solution. C'est ce coeur qui doit s'occuper de la base de données (qui n'est pas optionnelle). L'installation du paquet obm-core va donc installer avec dbconfig-common la base de données sur un serveur distant (qui ne contient qu'une base de données) et sa mise à jour va exécuter des scripts PHP pour mettre à jour la base de données. Mais bon, du coup, cela remet un peu en cause le paquet obm-ui qui s'il dépend d'obm-core et est installé sur une autre machine va aussi vouloir configurer une base de données, ce qui va perdre un peu l'utilisateur. Mais comme pour le moment, il n'existe pas d'autres paquets, il suffit d'intégrer obm-ui (un fichier de configuration pour Apache) dans obm-core. hum, ouai, je vais réflechir a cela avec l'équipe de dev OBM. Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Perso, je ne pense pas qu'il faut se projeter autant dans l'avenir. P'tet que le découpage paraîtra plus évident une fois qu'il y aura réellement un composant qui devra s'installer sur une autre machine. La situation actuelle, c'est qu'il y a deux paquets (obm-ui et obm-storage) qui sont quasiment vides en dehors des scripts de postinst (dbconfig-common inclus). J'ai déjà eu le cas avec uuwaf-preferences qui se contente de configurer une base MySQL pour être utilisée avec uuwaf (un peu comme obm-storage donc). Cependant : - uuwaf-preferences est optionnel - la base de données est tellement générique qu'elle peut utiliser directement la couche d'abstraction du framework ; elle n'a donc pas de code propre à elle Il me semble que dans obm, le premier point n'est pas vérifié. Pour le second, n'y-a-t'il pas dans obm-core du code qui n'est utile que pour obm-storage ? Découper un logiciel en plusieurs paquets a l'avantage de la modularité (ce que tu cherches à obtenir). Toutefois, il y a aussi quelques gros inconvénients : - les utilisateurs peuvent rapporter des bugs contre chacun des paquets, ne pas rapporter le bug contre le bon paquet, ne pas consulter les bugs des autres paquets (on a fait l'erreur de couper roundcube en deux paquets, ce qui n'a finalement pas apporté grand chose, mais du coup, les utilisateurs sont un peu perdus) - les mises à jour sont plus difficiles, il faut faire attention en transférant les fichiers d'un paquet à un autre, il faut faire attention aux versions, on peut casser une installation parce qu'un des paquets n'a pas réussi à s'installer et le système sera alors dans un état bancal (ce peut aussi être le cas avec un seul paquet, mais c'est généralement moins grave) - un paquet ne peut pas modifier les fichiers de configuration d'un autre paquet (ce que tu résous en ayant deux mécanismes de configuration de la base de données pour obm-core, l'une qui pose les questions, l'autre qui récupère les réponses de obm-storage si elles sont présentes ; il me semble d'ailleurs que ce n'est pas garanti que les scripts de postinst vont s'exécuter comme tu l'entends vu qu'il y a une dépendance circulaire. Par contre, il est relativement aisé de couper en deux un package (même s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu essaies de faire ici). Ok, Bon on a eut beaucoup
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : [...] Par contre, il est relativement aisé de couper en deux un package (même s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu essaies de faire ici). Et dans un autre message : Suite a nos conversation et vos remarques, j'ai cherché un moyen de regrouper les paquets. J'ai discuter avec Yann Dirson, un nouveaux collaborateur de ma société et aussi DD. Il en pense quoi du découpage ? :) Je l'ai juste croisé dans un couloir et on a discuté en vitesse. Il a pas encore jeter un oeuil aux paquets. -- No fortunes found -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Wed, 2008-05-28 at 21:16 +0200, Vincent Bernat wrote: OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55, Cedric Delfosse [EMAIL PROTECTED] disait: En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui). En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus. Vincent, est-ce la même chose qui te gênait dans le packaging ? Un peu. En fait, obm-storage se contente de configurer la base de données avec dbconfig-common. Mais si obm le faisait, ce serait pareil : dbconfig-common sait configurer une base distante. obm-ui se contenter d'installer une conf d'Apache. obm pourrait le faire de la même façon. Maintenant, Sylvain a donné sur debian-mentors@ quelques arguments dont un schéma pour expliquer les dépendances. Du coup, je suis un peu moins catégorique qu'avant, mais ça me semble toujours bizarre (je trouve que tout devrait être dans le même package). Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Re, Suite a nos conversation et vos remarques, j'ai cherché un moyen de regrouper les paquets. J'ai discuter avec Yann Dirson, un nouveaux collaborateur de ma société et aussi DD. Je me suis penché sur le raprochement des paquet obm-conf et obm-storage. Le but étant de généré le fichier de conf par dbconfig-common soit en backend ou en frontend, comme-ça, soit on install la BD soit on a juste le fichier de conf. J'ai donc modifier les paquet pour que cela fonctionne. Et là je me suis souvenu de pourquoi je n'ai pas utilisé cela à l'origine: Pour re-situer, obm-conf est requis par presque tous les autre paquets, c'est simplement un fichier de conf. Le problème c'est que si je regroupe obm-conf avec obm-storage, je n'aurais pas de problème pour généré le fichier de conf correctement.MAIS dans le cas d'une installation multiserveur si on a 1 seul paquet pour la conf et la BD, ce même paquet doit avoir une dépendance sur Mysql, sauf si on l'install en Backend pour avoir seulement le fichier de conf... DOnc cela n'est pas jouable, à la limite on se retrouve avec un paquet obm-frontend et obm-backend ce qui revient au même que obm-conf et obm-storage. Voilà, en attente de vos retour. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Thu, 2008-06-05 at 14:39 +0200, Raphael Hertzog wrote: On Thu, 05 Jun 2008, Sylvain Garcia wrote: généré le fichier de conf correctement.MAIS dans le cas d'une installation multiserveur si on a 1 seul paquet pour la conf et la BD, ce même paquet doit avoir une dépendance sur Mysql, sauf si on l'install en Backend pour avoir seulement le fichier de conf... DOnc cela n'est pas jouable, à la limite on se retrouve avec un paquet obm-frontend et obm-backend ce qui revient au même que obm-conf et obm-storage. Le serveur de BD peut toujours être distant et il n'y a donc pas lieu de mettre une dépendance en dur sur mysql. Des réponses à des questions debconf permettent au paquet de connaître le souhait réel de l'admin et de s'adapter en fonction. oui ok, mais si il n'y a pas de dépendance sur mysql, l'installation du paquet en Backend va échoué lors de la création du user et de la BD. En fait je trouve ça un peu louche. Le but étant d'avoir un aptitude install obm et hop ça marche, pour être le plus facilement utilisable. Il est plus pratique de garder l'architecture des paquets actuel, ainsi l'installation est assez facile et fonctionnel dans tous les cas. Si l'on regroupe obm-conf et obm-storage alors il faut enlever la dépendace sur mysql c'est donc une tache de plus a faire par l'admin,( avant d'installer OBM il faut d'abord installer mysql-server) alors que actuellement tous fonctionne. Je précise que je ne fait que exposer mon avis et que je ne suis pas du tout fermé a une réorganisation des paquets. Mais actuellement je pense que pour l'admin qui va installer OBM cela fonctionnera aisément sur un ou plusieurs serveurs. Là je ne voit pas d'avantage a regroupe ces deux paquets. A+ -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Julien Cristau [EMAIL PROTECTED] a écrit : On Thu, Jun 5, 2008 at 14:57:51 +0200, Sylvain Garcia wrote: En fait je trouve ça un peu louche. Le but étant d'avoir un aptitude install obm et hop ça marche, pour être le plus facilement utilisable. Il est plus pratique de garder l'architecture des paquets actuel, ainsi l'installation est assez facile et fonctionnel dans tous les cas. Si l'on regroupe obm-conf et obm-storage alors il faut enlever la dépendace sur mysql c'est donc une tache de plus a faire par l'admin,( avant d'installer OBM il faut d'abord installer mysql-server) alors que actuellement tous fonctionne. C'est pour ça qu'on a inventé le champ 'Recommends'. Julien ok, mais là j'ai besoin de plus d'explication. Sur mon paquet obm-storage, j'ai le choix de l'installer soit en frontend, soit en backend, je met un recommends sur mysql-server. Si j'utilise aptitude ( suivant la conf biensur) il va me tirer mysql-server même si je ne veut que le frontend. C'est donc de tout façon une manip a faire en plus pour l'admin, tandis que la solution actuelle, pas besoin. Donc recommends ou pas c'est pareille. A la limite ce qui serait jouable, c'est de faire 2 paquets: obm-backend et obm frontend, les deux avec les dependances correct l'un avec mysql l'autre sans. Tous les autres paquets on une dépendance sur obm-frontend et obm-backend provides obm-frontend. Enfin là ça devient compliqué pour pas grand chose, qui est déjà fonctionnel. Des avis? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55, Cedric Delfosse [EMAIL PROTECTED] disait: En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui). En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus. Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un ensemble d'API ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les API disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D ) Vincent, est-ce la même chose qui te gênait dans le packaging ? Un peu. En fait, obm-storage se contente de configurer la base de données avec dbconfig-common. Mais si obm le faisait, ce serait pareil : dbconfig-common sait configurer une base distante. obm-ui se contenter d'installer une conf d'Apache. obm pourrait le faire de la même façon. Maintenant, Sylvain a donné sur debian-mentors@ quelques arguments dont un schéma pour expliquer les dépendances. Du coup, je suis un peu moins catégorique qu'avant, mais ça me semble toujours bizarre (je trouve que tout devrait être dans le même package). Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Comme tu l'as dit, le schéma sur debian.mentors explique l'architecture complète de l'objectif. Tous les paquets du schéma existent, mais ne sont pas intégrable en l'état. L'un des avantages ( ou inconvénients ) d'OBM est que l'on utilise les logiciels fournis par les distributions. Nous n'avons pas notre porpre cyrus ou notre propre postfix; la configuration de ces services est difficile dans le cadre d'une intégration dans Debian (remplacement des fichiers de conf...On en reparlera dans une autre discussion :-D ). Mais j'étudie et cherche une solution pour incorporer le tous. Je pense que commencer par intégrer les paquets actuels serait un bon pas en avant pour permettre ensuite de travailler sur le reste. Comme je l'ai déjà précisé, je suis à l'écoute de toutes vos remarques, notamment sur le découpage du packaging. Cependant pour l'instant, et pour ma part, je ne pense pas qu'un autre découpage des paquets soit possible pour assurer l'objectif final qui est une intégration totale d'OBM. Pour l'instant, tous les arguments que vous m'avez avancé étaient justifiés pour une intégration partielle d'OBM et surtout mono serveur. Mon but est que tout le monde puisse installer un OBM sur une grosse architecture et non seulement sur un seul serveur. Pour une install monoserveur il existe le Meta-paquet OBM qui lui tire tous les autres paquets. L'install reste donc facile pour une installation monoserveur via le paquet OBM mais peut ensuite se faire de façon plus fine en installant seulement les paquets et donc services que l'on veut sur tous nos serveur. Tous les monde est donc content.. ( boutade!) En tous cas, je vous remercie de vos retours, et surtout de cette discussion pour faire avancer le shmilblik. -- NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS -+- Bart Simpson on chalkboard in episode 7F23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Mon, 2008-05-19 at 21:03 +0200, Cedric Delfosse wrote: Le mercredi 07 mai 2008 à 11:29 +0200, Sylvain Garcia a écrit : Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Bonjour, je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Cédric J'ai uploader sur mentors.net une nouvelle version, obm_2.1.9-3, qui gère maintenant le fichier de conf /etc/obm/obm_con.ini via ucf. Je pense que les paquets sont maintenant pret a être uploader. Merci pour ta vérification. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Cedric Delfosse [EMAIL PROTECTED] a écrit : Le mercredi 07 mai 2008 à 11:29 +0200, Sylvain Garcia a écrit : Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Bonjour, je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Cédric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Ah merci!!, par contre j'ai une nouvelle version que j'ai pas encore uploader qui gère le fichier de conf via ucf, attend un peu que je l'upload sur debian mentors :-D, je fais ça demain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
recherche sponsor pour nouveaux paquets [OBM]
Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Je travail chez AliaSource, société qui édite OBM. Qu'est ce qu'OBM: Open business Management OBM est beaucoup de chose en fait, groupware, CRM, gestion de projet de facturation, ... Actuellement les modules les plus utilisés sont les modules de groupware. OBM met a disposition gestion de calendrier partagé en Ajax, gestion des contacts, synchronisation possible avec Outlook, thunderbird +lightning, PDA. OBM gère la messagerie des utilisateurs, liste de diffusion, boite aux lettres partagées. OBM a été choisi par plusieurs institutions françaises par exemple : Ministère de la Defense, Ministère des finances, STIF, CE RATP, Université Technique de Troyes,... Tous ça pour quoi? Pour trouver un Sponsor afin d'intégrer OBM dans Debian. ET à terme... devenir DM. Actuellement les paquets proposés ne configurent pas tout un OBM, mais seulement la BD, et la configuration d'apache. On a donc accès à beaucoup de fonctionnalité d'OBM dans un premier temps. Mon but est d'intégrer le reste petit à petit; la gestion de l'annuaire LDAP, de Samba, et surtout de la messagerie. OBM est un projet qui se sert des briques traditionnel du Libre: Cyrus, Postfix Mysql/postgre Openldap .. A votre bon coeur :-D http://www.obm.org http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=obm -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit
Russ Allbery wrote: Sylvain Garcia [EMAIL PROTECTED] writes: Thanks for your anwswer How verify if the the program start by init script wait an entry on standard input; because when use init y hand this script work perfectly. Ah, hm. This may be a different problem, then. Some daemons don't close file descriptors, and Debian maintainer scripts sometimes have other file descriptors open. This can create a situation where the maintainer script waits for the daemon to close the file descriptor and hence hangs. Often adding: # Make sure we don't leave file descriptors open. exec 3/dev/null exec /dev/null to the start of the init script will fix this problem. That's kind of a hack, but without modifying the daemon, I'm not aware of a better fix. Thanks all for your answer, It's work. I have modify my init script with [pathToTheScriptDaemon] 3 /dev/null Thanks; -- Sylvain Garcia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit
Selon Russ Allbery [EMAIL PROTECTED]: Sylvain Garcia [EMAIL PROTECTED] writes: I would like package an application for debian and use dh_installinit for install init script, but I have problem. dh_installinit has add installation script at the of postint, but when i want install my .deb the postinst script take a pause when invoke-rc.d start the init script. If I want continu I must make Ctrl + c Sounds like a bug in the init script. In particular, it sounds like the init script is starting some program that's waiting for input on standard input. This would be bad when the init script is run during system boot as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Thanks for your anwswer How verify if the the program start by init script wait an entry on standard input; because when use init y hand this script work perfectly. for the init script I use /etc/init.d/skeleton. When I comeback at my job I will send my init script. thanks -- Sylvain Garcia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dh_installinit
Hi I would like package an application for debian and use dh_installinit for install init script, but I have problem. dh_installinit has add installation script at the of postint, but when i want install my .deb the postinst script take a pause when invoke-rc.d start the init script. If I want continu I must make Ctrl + c i don't uderstand if is bug of use of dh_installinit or un bug in my init script the end of my postinst script final (after dh_installinit) -- # Automatically added by dh_installinit if [ -x /etc/init.d/obm-satellite ]; then update-rc.d obm-satellite defaults /dev/null if [ -x `which invoke-rc.d 2/dev/null` ]; then invoke-rc.d obm-satellite start || exit $? else /etc/init.d/obm-satellite start || exit $? fi fi # End automatically added section exit 0 -- PS: I use debian SID to build my package and debian Etch to test install Thanks -- Sylvain Garcia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
