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