12:58:53 <dirk> #startmeeting rpm_packaging
12:58:55 <openstack> Meeting started Thu May 19 12:58:53 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:58:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:58:59 <openstack> The meeting name has been set to 'rpm_packaging'
12:59:06 <toabctl> hi
12:59:10 <mivanov> hi
13:01:05 <dirk> everyone, please add your agenda items to
13:01:08 <dirk> #link https://etherpad.openstack.org/p/openstack-rpm-packaging
13:04:07 <IgorYozhikov> dirk, I have no topics today
13:04:30 <dirk> thanks
13:06:27 <dirk> #topic renderspec version
13:06:39 <IgorYozhikov> dirk, when do you plan to release ?
13:07:05 <dirk> currently we#re using renderspec from git for the gating, which turned out to be bad (we already broke gating during the summit)
13:07:06 <IgorYozhikov> and should we use v like 1.0.0?
13:07:18 <dirk> so I wanted to change it to use a release, which means we actually need to have a release
13:07:24 <dirk> currently I think toabctl  is manually uploading releases
13:07:39 <dirk> I wanted to give the openstack release process a try, but I stumbled on choosing a version number
13:07:52 <dirk> would 0.1 be okay ?
13:07:57 <IgorYozhikov> agree, released projects is much easier to package
13:07:58 <toabctl> yes. but openstackci is already owner
13:08:14 <toabctl> 0.1 is fine for me
13:08:23 <dirk> I think we should make it an release:independent project, which means we should choose post versioning
13:08:30 <dirk> (semver)
13:08:50 <dirk> I was just unsure if we want to start with 1.0.0 or with something < 1.0.0
13:08:52 <IgorYozhikov> toabctl, does 0.1 looks fine according to versioning in OS
13:08:56 <dirk> (basically semver says 0.x is not semver)
13:09:08 <IgorYozhikov> dirk, ++
13:09:23 <toabctl> as a independent project, can we still follow the global-requirements with renderspec?
13:09:29 <dirk> toabctl: yes
13:09:39 <toabctl> ok. great
13:09:58 <dirk> the only trouble is that when we want to update a stable/ branch with a newer renderspec, we need to do that manually
13:10:29 <IgorYozhikov> dirk, should we make a tag 1st?
13:10:36 <dirk> no
13:10:41 <dirk> I think
13:10:54 <dirk> so ++1 was on the version number 1.0.0 or 0.1 ?
13:10:57 <dirk> IgorYozhikov: ^^
13:11:05 <IgorYozhikov> semver
13:11:10 <IgorYozhikov> 1.0.0
13:12:04 <IgorYozhikov> we could use 1.0.0.0b1, b2, and so on in case of necessity
13:12:22 <IgorYozhikov> just my thoughts
13:12:53 <toabctl> 1 for 1.0.0
13:13:01 * toabctl doesn't care about the number
13:13:07 <toabctl> +1 I mean
13:13:23 <dirk> yeah, I'd just start with 1.0.0 for now
13:13:32 <dirk> #agreed use 1.0.0
13:13:35 <toabctl> dirk: are you going to prepare the needed changesets for project-config ?
13:13:53 <dirk> toabctl: yep
13:13:59 <toabctl> thx
13:14:45 <dirk> #topic reviews
13:15:33 <dirk> https://review.openstack.org/#/q/status:open+project:openstack/rpm-packaging
13:15:45 <dirk> I was looking at python-keystoneclient which is sort of the next one
13:15:55 <IgorYozhikov> unfortunately, https://review.openstack.org/#/c/311285/ can't pass our CI due spec-cleaner from pypi
13:16:15 <IgorYozhikov> in master abs path is fixed
13:16:16 <toabctl> also the log update. for SUSE we need that
13:16:37 <dirk> IgorYozhikov: there was a new spec_cleaner release
13:17:15 <toabctl> dirk: that doesn't help for the /var/lib/obs problem
13:17:24 <toabctl> IgorYozhikov: have you already prepared a PR to fix that?
13:17:33 <IgorYozhikov> toabctl, https://github.com/openSUSE/spec-cleaner/blob/spec-cleaner-0.8.7/setup.py has abs path
13:17:58 <IgorYozhikov> https://github.com/openSUSE/spec-cleaner/blob/master/setup.py has fix
13:18:09 <IgorYozhikov> it installs into venv  fine
13:18:56 <IgorYozhikov> I just checked locally
13:19:05 <IgorYozhikov> everything installed into venv
13:19:30 <dirk> ok, so we need another release
13:19:39 <IgorYozhikov> dirk, looks so
13:20:03 <toabctl> dirk: do you know Tomáš irc nick?
13:20:31 <dirk> toabctl: scarabeus
13:20:44 <toabctl> ok. I'll ping him to get a new release out
13:21:03 <dirk> #action toabctl get a spec_cleaner release out that fixes virtualenv install issue
13:21:24 <dirk> I had a look at keystoneclient just a few hours ago
13:21:27 <IgorYozhikov> toabctl, thanx (^_^)
13:21:28 <dirk> #link https://review.openstack.org/#/c/290472/
13:21:49 <dirk> and I couldn't understand the fuel build failure. IgorYozhikov or maximov
13:21:53 <dirk> can you look into that one?
13:22:02 <dirk> (and everyone else: please review.. :) )
13:22:09 <IgorYozhikov> dirk, already looking
13:23:28 <IgorYozhikov> https://packaging-ci.fuel-infra.org/job/master-rpm-packaging-build/137/artifact/artifacts/python-keystoneclient-buildlog.txt/*view*/ looks strange, I'll investigate this failure today.
13:23:41 <IgorYozhikov> testr failed
13:24:27 <dirk> I'm also lacking desparate reviews on https://review.openstack.org/#/c/297112/
13:25:17 <toabctl> dirk: do we want to use global-requirements or upper-constrains ?
13:25:33 <IgorYozhikov> dirk, looks like file is outdated since it was uploaded
13:25:43 <IgorYozhikov> yes, this is the topic
13:25:49 <IgorYozhikov> g-r || u-c
13:25:52 <IgorYozhikov> thanx toabctl
13:26:27 <dirk> IgorYozhikov: imho we should use global-requirements
13:26:43 <dirk> we should aim for packaging upper constraints, but the requirements in the spec file should be the lower bound imho
13:27:10 <dirk> I saw the discussion on the mailing list, I think that was the conclusion there as well but maybe I misread it
13:27:38 <IgorYozhikov> dirk, so, Requires >= g-r, dependencies*.rpm should be updated according to u-c. Right?
13:27:50 <dirk> yes
13:28:44 <toabctl> dirk: have you already checked if we can get this file automatically updated with the bot?
13:28:59 <toabctl> anyway - we can handle that later.
13:29:13 <dirk> toabctl: currently it only updates requirements.txt or test-requirements.txt
13:29:18 <dirk> the bot I mean
13:29:21 <toabctl> a new spec-cleaner release is on its way :)
13:29:27 <dirk> we probably have to add a special case for that
13:29:50 <IgorYozhikov> It could bring complexity in tracking of versions changes. I ncase when u-c versions used - yum||zypper will take care
13:29:51 <dirk> unless we just want to rename it to requirements.txt
13:30:16 <toabctl> dirk: it's also on a different path...
13:30:54 <IgorYozhikov> just my thoughts
13:31:10 <dirk> toabctl: huh?
13:31:14 <dirk> its in the root dir
13:31:22 <toabctl> oh
13:31:32 <toabctl> ok
13:32:11 <dirk> IgorYozhikov: I'm not sure I understand that.. zypper uses the newest available version always (and when you update from an existing version, it will use the newest one that is installable without conflicts unless you force it, which will then cause a conflict dialog)
13:32:38 <dirk> so using a lower bound just gives you the flexibility of choosing to go with an older than the most current version
13:32:45 <dirk> it doesn't cause any other issue
13:32:58 <dirk> I don't know enough about yum to understand though if that is any different there
13:34:55 <IgorYozhikov> dirk, just trying to be more closer to current versions, this could help in case of projects will raise lower bounds which could be still << then values in u-c
13:35:24 <IgorYozhikov> that's it
13:35:54 <IgorYozhikov> anyway, got your point of view and it is clear 4 me
13:36:23 <dirk> IgorYozhikov: yeah, my secret master plan is to write a script to review the cases where lower bounds and uc are way out of sync
13:36:37 <dirk> and then run a test build with projects bound to the lower boudns to see if it still works
13:36:52 <dirk> so e.g. lower bounds should be meaningful
13:37:04 <dirk> from my current experience I don't think there are a lot of cases where lower bounds isn't "correct"
13:37:27 <IgorYozhikov> o i c
13:39:16 <dirk> IgorYozhikov: see 3.4.2 in https://etherpad.openstack.org/p/requirements-tasks
13:39:32 <dirk> so can we move forward with the global-requirements.txt copy file ?
13:39:43 <dirk> I think currently we don't generate spec files with lower bounds anymore, I would like to get that fixed
13:39:50 <dirk> current state is not useable for SUSE anymore
13:40:00 <dirk> please add your reviews to https://review.openstack.org/#/c/297112/
13:40:00 <dirk> tia
13:40:16 <dirk> any other topics ?
13:40:37 <dirk> otherwise will people join next week ?
13:40:40 <dirk> its a public holiday here
13:40:43 <IgorYozhikov> dirk, file is old, may be it could be better to update it 1st?
13:40:54 <dirk> #topic next meeting slot
13:40:56 <dirk> IgorYozhikov: sure, will do
13:41:42 <IgorYozhikov> and I guess 4 mitaka branch too :)
13:41:50 <IgorYozhikov> great
13:42:36 <dirk> IgorYozhikov: yeah, one step at a time..
13:42:51 <dirk> toabctl: would you be able to join next week?
13:43:32 <toabctl> dirk: yes. why not?
13:43:37 <IgorYozhikov> I'll be here
13:43:47 <dirk> toabctl: its a public holiday
13:43:49 <dirk> :-)
13:43:56 <dirk> ok, then cya next week same time!
13:43:57 <toabctl> dirk: ah. only in south germany I guess
13:44:00 <dirk> #endmeeting