20:08:58 #startmeeting 20:08:58 Meeting started Thu Jun 4 20:08:58 2015 UTC. The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:08:58 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:09:09 #topic say Hi! 20:09:15 hi! everybody! 20:09:20 hello boutil :) 20:09:23 welcome to the Ruby meeting 20:10:23 hi! 20:10:39 hey :) 20:11:21 so the topics today are ruby2.2, rspec3, gitlab and diaspora, and misc 20:11:40 #topic ruby2.2 20:12:06 terceiro is apparently ready to upload ruby2.2. 20:12:32 so ruby-defaults will point to 2.2? 20:12:37 I would go for it, what do you think? 20:13:07 the question is: will we have a transition period where we build for ruby2.1 and ruby2.2? 20:13:40 it wouldn't hurt, right? 20:13:56 to have a smooth transition, as we had for ruby2.0→ruby2.1 (or was it ruby1.9.1→ruby2.0?) 20:14:10 yes, I'm in favor of smooth transitions 20:14:34 #info terceiro is ready to upload ruby2.2 20:15:03 it's more about uploading ruby-defaults, right? 20:15:12 ruby2.2 is already in the archive 20:15:35 yes, indeed... sorry. 20:16:47 perhaps we should use the transition for ruby 2.2 also to ship rsepc3. so breaking the archive only once ;) 20:18:41 why not 20:19:08 terceir wanted a volunteer to track various problems related to ruby2.2. 20:19:32 or we should rebuild first all packages with rspec3 and 2.2 from exp to open bugs (I think it will be many) 20:20:36 #action boutil will track problems related to ruby2.2 20:21:20 #action terceiro will activate ruby2.2 in ruby-defaults 20:21:23 I'd go for an exp rebuild along masstest first 20:23:41 tnnn: you mean a rebuild of all ruby arch:any packages with ruby2.2, using e.g the Amazon account? 20:24:49 there is a priori no hurry: if ruby2.2 is activated in ruby-defaults, only new built packages will get support for ruby2.2 20:24:51 boutil: Yup, exactly. Antoinio has access to AWS so maybe he can schedule a quick rebuild? 20:25:19 at some point, we'll need to ask for NMU for not updated packages 20:25:35 but as long as ruby2.1 is the default version is ruby2.1, we are pretty safe 20:26:10 Mhm, I get it. Still, running a 2.2 rebuild might give us some insights 20:26:20 I mean, the rebuild with AWS can be done in parallell. 20:26:31 Yup, exactly what I thought 20:26:38 yes, it will good to know what the problems will be 20:27:13 #info a rebuild of all arch:any package on AWS with ruby2.2 would be (very) good 20:27:43 other comments/questions about ruby2.2? 20:28:04 #topic rspec3 20:28:31 We have still rspec2 in unstable, and rspec3 is available in experimental 20:29:17 more and more upstream projects are switching to Rspec3 20:29:28 since release of jessie is done, we can upload it to sid 20:29:40 about 200 packages build-depend on rspec 20:30:12 after the upload we can do a mass rebuild on aws with rspec3 from sid? 20:30:23 I think that about 2/3 of them will FTBFS in their current state if we upload rspec3 to unstable 20:30:40 and then we have to deal with dead upstream not fixing bugs :-/ 20:30:55 is there a way to restore compatibility with rspec2 in rspec3? 20:31:17 to buy some time on the rspec side, rather than patch many packages? 20:32:02 a project which used a fairly recent version of rspec2 should be ok with rspec3 if the deprecation warning were fixed 20:32:30 there is a tool, which is supposed to help with the conversion from rspec2 to rspec3 20:33:05 #info the transpec gem can help to update Rspec test suite to v3 20:33:48 oh nice 20:34:07 I also started a wiki page to list the most common problems 20:34:27 #link https://wiki.debian.org/Teams/Ruby/RSpec3 20:34:53 almost empty, feel free to add items 20:35:02 good work 20:35:23 there is also a Gobby document, with the list of packages, and some triage 20:35:30 I haven't finished yet 20:35:51 under Teams/RubyExtras/rspec3.txt 20:36:35 Some active upstream projects are stuck with a older version of RSpec2, and it will be more difficult 20:36:48 e.g. yard 20:37:45 Should we upload rspec3 to unstable, and simply deactivate (at least for the moment) test suites we cannot fix? 20:37:54 +1; yes 20:38:04 Just an info - the datamapper family of gems still use RSpec 1.. 20:38:09 :( 20:38:12 :( 20:38:45 yeah... ruby-httparty was in that situation, but surprisingly enough, a new upstream version made it jump directly to Rspec3 20:38:59 so keep faith :) 20:39:13 +1 for uploading rspec 3 to sid 20:39:19 ok. 20:39:29 #action boutil will upload rspec3 to unstable 20:39:55 As terceiro suggested, I'll take the opportunity to make a unique tarball 20:40:11 it will be easier to work with than the current multitarball setup 20:41:24 #info there is a 'rspec3' BTS user tag 20:41:32 https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=rspec3&user=debian-ruby%40lists.de 20:41:51 #link https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=rspec3&user=debian-ruby%40lists.debian.org 20:42:06 feel free to fill and tag some more bugs 20:42:52 questions about rspec3? 20:43:07 no, I'm fine 20:43:12 #topic gitlab and diaspora 20:43:54 did you see the mail from Pirate about crowd funding? 20:44:16 I think that diaspora is almost ready, right? 20:44:18 yes 20:44:37 yes.. IIRC, diaspora is apt-gettable 20:44:40 yup (I did see) 20:44:53 some more polishing works and tests are remaining I think 20:45:14 great news. 20:45:41 I think supporting gitlab over a release would very very hard, because gitlab fixes security with new release, they don't ship fixes for old releases 20:46:20 there is no package diaspora ATM in the archive or in NEW. (only diaspora-installer) 20:46:38 but there will be a diaspora binary package, right? 20:47:36 hggh: ah :/ Is it not possible to make them change their mind? 20:48:05 didn't gitlab guys mention something about an LTS version? 20:48:48 I don't know. they ship there own "debs" but these debs are :( (shipping ruby and all other stuff) (Puppetlabs does this now also :( ) 20:49:42 boutil: I think Praveen is ready with the diaspora package.. he is currently undergoing some treatment and don't have much access to computers.. he may upload it soon (hopefully) 20:51:31 bsc: ok 20:52:38 Sytse, mentioned that they are ready to do an LTS version if it helps packaging (in a personal mail). Is that a considerable idea? 20:52:47 bsc: can you recall the link to the status bar for Gitlab dependencies 20:52:49 ? 20:53:38 bsc: this is of course a considerable idea. 20:53:41 boutil, the one I used? - http://balasankarc.in/gitlab/ - there may be some false positives/negatives 20:54:38 FYI, I fixed my broken script, the pdf graphs should be produced successfully 20:54:46 https://people.debian.org/~boutil/gitlab/ 20:55:29 boutil, Ah.. cool.. This was just my hobby project to learn ruby.. :) 20:56:30 :) 20:57:00 #info anybody is welcome to package some Gitlab dependencies 20:57:09 #link https://people.debian.org/~boutil/gitlab/ 20:57:16 #link https://people.debian.org/~boutil/gitlab/ 20:57:28 #link http://balasankarc.in/gitlab/ 20:58:19 A good think is that upstream seems very responsive 20:58:26 *thing 20:58:39 boutil, I think we can send a mail to Sytse, ccying debian-ruby, about discussing more on the idea of an LTS version.. So far, they are cool to work with. :) 20:59:02 bsc, would you like to do that? 20:59:23 bsc, Yeah, I can do that. 21:00:02 boutil, ^ 21:00:03 and ask if they can commit for a support of a release cycle (~3 years) 21:00:22 boutil, ok 21:00:32 #action bsc will contact Gitlab upstream about a possible LTS version 21:01:10 let's move to the misc questions 21:01:21 unless there is something to add on this 21:01:30 #topic misc stuff 21:01:52 are there any comments/questions ? 21:03:15 I've a suggestion about RFSs.. Can we adapt something from DPMT - along with sending RFS to mailing list, one may add the package name to the topic of this IRC channel?? For more visibility of the RFS? 21:03:16 do you think we can organize the meeting around 16:00 UTC next time? 21:04:23 Well, for us from GMT+5.30, that is the better option (It is 2.30 AM here. zzzzz ). So, I am all good for UTC 1600. :) 21:04:49 I think that the problem is not visibility for the RFS, but manpower to process them 21:05:40 In fact, I meant 14:00 21:06:21 I have a black zone: 16:00-19:30 UTC 21:06:40 Quite a few people are at GMT+1, which makes it 16 so some people might be still at work or stuck in transport. Still, it would be proably easier to join while at work so, 14 is better than 16 IMO. 21:06:59 boutil, don't know about others, but I am good with 1400 also. :) 21:07:34 we could make it even a bit earlier, during lunch time (in Europe) 21:07:49 boutil: I'd go for it if you ask me. 21:08:14 I'll send a poll, to see what would be the most convenient time. (it will be easier than the wiki) 21:08:35 yeah.. let's do that poll 21:09:06 other comments/questions? 21:09:23 none from me 21:09:36 For RFS, no need to be a DD to review packages 21:09:55 so everybody is invited to check packages prepared by others 21:10:07 That's a good point. You could learn a thing or two by reviewing... 21:10:32 that's how praveen and I started a few years ago, along the proper packagign 21:10:43 ok, let's close the meeting then 21:10:53 ok 21:10:57 #endmeeting