20:00:04 #startmeeting 20:00:04 Meeting started Tue Sep 23 20:00:04 2014 UTC. The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:11 Hi everybody! 20:00:17 hi 20:00:25 Let's start the meeting. 20:00:52 Let's have a quick list of topics to discuss: 20:01:01 I put on the wiki: 20:01:14 Results of mass autopkgtest 20:01:14 Approaching freeze 20:01:14 package update rallye removal of obsolete packages 20:01:14 Quick glance through RC bugs 20:01:20 Pending RFS 20:01:30 Have you other things to discuss? 20:02:11 ok. 20:02:30 #topic Results of mass autopkgtest 20:03:16 Martin posted on the list the results of the mass autopkg run for all ruby packages 20:03:26 The results are pretty good! 20:03:52 Thanks Martin for the run, and terceiro for the underlying work 20:04:24 do we have a volunteer to analyse the results? :) 20:05:02 I can have a closer look, but help needed. 20:05:21 I guess that many tests are failing because of missing build-deps 20:05:27 wow 20:05:38 if it's just that then it's fine 20:05:51 err, more or less. missing build-deps should be RC bugs ): 20:05:53 #action boutil will inspect the results of autopkgtest 20:06:00 #link 20:06:04 #help needed to inspect those results 20:06:21 #link http://lists.alioth.debian.org/pipermail/autopkgtest-devel/2014-September/thread.html 20:06:29 I'd be happy to help (if I will be able that is...) 20:06:42 #link lists.debian.org/20140917152554.GE3724@piware.de 20:06:51 #link https://lists.debian.org/20140917152554.GE3724@piware.de 20:06:52 #info see the autpkgtest-devel archives for this month (link above) for previous analyses of test results by the Perl team 20:07:20 great, thanks tnnn! 20:07:26 #action tnnn will help 20:08:16 Should we try to increase (substantively) the rate of success of the tests (by new uploads)? 20:08:17 #info terceiro is available to advice on autopkgtest issues 20:08:42 Will the mass autopkgtest be run again? on a timely basis? 20:08:57 boutil: the idea is to whitelist now the packages we know pass 20:09:20 the ones that fail have to be fixed anyway, so they should be uploaded with the fix + the proper Testsuite: control field 20:09:25 what exactly means 'whitelist' in this context? 20:09:47 boutil: it means that debci will run tests for them even without Testsuite: control fields 20:10:02 ok. 20:10:06 #link http://anonscm.debian.org/cgit/collab-maint/debian-ci-config.git 20:10:07 oh, moin! 20:10:14 hell hggh 20:10:17 hello I mean :) 20:10:28 I'm late 20:11:20 about the auto test, so not every package need to me updated with debian/tests? 20:11:23 is there a expected time for this whitelisting to occur? 20:11:52 boutil: at this point I am just waiting for an analysis of the preview run of the ruby packages :) 20:12:25 terceiro: ack. 20:12:31 boutil and tnnn one of the outputs of that analysis is a list of packages to be removed from the whitelist at http://anonscm.debian.org/cgit/collab-maint/debian-ci-config.git/tree/ruby.txt 20:13:01 (i.e. we should remove from there the ones that are broken) 20:13:45 hggh: the idea is that by default, ruby packages (without Test-Suite field) have a default autopkgtest test suite. It can be overriden by files in debian/tests 20:14:22 boutil: ah fine. so standard gems should not have any debian/tests files 20:14:48 yeah 20:14:49 it their test suite can work with just the dependencies, then it's enough. 20:14:59 they need to declare `Testsuite: autopkgtest-pkg-ruby` in debian/control 20:15:24 hi 20:15:30 sorry for the delay… 20:15:31 if the test suite requires additional packages, then it has to be configured in debian/tests 20:15:36 sbadia: hi! 20:15:41 ok fine, I was trying to get it working with ruby-colorize 20:15:58 autopkgtest will add all build-deps to the test deps 20:16:03 except debhelper and gem2deb 20:16:09 plus gem2deb-test-runner 20:16:18 ah! I missed that 20:16:53 boutil: yeah I added some intelligence there :) 20:17:31 terceiro: should we add the Testsuite: autopkgtest-pkg-ruby ourselves, or is it added automatically by gem2deb/autopkgtest/black magic? 20:17:49 boutil: we need to add 20:17:56 in dh-make-ruby 20:17:58 or by hand 20:18:25 boutil: I actually already committed a change to gem2deb 20:18:27 for that 20:18:32 I guess I will make an upload 20:18:39 #info: we need to add "Testsuite: autopkgtest-pkg-ruby" to packages for which autopkgtest passed (without modification) 20:18:52 Testsuite: autopkgtest-pkg-ruby 20:18:57 boutil: no we don't 20:19:00 terceiro: maybe we can discuss gem2deb a bit later. I'd like to add a functionality. 20:19:07 is already available in the templates of gem2deb 20:19:26 I mean, we should add them, but the ones already whitelisted will be run anyway 20:19:33 boutil: sure 20:19:37 (re gem2deb) 20:20:29 do we have anything else on this topic? 20:20:40 terceiro: so we need to add it in the long term, but the whitelisted packages will be run anyway right? 20:20:50 * boutil is confused 20:20:50 boutil: exactly 20:20:56 ok. 20:20:58 I got it :) 20:21:15 #info we need to add it in the long term, but the whitelisted packages will be run anyway. 20:21:32 other questions about autopkgtest? 20:21:54 let's jump then to another topic 20:21:55 perhaps we need some information how to use it in quick for ruby-* packages 20:21:59 #info we need to add the `Testsuite: autopkgtest-pkg-ruby` control field in the long term 20:22:09 in the wiki 20:22:32 #action hggh will add information to wiki page 20:22:46 hggh thanks :) 20:23:02 thanks! 20:23:07 #topic The freeze is approaching 20:23:17 We have about 1 month left 20:23:23 (i'm a bit pessimistic) 20:23:35 boutil: what are your concerns? 20:23:56 a lot of packages are a bit/a lot outdated 20:23:58 #info terceiro should upload redmine soon; waiting for ruby-request-store to pass NEW 20:24:24 some are so old that they should go away 20:24:32 (like ruby-opengl?) 20:24:52 I don't know; it's hard to judge stuff I don't use 20:25:06 is it broken? 20:25:47 there is a bug report about ruby-opengl crashing with 2.1. It is working with 1.8 and 1.9.1 apparently. 20:26:03 yeah, if you so many packages that are upstream dead and unmaintained 20:26:10 It was already not easy to bring it into shape for wheezy... 20:26:50 new upstream ruby-opengl New version available: 0.61.0 20:26:55 my point is that we probably should put some effort into updating packages. 20:27:12 #link http://udd.debian.org/dmd/?email1=pkg-ruby-extras-maintainers%40lists.alioth.debian.org 20:27:21 * terceiro nods 20:27:25 0.61.0 is in fact an empty gem, requiring another implementation (using ffi) 20:27:42 I don't know how much it is compatible 20:29:03 before wheezy's freeze, we organize some packaging parties on IRC with paulvt (once a week) were we would update package and he would sponsor the uploads 20:29:31 good idea. 20:29:59 we can do that, but I think we should stop 2 weeks before the freeze to let some time for testing and fixed 20:29:59 It may be difficult to organize worldwide, but for Europe, I could try to organize something of this type. 20:30:01 fixes 20:30:26 perhaps we should start a mass rebuild 3w before the freeze? 20:30:32 terceiro: sure. the goal is not to break the whole archive :) 20:30:59 boutil: I know :) 20:31:05 :) 20:31:08 #idea: organize "packaging parties" on IRC, where one can do live RFS 20:31:20 rails and redmine, and everything else that uses Gemfile's can be sensitive to new versions of dependencies 20:31:29 yes... 20:32:11 Is there an easy way to test somehow using rubygems-integration metadata, that dependencies at the gem level are okayish? 20:33:12 I am thinking for example of ruby-mime-types, which has a new major version waiting for upload. 20:33:45 If we could have a way to at least smell that something may break without having to rebuild all reverse deps, that would be great 20:34:38 boutil: that's what ci is for 20:35:01 the updated redmine package has a smoke test for each supported DB :) 20:35:04 but it is somehow too late, because the problematic package is already in the archive. 20:35:19 right 20:35:47 I intend to add experimental ASAP, but not in time to help up right now 20:36:16 experimental could indeed be the place to break stuff :) 20:36:31 that is what it's for, right? 20:37:31 yes 20:37:49 so let's say we try to update a max of stuff before October 22. 20:38:32 #info try to update a maximum of packages before October 22. 20:38:40 should work 20:39:31 other questions/comments about the freeze? 20:39:48 no 20:39:57 let's move to the next topic 20:39:59 not from me 20:40:08 #topic quick glance through the RC bugs 20:40:28 #link http://udd.debian.org/dmd.cgi?email=pkg-ruby-extras-maintainers%40lists.alioth.debian.org 20:40:46 chef is quite in a bad state... 20:41:12 * hggh is using puppet 20:41:15 it's not the chef core though 20:41:39 what is about capistrano? 20:41:53 ruby-kramdown is missing ruby-prawn-table (gem which has been split from ruby-prawn, and entered the archive today) 20:42:37 "Capistrano 3 is very much not backwards-compatible with capistrano 2. Perhaps 20:42:40 that needs to be taken into account." 20:43:19 but if you have to chose between deprecated but compatible, or supported but incompatible... 20:44:03 second one. 20:44:13 me 2 20:44:28 idem 20:44:40 we are using capifony, that is an addon to capistrano, I can have a look 20:44:58 and sommer is gone, I should have more time again :) 20:46:21 the list is quite long, thanks to the mass rebuild by lucas 20:46:39 we shouldn't have said that we were quite fine wrt to RC bugs :) 20:46:46 #action hggh is looking at capistrano 20:47:17 questions/comments about RC bugs? 20:47:34 I think there's not much to discuss 20:47:37 #topic pending RFS 20:47:43 what we need is to go, investigate, and fix 20:47:56 is there someone here with pending RFS? 20:47:57 giving priority for the stuff that is out of testing 20:48:11 boutil: have no open RFS 20:48:15 (I guess no) 20:48:31 #topic gem2deb 20:49:02 terceiro: you were saying that you wanted to add some commits to gem2deb? 20:49:03 (If nothing bad happens I will have one by the weekend - my first one so some advice might be needed). 20:49:32 boutil: it's already in 20:49:33 tnnn: no problem, send an email to the list, and we'll answer ;) 20:49:41 the tip of the master branch 20:49:58 i have some RFS’s but boutil is taking good care of me 20:50:04 that changes the Testsuite: field to autopkgtest-pkg-ruby 20:50:12 terceiro: ok 20:50:16 tpot: :) 20:50:21 boutil: I wanted to have that in the archive RSN 20:50:33 boutil: do you have pending commits of your own? 20:50:51 terceiro: I would like to add also something which is in the extconf-options branch 20:51:06 it misses yet some documentation 20:51:22 boutil: do you have an ETA? 20:51:43 it would allow to pass options to extconf.rb via a dh_auto_install addistional option 20:51:55 I think you can go ahead with your change. 20:52:19 ok 20:52:20 It's nothing really we would need *for* jessie itself 20:52:44 terceiro: if you could have a quick look at some point, I'd like to have your feedback 20:52:59 boutil: I can 20:53:05 we can have a second upload later 20:53:24 there is another feature I will probably need for work, which is support for installing rails engines in a sane way 20:53:57 that would be great, indeed 20:54:16 it sometimes the source of file conflicts 20:55:16 is /usr/lib/ruby/vendor_ruby/rails/generators/ a canonical path to put them? 20:55:30 it's not 20:56:08 rails generators assume they are installed via rubygems with their own private $LOAD_PATH 20:56:13 $LOAD_PATH component 20:56:36 it's just the way it is, I don't have hopes of changing 20:56:38 do you have in mind a solution that would avoid moving/patching code manually? 20:56:50 installing them as if they were actual gems 20:57:01 to /usr/share/rubygems-integration/... 20:57:17 and it's not only generators 20:57:30 some rails engines have an rails app structure with app/ db/ etc 20:57:37 so there is not really another wy out 20:57:59 * boutil sigh 20:58:40 next topic? 20:59:02 #topic ruby-policy (again!) 20:59:30 #action sbadia boutil will gather and work on the ruby policy, for real 20:59:37 lol 21:00:03 we should have done that by the spring back in january ;) 21:00:04 caitlin gave some input, which we should take into account. 21:00:09 we'll propose it's inclusion in the debian-policy repo right? 21:00:25 yes, i think so 21:00:46 yes, but first we need to have it ready :) 21:01:19 let's make it a release goal for Jessie + 1 21:01:40 ok :) 21:01:58 #topic Ruby sprint 21:02:30 terceiro is right to do a sprint after the release of jessie 21:02:36 so we can break more stuff 21:02:41 ah fix it! 21:02:59 agreed. 21:03:28 the freeze period doesn't give too much freedom to move... 21:03:44 I hope the freeze won't las forever 21:03:50 *last 21:03:50 it won't 21:04:04 this time the really broken stuff is already not in testing 21:04:10 thanks autoremoval! 21:04:17 I have hopes of a very quick freeze 21:04:25 but don't quote me on that ;-) 21:04:52 so we can make (vague) plans for Spring then 21:04:55 hm as a sysadmin I hope for a longer freeze *duck* because 21:05:14 but for my debian hat on, I have a short freeze 21:05:46 boutil: the paris meetup is in another city? 21:05:59 it's in Lyon 21:06:31 we can always go the Paris anyway before or after the miniDebConf 21:06:37 since we have IRILL 21:06:47 (it's 2h by train from Paris, and about the same (even closer) from Geneva) 21:07:02 piece of cake 21:07:16 it would be better to have a friendly organization in Lyon already 21:07:23 but 2h by train is totally doable 21:07:25 IRILL is a great place (and they have free coffee) 21:07:32 :) 21:07:45 only terceiro needs again a long flight :) 21:08:17 maybe Mozilla offices in Paris can also host (sylvestre is now working there) 21:08:49 there's room at my university too. 21:08:58 so in Paris, it can definitly happen 21:09:26 hggh: all the logic options I will have my flying to Europe anyway 21:09:43 I'll contact people in Lyon to see if they can host sprints as satellite events of the mini-debconf 21:09:51 cool 21:10:02 other topics you want to bring up? 21:10:44 ok, let's stop here for today 21:10:47 thanks! 21:10:53 #endmeeting