13:05:43 <dirk> #startmeeting rpm_packaging
13:05:44 <openstack> Meeting started Thu Mar  3 13:05:43 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:05:48 <openstack> The meeting name has been set to 'rpm_packaging'
13:06:40 <dirk> toabctl, dirk, aplanas, IgorYozhikov, jruzicka : ping
13:06:49 <toabctl> hi
13:07:13 <mivanov> hi
13:07:28 <dirk> please review / check the agenda on
13:07:35 <dirk> https://etherpad.openstack.org/p/openstack-rpm-packaging
13:07:42 <dirk> hi everyone btw :)
13:07:58 <IgorYozhikov> dirk, hello
13:09:21 <dirk> can we start?
13:09:31 <dirk> #topic automatic version updates from global-requirements and/or extra yaml file ?
13:10:24 <toabctl> I think that was an idea from you, dirk.
13:10:39 <dirk> ah right
13:10:40 <dirk> ok
13:10:48 <toabctl> given that we are way to slow with new specs and also in updating specs, wen need to improve automation
13:10:55 <IgorYozhikov> mivanov, is working on refactoring of similar tool
13:11:19 <toabctl> mivanov: can you describe the tool a bit?
13:11:27 <IgorYozhikov> it is comparing erquirements.txt and required from spec
13:12:02 <mivanov> yes, this tool compare requirements from python projects and rpm specs
13:12:38 <mivanov> and search diff between it
13:12:50 <IgorYozhikov> initially tool was designed as reporter to team about what was changed in upstream code against our downstream specs
13:13:11 <dirk> #link https://github.com/openSUSE/obs-service-python_requires
13:13:14 <toabctl> does it add/remove requirements? and/or update versions ?
13:13:16 <dirk> this is our version of the same tool :)
13:14:12 <toabctl> dirk: but even with that tool we would be to slow. imo the only thing we should do is to add Requires and BuildRequires to the correct package/subpackage. versions should be handled automatically.
13:14:35 <dirk> toabctl: right
13:14:54 <toabctl> IgorYozhikov, mivanov: do you have a link to the current code?
13:14:54 <mivanov> no, my tool just search differences, but doesn't autoupdate spec
13:15:02 <dirk> toabctl: imho this comes back to extending renderspec to read the requires/buildrequires per package from a yaml and we generate those yamls
13:15:25 <IgorYozhikov> dirk, let me check, not sure that our current repo is open
13:15:41 <toabctl> dirk: yes. and I would even go one step further and add the abbility to read from a global-requirements if no one for a specific package is given
13:16:25 <toabctl> so basically 1) read a yaml file next to the spec 2) read a global yaml file
13:17:04 <IgorYozhikov> repos are private, but we already working to make them public and moving code to dedicated name-space in our gerrit
13:17:23 <toabctl> IgorYozhikov, mivanov: what do you think about the idea to read required versions from yaml files? converting from requirements.txt to a yaml file would be really simple.
13:17:24 <IgorYozhikov> in a couple of days it will be accessible
13:18:09 <IgorYozhikov> toabctl, why yaml? it looks like additional thing between requitements.txt and spec
13:18:56 <dirk> we could also extract the package's requirements*txt directly
13:19:25 <IgorYozhikov> dirk, toabctl - also we are working on reqspec - http://paste.openstack.org/show/489139/
13:19:26 <toabctl> yeah. but we need to process the content (python versions, platforms, optionals,...)
13:19:50 <IgorYozhikov> it will be accessible soon too
13:20:29 <toabctl> I think the main point would be that py2pkg can read requirement files and add the versions. so there's no need to update the spec.j2 when a version changes.
13:21:26 <dirk> yeah
13:21:29 <IgorYozhikov> toabctl, nice point - auto fill for versions
13:21:35 * dirk isn't sure how to conclude the topic
13:21:45 <dirk> what is the next step?
13:22:02 <IgorYozhikov> anyway - further investigation required here aka brainstorm
13:22:52 <toabctl> my intention was todo some brainstorm now :)
13:23:00 <toabctl> but it takes to much time I guess
13:23:01 <IgorYozhikov> ok
13:23:13 <dirk> my main issue is that I am a bit short on time now :)
13:23:24 <IgorYozhikov> agree
13:23:24 <toabctl> so my plan would be to extend py2pkg to read a extra file (I'm fine with requirements.txt) and autofill the versions.
13:23:27 <dirk> can we revisit this topic next week o?
13:23:36 <toabctl> ok. next week is fine, too
13:23:40 <dirk> toabctl: yes either py2pkg or renderspec
13:23:50 <toabctl> dirk: py2pkg is renderspec
13:24:06 <dirk> ah, d'oh
13:24:06 <IgorYozhikov> cool, and we also could rework this during 7-9 of March :)
13:24:09 <toabctl> I mean the contextfunction called py2pkg. not the python module pymod2pkg :)
13:24:16 <dirk> toabctl: yep
13:24:20 <dirk> ok
13:24:40 <dirk> patches accepted :)
13:25:18 <dirk> #agreed revisit topic in Mitaka Bughunt sprint days
13:25:32 <dirk> #topic howto handle changelogs ?
13:26:07 <dirk> did I bring that topic up? I am personally aiming for a git log of the subdirectory , e.g. the git summary
13:26:16 <toabctl> I just wanted some ideas if the changelog is out of scope for rpm-packaging or if we plan todo somethign with it?
13:26:17 <dirk> do we want to maintain a separate changelog?
13:26:35 <dirk> toabctl: e.g. a ChangeLog kind of file besides the .spec.j2 ?
13:26:36 <toabctl> dirk: I added it but we talked shortly about it iirc
13:26:44 <toabctl> dirk: I don't know.
13:27:04 <IgorYozhikov> dirk, we are posting the last 10 log entries from git into package change log
13:27:30 <toabctl> but then we are missing the changes from the python module itself.
13:28:04 <toabctl> so when updating i.e. oslo.log we don't have the ChangeLog entries from oslo.log . just from rpm-packaging/openstack/oslo.log . that's imo bad
13:28:24 <IgorYozhikov> but this is done by our build machine, so it is automated
13:28:36 <dirk> toabctl: hmm. good point
13:28:46 <toabctl> IgorYozhikov: so you would mergre both changes?
13:29:00 <toabctl> we basically have 2 changes - the spec file and the "upstream project"
13:29:03 <dirk> IgorYozhikov: but only from git? or do you extract additional changelogs?
13:30:44 <IgorYozhikov> dirk, our build machine extract from git history entries and inset them into %Changelog in spec, changelogs from code non touched and packaged
13:31:17 <IgorYozhikov> I want to say - it is automated process.
13:33:02 <dirk> ok, thanks for the explanation
13:33:29 <dirk> so you're missing hte upstream changelog in the .changes file
13:33:32 <IgorYozhikov> So I do not see how can we handle | maintain SPEC Changelog records in manual way with data from code
13:33:44 <dirk> which is a problem for SUSE. we are asked by policy to include upstream changelog
13:34:11 <dirk> toabctl: I guess we need to find a way to do that, maybe by adding it to the git commit message and extracting it or by adding it as a changelog in the directory :/
13:34:14 <IgorYozhikov> dirk, may be it will be better to merge records
13:34:58 <IgorYozhikov> spec -> obs ->code changelog >> SPEC changelog -> build
13:35:28 <toabctl> dirk: or with a source service. the tarball with the ChangeLog is anyway there
13:36:17 <toabctl> anyway - let's postpone it. we may find a SUSE solution for that.
13:36:25 <dirk> agreed
13:36:35 <dirk> #action dirk figure out solution for changelog extraction problem
13:36:47 <dirk> topic  beta tags handling in templates aka Version: 12.0.0 vs tag 12.0.0.0b2
13:36:49 <dirk> #topic  beta tags handling in templates aka Version: 12.0.0 vs tag 12.0.0.0b2
13:37:05 <dirk> hehe. I see toabctl  you tried to use the spec files :)
13:37:07 <IgorYozhikov> yes, my one
13:37:22 <dirk> ah, IgorYozhikov
13:37:24 <toabctl> dirk: ?
13:37:37 <dirk> IgorYozhikov: so basically we need a translation for python to rpm package version
13:37:44 <dirk> IgorYozhikov: are you good with using '~' ?
13:37:53 <IgorYozhikov> here I want to clarify
13:37:56 <toabctl> ~ works since rpm 4.10
13:37:59 <dirk> we're automatically translating the .b2 version to ~b2
13:38:06 <IgorYozhikov> yes - that is exactly what we are already using
13:38:07 <dirk> which means "smaller than .0"
13:38:21 <dirk> ok, so we need to implement that
13:38:22 <IgorYozhikov> 12.0.0.0b2 -> 12.0.0~b2
13:38:26 <dirk> in renderspec
13:38:34 <IgorYozhikov> dirk, ^^
13:38:59 <dirk> it is similar to the epoch problem anyway. we need to set the epoch of the package from the epoch definiton of the distro
13:40:34 <IgorYozhikov> dirk, so using 12.0.0~b2 is ok for you?
13:40:56 <toabctl> IgorYozhikov: yes. we are using it
13:41:17 <IgorYozhikov> toabctl, https://github.com/openstack/fuel-mirror/blob/master/perestroika/convert_version.py
13:41:21 <IgorYozhikov> we are too
13:41:36 <dirk> ok, so we're in agreement
13:42:05 <IgorYozhikov> so, am I right that we could use this approach in templates?
13:42:54 <toabctl> IgorYozhikov: I need to check. there's no testsuite for it :)
13:43:12 <IgorYozhikov> toabctl, thanks
13:44:45 <toabctl> btw. there was also a short discussion about the topic on the openstack-dev list. there is a "python setup.py rpm_version" (which produces bad output)
13:44:59 <dirk> lol
13:45:01 <toabctl> anyway - so using "~" seems to be fine for everybody.
13:45:15 <IgorYozhikov> YeY
13:45:18 <dirk> yeah, so we need to implement a filter in renderspec and leave the implementation there?
13:45:26 <toabctl> not really wrong but for 2.0.0dev3 something like 1.999999999999999dev3 or so :-)
13:45:44 <dirk> #agreed converting rpm package versions using the '~' approach
13:46:10 <dirk> IgorYozhikov: toabctl : can you two figure out which implementation of set_version to use? and send a PR ?
13:46:17 <dirk> changerequest to renderspec?
13:46:31 <dirk> #topic SysV init, upstart & systemd units - where to store(non code parts but required stuff)?
13:46:52 <toabctl> IgorYozhikov: btw. are your .spec files you produce somewhere public available?
13:47:28 <IgorYozhikov> toabctl, will check and update you later
13:47:43 <toabctl> thx
13:48:17 <IgorYozhikov> OK, this one topic is mine too
13:48:47 <IgorYozhikov> very soon we will meet so called "server packages"
13:49:00 <IgorYozhikov> OpenStack services/daemons
13:49:04 <toabctl> "very soon" is very optimistic:-)
13:49:17 <dirk> it depends a bit on the reviews topic.. :)
13:49:50 <toabctl> sorry for interrupting - go ahead igor ..
13:49:51 <IgorYozhikov> anyway, we need to get understanding - what & how
13:50:21 <dirk> well, we need to have systemd files for SLES at least
13:50:29 <IgorYozhikov> storing near j2 in corresponding folders?
13:50:36 <dirk> are you asking whether we should standardize on only one service ?
13:50:47 <dirk> or do you ask whether we need to have  a vendor subdir to store specific files in there?
13:50:52 <toabctl> preferable theses files are included in the projects itself I think
13:50:53 <IgorYozhikov> I'm ok with systemd units, but where to store?
13:51:06 <dirk> same git dir, just besides the spec.j2 ?
13:51:56 <toabctl> ok. looks like that only one (networking-cisco) has upstream service files
13:52:02 <IgorYozhikov> dirk, does SUSE sysd units differ from centos?
13:52:08 <toabctl> +1 for same git dir beside the spec.j2
13:52:23 <toabctl> IgorYozhikov: I'm pretty sure, yes
13:52:23 <dirk> IgorYozhikov: probably yes in small details
13:52:28 <dirk> I haven't looked at them in detail
13:52:55 <toabctl> IgorYozhikov: given that you want to start using the packages in newton - do you still need sysv init scripts? or is systemd enough?
13:52:57 <IgorYozhikov> ok - so + additional changes
13:52:59 <dirk> I am more focused on getting to the goal of python-openstackclient
13:53:06 <toabctl> even ubuntu 16.04 will be using systemd
13:53:14 <dirk> reached. service packages are not yet in my  goal
13:53:21 <IgorYozhikov> Source1: {{'something.unit' | systemd }}
13:53:29 <toabctl> dirk: yeah. I agree.
13:54:13 <IgorYozhikov> where filter will just translate spec-style into folder
13:54:55 <IgorYozhikov> example: openstack/nova/nova.spec.j2, openstack/nova/suse/unit.N , openstack/nova/fedora/unit.N
13:55:01 <dirk> IgorYozhikov: could be done, yes
13:55:02 <IgorYozhikov> toabctl, dirk ^^^^
13:55:06 <dirk> I like the idea
13:55:20 <dirk> although I would call it | flavorprefix
13:55:22 <dirk> or something like that
13:55:28 <dirk> to make it reusable for others
13:55:39 <toabctl> ah. yeah. sounds good
13:55:41 <dirk> we also need to have a {{ if flavor == }} at some point
13:56:10 <dirk> IgorYozhikov: want to send a patch and we move the discussion there?
13:56:21 * dirk is running out of time :(
13:56:23 <IgorYozhikov> will try
13:56:30 <IgorYozhikov> mine AI
13:56:53 <IgorYozhikov> lets proceed with topics
13:57:03 <IgorYozhikov> dirk, add please AI 4 me
13:57:33 <dirk> #action IgorYozhikov send CR for flavor-specific subdirectory handling in renderspec
13:57:43 <dirk> #topic reviews :-)
13:57:48 <IgorYozhikov> , openstack/nova/suse/unit.N
13:57:55 <toabctl> ok. would be cool to get this merged: https://review.openstack.org/#/c/273528/13
13:57:56 <IgorYozhikov> sorry :)
13:57:57 <dirk> since we have a hard stop in 3 minutes, agree to handle that in #openstack-rpm-packaging?
13:58:08 <IgorYozhikov> https://review.openstack.org/#/c/270427/
13:58:08 <toabctl> test passed - the build job had just a timeout afacs
13:58:43 <toabctl> and a easy one would be renderspec docs: https://review.openstack.org/#/c/287022/
13:58:43 <dirk> I need to leave, please continue without me
13:58:54 <dirk> in #openstack-rpm-packaging
13:58:56 <dirk> #endmeeting