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