20:01:05 #startmeeting 20:01:05 Meeting started Tue May 27 20:01:05 2014 UTC. The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:01:34 Hi everybody and welcome to this 4th(?) Debian meeting! 20:02:44 \o/ 20:02:50 boutil: is the chairman :) 20:02:57 we are only 3 ? 20:03:22 maybe... 20:03:40 arf ok :/ 20:04:27 we have a agenda for this meeting? 20:04:34 nope 20:04:52 we (I) are less and less organized 20:04:55 I think praveen added some topics to the wiki 20:05:29 that was for last month's meeting 20:05:35 hm 20:05:41 but we could still discuss them :) 20:05:57 let's start with the status of the interpreters 20:06:08 #topic interpreters, ruby2.1 status 20:06:14 ok 20:06:22 so ruby2.1 is already the default 20:06:25 \o/ 20:06:30 which is nice, since we still have ~6 months to the freeze 20:06:32 we have a lot of ftbfs about 2.1 :/ 20:06:44 /o\ 20:06:55 how many is a lot? 20:07:35 no you're right, it's no so much 20:07:49 there is about ~30, and half of them are FTBFS I think 20:07:57 #link https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby2.0-rm;users=debian-ruby@lists.debian.org 20:08:09 yeah I think we are fine 20:08:11 but among them, many are not caused by ruby2.1 20:08:18 yes 20:09:22 we have still packages with bugs about ruby1.8 hard dep. Should be remove them? 20:10:00 I think ruby-tmail is already not in testing 20:10:16 I think about ruby-tmail, ruby-amrita* 20:10:20 we just need to take care to not spend time on lost causes 20:11:12 If we didn't manage to do the work for ruby1.9.1, then for ruby2.1, I believe we will not able to do any better. 20:12:11 that's right 20:12:26 are there other steps to make to improve ruby2.1 experience? 20:12:56 there is the sourcefull upload of arch:all packages to get gemspec in the all/ subdir 20:13:54 have all needed NMUs been scheduled? terceiro: I saw you asked some of them, but didn't follow closely 20:14:54 boutil: I think they weren't scheduled 20:15:06 we should probably infiltrate someone in the RT :) 20:15:20 ^^ 20:15:46 :) 20:16:38 did you ask all the needed ones? or was it the first wave? 20:17:53 terceiro: ^ 20:18:01 it was all the needed ones 20:18:04 AFAICT 20:18:06 ok. 20:18:09 it was a small set BTW 20:18:29 #action terceiro will ping the RT regarding the needed NMU's to remove ruby2.0 20:18:39 so everything looks good for ruby2.1 (or almost) 20:18:45 pretty much 20:18:58 let's just fix some RC bugs :) 20:19:16 Is that all for the interpreter? 20:19:24 ah a 20:19:27 I have a quick topic: 20:19:33 I have a topic I would like to discuss as well 20:19:34 #topic: ruby policy 20:19:36 boutil: you first 20:19:44 No news :/ 20:20:00 boutil: what's the current status? 20:20:05 sbadia: I remember you proposed some help 20:20:18 yep :) 20:20:39 terceiro: the status is almost the same as the status at the sprint, which was about the same as pre-wheezy 20:20:44 sorry for the last month… 20:20:46 yep 20:20:50 hahaha 20:21:13 so let's hope we make some progress in the coming month :) 20:21:25 #action boutil work on the policy 20:21:26 I think we kind of agreed to put the policy in src:ruby-defaults? 20:21:33 ah? 20:21:44 would be great. 20:21:46 no? 20:21:56 There is really no need for an additional package 20:22:09 I am totally fine with that 20:22:20 ok 20:22:29 #action move policy to ruby-defaults 20:22:45 that's it for the policy 20:22:46 we can add the policy to ruby-dev, or even create a new binary for it 20:22:52 ruby-dev makes a lot of sense I think 20:22:58 indeed 20:23:22 ok, so let's to my point 20:23:46 #topic call for help: gem2deb maintainance 20:24:12 I have been working on too many things so I would like help with gem2deb 20:24:46 for instance there are 2 patches floating in the debian-ruby ML that I didn't get to review yet 20:25:20 I can try to have a look 20:25:31 hum and 22 bugs 20:26:13 there are a lot of wishlist bugs though 20:26:14 but I don't feel very confident to mess deeply with such a critical tool 20:26:52 boutil: if all tests pass you are most probably on the safe side :) 20:27:09 terceiro: you're right :) Thanks TDD 20:27:26 besides, at this point there is probably no need for big changes 20:27:42 it's mostly keeping up with bugs and with the patches for those wishlists 20:27:51 ok, I promise to have a look! 20:28:00 boutil: thanks a lot 20:28:12 #action boutil help maintaining gem2deb 20:28:37 another topic would be debci/gem2deb integration 20:28:50 shall we discuss this now? 20:29:13 let's 20:29:15 yes 20:29:48 #topic debci and gem2deb 20:30:24 so, there is some support in gem2deb already 20:30:29 see commit 4c961efe8c549e5f05a444c776cde5f54ba4e3de 20:30:52 * terceiro getting a proper link 20:32:04 #link http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/gem2deb.git;a=commitdiff;h=4c961efe8c549e5f05a444c776cde5f54ba4e3de;hp=d2235fbaa55c5112d4acad3a5d60fedade81832f 20:32:16 what's pending is: 20:32:43 - extract the test runner to a separate binary package so that test suite don't need to depend on the whole gem2deb 20:33:13 - change dh-make-ruby to create the DEP-8 files 20:33:48 - ellaborate a strategy to mass-enable autopkgtest in the existing packages (maybe not really feasible) 20:34:22 that is already a lot 20:35:28 what is exactly the workflow: where the new binary package will intervene: shall we build-depend and/or depend on it? 20:35:38 it is still a bit vague in my mind 20:36:00 ah it would be a dependency declared in the DEP-8 file? 20:37:00 yes! 20:37:06 great. 20:37:19 and gem2deb would also depend on it 20:37:45 and the new binary would be used (without the --autopkgtest switch) by dh_ruby 20:38:10 so after the build, we would run the DEP-8 test-suite 20:38:16 basicaly it's turning lib/gem2deb/test_runner.rb into /usr/bin/$something 20:38:33 and have dh_ruby call that instead of test_runner.rb 20:39:16 ok, I see the global pattern now. 20:39:47 03Antonio Terceiro 05master cd0710f 06gem2deb 10debian/changelog 10lib/gem2deb/extension_builder.rb extension builder: display build logs in real time * 14http://deb.li/31i2v 20:40:14 I have nothing more to ask. 20:40:22 about that, I mean. 20:41:02 next topic? 20:41:37 #topic rails 20:42:36 does anybody now the state of Rails4 in Debian? 20:42:46 nope… 20:43:31 me neither 20:43:46 I will probably want to check that out at some point 20:43:52 but wouldn't mind someone going for it as well 20:44:06 do we provide a unified path to install the various rails file shipped by different package? 20:44:18 what do you mean 20:44:20 ? 20:44:49 we have/had several bugs about packages shipping files with the same name 20:45:38 yes 20:45:47 specially packages that override rails generators 20:46:10 because the rails generator think abuses the $LOAD_PATH and because with rubygems people are usually safe from it 20:46:27 some packages also are shippings assets or other files to be used with rails 20:46:58 and I don't know if as they are installed now, rails will be able to use them. 20:47:02 the ones I worked on were patched to install the assets to /usr/share/$pkg and read them from there 20:47:22 e.g. ruby-jquery-rails 20:47:41 praveen packages some packages of this kind, and we both don't have much clue about rails 20:48:17 I think using ruby-jquery-rails as an example is a good start 20:48:28 ok, so we can look at it for inspiration 20:48:43 also ruby-coffee-rails and ruby-sass-rails IIRC 20:49:08 about tests using rails apps. Is there anything reasonable we could do? 20:49:43 that was a question by praveen on the list and a topic added in the wiki for the (previous) meeting 20:50:11 I never managed to look at it in depth 20:50:29 and TBH I didn't understand what the problem really is 20:52:24 me neither. 20:52:40 maybe let's keep it to the next meeting 20:53:22 ok 20:53:24 It would be great if praveen could join the meeting, this would probably help 20:53:36 other topics to discuss? 20:53:54 just two informal questions for me 20:54:01 go ahead 20:54:17 about capsitrano (the mail on the ML) 20:54:28 #topic various topics 20:54:39 capistrano >= 3 break the retro-compat. 20:54:55 we should add a notice on the installation 20:55:02 yes 20:55:06 or make another binary package 20:55:18 ok, how we do that ? 20:55:27 debian/NEWS 20:55:37 oh! ok 20:55:42 thanks 20:56:34 I want to look at that RFS at some point 20:57:42 no problem :) 20:57:57 regarding compatibility I think there isn't much to do 20:58:17 I should also mention the (lack of) progress of Gitlab packaging. Still about ~70% of deps packaged. 20:58:28 yep :-/ 20:58:32 it's not like the uprgade will break peoples server, they will "just" need to update their deployment setup 20:58:37 It probably will not make it for jessie 20:58:37 before deploying again 20:58:51 terceiro: yep 20:59:03 there is also a migration guide out there 20:59:06 #link https://semaphoreapp.com/blog/2013/11/26/capistrano-3-upgrade-guide.html 20:59:59 sbadia: you had a second question? 21:00:11 we have reached the 1-hour mark 21:00:27 boutil: sbadia any other topics? 21:00:53 still on capistrano: 21:01:03 official upgrade doc: 21:01:09 #link http://capistranorb.com/documentation/upgrading/ 21:01:29 yep, sorry it's about vagrant, but apparently laurent said he want to contact the upstream (bundler is a pain…) 21:02:34 terceiro: i can link the upstream doc in NEWS ? or I should integrate them inside? 21:03:03 sbadia: write a warning paragraph and add the link 21:03:15 no ok… yep forget my question :) 21:03:46 let's wait for upstream's answer about vagrant? 21:03:50 that would be all for me. 21:04:06 me too, thx! 21:04:18 thanks for joining! 21:04:40 #endmeeting