13:01:49 #startmeeting rpm_packaging 13:01:50 Meeting started Thu Sep 8 13:01:49 2016 UTC and is due to finish in 60 minutes. The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:53 The meeting name has been set to 'rpm_packaging' 13:01:58 #topic roll call 13:02:19 ping dirk toabctl IgorYozhikov number80 jruzicka 13:02:40 let 13:02:44 's start 13:02:50 agenda is here 13:02:53 o/ 13:02:53 https://etherpad.openstack.org/p/openstack-rpm-packaging 13:03:06 #chair IgorYozhikov jpena toabctl jruzicka 13:03:07 Current chairs: IgorYozhikov jpena jruzicka number80 toabctl 13:03:31 has anyone a topic to bring before reviewing the queue? 13:03:44 toabctl: ^ 13:03:47 I see one topic in the agenda 13:04:00 number80, the topic about build cycles. 13:04:02 ack 13:04:08 #topic build cycles 13:04:20 * number80 had to refresh the pad 13:04:44 toabctl: can you present the issue? 13:05:03 one sec 13:05:49 you can see the problem basically here: https://build.opensuse.org/project/monitor/openSUSE:Factory:Staging:adi:69 13:06:42 it's mostly about being able to bootstrap builds 13:06:50 yes 13:06:59 so pkg A needs B and B needs A 13:07:16 omg,as build time depend? 13:07:20 yes 13:07:39 we have a couple of them and one reason is that we run the tests which need BuildRequires 13:07:51 so might be it is connected to second topic from agenda? 13:07:53 another one (i.e. for openstackclient) is that we add BuildRequires for documentation build 13:08:26 I'm about using bcond for tests nad docs? 13:08:37 s/nad/and/ 13:09:15 o/ 13:09:20 * dirk is there, sorry for being late 13:09:21 if we will use it - we will be able to build 13:09:21 #chair dirk 13:09:22 Current chairs: IgorYozhikov dirk jpena jruzicka number80 toabctl 13:09:30 number80: thx 13:09:39 IgorYozhikov: the thing is that some cyclic dep are not docs and tests 13:09:52 without tests and docs as the 1st stage 13:10:07 yeah. iirc oslotest and os-client-config is such a case 13:10:10 e.g oslo have a lot of cyclic dep 13:10:19 and before release we can enable build with bcond values set 13:10:22 yeah, you can't really survive without breaking the cycles 13:10:29 may be using another set of jobs 13:11:06 so 1. while sources are in dev state before GA - skipping tests and docs but keeping them in templates 13:11:14 I think that we should use conditionals like IgorYozhikov suggested but add a bootstrap one (which will disable the other too at the same time) 13:11:29 2. after/before GA during hcf rebuild with tests and docs 13:11:51 and fix possible issues 13:11:54 number80, sounds good to me (but not sure how suse handles such cases usually). dirk: would that work for us? 13:12:04 IgorYozhikov: yes 13:12:46 if every1 agree - I'll propose this to wiki guide 13:13:37 IgorYozhikov: let's wait for Dirk answer 13:13:45 number80, sure 13:13:57 toabctl: normally we do something like a %global is_mini 0 and ifdef out tons of stuff when it is set 13:14:16 and then cp the foo.spec into foo-mini.spec (which provides foo, that needs to be added) and build that one first 13:14:48 dirk, and is_mini=1 is automatically set if the spec name ends with -mini.spec ? 13:15:04 dirk: sounds like something that could be done within renderspec? 13:15:17 number80, ah. good point! 13:15:33 number80: that's a good idea. We use a similar concept in DLRN, but without creating 2 specs 13:15:37 does it means that we will maintain 2 copies of same spec per project folder 13:15:42 one -mini 13:15:46 one full? 13:15:51 jpena: yep, shouldn't require much change in DLRN 13:15:57 IgorYozhikov, I don't think so. we would do that internally for SUSE 13:15:59 it does sound like something that could be done with renderspec 13:16:02 just trying to understand 13:16:36 IgorYozhikov: you could do both, it's actually the same spec, you can either inject the value at build time or copy it in -mini.spec 13:16:40 toabctl: currently not, but we can add that 13:16:48 renderspec can easily abstract that 13:16:56 in theory, you shouldn't need to have two spec files, you could use a conditional macro in rpmbuild, e.g. 13:16:59 toabctl: e.g. add a renderspec option to generate a -mini option (in the end its just injecting a is_mini 1 define anyway) 13:17:10 normally obs can do that for us (or the good old pre_checkin.sh hack) 13:17:19 yeah, since renderspec already renders, why not add option to render mini ;) 13:17:40 ok 13:17:43 toabctl, so by introducing mini global we also add if ... for tests and docs with depends, right? 13:17:44 we could call it minirenderspec ;) 13:17:46 time to vote 13:17:47 give me the .spec and I'll provide the renderspec code 13:17:48 :D 13:18:10 Proposal 1: add mini variable for bootstrapping in spec files 13:18:32 Proposal 2: add logic in renderspec to generate mini spec files 13:18:40 1: +1 2: +1 13:18:54 wfm obviously, so 2x +1 13:19:13 number80, looks like a plan 13:19:31 Let's see which solution is most elegant 13:19:53 jruzicka: both are not mutually exclusive :) 13:20:00 right :) 13:20:10 no objection? 13:20:15 no, works for me 13:20:17 DOUBLE+1 13:20:28 (also known as +2) 13:20:52 * IgorYozhikov agree 13:20:56 #agreed Add mini variable for packages bootstrapping + feature in renderspec to render mini versions of packages 13:21:10 IgorYozhikov: are you still up to update wiki? 13:21:30 I'll implement the renderspec part 13:21:31 number80, yep 13:21:37 good, then next topic 13:21:52 #topic tests and docs - Review guide 13:22:00 https://wiki.openstack.org/wiki/Rpm-packaging/ReviewGuidelines 13:22:02 IgorYozhikov: ^ 13:22:31 number80, that is was about circular deps 13:22:55 and how it should be reflected on wiki 13:23:12 I think we could a section about bootstrapping 13:23:29 in the current version I suggesting to use conditionals 13:23:48 number80, ok, good point 13:24:04 so it will be another page 13:24:11 wfm 13:24:21 great 13:24:56 and does it means that current guide reflects truth and not required in any changes? 13:24:56 next topic? (we still some more items) 13:25:40 IgorYozhikov: I need to read it carefuly (%bcond are tricky) 13:26:13 number80, ok, let's discuss it later 13:26:44 ack 13:26:50 #topic patching 13:27:05 We discussed it some time ago. 13:27:05 astsmtl: ? 13:27:11 #chair astsmtl 13:27:11 Current chairs: IgorYozhikov astsmtl dirk jpena jruzicka number80 toabctl 13:27:33 IIUC there was no progress since that discussion. 13:27:42 I think we agreed some time ago to support patches being applied in spec files 13:27:44 Am I wrong? :) 13:27:48 if those changes are mandatory for getting things building 13:27:54 yes 13:27:57 and then we tried to use it in one case and noticed that the CIs don't support it 13:28:02 and then I went on vacation :) 13:28:17 I guess we should just create an example review and fix the CIs for that 13:28:22 I can help a bit on this on the SUSE ci front 13:28:26 So, we need to add support for patch to CI systems? 13:28:32 so that we have it working when we need it 13:28:35 Yep and maybe start a thread on the list to avoid context loss 13:28:38 astsmtl: imho yes 13:29:01 Ok, I'll taka an action to add it to our CI. 13:29:06 s/taka/take 13:29:27 what about adding it to renderspec? so downstream can also add patches per spec-style? 13:30:07 #action astsmtl Patching support in Mirantis CI. 13:30:20 toabctl: with %autosetup, it should require litte to no chang 13:30:30 https://review.openstack.org/#/c/357310/9 is an example of my (failed) attempt to add a patch to a spec 13:30:34 number80, oh. ok. I need to look into that 13:30:41 toabctl, it should be done in similar way because it could be reused for systemd units 4 example 13:31:20 I'm about support of additional files like patches and systemd units 13:31:25 toabctl: we use %autosetup -S git downstream, so that we just add Patch000: XXXX lines and it just works 13:33:23 next topic 13:33:26 #topic packages reviews 13:33:33 we are also use Patch0: xxx in head of spec and just Pathc0 -pN in pre 13:33:37 https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open 13:34:01 IgorYozhikov: with %autosetup -S git, patch will automatically get applied 13:34:20 number80, got it 13:34:21 so you don't have to modify spec at two different paces 13:34:37 good to know :) 13:34:39 yeah, that was dumb 13:35:07 ok about reviews and version bumping 13:35:12 dirk: btw, could you relook at https://review.openstack.org/#/c/342045/, I'm not sure to understand what's the probem 13:35:19 sure 13:35:21 (could be done async) 13:35:26 I missed requirements team meeting :( 13:35:51 dirk, did you decide anything? 13:35:51 IgorYozhikov: we've frozen reqs for newton, now we have few FFE requests running 13:36:47 number80, and they are reflected in U-C, right? 13:37:02 IgorYozhikov: yes, U-C is correct atm 13:37:46 cool, since that, toabctl will you modify your status script to take this fact in account? 13:37:51 before I move to another topic, any review you want to highlight? 13:38:09 IgorYozhikov, I'm on vacation for the next 2 weeks. that will take a while.. 13:38:20 o i c 13:39:00 IgorYozhikov: basically the decision was that uc and only uc is the version we should target to package 13:39:17 IgorYozhikov: the plan is then once newton is released to bump uc accordingly later in the stable tree phase 13:39:25 dirk, got it 13:39:26 and for anything that we consider relevant, we need to file FFE's 13:40:43 anyway, our work as downstream is to help curate g-r before freeze 13:41:00 if you see errors => submit reviews 13:41:41 ok, I'm fine with this 13:41:48 moving next? 13:41:52 +1 13:42:17 ack 13:42:42 #topic pymo2pkg reviews 13:42:43 https://review.openstack.org/#/q/project:openstack/pymod2pkg+status:open 13:42:55 toabctl submitted a release last week 13:43:08 yep, it got approved yesterday 13:43:19 and we already merged the version update to package 13:43:22 and jpena's review just got merged 13:43:34 excellent 13:43:49 then, next topic 13:43:55 #topic renderspec reviews 13:43:56 https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:44:10 number80, about patches here 13:44:18 yes? 13:44:20 I have very old review 13:44:25 https://review.openstack.org/#/c/291158/ 13:45:05 may be it could useful somehow to handle patches 13:45:10 in j2 templates 13:45:17 or I can abandon it 13:45:28 tbh I would abandon it for now 13:45:52 yeah 13:46:05 ok, i'm fine with it 13:46:06 jruzicka, if you have some time, comments on https://review.openstack.org/#/c/360919/ would be welcome. 13:49:03 next topic? 13:49:12 #topic open discussion 13:49:23 any topic before we close this meeting? 13:50:56 nope 13:51:00 nop 13:51:06 no 13:51:36 * astsmtl is waiting for plain "n" 13:51:42 n 13:51:46 . 13:51:52 ! 13:52:06 :D 13:52:06 ah.. meeting chairs for next week.. 13:52:13 toabctl is away I take it 13:52:21 I will ilkely be there, but can't guarantee it yet 13:52:41 I'll plan to be on-line 13:52:42 would be good if someone else can step in again in case I am in a rural suburb area without internet as I'm travelling 13:53:01 I can take it again next week but I'm fine to leave it to someone else 13:53:18 * number80 will be travelling a lot in october 13:53:20 ok, good lets figure that out next week then 13:53:25 ack 13:53:31 ok 13:53:33 btw. who's going to barcelona? 13:53:43 o/ 13:53:43 * IgorYozhikov is 13:53:48 well - we'll see. let's end the meeting now. 13:53:52 I'll be there 13:54:00 thank you for attending and see you next week! 13:54:04 #endmeeting