13:00:29 #startmeeting rpm_packaging 13:00:30 Meeting started Thu Sep 1 13:00:29 2016 UTC and is due to finish in 60 minutes. The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:34 The meeting name has been set to 'rpm_packaging' 13:00:37 ping dirk toabctl IgorYozhikov number80 jruzicka 13:00:40 o/ 13:00:45 hi 13:00:46 o/ 13:00:47 #chair IgorYozhikov toabctl 13:00:47 Current chairs: IgorYozhikov dirk toabctl 13:00:52 #chair IgorYozhikov toabctl number80 13:00:52 Current chairs: IgorYozhikov dirk number80 toabctl 13:00:59 #topic roll call 13:01:13 everyone, please review/update agenda on 13:01:20 #link https://etherpad.openstack.org/p/openstack-rpm-packaging 13:02:10 o/ 13:03:54 o/ 13:05:03 toabctl: did you want to add it for next meeting or for todays meeting? 13:05:11 oh. todays meeting 13:06:12 should we start? 13:06:21 #topic Newton schedule update 13:06:31 #link https://releases.openstack.org/newton/schedule.html 13:06:34 as a reminder - 13:06:43 this week (today) there is the upstream requirements freeze 13:06:53 which means we can start looking more closely at matching the packaging for newton 13:07:04 I know that from the sUSE side toabctl and others are already working on that 13:07:26 dirk, are you about updating of reqs ? 13:07:26 How does it look from Red Hat/Mirantis side? 13:07:33 according to last U-C? 13:07:51 I've see lots of reviews from Javier and others 13:08:17 IgorYozhikov: of possible we use UC, but there might be product specific issues with non-openstack components that require us to choose something else 13:08:28 s,of possible,if possible, 13:08:46 i c 13:08:59 well, in pratice, oslo + clients should to stick to UC as nobody tests against master 13:09:22 for our downstream CD, we have both: full master and master + UC for clients/oslo 13:09:31 from mos side - we are trying to back-port new projects in case of necessity 13:10:15 our CI is using if you saw our packages + centos as dependencies 13:10:26 as in build as in tests 13:10:36 our CI doing 3 steps 13:10:50 build, publish and install 13:11:04 Also, we intend to ship the rpm-packaging spec file results in the upcoming openSUSE Leap 42.2 release 13:11:13 so it test requirements everywhere 13:11:15 I hope that they would end up also in other distributions releases 13:12:08 dirk, in our just started iteration we planned to reuse all what we have done in rpm-packaging 13:12:18 that's the long-term plan, but there's still a gap we need to bridge in renderspec (jruzicka is working on that) 13:12:37 during packaging rounf for Newton b2 we reused about 40% of prm-packaging 13:12:57 s/rounf/round/ 13:13:18 I think we use ~90-95% if the specs currently. 13:13:26 number80: I'd love to hear about the gaps though 13:13:37 ok, 2nd topic I wanted to bring out 13:13:40 bring up 13:13:54 In two weeks, there is the Ocata cycle PTL self nomination period 13:13:57 dirk: one I think of is how to handle l10n, which requires some magic 13:14:02 Please think about whether you want to be a candidate 13:14:17 falks, sorry bbs @10 min :( 13:14:18 ack 13:14:28 and bring it up, here, in our channel or on the mailing list when the nomination period starts 13:16:15 #topic feedback for renderspec improvals (see https://review.openstack.org/#/c/360919/ ) (toabctl) 13:16:22 #link https://review.openstack.org/#/c/360919/ 13:17:03 toabctl? 13:17:06 I created recently a project called metaextract which gets the install_requires, tests_require and extras_require from a setup.py 13:17:39 with that we could start automating the Requires and BuildRequires sections. I created a POC which needs some more love but initial feedback would be very welcome! 13:19:38 I think there's not more to say about it currently. 13:19:46 ok, thanks 13:19:53 but given the amount of specs we already have we need to automate more. 13:20:13 yeah, I actually recently got a request on why we don't have openstack spec files yet 13:20:22 people are looking for it but are confused on why we only have the clients 13:20:34 next topic? 13:21:23 * IgorYozhikov back 13:21:36 yes. next 13:22:33 #topic python3 renderspec 13:22:40 #link https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec 13:22:52 IgorYozhikov? 13:23:28 * dirk didn't have time to read through the etherpad yet 13:23:28 I think Igor left for ten min 13:23:37 number80, I'm here 13:23:40 :) 13:23:42 great 13:24:07 anything you want to say to it? 13:24:15 we where waiting for you dirk - to discuss this topic about using py3 for renderspec 13:24:23 I see 13:24:35 ok, I'll get to it and start a discussion on irc within this week 13:24:36 ok? 13:24:55 I'm only back since yesterday and there were a few things to take care of 13:25:09 yes, please read my thought. 13:25:25 #topic Extend pymod2pkg to include mapping between PyPi module name and OpenStack project name 13:25:27 just want to understand - how we are going to work with py3 13:25:34 #action dirk get back to IgorYozhikov on the python3 proposal 13:25:54 jpena: are you around? 13:25:59 yes, I'm here 13:26:03 I think we're lacking a proper rpm spec parser 13:26:18 so currently pymod2pkg is providing mappings for PyPi project names fo suse/fedora packages 13:26:21 most of python3 boilerplate can be generated with few macros 13:26:40 and in some cases, it would be nice to have a mapping between PyPi project/OpenStack project (it's not 1:1 all the time) 13:27:13 I've been playing with a patch to add that mapping, but I wanted to check before 13:27:33 is that something that matches the pymod2pkg purpose? 13:27:45 I guess, it could work (I see also benefit for downstream rdoinfo too) 13:28:13 jpena: sound sgood to me 13:28:23 jpena: should be okay to keep the exception list 13:28:33 you need that for the URL:/Source: lines? 13:29:12 is there a review already? 13:29:39 dirk: I could use it for our DLRN implementation. That way, we could clone the github repo using that mapping, then use the Version: field to find the proper tag 13:29:47 dirk: no, I'll upload the review after the meeting 13:30:06 ok 13:30:07 jpena: add jruzicka as a reviewer, it may impact his tooling 13:30:11 #action jpena post review 13:30:12 number80: ack 13:30:23 #topic Including test directories in package 13:30:35 that's also mine 13:31:22 I've noticed we include the test directories for every repo in our packages. This is different to what we do in RDO (separate test packages), just wanted to know if it's on purpose 13:31:24 so this is about splitting tests into -test subpackage or in the main package (or not at all)? 13:31:36 dirk: exact 13:31:44 I think I prefer an extra -test pacakge but I don't have a strong opinion 13:32:14 tests have a lot of deps, so +1 to split them out 13:32:25 that would have an impact on some packages. For example, I've seen openstackclient requires tests from osc-lib 13:32:30 otherwise, I wouldn't care of keeping them 13:32:46 I meant muranoclient 13:33:06 jpena, you are proposing to add extra foo-test.rpm which is going to do almost the same things like in %check section? 13:33:08 jpena: runtime stuff requiring test utils? 13:33:26 IgorYozhikov: nope, shipping test files in a separate subpackage 13:33:26 number80: no, during build 13:34:01 jpena: we choose as a policy to run tests as much as possible at build time 13:34:07 might be more useful to make am example? 13:34:31 IgorYozhikov, as an example, we have https://github.com/openstack/osc-lib/tree/master/osc_lib 13:34:45 there is a tests/ directory inside the repo, which includes the test we run during %check 13:35:09 they're only useful to us during build, but we package them because they get installed during %install 13:35:51 however, during build, some packages require tests from other packages (muranoclient), so it'd be good to have a separate -tests subpackage for osc-lib, and have that as a BuildRequires 13:36:45 python-osc-lib - with py2 code 13:37:03 python-osc-lib-test - with py2 tests folder for osc-lib? 13:37:09 exact 13:38:11 wait, so muranoclient requires the tests from osc-lib? its not enough with osc-lib package? That sounds wrong :/ 13:38:11 and py*client will need BuildRequires: python-osc-lib-test ? 13:38:29 * IgorYozhikov confused 13:38:39 IgorYozhikov, if they need to use tests from osc-lib, yes 13:39:18 itxaka: https://github.com/openstack/python-muranoclient/blob/master/muranoclient/tests/unit/osc/v1/fakes.py#L14 13:39:31 that's the example I've found (maybe there are more?) 13:40:09 from osc_lib.tests import utils 13:40:40 from the OpenStack project point of view, they just require the PyPi package, and it includes everything. It might be easier for us to follow them, I just wanted to make sure it was a conscious choice 13:40:57 https://github.com/openstack/python-neutronclient/blob/cccc7f7fb0cecb585a8a250c11c22e2135838b47/neutronclient/tests/unit/osc/v2/trunk/test_network_trunk.py#L21 13:41:00 same here 13:41:16 jpena, more || les I've got your pint 13:41:54 but will extracted tests work without main lib code? 13:42:16 wow 13:42:16 just curious 13:42:26 IgorYozhikov, no, for that the -test subpackage needs to Require: the main one 13:43:10 so why do we need to extract tests then ? 13:43:52 * dirk is back 13:43:53 just to create lightweight main python lib rpm package? 13:44:23 * IgorYozhikov trying to understand 13:44:28 but in this case the test dir is an integral test of the osc_lib package so we should not split it ever, even if that is super wrong 13:44:55 that's why I asked :). We can think of it two ways: a) remove unnecessary code for installation (so split), b) tests are part of the code (so keep) 13:45:19 I'm not 100% convinced on any of them 13:45:48 jpena, do we have currently a problem with the way it is? 13:45:50 What do we gain by splitting the packages? less BuildRequires? 13:46:29 toabctl: not really, just if we dislike seeing the tests/ directory in the package 13:46:31 itxaka, yes. less possible dependency cycles 13:47:08 one advantage you have of -test packages is that you can install them and then run the tests 13:47:13 jpena, I'm currently fine with having them in the packages. but I would also be fine if somebody is doing the work and split the packages. 13:47:15 instead of having them run during build times 13:47:28 yes 13:47:28 but it is a lot of painful work to keep that running, and getting patches for that upstream is difficult 13:47:42 speaking from past experience 13:48:55 ok, let's keep them for now, then split if we feel the need 13:49:08 so can we summarize that we keep all the tests in python-$name package ? 13:49:10 just 10 min left. let's go to the next topic. 13:49:16 dirk, +1 13:49:23 +1 13:49:25 +1 (¯―¯٥) 13:49:27 +1 13:49:29 #agreed keep tests inside main package for now, revisit topic potentially later 13:49:41 #topic Core reviewer additions (dirk) 13:50:11 I was wondering whether we'd be interested in adding further core reviewers alongway, especially with the ocata cycle upcoming 13:50:27 I already reached out to jpena and aplanas, jpena said he'd be interested 13:50:32 dirk: I was thinking about increasing the pool post-GA too 13:50:40 any comments/suggestions/opinions? 13:50:49 +1 for both. 13:50:52 I think both are good candidates 13:50:53 +1 13:50:59 dirk agree 13:51:20 aplanas actually asked to not become core for now 13:51:21 fwiw 13:51:21 they already do reviews and having more persons being able to add +2's would be good 13:51:44 number80: so are you good with adding people now or do you want them only for ocata+ü 13:51:47 ocata++ 13:52:16 dirk: I'm fine with both 13:52:47 In aplanas case, I'd definitively revisit his case post-GA if he changes his mind by then 13:52:52 so I suggest to create a mailing list posting on openstack-dev and I would invite the existing cores to +1/-1 that 13:53:01 ack 13:53:04 * dirk would start that 13:53:07 ++ 13:53:17 +1 13:53:21 #topic open floor 13:53:33 #action dirk send mail about new core members to openstack-dev 13:53:46 dirk, what is your opinion about Barcelona 13:54:09 fishbowl || work-session 13:54:22 * toabctl will most likely not be in Barcelona 13:54:23 may be combined with deb 13:54:41 let's say work-session and fishbowl combined with deb folks 13:55:13 to discuss availability to do the same build "machine" using infra resources 13:55:41 as already done for deb with help of Paul Belanger 13:55:43 ah, good point 13:56:07 so there was a mail asking for input on barcelona sessions a few weeks ago, during my vacation 13:56:08 zigo, if u r here ^^^^ 13:56:18 I responded to that with the results of what we discussed in june 13:56:31 I requested 1 fishbowl, possibly co-located with deb-packaging and two work sessions 13:56:35 no contributor day session 13:56:51 to summarize, barcelona is really crowded 13:57:19 it is shorter and in order to remove overlap with other tracks the design tracks are just two days iirc 13:57:26 dirk, now or in future summit? 13:57:28 and contributor day is only half a day 13:57:42 oh, got it 13:57:59 IgorYozhikov: just talking about barcelona, I don't recall the future planning 13:58:08 there was some discussion about it somewhere, but I forgot the details 13:58:35 so to meet the deadline I submitted request for 1 fishbowl and two work sessions 13:58:44 I haven't heard anything back yet 13:58:53 i c 13:58:59 so we'll see. I think we're a small enough group so that we can gather somewhere else as well 13:59:03 thanx anyway 13:59:29 IgorYozhikov: it should match what you suggested, except that its two work sessions 13:59:50 I'd like to focus one on the upstream rpm packaging building effort and one at least on general topics 14:00:04 anyway, we have to end this 14:00:21 due to time constraints.. lets continue with the packaging reviews that I skipped in #openstack-rpm-packaging 14:00:26 thanks, see you next week! 14:00:28 #endmeeting