13:01:47 <dirk> #startmeeting rpm_packaging 13:01:48 <openstack> Meeting started Thu Feb 25 13:01:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:51 <openstack> The meeting name has been set to 'rpm_packaging' 13:02:07 <IgorYozhikov> hi 13:02:23 <dirk> everyone, please add your agenda items to https://etherpad.openstack.org/p/openstack-rpm-packaging 13:02:27 <mivanov> hi 13:05:33 <dirk> done with topics? can we start? 13:07:01 <dirk> #topic Mitaka Bugsquash event 13:07:45 <dirk> There is an OpenStack Foundation managed Bug Squash event world wide happening in various locations March 7th-9th 13:07:46 <dirk> https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka 13:08:07 <dirk> in one of the previous meetings we've been pondering about doing a rpm packaging hackathon during that time 13:08:38 <dirk> just wanted to remind you again, feel free to join our irc channel (#openstack-rpm-packaging) during that time and/or meet us in person 13:09:11 <dirk> there is one meetup in Nuernberg Germany at the SUSE headquarters hosted where some of us will participate 13:09:29 <dirk> but in any case lets meet on irc and get more spec files / reviews done 13:09:54 <dirk> #link https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka 13:10:18 <dirk> #link etherpad.openstack.org/p/openstack-rpm-packaging 13:10:19 <IgorYozhikov> dirk: according to doc any interested people in Moscow could join us too in Mirantis office 13:10:31 <dirk> IgorYozhikov: nice! 13:10:48 <dirk> well, it is hard to beat moscow of course :-) 13:12:11 <dirk> IgorYozhikov: will you set aside some time for rpm-packaging during that time? 13:12:13 <IgorYozhikov> should we try to review | merge as much as possible and with good quality during this event? 13:12:50 <IgorYozhikov> Yes, I could be on irc and participate in public activities 13:12:53 <toabctl> +1 (but I also need some time for manila so I can participate the whole time) 13:13:54 <IgorYozhikov> looks like we need some kind of to-do :) 13:14:15 <dirk> isn't http://www.toabctl.de/openstack/rpm-packaging-status.html the todo? :) 13:14:18 <dirk> or your spreadsheet 13:14:24 <IgorYozhikov> or just will keep going through the list ^^^ 13:14:28 <IgorYozhikov> yes :) 13:14:59 <dirk> #topic specify versions for BuildRequires ? 13:15:06 <dirk> toabctl? 13:15:39 <toabctl> I was wondering if we want to specify the versions for BuildRequires . afaik some of our specs do, others don't 13:15:52 <toabctl> so what's our prefered way to handle this? 13:15:53 <IgorYozhikov> to be frank, I prefer to use lower bounds 13:16:30 <dirk> I personally don't really care, I'd be fine without versioned requires on buildrequires 13:16:49 <IgorYozhikov> just to be closer to versions used as for testing as for build and mentioned in corresponding requirements.txt 13:18:00 <IgorYozhikov> dirk: I'm agree here only with one exception, we have already pre-built dependencies with required versions 13:18:16 <dirk> main downside of that is that it serializes the order in which we can merge spec files quite drastically 13:18:40 <dirk> since upstream is doing version bumps everywhere, and then very quickly packages become unbuildable if not updated in the right order 13:19:05 <dirk> maybe that is not a big concern though, but in some cases while the version was bumped you can still build against older versions, so that allows some flexibility 13:20:35 <IgorYozhikov> yes - it is easier, but how to be with same projects which are present in both sections as in BuildRequires as in Requires + version? 13:21:18 <dirk> hmm, okay 13:21:30 <IgorYozhikov> for example - in Mirantis we can't merge spec without successful installation test 13:21:57 <toabctl> we still need such a test for reviews and gating ... 13:22:16 <dirk> yeah, but thats just a few lines of code with the OBS CI job 13:22:26 <IgorYozhikov> toabctl: I'm working on similar stuff 13:22:30 <dirk> (once the bottlenecks with it are solved) 13:22:49 <toabctl> IgorYozhikov: working on CI? 13:22:51 <IgorYozhikov> already made proposal to our infra team, will clarify ETA 13:22:57 <dirk> ok, so we agree to list versions both on buildrequires and requires? 13:23:20 <toabctl> fine for me. 13:24:01 <dirk> #agreed also list versioned dependencies for BuildRequires 13:24:15 <dirk> I think we need to document that on the wiki for some reviewing guidelines 13:24:29 <IgorYozhikov> dirk: yes 13:24:31 <toabctl> +1 for documenting it 13:24:31 <dirk> technically I was thinking about a pep8 tool for our spec files but that is maybe a bit too much work right now 13:24:56 <dirk> any volunteer for startign such a wiki page? it doesn't have to be perfect, but it would be good to document our best practices for new contributors and reviewers 13:25:25 <IgorYozhikov> dirk, toabctl - also need to add about calls for test & docs 13:25:52 <IgorYozhikov> dirk: I will do 13:26:47 <dirk> whats the wiki url? wiki.openstack.org/rpm-packaging/ReviewGuidelines ? 13:26:49 <dirk> perhaps ? 13:27:21 <toabctl> I can create the wiki page 13:27:28 <dirk> #action IgorYozhikov document existing review guidelines under wiki.openstack.org/rpm-packaging/ReviewGuidelines 13:27:33 <toabctl> oh. sorry. forgot to scroll down 13:27:39 <toabctl> IgorYozhikov: please go ahead. 13:27:44 <dirk> thanks Igor! 13:27:44 <toabctl> didn't read the answer :) 13:27:55 <dirk> to everyone else, please help/review the changes 13:28:02 <IgorYozhikov> toabctl: ok 13:28:08 <dirk> #topic what files in %doc: AUTHORS ChangeLog CONTRIBUTING.rst HACKING.rst LICENSE README.rst ? 13:28:14 <dirk> again a topic from toabctl :) 13:28:27 <toabctl> also something to document I guess. What files do we want to have there? 13:29:00 <toabctl> imo no LICENSE (because that's under %license) but I'm for AUTHORS, ChangeLog and README 13:29:17 <toabctl> I think CONTRIBUTING.rst and HACKING isn't really needed 13:29:40 <dirk> yeah, I would leave out HACKING* at least 13:29:47 <dirk> I"m undecided about AUTHORS 13:29:58 <dirk> works foe me. 13:30:20 <toabctl> well - AUTHORS is not really documentation. so we can leave that out, too 13:30:57 <dirk> any concerns, thoughts, objections? 13:31:03 <IgorYozhikov> -HACKING, yes 13:34:03 <dirk> #agreed do not add HACKING* and CONTRIBUTING* to %doc 13:34:17 <dirk> #agreed do not add HACKING* and CONTRIBUTING* and AUTHORS to %doc 13:34:31 <dirk> I think we agreed to the 2nd one :) 13:34:39 <toabctl> :) 13:36:08 <dirk> #topic renderspec epoch handling - comments? (see https://review.openstack.org/#/c/283744/ ) 13:37:05 <toabctl> I added support for epochs to renderspec . are there any comments? should something change there? 13:37:09 <dirk> first of all, thanks to toabctl for writing tons of tests and working out a proposal 13:37:46 <toabctl> I would like to get this merged soon (or chanage it) so we can use the new style template mechanism to support epochs 13:37:53 <dirk> I haven't checked it out in detail, where/how would we add the epoch yaml files? 13:38:13 <dirk> would they be a separate file, e.g. %distro-epochs.yaml alongside the spec.j2 ? 13:38:21 <dirk> how does it hande the case that the file doesn't exist? 13:38:22 <IgorYozhikov> As I already said - 2nd variant looks easier 13:38:23 <toabctl> dirk: that's a good question. I asked number80 about it but got no response 13:38:46 <IgorYozhikov> and yes - yamls - where they will resides? 13:38:51 <toabctl> if the file doesn't exist, epochs are currently just ignored 13:39:56 <toabctl> my current feeling is that we should store the $distro-epochs.yaml in the rpm-packaging repo 13:40:09 <toabctl> IgorYozhikov: why easier? 13:40:44 <IgorYozhikov> one function with params 13:41:11 <toabctl> IgorYozhikov: 2nd variant == {{ py2pkg('oslo.config', ('>=', '3.0.0')) }} ? 13:41:22 <IgorYozhikov> filter -> function 1,2,3 13:41:23 <IgorYozhikov> yes 13:41:35 <toabctl> ok. I guess then we all agree about that. 13:41:48 <dirk> +1 13:41:56 <IgorYozhikov> ++ 13:42:18 <dirk> I also think the yamls should be just submitted into the git repo alongside the spec.j2 files 13:42:31 <dirk> e.g. the renderspec tool should search for them in the given directory where the spec.j2 resides by default 13:42:50 <toabctl> dirk: so you want to have a epoch db per spec.j2 ? 13:42:59 <IgorYozhikov> Just to be clear, it will handle the old format normally, right? 13:43:12 <toabctl> IgorYozhikov: yes. we can slowly migrate to the new format 13:43:19 <dirk> IgorYozhikov: old sformat is still supposed 13:43:33 <dirk> toabctl: ah, you mean it should be in a common directory? 13:43:34 <IgorYozhikov> dirk, toabctl - thanx 13:43:45 <toabctl> dirk: yes. a single db per distro. 13:44:03 <toabctl> dirk: I don't see a reason why we need to duplicate that information 13:44:19 <IgorYozhikov> I've got feeling that yaml will resides near spec.j2 13:44:21 <dirk> so storing in the parent directory? 13:44:45 <IgorYozhikov> but this is not good 13:44:50 <toabctl> dirk: maybe just in rpm-packaging/epochs/fedora-epochs.yaml 13:45:30 <dirk> works for me as well 13:45:31 <IgorYozhikov> common storage, yes. And it should target current OS release 13:45:45 <dirk> I guess we need to discuss this when number80 is back from PTO 13:45:51 <toabctl> m. yes 13:46:11 <dirk> I was anyway thinking that we should add some magic to fetch the proper version numbers from the glocal requirements repo 13:46:29 <dirk> and stop listing them explitely in the spec.j2 template. it would be substituted automatically 13:46:36 <dirk> so the epoch would be similar in that regard 13:46:49 <toabctl> dirk: we can add that later I guess 13:46:53 <dirk> ok, so in generall we agree that this is looking good, we need to finalize the epoch stuff with number80 ? 13:46:57 <dirk> can we agree to that? 13:47:01 <toabctl> +1 13:47:31 <IgorYozhikov> dirk: we already have tool for GR parsing against specs 13:47:54 <IgorYozhikov> mivanov: could you post link? 13:48:08 <dirk> #agreed proposal for py2pkg change in renderspec (see https://review.openstack.org/#/c/283744/ ) looks good, we need to finalize epoch discussion with Red Hat 13:48:17 <dirk> IgorYozhikov: cool.. can we integrate it somehow? 13:48:36 <IgorYozhikov> maybe, mivanov - is one of the authors 13:51:06 <dirk> we should take a look at that 13:51:12 <dirk> mivanov: around? 13:51:51 <mivanov> yes, i'm here 13:52:52 <mivanov> i'm just searching in my repos :) 13:53:04 <IgorYozhikov> mivanov: can you record a small demo and post the link here 13:53:20 <dirk> ok, cool, I'd suggest to continue the discussion in #openstack-rpm-packaging since we have a hard stop here for the next meeting 13:53:24 <dirk> any last topic ? 13:53:39 <toabctl> just the usual "please do reviews" :) 13:53:57 <toabctl> afaics we need next oslo.serialization which is https://review.openstack.org/#/c/284700/ 13:54:10 <dirk> yes, good point 13:54:13 <toabctl> this hopefully unblocks oslo.concurrency 13:54:23 <dirk> I realized as well that oslo.serialization blocks everything 13:54:37 <dirk> so please review https://review.openstack.org/#/c/284700/ 13:57:08 <dirk> ok, meet everyone in #openstack-rpm-packaging 13:57:13 <IgorYozhikov> I'm fine with CR, reqs are up to date 13:57:19 <dirk> thanks! next meeting next week same place same time :) 13:57:22 <dirk> #endmeeting