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