13:01:14 <dirk> #startmeeting rpm_packaging
13:01:15 <openstack> Meeting started Thu Mar 10 13:01:14 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:18 <openstack> The meeting name has been set to 'rpm_packaging'
13:01:21 <toabctl> hi
13:01:36 <dirk> #topic https://etherpad.openstack.org/p/openstack-rpm-packaging
13:01:43 <dirk> argh
13:01:47 <toabctl> :)
13:01:52 <dirk> #topic collect topics
13:02:03 <dirk> everyone, please add your agenda item to
13:02:11 <dirk> #link https://etherpad.openstack.org/p/openstack-rpm-packaging
13:04:28 <IgorYozhikov> o/
13:05:17 <dirk> #topic  requirements version handling - see proposed https://review.openstack.org/#/c/290330/, update absent | override old
13:06:54 <dirk> toabctl: thats a topic from you?
13:07:21 * dirk doesn't know what 'update absent | override old' means
13:07:36 <IgorYozhikov> dirk, this is my additions
13:07:38 <toabctl> the first part is from me.
13:08:05 <toabctl> I implemented a prototype to use requirements from a single file instead of adding all requirements to the spec.j2 files
13:08:30 <IgorYozhikov> I suggesting to add some flexibility there to make tool able to update old versions according to updated requirements
13:08:35 <toabctl> so basically a {{ py2pkg('oslo.config') }} will automatically add the version if available in a requirements.ttx file
13:09:07 <IgorYozhikov> confirming, tool is working as expected - filling up entries without versions
13:09:31 <toabctl> IgorYozhikov: I still don't get why you want to have old versions in th .spec.j2 . can you explain?
13:09:52 <IgorYozhikov> I do not want
13:10:37 <IgorYozhikov> Just looking further - using tool in automated env we will get updated spec.j2
13:11:12 <IgorYozhikov> in case if outdated versions, for example:
13:11:31 <IgorYozhikov> mitaka-2 has foo >=2.5.0
13:11:48 <IgorYozhikov> mitaka-3 introduce foo >=2.5.2
13:12:16 <IgorYozhikov> and I just want to be sure that renderspec will update 2.5.0.with 2.5.2
13:12:51 <toabctl> IgorYozhikov: then in the spec.j2 would be {{ py2pkg('foo) }} and you just update in requirements.txt "foo>=2.5.0" to "foo>=2.5.2"
13:12:56 <toabctl> that's it.
13:13:11 <IgorYozhikov> history?
13:13:27 <toabctl> IgorYozhikov: history of what?
13:13:45 <IgorYozhikov> versions vs OS release
13:14:28 <toabctl> you can track the requirements.txt in git
13:14:30 <IgorYozhikov> I believe that we are going to create branches
13:14:38 <toabctl> yes
13:15:23 <dirk> right, thats probably one of the next actions - to update rpm-packaging tox jobs to generate renderspec' specfiles for all variants
13:16:44 <IgorYozhikov> where we will keep templates with versions. I far as I know requirements for stable OS releases has been updated from time to time
13:17:49 <IgorYozhikov> and will we reuse last requirements from updated stable branches, or will keep versions inside j2
13:18:15 <dirk> we'd branch rpm-packaging git repo for the stable branch, and maintain a "stable" copy of the glocal requirements file there
13:18:19 <IgorYozhikov> if we are going to rely on requirements, we could totally skip versinoing in j2s
13:18:33 <dirk> in theory, yes. at least for all python dependencies
13:18:40 <dirk> there might be more dependencies though (non-python deps)
13:18:43 <IgorYozhikov> yes
13:19:01 <IgorYozhikov> if so - I'm fine
13:19:40 <IgorYozhikov> for projects with requirements.txt - it is looking fine
13:20:43 <IgorYozhikov> toabctl, dirk - anything else for this topic?
13:20:50 <dirk> not from me
13:21:05 <dirk> thanks to toabctl  for working on this while I was PTO!
13:21:09 <toabctl> well - does the currentl proposal look ok? or any changes requested?
13:21:19 <IgorYozhikov> you already have my 2
13:21:22 <dirk> small comments only, lets address that in the review
13:21:32 <toabctl> ok.
13:21:33 <dirk> overall I am fine with it
13:21:40 <toabctl> ad thanks igor for reviewing and testing!
13:21:49 <dirk> I haven't fully checked how this interacts with the epoch handling though
13:23:12 <IgorYozhikov> dirk, https://review.openstack.org/#/c/280246/4/openstack/python-glanceclient/python-glanceclient.spec.j2 - epoch works, test locally
13:23:26 <IgorYozhikov> let's proceed with topics?
13:23:55 <dirk> #topic  AI reviews#
13:24:13 <dirk> so first one is
13:24:21 <dirk> #link http://eavesdrop.openstack.org/meetings/rpm_packaging_weekly_meeting/2016/rpm_packaging_weekly_meeting.2016-02-18-14.04.html
13:24:56 <dirk> there was
13:24:58 * dirk toabctl proposes rpm-packaging-status.py to rpm-packaging-tools repo
13:25:04 <toabctl> ^^ done
13:25:05 <dirk> iirc that was done
13:25:11 <toabctl> needs another +1 iirc
13:25:18 <dirk> and ACTION: toabctl come up with prototype
13:25:28 <toabctl> hm. prototyper for what? :)
13:25:39 <dirk> I think for the epoch handling
13:25:40 <dirk> which is done
13:25:47 <toabctl> ah.ok.
13:25:52 <toabctl> it's done and merged.
13:26:14 <dirk> yep
13:26:16 <dirk> next one
13:26:19 <dirk> #link http://eavesdrop.openstack.org/meetings/rpm_packaging/2016/rpm_packaging.2016-02-25-13.01.html
13:26:28 * dirk IgorYozhikov document existing review guidelines under wiki.openstack.org/rpm-packaging/ReviewGuidelines
13:26:30 <dirk> that was done
13:26:36 <dirk> I haven't had a close look yet
13:26:43 <dirk> did anyone else review it?
13:26:43 <toabctl> it's done but already outdated
13:27:13 <IgorYozhikov> I'll update it tomorrow
13:27:22 <toabctl> I suggest to remove the parts where we describe renderspec features
13:27:28 <toabctl> that's already in #link http://docs.openstack.org/developer/renderspec/
13:27:29 <IgorYozhikov> yes
13:27:47 <toabctl> which will be updated with every new commit.
13:29:21 <IgorYozhikov> let's move forward if there are no objections...
13:29:31 * dirk has to reboot
13:30:11 <dirk> Can somebody check the action items in the next meeting?
13:30:38 <IgorYozhikov> dirk, I can
13:31:11 <dirk> Please do.. I'm on fs check now :-)
13:31:21 <IgorYozhikov> ok
13:32:14 <IgorYozhikov> dirk figure out solution for changelog extraction problem
13:32:41 <IgorYozhikov> I believe that we will wait for fsck here
13:32:51 * IgorYozhikov IgorYozhikov send CR for flavor-specific subdirectory handling in renderspec
13:33:00 <IgorYozhikov> https://review.openstack.org/#/c/291158/
13:33:07 <IgorYozhikov> work in progress here
13:33:31 <dirk> IgorYozhikov: not done
13:33:35 <IgorYozhikov> I need to write tests, main part and docs more | less done
13:33:45 <dirk> IgorYozhikov: I was on PTO :/ will work on it
13:34:09 <IgorYozhikov> thanks dirk
13:34:30 <IgorYozhikov> I believe that thar are all AIs from last meetings
13:35:51 <dirk> thanks
13:35:59 <IgorYozhikov> toabctl, dirk - as we discussed, I add flavor - https://review.openstack.org/#/c/291158/
13:36:12 <dirk> I have one extra topic
13:36:26 <IgorYozhikov> description in usage.rst
13:37:05 <IgorYozhikov> just want to discuss your thoughts about implementation of SOURCEs flavor
13:38:48 <dirk> in general it looks good to me though I'd rather add it when we have a concrete issue to solve
13:39:15 <dirk> or maybe.. I forgot the conrete issue we tried to solve
13:39:23 <dirk> ah, I remembe,r it was for various init scripts
13:39:30 <dirk> which could be distro specific
13:39:34 <dirk> ok.
13:39:38 <IgorYozhikov> different systemd units
13:39:41 <toabctl> I wonder if we start to add more and more --foobar flags which we then pass to the context.
13:39:44 <IgorYozhikov> for fedora | suse
13:40:24 <IgorYozhikov> toabctl, if --flavor not set and context functions is used it will use spec-style
13:40:37 <IgorYozhikov> I'm trying to be flexible here
13:41:08 <toabctl> IgorYozhikov: what if there is no difference?
13:41:22 <dirk> IgorYozhikov: the question I guess is if we should consider --spec-style and --flavor to be always identical
13:41:29 <dirk> e.g. rename --spec-style to --flavor
13:42:06 <IgorYozhikov> in case of --flavor is set - flavor value is used
13:42:19 <IgorYozhikov> if not - spec-style value used
13:42:40 <IgorYozhikov> here I want to solve next situation
13:42:51 <toabctl> IgorYozhikov: but then we need for everything that uses flavor at least the "number of specs style files"
13:43:09 <IgorYozhikov> for example: user wants to render with fedora style but with custom SOURCE folder,
13:43:24 <toabctl> btw. it would be cool to have more external CIs to see problems in real build envs...
13:43:46 <IgorYozhikov> toabctl, I'm working of CI development
13:44:02 <toabctl> IgorYozhikov: do you need that for yourself? or just a theoretical user?
13:45:19 <IgorYozhikov> toabctl, both cases, if to be frank
13:46:54 <dirk> IgorYozhikov: ok, but why does it make sense to have two flags and not just one?
13:47:03 <dirk> if we need a mirantis_rhel and a mirantis_suse spec style?
13:47:05 <toabctl> IgorYozhikov: even with the current setup (without any flavor at all) you can do what you can with the flavor feature. just replace the SOURCE file with the one you need
13:47:58 <IgorYozhikov> toabctl, flavor used only as override in case of using custom folder name
13:48:35 <IgorYozhikov> that is it.
13:49:47 <dirk> is it okay when we postpone the discussion of this iinto the review or the regular irc channel?
13:49:49 <IgorYozhikov> toabctl, about replacing - week ago we spoke about storing systemd units with spec.j2
13:50:00 <IgorYozhikov> dirk, ok
13:50:27 <toabctl> IgorYozhikov: yeah. I need to reread what we talked about. pardon
13:50:52 <toabctl> I just try to focus on our goal (clients for mitaka) and try to avoid adding things which are not needed for that
13:51:18 <toabctl> init systems are not needed
13:51:31 <dirk> #agreed discuss --flavor handling in renderspec in more detail
13:51:41 <IgorYozhikov> :)
13:51:48 <IgorYozhikov> reviews?
13:51:50 <dirk> #topic  PTL self-nomination
13:51:56 <toabctl> one more topic from dirk :)
13:52:02 <IgorYozhikov> wow
13:52:21 <dirk> according to http://releases.openstack.org/mitaka/schedule.html next week is PTL self nomination time
13:52:43 <dirk> is anyone interested?
13:52:50 * toabctl not
13:53:11 <dirk> just wanted to bring up the topic to think about. I am myself unsure
13:53:15 <IgorYozhikov> dirk, it depends in responsibilities
13:53:39 <dirk> IgorYozhikov: responsibilities as documented :)
13:53:41 <IgorYozhikov> need to read more before answer frankly
13:53:52 <dirk> yep, just think about it. we can talk about it before hand
13:54:11 <IgorYozhikov> yesp, thanks for rising the topic
13:54:18 <dirk> #topic Design Summit Austin space needs
13:54:42 <dirk> Similarly, we need to propose our needs for the design summit in austin
13:54:54 <dirk> I Haven't read the details yet, I'll send that around by email in the next day(s)
13:55:20 <IgorYozhikov> dirk, toabctl - shared document with all thoughts?
13:55:56 <dirk> IgorYozhikov: context? design summit or flavor thing? for flavor I think we can create a wiki page / blue print / etherpad
13:56:05 <IgorYozhikov> summit
13:56:11 <toabctl> about ptl? ok
13:56:28 <toabctl> summit. ah. ok. I suggest etherpad
13:56:37 <toabctl> cI have a hard stop in 4 minutes btw
13:56:40 <dirk> ok, will do
13:56:48 <IgorYozhikov> ok
13:56:55 <dirk> #topic reviews
13:57:18 <IgorYozhikov> https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open
13:57:45 <IgorYozhikov> https://review.openstack.org/#/c/270352/
13:57:48 <toabctl> also #link https://review.openstack.org/#/q/project:openstack/renderspec
13:58:33 <toabctl> ^^ can be merged
13:58:40 <toabctl> build just timedout
13:58:46 <toabctl> dirk: can you review and merge?
13:58:51 <dirk> toabctl: yes, will do
13:59:13 <toabctl> btw. it would be good to get the renderspec changes in so we can simplify all the new spec.j2 directly
13:59:20 <dirk> agreed
13:59:43 <toabctl> IgorYozhikov: I had no time yet to look at the proposed client specs. sorry for tha
13:59:45 <toabctl> t
14:00:05 <IgorYozhikov> toabctl, dirk - will spent some time on review today | tomorrow
14:00:50 <toabctl> ok. I have to go. sorry
14:01:12 <dirk> IgorYozhikov: yes, me too. I'm catching up with stuff today after being offline
14:01:15 <dirk> talk to you next week!
14:01:17 <dirk> #endmeeting