19:59:06 <boutil> #startmeeting
19:59:06 <MeetBot> Meeting started Tue Apr 15 19:59:06 2014 UTC.  The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:59:32 <boutil> Hi everybody, welcome to this third IRC meeting.
19:59:39 <avtobiff> hi!
19:59:46 <aj-> hi
19:59:53 <nomadium> hello
20:00:01 <deiv> hi !
20:00:21 <sbadia> hi
20:00:44 <boutil> can we start with a list of subjects you would like to discuss today?
20:01:31 <avtobiff> status of ruby1.9.1-rm maybe?
20:01:46 <hggh> hi
20:01:51 <boutil> status of ruby2.1 support too.
20:01:56 * hggh is very busy, so only reading
20:02:24 * nomadium is new to debian-ruby meetings, so only reading as well
20:02:36 <boutil> rails metapackages ?
20:03:43 <boutil> maybe other topics will come to mind during the discussion.
20:04:11 <boutil> I see that zeha sent a message to the list about the status of the various versions of the interpreter.
20:04:40 <boutil> #topic Ruby1.9
20:04:59 <boutil> Quoting zeha:
20:05:00 <boutil> 1.9 is on it's way out, as one can track on this transition
20:05:00 <boutil> tracker:
20:05:01 <boutil> https://release.debian.org/transitions/html/ruby1.9.1-rm.html
20:05:21 <boutil> I think everything that can be fixed by a binNMU has been fixed
20:05:21 <boutil> already; those packages are usually those in the list that are green
20:05:21 <boutil> on all archs except sparc -- we don't have ruby2.1 on sparc, so
20:05:21 <boutil> that's a (hopefully small) issue as long as sparc is still in
20:05:21 <boutil> testing. (I think we can ignore sparc, altough it might delay the
20:05:23 <boutil> removal for a bit longer.)
20:05:39 <boutil> I believe all arch-specific packages that FTBFS or have other issues
20:05:39 <boutil> that prevent a binNMU bugs have been filed. It'd be great if
20:05:39 <boutil> somebody could check for this: all arch-specific packages should
20:05:39 <boutil> have an open RC bug.
20:05:47 <boutil> There are a few team and non-team packages that would benefit from
20:05:48 <boutil> NMUs to either fix dependencies or fix FTBFS. Please work on this!
20:05:48 <boutil> :)
20:06:28 <boutil> Does anyone know if there is a usertag specific to these bugs?
20:06:46 <hggh> i think so. read it somewhere
20:07:37 <hggh> http://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-ruby%40lists.debian.org nope
20:08:34 <boutil> We can use the same convention as for ruby1.8: something like 'ruby19-removal'
20:08:51 <hggh> yes
20:09:42 <boutil> If you encounter bugs preventing the removal of ruby1.9.1, please tag them with username: debian-ruby@lists.debian.org, usertag: ruby19-removal
20:09:57 <centrx> Excuse me, I was told there would be drinks
20:10:18 <avtobiff> there was an issue with a package that changed from arch:any to arch:all, is that something that needs manual intervention? i suggested to file a RM request to ftp.debian.org for the package and reupload.
20:10:23 <boutil> centrx: you should have brought your :)
20:10:45 <hggh> avtobiff: I think my em-foo package
20:10:59 <hggh> ruby-em-http-request
20:11:02 <avtobiff> hggh, indeed
20:11:16 <boutil> avtobiff: I was thinking also about requesting a RM. Is reuploading necessary?
20:11:19 <hggh> lot track, because of too much workload at $work
20:11:28 <hggh> s/lot/lost/
20:11:37 <boutil> Maybe the package is in the archive, but screened by the arch:any existing old version
20:11:42 <avtobiff> boutil, hey i am just guessing here.
20:11:44 <avtobiff> boutil, probably
20:11:55 <boutil> (haven't checked the content of the archive, though)
20:12:15 <hggh> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744742
20:12:19 <boutil> at least, the RM step seems mandatory
20:12:21 <avtobiff> #744742
20:12:23 <avtobiff> yes
20:12:41 <avtobiff> ok, then it was sound advice at least
20:12:45 <boutil> avtobiff: will you do it?
20:12:53 <avtobiff> it's already done boutil afaics
20:12:58 <boutil> oh, nice.
20:13:15 <avtobiff> :)
20:13:24 <boutil> questions about ruby1.9?
20:14:15 <avtobiff> is there anything that can't run with ruby2.0 (or 2.1)?
20:14:15 <boutil> ok, so what about ruby2.0 and 2.1...
20:14:37 <boutil> #topic ruby2.0 & ruby2.1
20:14:38 <avtobiff> or are those things (probably) dead upstream anyway and we don't care about them?
20:14:42 <avtobiff> or unused?
20:15:18 <boutil> I don't remember having met packages with (strong) incompatibilities with ruby2.0/ruby2.1
20:15:49 <boutil> everything working with ruby1.9.1 should (almost) work with 2.x.
20:16:05 <boutil> The porting effort is much less than from 1.8 to 1.9.1
20:16:07 <avtobiff> nah, i just remember trying to bring things from 1.8 to 1.9, that required some intervention in some cases. haven't seen anything this time around.
20:16:33 <boutil> about support for 2.0 & 2.1, zeha writes:
20:16:38 <boutil> With the same binNMUs as for the 1.9.1 removal most packages gain
20:16:38 <boutil> binaries for ruby 2.1; if not, they'll at least have support for
20:16:39 <boutil> 2.0.
20:16:44 <boutil> Can't think of any immediate action here, except for that we should
20:16:44 <boutil> plan for the default switchover to 2.1. Maybe we could already do
20:16:44 <boutil> that RSN.
20:16:57 <boutil> In addition to the arch-specific package fixing which benefits the
20:16:57 <boutil> 1.9 removal and 2.1, all arch:all packages that don't install into
20:16:57 <boutil> the shared "all" gemspec directory need sourceful reuploads. (One
20:16:57 <boutil> can search for these using grep-dctrl for XB-Ruby-Versions being
20:16:59 <boutil> !all and Architecture == all).
20:17:25 <boutil> What does RSN mean?
20:18:12 <boutil> Really Soon Now, it seems
20:19:16 <avtobiff> ok
20:19:31 <boutil> ok, so arch:any packages should be ok after the bin-NMU round, arch:all are good anyways, but they will be even better after a new upload wrt rubygems-integration.
20:20:47 <boutil> huge thanks for the precise report, and all the work behind it
20:20:59 <boutil> thanks zeha!
20:22:01 <boutil> questions about ruby2.0 / ruby2.1?
20:22:54 <avtobiff> i don't think i have any at least
20:23:09 <avtobiff> well, i haven't understood if we are going for ruby2.1
20:23:19 <avtobiff> and why we are migrating to ruby2.0 in between.
20:24:45 <boutil> That's a good question.
20:25:08 <hggh> i think because 2.0 hits testing, so you need to provide upgrade paths
20:25:46 <boutil> During the meeting in Paris, we decided what would be the version of the interpreter in Jessie,
20:26:01 <boutil> but also came up with an upgrading scheme.
20:26:33 <avtobiff> ok, but do we have to do anything with arch:all packages that are rebuilt with Ruby-Versions: all?
20:26:44 <boutil> Since the packaging for ruby2.0 was ready at that time (and not that of ruby2.1), it was natural to test it from the transition ruby1.9.1-> ruby2.0
20:26:50 <avtobiff> ok
20:27:34 <boutil> the next sourceful upload of arch:all should be the last one needed to take into account various versions of the interpreter:
20:28:26 <boutil> whereas arch:any packages ship rubygems metadata in /usr/share/rubygems-integration/2.xsomething,
20:28:46 <boutil> arch:all packages move them to /u/s/rubygems-integration/all
20:28:52 <avtobiff> yeah, i have seen that in the process of fixing packages
20:29:06 <avtobiff> ok, i thought i'd ask instead of continue wondering at least :)
20:29:18 <boutil> so a new upload to support a new version shouldn't be needed.
20:29:24 <avtobiff> and i believe the answer was good also :)
20:29:25 <avtobiff> neat
20:29:28 <boutil> :)
20:29:41 <boutil> next topic?
20:29:58 <boutil> #topic ruby rails metapackages?
20:30:09 <boutil> I had a question about this:
20:30:47 <boutil> ruby-active*-3.2 used to provide ruby-active* metapackages.
20:31:00 <boutil> which would correspond to the default version of rails.
20:31:45 <boutil> I saw that these do not provide the ruby-active* packages anymore, but some packages still depend on those unversioned packages.
20:32:48 <boutil> ex: ruby-gettext-activerecord depends on ruby-activerecord
20:34:03 <boutil> which is provided by an 'old' version of rails-3.2
20:34:20 <boutil> (3.2.13, whereas we have 3.2.17 in unstable)
20:35:08 <boutil> I was wondering if there was a plan to reintroduce them or whether all packages should depend on versioned ruby-active*-3.2/4.0 packages.
20:35:51 <boutil> without terceiro or zeha, don't know if I get an answer here, but at least it will appear in the notes.
20:36:46 <boutil> #topic ruby policy
20:36:55 <boutil> no progress on this on my side.
20:37:24 <hggh> oh we should done that in paris :)
20:37:33 <boutil> For the record, there is a ruby-policy git repo, containing a draft for a Ruby Debian policy
20:38:15 <boutil> but it is "slightly" outdated: pre-wheezy (more precisely post-squeeze I guess)
20:38:36 <boutil> It needs some editing.
20:39:31 <boutil> I am looking for volunteers to help me with that, at least to first read the text, and possibly propose improvements
20:40:35 <boutil> Mainly we need to document there what gem2deb is currently doing
20:40:54 <aj-> I can read that
20:40:59 <sbadia> indeed
20:41:02 <sbadia> I am willing to help
20:41:05 <boutil> since it is our reference implementation :)
20:41:15 <boutil> thanks!
20:41:44 <boutil> #action aj- sbadia read and comment the ruby-policy document
20:42:37 <sbadia> aj-: you live in france ?
20:42:56 <boutil> deiv: can you say a few words about the mass rebuilds you did for the Ruby team these days?
20:43:34 <aj-> sbadia: I am on central time
20:43:43 <sbadia> ok
20:43:50 <aj-> france -7
20:44:02 <sbadia> boutil: I can come to paris (it may be easier to be in the same room to work on it)
20:44:18 <boutil> that'd be perfect!
20:44:23 <aj-> we can videoconf
20:44:36 <sbadia> yep also
20:44:51 <terceiro> boutil: the unversioned ruby-acti* rails packages are still provided by src:rails
20:45:02 <terceiro> which now kinds of acts as a -defaults package
20:45:03 <deiv> not much, at least :)
20:45:22 <deiv> the number of FTBFS in not bigger (around 30 I think)
20:45:32 * terceiro is really sorry for forgetting the beginning of the meeting :-(
20:46:24 <boutil> deiv: that's good news :)
20:47:01 <deiv> I remeber to see a pair of "ruby1.9.1: Command not found" ;)
20:47:18 <boutil> are there other rebuilds scheduled?
20:48:03 <deiv> specific to ruby, none
20:48:24 <boutil> ok, thanks. So we have time to fix a few RC bugs
20:48:36 <sbadia> \o/
20:48:55 <aj-> what is the next deadline ?
20:50:37 <deiv> I dunno if zeha file them (http://aws-logs.debian.net/ftbfs-logs/ruby-14-4-14/ruby.results.failed)
20:51:17 <boutil> terceiro: re rails, Ah! So e.g ruby-activerecord is provided by ruby-activerecord-4.0, but there is still a real ruby-activerecord package 2:3.2.13+b1 in unstable, which probably needs to be removed right?
20:53:20 <terceiro> boutil: my idea was to keep the unversioned packages as real ones provided by src:rails and remove the Provides from rails-4.0 as I did with rails-3.2
20:53:20 <boutil> deiv: I think they were filed: I saw a recent RC bug for mysql2 and gherkin
20:54:04 <terceiro> we need someone to look after rails4
20:54:44 <boutil> #help someone to look after rails4
20:56:49 <boutil> terceiro: ah, so are the ruby-active*-3.2 deprecated?
20:57:14 <terceiro> boutil: they are not. They just don't replace/provide the unversioned ones
20:57:24 <boutil> terceiro: I am a bit lost, because in unstable, I have
20:57:38 <terceiro> the idea it to use src:rails as if was a rails-defaults, dependencing on the current default version
20:57:43 <boutil> ruby-activesupport-3.2 3.2.16-1 and 3.2.17-3 and ruby-activesupport
20:58:05 <terceiro> Package: ruby-activesupport
20:58:08 <terceiro> Depends: ruby-activesupport-3.2
20:58:37 <boutil> ok, right (I am a bit dense tonight...)
20:58:58 <terceiro> so when we think rails4 is in good enough shape to be the default, ruby-activesupport should depend on ruby-activesupport-4.? and so on
20:59:34 <boutil> and the fact we have still two versions in 3.2.16 and 3.2.17 in unstable?
21:00:16 <terceiro> that's because there used to be a ruby-*-3.2 source packages, which are now superseded by the common src:rails-3.2 that provides all the binaries
21:00:32 <terceiro> in theory the old packages should be removed automatically by the archive
21:01:30 <boutil> ok, thanks for the explanation.
21:01:48 <boutil> other questions/topics?
21:02:55 <boutil> so, I propose we close this meeting.
21:03:00 <boutil> thanks everyone!
21:03:01 <sbadia> maybe a point on gitlab ?
21:03:07 <boutil> ah good idea!
21:03:17 <sbadia> (related on email from gitlab team)
21:03:30 <avtobiff> yeah, i was going to ask if there is anyone driving gitlab/gitorious/diaspora
21:03:36 <boutil> today's graph: http://people.debian.org/~boutil/gitlab/gitlab_deps20140415.pdf
21:03:55 <avtobiff> i have been taking packages at random trying to get into debian but it can take a while...
21:04:14 <boutil> praveen (aka j4v4m4n on IRC) is driving the diaspora packaging effort
21:04:30 <boutil> they have a dedicated IRC channel #debian-diaspora
21:04:39 <boutil> not much activity there at the moment
21:05:14 <boutil> hggh volunteered to be the contact with upstream Gitlab, if I remember well
21:05:20 <hggh> yep, my work on redis stuff stalled
21:05:54 <boutil> diaspora and gitlab share a certain number of gems.
21:06:20 <boutil> I think diaspora reached recently 75% of packaged gems
21:06:30 <boutil> For Gitlab, it is a bit less
21:06:51 <boutil> There has not been much progress since last month
21:07:28 <hggh> yes. em-mongo was upload but rejected, was my fault because d/copyright was not correct
21:07:38 <boutil> So people looking for packaging tasks are welcome to pick unpackaged gems and turn them into proper Debian packages
21:08:03 <avtobiff> maybe we could put in a textual list on the wiki? complementing the graph?
21:08:35 <boutil> you mean a linear list of gems, with possibly the name of people wanting to take care of them?
21:08:47 <avtobiff> yes
21:09:13 <avtobiff> i don't know if your graph provides some list with the info?
21:09:34 <hggh> there are many ITP opened, but get stalled because of missing dependencies
21:10:11 <boutil> on this page: http://people.debian.org/~boutil/gitlab/ there is a pdf with the graph, and the corresponding dot file. The first part lists the nodes of the graph.
21:10:47 <boutil> some ITP are simply stalled, filed months ago, without any sort of activity.
21:11:11 <avtobiff> yeah, maybe a human operated list would be a good complement
21:11:12 <boutil> I consider that those can be hijacked.
21:11:20 <hggh> 5 ITPs opened by me :-/
21:11:20 <avtobiff> because i don't look at stuff which already have an ITP
21:11:43 <boutil> avtobiff: agreed. I'll come up with a list in the wiki.
21:12:12 <avtobiff> great!
21:13:11 <boutil> upstream seems very eager to help our packaging task, that is great.
21:13:25 <boutil> Let's see how it goes...
21:13:35 <boutil> Other questions about diaspora/gitlab?
21:14:13 <sbadia> nope
21:14:29 <boutil> ok, then let's close this session. Thanks everybody!
21:14:35 <sbadia> Thanks!
21:14:52 <avtobiff> thanks!
21:14:55 <boutil> #endmeeting