21:58:56 <boutil> #startmeeting 21:58:56 <MeetBot> Meeting started Tue Feb 11 21:58:56 2014 UTC. The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:58:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 21:59:04 <boutil> Hi everybody! 21:59:38 <terceiro> hello 21:59:46 <boutil> Meetbot will be recording logs/minutes of the meeting. 21:59:46 <MeetBot> boutil: Error: "will" is not a valid command. 21:59:55 <boutil> :( 22:00:03 <hggh> hey 22:00:08 <paulvt> :D 22:00:10 <paulvt> heya 22:00:30 <boutil> #chair terceiro paulvt hggh 22:00:30 <MeetBot> Current chairs: boutil hggh paulvt terceiro 22:00:38 <boutil> is zeha here? 22:01:28 <zeha> yes 22:01:31 <zeha> sorry 22:01:32 <hggh> :) 22:01:47 <paulvt> I was about to say.. 8min idle 22:01:49 <paulvt> :) 22:02:27 <boutil> #chair zeha 22:02:27 <MeetBot> Current chairs: boutil hggh paulvt terceiro zeha 22:02:37 <paulvt> many chairs 22:02:44 <boutil> he he :) 22:03:12 <boutil> there are some more if people want to have a seat 22:03:27 <boutil> let us start with a list of topics? 22:03:41 <paulvt> agreed 22:03:47 <boutil> -ruby1.8 removal 22:03:50 <paulvt> just scratch out init-systems ;) 22:03:51 <zeha> sure, /me proposes look at ruby1.8-removal 22:04:03 <boutil> -ruby1.9.1 removal 22:04:06 <terceiro> agreed 22:04:09 <boutil> -ruby2.1 status 22:04:20 <hggh> -gitlab 22:04:27 <terceiro> -switch to ruby2.0 as default 22:05:00 <boutil> ok, that is a good start. Maybe some more will come to mind later 22:05:07 <boutil> #topic ruby1.8 removal 22:05:16 <terceiro> yes. also do we have a time limit? 1h? 22:05:24 <zeha> 1h seems reasonablre 22:05:28 <paulvt> that would be nice :) 22:05:29 <terceiro> k 22:05:31 <boutil> let's try that, yes. 1h. 22:05:40 <terceiro> all rigth, so about ruby1.8 removal 22:05:53 <boutil> #link https://release.debian.org/transitions/html/ruby1.8-removal.html 22:05:57 <zeha> there are still some important-enough packages that need fixing 22:06:06 <terceiro> do we know how many of those pending packages are scheduled for autoremoval? 22:06:10 <boutil> #link http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ruby@lists.debian.org;tag=ruby18-removal 22:06:15 <zeha> terceiro, a lot 22:06:24 <zeha> but not all of them. 22:06:38 <terceiro> zeha: do we know which of them will not be autoremoved? 22:06:49 <paulvt> ooph, 45+ 22:07:01 <zeha> graphviz won't be autoremoved 22:08:12 <boutil> are there packages in the list that the Ruby team would be interested in helping? 22:08:15 <zeha> ruby-nora, redland-bindings, stfl probably 22:08:28 <zeha> i think the other packages will go out 22:08:51 <paulvt> are we talking about the list in the second link? 22:09:02 <zeha> i believe gwolf worked on ruby-bdb, but didn't finish 22:09:36 <zeha> paulvt, transition tracker page is IMO more helpful for this 22:10:09 <zeha> rgd. xmms2: I have no idea why it's still listed as bad, and -release couldn't tell me either. somebody please take a look :) 22:10:19 <paulvt> right, some our ours 22:10:21 <boutil> maybe rubyluabridge? 22:10:39 <paulvt> such as ruby-gnome2, which is mine.. but it should work on >= 1.9.1 AFAICT 22:10:50 <zeha> another holdup: ruby1.9.1 failed to build on powerpc, preventing migration of ruby-tokyocabinet 22:11:29 <terceiro> #action terceiro will ask for a giveback of ruby1.9.1 on powerpc and hope it builds 22:11:52 <boutil> there is some work by terceiro and myself on ruby-gnome2. 22:12:13 <boutil> terceiro: do you plan to finish it, or do you want me to have a look? 22:12:27 <terceiro> boutil: if you could look at it would be nice 22:12:33 <boutil> or maybe paulvt is interested in having a look? 22:12:37 <zeha> terceiro: https://lists.debian.org/debian-wb-team/2014/02/msg00007.html 22:12:57 <boutil> #action boutil fix and upload ruby-gnome2 22:13:04 <terceiro> zeha: ok; so it failed again? 22:13:12 <zeha> no, nobody cared to do the g-b 22:13:34 <hggh> ruby-luabridge has no gem2deb, no rubygems.org release, I check if it's build against 2.0 22:14:16 <boutil> anyway, the situation is much better than 3 weeks ago before the RC bugs. 22:14:46 <boutil> terceiro: can you remind us when the removal of ruby1.8 is planned? 22:14:52 <paulvt> boutil: I could but I cannot give any timeframe.. it is better for me to give me small and concrete stuff to do with a deadline at the moment 22:14:53 <zeha> yes; maybe someone could do a 'point out to MIA team' sweep 22:15:43 <terceiro> boutil: I think I said "in 4 weeks" during the sprint 22:15:44 * terceiro checks 22:15:51 <zeha> (rubyluabrigde is sid-only btw.) 22:16:23 <hggh> ruby-luabridge does not build with 1.9 22:16:39 <boutil> hggh: thanks, good to know :( 22:17:25 <spk`> zeha: cannot find the logs for tokyocabinet powerpc build 22:17:40 <zeha> it's BD-Uninstallable 22:17:41 <spk`> how can we have it ? 22:17:42 <zeha> so no logs 22:17:44 <terceiro> #action terceiro start dialogue with RT about actually removing ruby1.8 from jessie ASAP 22:17:49 <terceiro> boutil: ^ 22:18:18 <boutil> so, let's try to save some that seem important to us, and let the other packages break by the removal? 22:18:20 <zeha> paulvt, btw, I NMU'ed gnoemoe2, which lists you as an Uploader; it seems the original Maintainer disappeared? 22:18:44 <paulvt> zeha: yes, I saw it.. he has 22:18:52 <paulvt> I actually also have on my list to port it to Gtk+3 22:19:01 <paulvt> the interface to Ruby was fairly simple IIRC 22:19:21 <paulvt> maybe I can port that too 22:19:28 <zeha> boutil, I think we need to fix graphviz in any case, -release won't remove that 22:19:30 <terceiro> who wants to NMU graphviz? 22:19:33 <paulvt> (the original Maintainer is now actually a co-author of gedit btw) 22:20:12 <zeha> my last graphviz build try failed, so not me please :-) 22:20:13 <hggh> terceiro: I had I look at graphviz on the sprint, the easy solution was removing the ruby bindings 22:20:24 <zeha> i think it would build with 1.9 or 2.0 22:20:29 <paulvt> hggh: but that's an option in all cases no? 22:20:31 <zeha> but the package is annoying to build 22:20:40 <hggh> zeha: ack 22:20:41 <paulvt> I mean.. non-Ruby-libs packages that is 22:20:48 <boutil> graphviz is a terrible swig binding 22:21:20 <paulvt> the almost always are 22:21:34 <boutil> removing the ruby binding could be a last resort action. 22:21:41 <paulvt> for work I've been struggling with libproxy's binding (not built in Debian fortunately, or that also would've been a concern) 22:21:46 <terceiro> an NMU to remove a binary package is too brutal 22:22:19 <boutil> #action NMU graphviz 22:22:28 <boutil> ^ needs a volunteer :) 22:22:45 <boutil> ok. Something else to add about ruby1.8? 22:22:53 <terceiro> I don't think so 22:23:12 <boutil> #topic ruby2.0 as default / ruby2.1 status 22:23:23 <zeha> 2.1 is stuck in NEW 22:23:24 <paulvt> yes please, what is the status 22:23:42 <terceiro> let's poke super paultag :) 22:23:47 <paulvt> or luca 22:23:57 <zeha> for 2.0-default, we're waiting for the test rebuild 22:24:00 <boutil> is there a blocker to switch the default to 2.0? 22:24:04 <boutil> ah, ok. 22:24:23 <zeha> everybody could help testing by installing 'ruby' from experimental 22:24:29 <paulvt> ah! 22:24:30 <terceiro> yep 22:24:31 <zeha> (and see what breaks locally) 22:24:36 <hggh> ah... about graphviz. there is already a package named ruby-graphviz. so libgv-ruby should be renamed to ruby-gv 22:24:47 <boutil> #info one can install ruby from experimental to test ruby2.0 as default 22:24:56 <paulvt> done! 22:25:12 <paulvt> btw, side-question, there is no ri2.0 and ri2.1 anymore? 22:25:26 <terceiro> there is 22:25:31 <boutil> hggh: if we fix the package but keep its old name, I think it is ok... 22:25:31 <zeha> ruby2.0: /usr/bin/ri2.0 22:25:36 <terceiro> $ which ri2.0 22:25:36 <terceiro> /usr/bin/ri2.0 22:25:51 <zeha> boutil, agreed, I'd also keep libgv-ruby in this case. no point of going to NEW for this 22:25:52 <hggh> #action hggh will try to build graphviz with ruby 1.9 22:26:06 <paulvt> yes, but the ri-data was separate 22:26:23 <terceiro> paulvt: yep I think you need ruby2.0-doc 22:26:34 <paulvt> ri1.9.1 contained the ri data for binary ri1.9.1 (which I've found to confuse users) 22:26:37 <paulvt> great, that's better 22:26:39 <terceiro> hggh: try changing it to the default ruby whatever it is 22:26:42 <zeha> #action zeha will ask -ftp to get 2.1 out of NEW 22:26:45 <terceiro> hggh: wrt graphviz 22:26:56 <hggh> terceiro: yep, that was also on my mind :) 22:27:13 <terceiro> hggh: cool, than next time we can just request a binnmu 22:27:22 <zeha> i think that's it for 2.0/2.1? 22:27:30 <terceiro> pretty much I think 22:27:47 <boutil> terceiro: about rubygems-integration, the content seems not symmetric in ruby1.9 /ruby2.0. Is that normal? 22:27:59 <terceiro> boutil: what you mean? 22:28:06 <paulvt> (yay, my most important application works with "ruby" from exp" 22:28:27 <boutil> (maybe I'll ask rubygems-integr. question later when I collect info...) 22:28:59 <boutil> do we know an ETA for the test rebuild results? Has deiv already scheduled it? 22:29:14 <zeha> I don't know really 22:29:24 <hggh> deiv is testing against 2.1? 22:29:31 <zeha> 2.0 22:29:38 <hggh> ok 22:30:02 <boutil> anything to add on this topic? 22:30:32 <boutil> let's move to the next one... 22:30:35 <terceiro> +1 22:30:42 <boutil> #topic ruby1.9 removal 22:31:01 <hggh> have we an tracker for 1.9 removal already? 22:31:06 <terceiro> we don't 22:31:10 <terceiro> I can ask for one 22:31:13 <zeha> we have an old snapshot 22:31:16 <zeha> http://people.debian.org/~zeha/rubyremoval/html/ruby191-removal.html 22:31:16 <boutil> should we start filing bugs? 22:31:32 <boutil> #link http://people.debian.org/~zeha/rubyremoval/html/ruby191-removal.html 22:31:35 <terceiro> #action terceiro ask for a ruby1.9.1-removal tracker on release.debian.org 22:31:37 <zeha> just to give people an idea 22:31:49 <terceiro> I think we should 22:32:00 <zeha> yes, having it on release would be good 22:32:09 <hggh> first we should disable gem2deb to build with 1.9? 22:32:10 <paulvt> but can we do this, this fast? 22:32:20 <terceiro> severity important for now; for the packages that are hardcoding ruby1.9.1 somehow 22:32:21 <paulvt> I've been still mainly using 1.8 at work (we're on Precise) 22:32:37 <zeha> 1.9 needs to go before we freeze 22:32:38 <zeha> :) 22:32:42 <zeha> so better do it now 22:32:50 <paulvt> .. so I don't know about the situation 22:32:57 <boutil> #action file important bugs against packages hard-coding ruby1.9.1 in dependencies 22:33:00 <paulvt> 2.0 and 1.9.1 is identicaly? or at least inclusive? 22:33:09 <zeha> paulvt, to fill you in, jessie should be 2.1-only 22:33:15 <paulvt> yes, I read that 22:33:22 <zeha> everything else won't be viable security-wise 22:33:36 <zeha> and 2.0 has only minor changes from 1.9 22:33:57 <zeha> so if it builds/works with 1.9, it likely builds/works with 2.0/2.1 22:34:12 <hggh> most packages on the tracker needs a rebuild with newer gem2deb that does not build for 1.9 22:34:17 <paulvt> yes, I've seen that somewhere too.. but no real-life experience with it.. pure Ruby and extension-wise 22:34:31 <zeha> ideally gem2deb should use ruby-all-dev 22:34:38 <terceiro> zeha: it will 22:34:39 <zeha> but i haven't found time to make this work yet 22:35:00 <terceiro> I have been working on gem2deb in the last days, I can also change that 22:35:03 <paulvt> I am also assuming 1.9.1-remove is/will be blocked until ruby with 2.0 as default enters unstable 22:35:06 <paulvt> is there a timeline for that? 22:35:12 <terceiro> paulvt: ASAP 22:35:16 <paulvt> terceiro: great work btw 22:35:26 <paulvt> ok, so testing is done 22:35:29 <terceiro> we just need to know the size of the breakage with ruby2.0 as default 22:35:52 <paulvt> right! 22:36:23 <paulvt> and let's break some things in unstable.. our Ruby stuff has been too nice for unstable :P Python and Perl have wrecked the place far more often ;) 22:36:33 <paulvt> no, but seriously 22:36:42 <zeha> we did manage to break unstable often enough :) 22:36:51 <paulvt> ? 22:37:18 <zeha> ruby-debian dropped 1.8 binaries, and apt-listbugs broke for some users, etc. 22:37:40 <zeha> (and other minor stuff, like 'ruby' not being installable) 22:37:44 <paulvt> hmm, ok, so... ruby with 2.0 as default moves to unstable ASAP 22:37:59 <paulvt> then ruby1.9.1 removal is started concurrently with the 1.8 removal 22:38:16 <paulvt> but it shouldn't be that bad given the small differences between 2.0 and 1.9.1 22:38:23 <boutil> I was thinking of having small cgi scripts serving lists of packages with some properties, like build-depending explicitly on ruby1.9.1, like the one with packages maintained by the team. 22:38:27 <paulvt> ... summarizing 22:38:38 <boutil> would you find that handy for following bug filings, etc? 22:39:18 <terceiro> paulvt: that's the transition tracker 22:39:29 <terceiro> except it doesn't separate by maintainer 22:39:31 <zeha> http://people.debian.org/~zeha/rubyremoval/html/ruby191-removal.html updated 22:39:53 <terceiro> zeha: how do you do that? :) 22:40:18 <paulvt> ouch 22:40:19 <zeha> you can install ben from unstable 22:40:24 <zeha> it 'mostly' works 22:40:30 <terceiro> ah 22:40:54 <boutil> ok... but we would need a list with only a selection on Build-Depends matching ruby1.9.1 22:41:35 <paulvt> yes because now everything that uses gem2deb is in there 22:41:40 <boutil> to know packages that are really problematic, against those needing only a rebuild against newer gem2deb 22:42:13 <boutil> libruby1.9 is matched in the depends line, if it is added by gemdeb for arch: any packages 22:42:37 <zeha> yeah 22:42:49 <paulvt> yeah 22:42:54 <zeha> i'll try that (but ben will need a few minutes) 22:43:05 <boutil> zeha: could you provide another list to complement with just the match on build-depends to have an idea? 22:43:48 <terceiro> zeha: also the Good: line could be just "not matches ruby1.9" 22:44:09 <boutil> next topic? 22:44:18 <paulvt> aye 22:44:23 <zeha> terceiro, do you know how to say that in ben syntax? 22:44:29 <terceiro> !~ ? 22:44:47 <boutil> #topic gitlab packaging? 22:44:53 <boutil> #topic gitlab packaging 22:45:09 <boutil> there hasn't been much progress lately 22:45:25 <boutil> #link http://people.debian.org/~boutil/gitlab/gitlab_deps20140128.pdf 22:46:05 <boutil> I haven't done precise stats, but I think we are about 75% through 22:46:14 <boutil> (maybe more). 22:46:19 <terceiro> that's awesome 22:46:28 <paulvt> huge task indeed 22:46:51 <paulvt> on a side-note, wasn't there also a diaspora effort of about the same size, or did that die out? 22:46:54 <boutil> Some packages are almost ready in the repository, but Daniel Marti didn't show up for a while on the list 22:47:17 <boutil> paulvt: diaspora packaging is still +/- active 22:47:27 <paulvt> who is running that? 22:47:35 <boutil> praveen 22:47:36 <paulvt> I reckon they run into similar issues 22:47:37 <paulvt> ok 22:47:40 <boutil> #link http://people.debian.org/~boutil/diaspora/diaspora_deps20140128.pdf 22:47:49 <hggh> perhaps I could grab some of the gitlab deps 22:47:52 <boutil> about the same state 22:47:57 <paulvt> indeed 22:48:13 <paulvt> I think they are both quite nice applications to have 22:48:20 <boutil> same progress / same current activity 22:48:38 <hggh> paulvt: ack 22:48:40 <boutil> there is a dedicated channel #debian-diaspora 22:48:55 <terceiro> yep 22:49:08 <terceiro> once we have redmine, gitlab and diaspora in debian it will be really cool 22:49:13 <paulvt> yes 22:49:19 <hggh> yep 22:49:21 <boutil> there is a lot of related ITP filed, but no packages around. 22:49:32 <boutil> one would need to prioritize that. 22:49:37 <hggh> #action hggh will have a look at the gitlab deps 22:49:55 <boutil> prioritize packaging those "dead" ITPs 22:50:07 <terceiro> someone please give a debian account to hggh :) 22:50:23 <hggh> terceiro: I have some open rfs :P 22:50:28 <terceiro> hggh: I know! :) 22:50:34 <paulvt> so! 22:50:35 <boutil> everybody knows :) 22:50:58 <terceiro> hggh: we should forward all of those to your AM 22:51:03 <terceiro> lol 22:51:08 <paulvt> not I, but I've been a bit lost in mail and stuff... I see PET is working again 22:51:09 <boutil> :D 22:51:09 <hggh> .oO my status is "waiting for AM to confirm" 22:51:18 <paulvt> whois is your AM? 22:51:30 <hggh> paulvt: nhandler 22:51:33 <boutil> PET is working again, and DMD provides a nice list. 22:51:56 <boutil> I will send an email to the list to try to revive gitlab packaging 22:52:14 <paulvt> is it just packaging issues? 22:52:21 <paulvt> or also gems that are modified within the project and stuff? 22:52:41 <terceiro> there's also that 22:52:46 <boutil> #action boutil mail debian-ruby@ about gitlab packaging initiative 22:52:49 <terceiro> but I'd say it's only a handfull of packages 22:52:52 <hggh> paulvt: i think the modified issue has gone down with the newest gitlab version 22:52:59 <paulvt> good 22:53:08 <paulvt> lol, still a lot of missing tags in PET I see :) 22:53:22 <paulvt> next topic! 22:53:24 <zeha> pet is somewhat broken i think 22:53:36 <boutil> #action boutil mail debian-ruby@ about the state of the team repo 22:53:59 <boutil> next topic beeing... 22:54:08 <hggh> 5min left 22:54:19 <boutil> ahhaha! 22:54:37 <terceiro> I think that was the last topic 22:54:44 <hggh> yes 22:54:47 <paulvt> wow ok 22:54:58 <zeha> random thought: if anybody wants to look at 'fix "rails new" to work ootb', please do ;-) 22:55:03 <paulvt> so I made some mental note about something, but forgot 22:55:13 <paulvt> zeha: it doesn't work? 22:55:16 <boutil> so about rubygems-integration: now we have are supposed to have an all/ directory? 22:55:17 <terceiro> zeha: the fix in stuck in NEW 22:55:23 <paulvt> ooph 22:55:25 <zeha> terceiro, ah, indeed 22:55:36 <zeha> + lots of dependencies for 4.0 22:55:53 <paulvt> yes! can we talk about rubygems-integration a bit 22:56:00 <boutil> I built a package recently, and couldn't find it in the result... 22:56:09 <boutil> #topic rubygems-integration 22:56:10 <terceiro> boutil: yes, I uploaded rubygems-integration 1.5 yesterday with support for "all" 22:56:11 <hggh> boutil: the creating pdf for gitlab stops at 28.01, it only creates a new pdf if some changes or cronjob stopped? 22:56:24 <zeha> http://people.debian.org/~zeha/rubyremoval/html/ruby191-bd.html this is probably the "ugly" set 22:56:29 <terceiro> boutil: the corresponding gem2deb chnage will be uplooaded tonight most probably 22:56:35 <boutil> hggh: it's a bug in the way graphs migrate to my homepage. 22:56:38 <boutil> will fix it. 22:56:47 <boutil> terceiro: ah ok. 22:56:50 <hggh> boutil: is the source available? 22:57:05 <terceiro> zeha: the ugly set is small enough 22:57:12 <paulvt> indeed! 22:57:20 <paulvt> but almost none are "ours" 22:57:25 <boutil> hggh: give you the link later when I find it. 22:57:29 <hggh> haha that are also the ugly one from the ruby1.8er removal 22:57:42 <hggh> libzip-ruby, ruby-filesystem. -.- 22:57:47 <paulvt> no surprises there ;) 22:57:56 <boutil> about rubygems-integration: there is an issue with the specs of packages declaring binaries 22:58:10 <terceiro> boutil: what issue? 22:58:25 <boutil> I remember that paulvt filed a bug of this kind for rake. is that correct? 22:58:33 <paulvt> boutil: 22:58:38 <paulvt> ...yes 22:58:47 <terceiro> #710814 22:58:48 <terceiro> ? 22:59:01 <boutil> the binary field is usually relative to the gem structure. 22:59:16 <paulvt> I've been using rubygems(-integration ) to develop on my sid machine and be able to deploy on wheezy 22:59:20 <paulvt> on squeeze* 22:59:25 <paulvt> boutil: right 22:59:38 <boutil> when the specs are moved to /usr/share/rubygems-integration, the binary is not where it is looked for. 23:00:01 <paulvt> right, and that is something that "we" break 23:00:03 <terceiro> IIRC rubygems-integration does not say anything about bin_path 23:00:04 <boutil> should we manually patch the gemspecs to fix the path? 23:00:05 <paulvt> terceiro: indeed 23:00:26 <hggh> boutil: https://gitorious.org/debian-diaspora/gemdeps/source/e6640d4603661ec606397f1e69dbb67a0d6e48a1: I think that's the source. 23:00:59 <boutil> hggh: indeed :) 23:01:48 <hggh> http://people.debian.org/~boutil/diaspora/README found it here 23:01:49 <paulvt> boutil: or patch the stub 23:01:56 * boutil opened the rake gemspecs 23:02:53 <terceiro> I don't know the solution now, but we probably want to make it point to /usr/bin instead, and do that in rubygems-integration 23:03:02 <paulvt> hmm no, that's hard if you would install a X and Y version of a gem with a binary stub 23:03:05 <boutil> so the 'executables' should be understood by rubygems for specs in /usr/share/rubygems-integration to be in /usr/bin, and not in their /usr/share/rubygems-integration directory 23:03:20 <paulvt> yeah 23:04:43 <boutil> other misc topics? 23:04:47 <paulvt> another random thought... it would be nice somehow if gem list could show somehow which are Debians versions 23:04:56 <boutil> +1 23:05:08 <hggh> oh +1 23:05:18 <paulvt> at some point I'm coninuously using gem list and apt-cache policy to find out what the hell is going on 23:05:21 <terceiro> yeah me too, patches welcome :) 23:05:39 <paulvt> I've looked into this a bit, but it goes pretty deep 23:05:50 <boutil> there is also the policy thing... 23:05:53 <paulvt> maybe rubygems-integration could provide something similar 23:06:13 <paulvt> to show "the status of the integration" and then we don't have to dive into Rubygems 23:06:23 <terceiro> I need to go out now, maybe we can add the policy to the agenda of the next meeting? 23:06:29 <paulvt> agreed 23:06:30 <boutil> ok. 23:06:40 <zeha> +1 23:06:41 <terceiro> boutil: thanks for organizing! 23:06:42 <paulvt> I need to go to bed too 23:06:47 <boutil> shall we fix roughly a day for the next meeting? 23:07:00 <boutil> let's say four weeks from now 23:07:01 <paulvt> so if it's at 23:00 I can attend on Mondays/Tuesdays 23:07:06 <paulvt> ack 23:07:10 <terceiro> works for me 23:07:15 <hggh> fine for me 23:07:20 <paulvt> (at 22:00 UTC I mean) 23:07:21 <boutil> ok, let's stay with tuesday then 23:07:40 <boutil> see you (if not before) on March 11, 22:00 UTC. 23:07:46 <zeha> ack 23:07:53 <terceiro> cool 23:07:53 <paulvt> I'll try before 23:07:56 <terceiro> thanks everyone 23:07:59 <paulvt> I'd also like to reiterate: 23:08:16 <paulvt> if you have a small task for me with a given deadline... pass it on.. otherwise I cannot do much atm 23:08:29 <boutil> ruby-dbus needs help 23:08:34 <paulvt> (such as a RFS) 23:08:38 <paulvt> oh? 23:08:39 * terceiro needs to go o/ 23:08:43 <boutil> #endmeeting