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