(10:07:24) #fusionforge: Le sujet de #fusionforge est : FusionForge, the free/open-source collaborative development forge || https://fusionforge.org/ || Current stable: 5.1, in memoriam neymanna || Weekly Meeting every Friday 11:30 UTC, 13:30 Europe/Paris || Next freeze date: 2011-12-01
(10:15:06) lcanas a quitté le salon (quit: Remote host closed the connection)
(10:54:49) mira|AO: ssh: connect to host taramir.gnurandal.net port 45022: Connection refused
(10:58:29) obergix[work] [~olivier@inf-8657.int-evry.fr] a rejoint le salon.
(11:22:28) obergix[work]: coin
(11:23:58) mira|AO: dobar dan
(11:28:47) Lo-lan-do: mira|AO: Would you be trying IPv6, maybe?
(11:28:50) Lo-lan-do: ssh -v
(11:29:08) obergix[work] a quitté le salon ("Ex-Chat")
(11:29:13) obergix[work] [~olivier@inf-8657.int-evry.fr] a rejoint le salon.
(11:30:18) Lo-lan-do: My porting of sqlparser.pm to PHP is on the right track: it gives the same results for simple and moderately complex SQL files :-)
(11:30:41) obergix[work]: LALR grammar and stuff ?
(11:30:48) mira|AO: hmm
(11:31:08) mira|AO: debug1: connect to address 88.190.26.83 port 45022: Connection refused
(11:31:18) mira|AO: could be outgoing firewall too (since we moved ☹)
(11:31:31) mira|AO: lemme try from @home
(11:31:56) Lo-lan-do: Ah, yes, I need to update the IP address in the FW
(11:31:59) mira|AO: aaaah ;)
(11:32:00) mira|AO: ok
(11:32:26) mira|AO: 94.198.62.204
(11:32:28) Lo-lan-do: Is the old one definitely abandoned, or is it liable to be used again?
(11:32:58) Lo-lan-do: obergix[work]: regexes and a state machine
(11:33:10) Lo-lan-do: (Ugly, I know)
(11:33:24) Lo-lan-do: mira|AO: Try again?
(11:33:32) obergix[work]: Lo-lan-do: there's a language grammar + parser toolkit we use in the OSLC plugin that's pure PHP and may be interesting to you
(11:33:47) mira|AO: the old one will be abandoned by new year
(11:34:07) mira|AO: seems to work, merci
(11:34:18) mira|AO: also, while at it ;) what's the status of the bzr training for us?
(11:34:27) Lo-lan-do: mira|AO: Will it be used in the meantime, or can I remove it?
(11:35:15) mira|AO: it might be used
(11:35:24) mira|AO: depending on where the access happens
(11:35:44) Lo-lan-do: Okay.  Leaving it open for now then.
(11:35:48) mira|AO: we’re in the process of moving, but servers (including remote-working VMs) are still there
(11:35:49) mira|AO: ok
(11:36:33) Lo-lan-do: About bzr: I didn't hear back from Stefan about it, so I didn't really start on the preparation, but I can do that next week, and do the training sessions during September.
(11:36:45) mira|AO: oh ok
(11:36:49) mira|AO: that would be nice, yes
(11:36:57) mira|AO: because mike and pit want to commit too ;)
(11:39:34) Lo-lan-do: Right.  I'll do that then.
(11:39:57) Lo-lan-do: I also need to review Pit's Jenkins plugin, and see if it can be merged into the current Hudson plugin (or the reverse).
(11:40:51) Lo-lan-do: (The current Hudson plugin is the reason https://fusionforge.org/projects/fusionforge/ takes 20-30 seconds to load)
(11:43:46) aljeux_: Ye, but it should be possible to delay jenkins OO loading.
(11:44:31) aljeux_: I thought it was already done.
(11:45:00) mira|AO: I think the reverse should be easier
(11:45:04) mira|AO: but good luck ;)
(11:45:27) aljeux_: what is Pit's Jenkins plugin doing?
(11:45:57) mira|AO: quite a lot actually
(11:46:09) Lo-lan-do: The problem isn't loading, it's that the page grabs and parses one XML file from the CI server for each job, *just* to display the red dot in the titlebar of the widget.
(11:46:11) mira|AO: haven’t seen it in action yet, but will deploy the fixed (“should be working”) code soon
(11:46:21) mira|AO: oh
(11:46:39) Lo-lan-do: And then, the widget itself does it again asynchronously in Javascript to display the individual red/blue dots.
(11:46:57) Lo-lan-do: And since we have 8 configured jobs…
(11:46:59) Pit: aljeux_: You can create a project in jenkins about evolvis, that has the same information about the project in evolvis.
(11:47:46) aljeux_: Lo-lan-do: ok, you know it better than I
(11:47:48) Pit: the svn uri is also in the new project included. Also you can disable and enable the project in jenkins and trigger an new built about evolvis.
(11:49:22) Pit: Also you can delete the project as well. Etc. :)
(11:49:36) ***Lo-lan-do was only speaking about the FF Hudson plugin, haven't reviewed the Jenkins plugin yet
(11:51:09) ***aljeux_ using the FF Hudson plugin but the slowdown when displaying widgets is a pain.
(11:51:17) Pit: aljeux_ asked about what the evolvis plugin is doing :)
(11:51:49) Pit: Maybe i need to tweak the performance on the evolvis jenkins plugin as well.
(13:13:41) Lo-lan-do: sqlparser.php news: all src/db/*.sql files give the same results as with the sqlparser.pm, except for two where the Perl version crashes :-)
(13:13:57) Lo-lan-do: (But I know why, because I fixed that in the PHP version already)
(13:20:36) aljeux_: What base are you using to rework the upgrade procedure? from scratch ?
(13:24:16) aljeux_: I'm asking because I have a modified version of upgrade-db which have extra features like allowing sql directories (one for fusionforge, one for acos) that I may share if needed.
(13:27:52) lcanas [~quassel@82.158.140.181.dyn.user.ono.com] a rejoint le salon.
(13:32:55) ***aljeux_ here
(13:33:17) ***Lo-lan-do too 
(13:33:27) ***Lo-lan-do grabs the token
(13:33:41) Lo-lan-do: So.  I've started working on unifying the DB upgrade process.
(13:34:13) Lo-lan-do: First step (almost complete): porting my SQL parser from Perl to PHP, so we can run the SQL snippets inside transactions.
(13:35:09) Lo-lan-do: Then my plan is to have a table with a listing of which snippet was applied and when.
(13:35:36) Lo-lan-do: We may already have such a table; if so, I'll extend it to have an extra column, so the same mechanism can be used for core and for plugins.
(13:36:14) Lo-lan-do: Then, I'll grab database dumps from the bulidbot for each of the three installation methods, and compare the schemas.
(13:36:28) Lo-lan-do: If there are differences, I'll work on a convergence snippet.
(13:37:30) Lo-lan-do: And after that, if we start from a common point and all use the same tool to upgrade, we should be home and dry.
(13:37:40) Lo-lan-do: …profit!
(13:37:46) Lo-lan-do: What could possibly go wrong?
(13:37:55) Lo-lan-do: (This is where you tell me :-)
(13:38:05) aljeux_: it's fine for me.
(13:38:50) aljeux_: FYI, upgrade-db si already have the table and handling the core & plugins.
(13:39:26) Lo-lan-do: Great.  Less work for me :-)
(13:39:48) aljeux_: As said earlier, I have a modified version that can handle seperate sql directories. This is usefull for site like mine with big changes
(13:40:20) aljeux_: with md5 sign to detect already applied sql (when a sql is moved from acos to fusionforge).
(13:40:49) aljeux_: This is a quite special case anyway.
(13:43:04) ***aljeux_ stolen token released.
(13:43:25) Lo-lan-do: I guess I can release it too, unless others have anything to add for that point
(13:44:15) Lo-lan-do: I gave up on fixing the .spec for now, since the calls to the fusionforge-install-*.php will be replaced with the new shell scripts soon anyway.
(13:44:59) aljeux_: I'm not a fan of shell scripts (when loc > 10)
(13:47:03) aljeux_: Some small news.
(13:47:48) aljeux_: We've started to move from xhtml to html5. This could be discussed one day.
(13:48:08) Lo-lan-do: With Smarty templates?
(13:48:41) aljeux_: no, sorry, just a reworked theme with a cleaner layout.
(13:49:05) aljeux_: taking advantage of new HTML5 attributes.
(13:50:58) aljeux_: I'm also playing with the scmhooks plugins.
(13:51:01) Lo-lan-do: Another new theme?
(13:51:19) aljeux_: No, it's our own corp themes.
(13:51:39) aljeux_: But with HTML5, there are new attributes that can be interesting
(13:52:00) aljeux_: so, moving from xhtml to html5 for fusionforge should be discussed.
(13:52:25) aljeux_: For example, on forms, you may add a "required" attribute.
(13:53:15) aljeux_: We'll probably add that in our code and if ff goes to html5, I may add this kind of new code.
(13:54:34) aljeux_: Most is done in theme but some new attributes should be added in code like the "required", date type, ...
(13:54:44) aljeux_: to benefit from html5
(13:55:25) mira|AO: 13:47⎜<aljeux_:#fusionforge> We've started to move from xhtml to html5. This could be discussed one day.    ← impossible because mediawiki produces xhtml/1.0 transitional, which we include in our output
(13:57:50) aljeux_: xhtml + html5 header is a valid html5 doc AFAIK
(14:02:04) ***aljeux_ token released if someone wants it.
(14:02:19) julien: I would like talking about tsearch2 ?
(14:02:45) aljeux_: please, do
(14:03:53) julien: I make a lot of tests again this morning
(14:04:22) julien: and, I think it's a bad idea to create default text configuration with english dictionnary
(14:05:15) julien: if the postgresql user is not in english (user gforge) research don't work properly
(14:05:54) julien: so, 2 possibility : set gforge in english too, or, use default configuration in postgresql.conf
(14:06:50) julien: and I have find sql command to update configuration, and rebuild index
(14:08:01) Lo-lan-do: Is the default configuration inherited from the database in the schemas?
(14:09:31) julien: when you create schema, the schema used the default parameters in postgresql.conf
(14:09:46) julien: so for fusionforge.org, we continue to use english
(14:10:00) julien: bicause, you use en_GB.UTF-8
(14:10:12) julien: en the user gforge used it too
(14:11:12) Lo-lan-do: Actually, the schemas are created with a default configuration of english, hardcoded in create-wikis.php :-/
(14:11:18) julien: yes
(14:11:33) Lo-lan-do: (Independently of postgresql.conf)
(14:11:33) julien: and, if you look in mediawiki installation (not in fusionforge)
(14:11:41) julien: it's never specified the language
(14:11:58) aljeux_: tsearch2 is a problem when you have projects not all using the same lang.
(14:11:59) julien: the language is never force
(14:12:03) aljeux_: I have this problem
(14:12:08) julien: aljeux_: yes
(14:12:22) julien: wikipedia used mysql and lucene search
(14:12:29) aljeux_: So, i have some projects complaning about bad search results.
(14:12:58) julien: aljeux_: yes, and I think we can't resolve the multi language problem
(14:13:31) julien: but client (user postgres -> gforge) must be used the same language that the indexer
(14:13:58) Lo-lan-do: I agree that the multi-language problem is something different, but at least being able to configure the whole forge in French would be a good first step.
(14:14:31) aljeux_: yes, default should be the same as $sys_lang
(14:14:58) Lo-lan-do: Haha, it's not that easy.
(14:15:01) aljeux_: So, a pure french forge should index using French dict.
(14:15:28) Lo-lan-do: Because there's not a 1↔1 mapping between sys_lang and PostgreSQL text search configurations.
(14:15:47) Lo-lan-do: Not all languages have been implemented in PostgreSQL :-/
(14:15:49) julien: hum... if we not force in cearte-wiki.sh, it's the "echo $LANG"
(14:16:26) Lo-lan-do: create-wiki.sh is no more.  Current code is in create-wikis.php, which hardcodes english.
(14:16:38) julien: postgresql.conf use the language plateforme (linux os), and not the $sys_lang fusionforge
(14:18:45) julien: I suppose that someone want install fusionforge in international context, he installed OS in english (and fusionforge too)
(14:19:04) chris38: Got a question a bout upgrade scripts rather for Lo-Lan-do, did you look at tuleap upgrade API  suggested by M Vacelet, and how it would integrate with new php upgrade script ?
(14:19:20) julien: and I suppose too, if someone installed fusionforge in french corp, he install OS in french (and fusionforge too)
(14:19:25) Lo-lan-do: chris38: Not yet
(14:19:46) aljeux_: julien2: I wouldn't rely on that
(14:20:58) julien: so, I think that in the first step, we can don't force in create-wiki.sh, and let default configuration set in postgresql.conf
(14:20:58) chris38: for aljeux_ the php scripts are mainly doing set of system("bash") call I don't see any gain to this and if you really want to keep php it should be easy to make a php with a single system("bash") call
(14:21:46) Lo-lan-do: julien2: Really, the best thing to do is to 1) add a configuration option, 2) use it everywhere, 3) provide a script to update the indexes when the configuration option changes.
(14:22:23) aljeux_: Lo-lan-do: 1) is the default lang of the forge, no?
(14:22:42) Lo-lan-do: aljeux_: No, because there's no 1↔1 mapping…
(14:23:28) julien: Lo-lan-do: no, because in mediawiki, if you use postgresql >=8.3, mediawiki don't use default configuration
(14:24:25) chris38: Any idea  about the !! title not set !! on ff wiki pages ?
(14:25:05) julien: hum, I write something... but it's not clear, same for me...
(14:25:48) Lo-lan-do: julien2: What does it use?
(14:26:29) Lo-lan-do: aljeux_: See SELECT * from pg_ts_config;
(14:26:56) julien: yes!!! in this table, we have default dic, and default * nb wikis
(14:27:00) aljeux_: Lo-lan-do: I trust you.
(14:27:25) julien: but, when you installed mediawiki (not in fusionforge), we have never default row in this table
(14:27:48) aljeux_: chris38: I'm just not a shell addict so I'm afraid of debugging & maintaining shell scripts.
(14:27:57) julien: because is used predefined configuration
(14:28:01) Lo-lan-do: julien2: As I said, it's done by create-wikis.php now.
(14:29:30) julien: yes, but why ? why do that : CREATE TEXT SEARCH CONFIGURATION $schema.default ( COPY = pg_catalog.english )
(14:29:54) julien: you don't find this in mediawiki alone installation 
(14:30:36) julien: because in alone installation, mediawiki used predefined dictionnary, and use the plateform language
(14:30:56) julien: and indexer and client use the same parameters
(14:31:08) Lo-lan-do: Okay.  Supposing we drop that in the schemas.
(14:31:32) chris38: aljeux_, at least shell has a -x option that make it easier to debug than php
(14:31:43) Lo-lan-do: We still need a default config for the database, and a way to change it.
(14:32:26) ***obergix[work] arrives late
(14:32:46) ***chris38 was late too
(14:33:06) julien: if you look in mediawiki/maintenance/postgresql/tables.sql, I read that :
(14:33:06) julien: -- Tsearch2 2 stuff. Will fail if we don't have proper access to the tsearch2 tables
(14:33:06) julien: -- Note: if version 8.3 or higher, we remove the 'default' arg
(14:33:06) julien: -- Make sure you also change patch-tsearch2funcs.sql if the funcs below change.
(14:33:31) julien: Lo-lan-do: yes, use the default variable in postgresql.conf 
(14:34:13) Lo-lan-do: No, we need to be able to override that.
(14:34:24) Lo-lan-do: At least forge-wide, if not project-wide.
(14:35:49) Lo-lan-do: It may be a simple matter of defining the default config when establishing the connection.
(14:35:59) Lo-lan-do: (Like in pre.php)
(14:36:19) Lo-lan-do: But anyway, we also need a way to refresh all the indexes.
(14:36:29) obergix[work]: chris38: will you have time to investigate the NSS + PG vulnerability ?
(14:37:42) chris38: obergix[work], I'm not this is really to consider as a vulnerability as nis for exemple has the same behaviour
(14:38:03) julien: Lo-lan-do: You think that it's possile to set this, for each project, ALTER USER mwuser SET default_text_search_config = 'german'; 
(14:38:10) obergix[work]: chris38: I'd like to elaborate but on secure channel preferably
(14:38:14) julien: but not in hard, but for each connection
(14:38:25) obergix[work]: Lo-lan-do, chris38 can we try and work on that ?
(14:38:43) chris38: obergix[work], but i think nevertheless nss has some extra feature we may not use correctly
(14:38:47) obergix[work]: chris38: a side issue would be to get rid of the changes to pg_hba.conf if possible for debian packaging
(14:39:49) chris38: obergix[work], yep, i've got to plunge again in nss, py phone channel  ?
(14:39:56) chris38: by phone channel ?
(14:40:02) Lo-lan-do: julien2: The Mediawiki plugin doesn't use a dedicated PG user… it reuses the gforge connection.
(14:40:14) obergix[work]: chris38: could do
(14:40:23) obergix[work]: if Lo-lan-do feels interested maybe
(14:40:26) julien: Lo-lan-do: If you think that it's possible to set default search language where connection is etablish, and set default language for each mediawiki, it's the good solution
(14:40:31) julien: yes
(14:40:49) obergix[work]: chris38: s/plunge/dive/ ?
(14:40:52) Lo-lan-do: obergix[work]: Not really.  I'm much more interested in migrating to nss-db.
(14:40:56) chris38: obergix[work], let me have a look to refresh my memory
(14:41:06) chris38: obergix[work], yep s/plunge/dive/
(14:41:45) obergix[work]: Lo-lan-do: yes, in a later time, no objection... unless you feel like being able to deliver this as a fix for a vuln in Debian package ;)
(14:42:26) ***obergix[work] is not really qualified too much but would like te bo reassured that we can live up to Debian standards
(14:43:30) Lo-lan-do: obergix[work]: My opinion is that it's not worth "fixing" when there's a much better solution coming.  But I'm not discouraging anyone.
(14:43:39) chris38: obergix[work], really not sure this is a vuln as nss with nis but also with ldap may have the same behaviour
(14:43:41) obergix[work]: Lo-lan-do: when ?
(14:43:51) obergix[work]: chris38: 3 vulns ?
(14:44:15) Lo-lan-do: When it's ready / sooner if you help. (What did you expect?)
(14:44:27) chris38: obergix[work], nis is not considered as very secure though
(14:44:30) obergix[work]: Lo-lan-do: should a report to security@d.o ?
(14:44:43) obergix[work]: s/a/I/
(14:45:27) Lo-lan-do: If you consider it a security issue, then sure.  See what they think about it.
(14:46:03) obergix[work]: ok, /me will try to exhibit the flaw
(14:46:57) julien: Lo-lan-do: so, the solution is to create 1 user by project ?
(14:47:48) julien: and add option configuration for set language in mediawiki ?
(14:48:11) julien: 1 database user *
(14:49:30) Lo-lan-do: julien2: If we want to have one config for the whole forge including wikis, the solution is to move lines 177-181 of src/common/search/SearchQuery.class.php to src/common/include/database-postgresql.php (or pre.php)
(14:50:50) Lo-lan-do: If we want to have a different configuration for each wikis, then do something similar in the ./src/plugins/mediawiki/www/LocalSettings.php
(14:55:54) mira|AO: so, extratabs in evolvis can now do outerTabs as well, not just projectTabs
(14:55:57) mira|AO: and… TOOLTIPS!
(14:55:58) mira|AO: ;)
(14:56:24) julien: Lo-lan-do: hum... and with your solution, we can override client configuration, and wiki creation configuration, for set the same language
(14:56:26) mira|AO: (only with the evolvis theme, but the theme changes are trivial)
(14:56:49) Lo-lan-do: julien2: Exactly.
(14:56:57) julien: Great !
(15:00:17) ***chris38 take the token, did nothing as I was on holiday, I've the plan to review createplugin.sh and make it check the plugin some plugin structures convnetion are respected 
(15:01:23) chris38: I palne to use HelloWorld plugin as a template model so it would be nice you add in HelloWorld the stuffs you would like to see in auto generated plugin structures
(15:03:01) chris38: plan to work on this next week and make so the generated plugin also works on tuleap/codendi possibly use this to port auth plugins on tuleap/codendi
(15:03:16) julien: Lo-lan-do:  and in creaion, we can override too that ? Note: if version 8.3 or higher, we remove the 'default' arg
(15:05:57) obergix[work]: chris38: I thought we had agreed earlier that some other plugin was more indicated as an example... but can't remember which
(15:06:30) Lo-lan-do: julien2: Since create-wikis.php uses the FF infrastructure to connect to the DB, yes, you can override stuff there.
(15:06:59) chris38: obergix[work], extratab
(15:07:09) obergix[work]: chris38: ok
(15:07:17) chris38: I will probably make you can choose the model
(15:07:49) obergix[work]: the thing is to make sure the model is most up-to-date to recent coding standards/guidelines/best practices
(15:08:25) obergix[work]: so that others learn along the way
(15:31:41) obergix[work]: am I the only one annoyed to see the Template project each time I go to new project approvals ?
(15:32:08) Lo-lan-do: You could approve it.  Or reject it.
(15:32:27) obergix[work]: Lo-lan-do: what's the point of approving template projects ?
(15:32:41) Lo-lan-do: You don't see them as pending :-)
(15:32:57) obergix[work]: yes, but aren't them in the list of projects then ?
(15:33:12) Lo-lan-do: Yes.
(15:34:08) obergix[work]: s/them/they/
(15:34:32) Lo-lan-do: But having them as status deleted won't list them as templates, they need to be active, suspended or pending.
(15:34:35) ***obergix[work] thinks that this looks rather unfinished somehow (even though may be convenient)
(15:34:51) ***obergix[work] thinks of templatestatus, obviously, then
(15:35:05) obergix[work]: 'template' status
(15:37:19) aljeux_: if you don't want to see it, why not making it as private then?
(15:37:29) obergix[work]: dunno
(15:37:56) obergix[work]: I'm just curious if that shouldn't be the default when installing a forge from scratch with Debian packages
(15:38:19) obergix[work]: it's unclear what you can do with that "Template" project or not
(15:38:33) Lo-lan-do: If you mark it as private, any new projects based on it will be private, because the roles and permissions are cloned.
(15:38:41) aljeux_: I approve the template just to get rid of it in the pending :-)
(15:38:43) obergix[work]: so approved and private would make more sense then, than pending ?
(15:39:01) Lo-lan-do: Depends.  Do you want new projects to be private by default?
(15:39:11) obergix[work]: Lo-lan-do: dunno
(15:39:16) aljeux_: Well, I think public/private should be a registration option.
(15:39:18) obergix[work]: depends on the context
(15:39:25) ***obergix[work] too
(15:40:11) aljeux_: Lo-lan-do: I wasn't aware of that, good to know.
(15:40:55) Lo-lan-do: Roles, permissions, trackers, lists, task managers, forums, and use of plugins are cloned.  Maybe some other things.
(15:42:19) obergix[work]: hmm
(15:42:28) mira|AO: 15:31⎜<obergix[work]:#fusionforge> am I the only one annoyed to see the Template project each time I go   ← no
(15:43:00) obergix[work]: kind of typical usability annoyances somehow
(15:43:16) aljeux_: obergix[work]: Feel free to make a upgrade script to approve the template projet.
(15:43:20) obergix[work]: but I do lots of installs for tests and not typical forge admin work, so...
(15:43:47) obergix[work]: aljeux_: sure, I can commit, but wasn't sure of the rationale of present state
(15:44:15) Lo-lan-do: 10 years of not changing it :-)
(15:44:59) aljeux_: I was now I delegated to bots ;-)
(15:51:41) ***obergix[work] doesn't cry, oh no
(15:51:58) Pit a quitté le salon ("Kopete 0.12.7 : http://kopete.kde.org")
(16:54:04) CIA-48: olberger * r14301 /trunk/src/ (2 files in 2 dirs): Add hook to support addition of complemetary RDF metadata for project DOAP RDF
(16:54:07) CIA-48: olberger * r14302 /trunk/src/plugins/oslc/include/oslcPlugin.class.php: Use the project_rdf_metadata hook to provide a link to the project's OSLC ServiceProvider description
(17:01:11) obergix[work]: mdhar: what's the status of the oauthconsumer plugin ?
(17:04:55) mdhar: obergix[work]:  i'd say, 60% done
(17:08:02) obergix[work]: ok
(17:08:12) obergix[work]: anything in the twitter plugin ?
(17:08:31) obergix[work]: mdhar: I'm trying to rebuild the package
(17:08:42) mdhar: obergix[work]:  nope, nothing yet
(17:08:51) obergix[work]: ok
(17:12:08) obergix[work] a quitté le salon (quit: Quit: Ex-Chat)
(17:17:57) julien: I'm ok to work on mediawiki tsearch2. I can ?
(17:26:34) Lo-lan-do: Sure
(17:27:01) julien: ok
(17:44:12) ffbuildbot3: Project fusionforge-trk-build-and-test-src-centos5 build #118: FAILURE in 39 min: http://buildbot3.fusionforge.org/job/fusionforge-trk-build-and-test-src-centos5/118/
(17:44:12) ffbuildbot3: * olberger: Use the project_rdf_metadata hook to provide a link to the project's OSLC ServiceProvider description
(17:44:13) ffbuildbot3: * olberger: Add hook to support addition of complemetary RDF metadata for project DOAP RDF
(18:01:41) lcanas: guys, see you in a few days (vacation!)
(18:03:10) mira|AO: have fun
(18:03:29) lcanas: I'll try, adios!
(18:03:33) mira|AO: XD
(18:03:41) lcanas a quitté le salon (quit: Remote host closed the connection)
(18:07:43) Ce compte a été déconnecté et vous n'êtes plus dans la discussion. Vous rejoindrez automatiquement cette discussion lors de la reconnexion.