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