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