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