13:02:15 #startmeeting rpm_packaging 13:02:16 Meeting started Thu Dec 15 13:02:15 2016 UTC and is due to finish in 60 minutes. The chair is IgorYozhikov. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:19 The meeting name has been set to 'rpm_packaging' 13:02:30 ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof 13:02:35 o/ 13:02:51 #chair IgorYozhikov jpena toabctl 13:02:52 Current chairs: IgorYozhikov jpena toabctl 13:03:18 hi 13:03:36 o/ 13:03:41 * toabctl will be a bit distracted during the meeting... 13:03:45 #chair IgorYozhikov jpena toabctl dirk 13:03:46 Current chairs: IgorYozhikov dirk jpena toabctl 13:03:55 let's spend some time on agenda 13:07:04 let's start 13:07:32 #topic https://review.openstack.org/#/c/407102/ - semver version part - let's finalize decision 13:07:47 toabctl, still has questions here 13:09:05 Yep, I have questions too. I've seen that the XStatic-* packages have 4 digit versions, e.g. https://review.openstack.org/#/c/410747/8/openstack/XStatic-Magic-Search/XStatic-Magic-Search.spec.j2 13:09:07 I believe that here we need some additional input from RDO side 13:10:08 jpena, afaik py2rpmversion is used only for OS projects 13:10:33 since that dependencies are not affected here 13:10:54 ok, in that case we should be fine 13:11:08 also dependencies doesn't use mid-milestone dev tails in versions, no? 13:11:27 no, they don't 13:12:00 renderspec should work also for non-OS project. but if you are fine with the fedora solution, that is ok for me 13:12:19 it just feels wrong. imo we should at least document that it is not doing the right thing 13:12:28 ok, so as I remember - these 2 functions were developed to handle OS components version/release 13:12:45 IgorYozhikov, the can handle any pre/post release 13:14:03 toabctl, didn't get your question :( 13:14:19 what question? 13:14:28 about pre/post releases 13:14:47 hm. there is no question 13:15:32 ah, ok. and yes - I'm agree about documenting functions usage 13:17:41 if there are no objections and every1 agree with proposed changes - I will update documentation for py2rpmversion 13:19:17 otherwise - let's elaborate additional changes which should be made 13:19:40 your thoughts ? 13:21:57 +1 for me 13:23:45 next? 13:24:17 dirk, yes 13:24:47 hope that we will agree on something just a little bit later 13:24:53 #topic systemd macro, new common with translation into rdo & suse or something else? 13:25:23 dirk, you mentioned the upstream systemd macros where available for SUSE, right? 13:25:31 I saw that commit was abandoned 13:26:16 jpena: so those with %service_* and with %systemd_* should be available now in the suse ci, yes 13:26:30 I'm confused which ones are the "upstream ones" and which we should be using going forward 13:27:19 When I say upstream macros I'm referring to the ones in https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in 13:28:01 I tried to dig a bit into the SUSE packaging, and I found they use different ones (the ones I was trying to emulate in my review) 13:29:56 dirk, does it means that I can revert your changes - https://review.openstack.org/#/c/382196/34/openstack/mistral/mistral.spec.j2 ? 13:30:48 to be more specific - https://review.openstack.org/#/c/382196/32..34/openstack/mistral/mistral.spec.j2 13:31:18 and systemd_post will work as in centos an in suse linux? 13:32:22 that's what I expect 13:34:25 ok, I'll try to do that today and will see :) 13:35:42 anything else related to this topic? just want to be more || less sure that this will not block us with the rest of services. 13:37:28 #topic Xstatics* almost done - do we ready for horizon? 13:38:22 There is last of xstatics*, I believe, on review - https://review.openstack.org/#/c/410228/ 13:38:54 Does it means that we can start work on horizon? 13:39:53 or there are another parts to be done before? 13:39:53 jpena: IgorYozhikov : yep, so lets go with %systemd_ macros 13:40:11 #agreed for service packaging please use the %systemd_* macros from https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in 13:40:24 dirk, yey 13:40:27 thanx 13:41:12 IgorYozhikov: I am not sure regarding horizon, but its always worth putting up a review and see where it fails.. 13:41:29 I was actually planning to help a bit with that but currently there are too many fires 13:42:09 dirk, got it 13:43:52 ok, may be kaslcrof or tlbr could help with horizon, it' is not to urgent but will be very nice to have it in working state 13:44:27 or if any1 else want to take it(horizon) - I'm fine with it 13:44:41 yes, we can take a look if required 13:45:18 great, tlbr thanx a lot 13:45:28 np :) 13:45:31 moving forward? 13:45:41 #topic Open floor 13:46:40 dirk, I believe that you want to clarify rdo gate readiness/status? 13:48:09 I saw commit from Tristan https://review.openstack.org/#/c/393606/ 13:49:10 this was a test to verify if some of the gerrit problems we had were fixed 13:49:39 right now, the CI job is mostly behaving, although we still have the networkx.drawing package issue 13:49:56 we could set the CI as non-voting for now, at least it's giving me some useful feedback 13:50:20 yeah 13:50:26 I would really like to see some reports in the reviews 13:50:29 ah, that's nice, so it's moving 13:50:47 ok, I'll go for it tomorrow then 13:50:59 jpena: is there a way we can have networkx.drawing issue worked around for now? 13:51:39 dirk: we have https://github.com/rdo-packages/taskflow-distgit/blob/rpm-master/python-taskflow.spec#L92-L93 in the RDO specs 13:52:13 jpena: so put that up as an review under a %if is_rdo condition? 13:52:31 dirk: works for me 13:52:38 I'd prefer imperfect but working ci over no ci any time 13:52:59 agreed, I'll go for it 13:53:12 is it just building the package under review like the mos ci or does it rebuidl everything like the suse ci? 13:53:23 only the package under review 13:53:37 k, so the issue with networkx should be fairly isolated 13:54:00 I also have 2 updates from my side 13:54:22 1. about keystone + updated passlib 13:54:45 I'll update keystone PR right after b2 will be released 13:55:01 because b1 is not compatible with passlib 1.7.0 13:55:26 already spoke with keystone developers 13:55:56 and 2nd - finally mos-ci add newton support 13:56:30 and now it rebuilds whole bunch of projects resided under stable/newton branch @ rpm-packaging 13:56:33 https://packaging-ci.fuel-infra.org/job/newton-rpm-packaging-build-centos7/ 13:57:11 this means that mos-ci will reacts on commits into stable/newton as already reacts for mitaka & master 13:57:36 all issues will be fixed in a couple of days 13:58:01 that's all from my side 13:58:42 thanks IgorYozhikov for the update! 13:58:56 last q : another meeting next week same time same place? 13:59:06 or is everyone already off for end of the year vacation? 13:59:08 wfm 13:59:28 we have vacation right after NY 13:59:54 I know that in EU & US vacations before NY 14:01:03 let's discuss this at our channel. we r out of time 14:01:16 #endmeeting