13:00:17 #startmeeting rpm_packaging 13:00:18 Meeting started Thu Jun 9 13:00:17 2016 UTC and is due to finish in 60 minutes. The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:22 The meeting name has been set to 'rpm_packaging' 13:00:27 hi 13:00:56 everyone, please add your agenda items to 13:00:57 #link https://etherpad.openstack.org/p/openstack-rpm-packaging 13:02:39 o/ 13:06:35 #topic consume renderspec & pymod2pkg from pypi in CI jobs 13:07:38 yes, I started asking about it already. 13:07:47 IgorYozhikov: I'd say yes, we should consume the versions listed in the *txt files 13:07:55 e.g. to make it similar like running locally tox -e 13:07:57 so just to be sure that we are using the same versions in CI 13:08:30 and results of jobs are more || less the same according to used renderspec version 13:08:40 yep 13:08:54 I'm obviously pro the topic. any concerns? 13:08:57 from anyone? 13:09:22 since that do we need make pymod2pkg release too? 13:09:45 which will contain all latest commits? 13:10:27 after that we could just use pip install renderspec instead of checking out code from git 13:11:19 number80, toabctl - your opinion 13:11:20 IgorYozhikov: we released the tip of tree of pymod2pkg and renderspec as of yesterday as 0.4.0 and 1.0.0, respectively 13:11:33 dirk, cool 13:11:57 since that I can update packages for them in our downstream - yey 13:12:54 +1 for using the released versions. 13:13:04 that's also what we do in the SUSE CI 13:13:50 IgorYozhikov: as I suggested we could just package the spec files for those packages in the rpm-packaging project :-) 13:15:53 dirk are you speaking about creating spec.j2 for renderspec & pymod2pkg? 13:16:17 make sense, dirk :) 13:17:07 IgorYozhikov: yep 13:17:23 dirk, I can do that if there are no objections 13:17:49 #agreed CIs should use the relesased versions of renderspec/pymod2pkg that the requirements.txt file depends on 13:17:54 IgorYozhikov: fine by me 13:19:09 great, let's proceed? 13:19:11 #topic python version for renderspec 2 or 3, functionallity extension - auto populate from project requirements + blacklist support 13:19:49 I am not sure I understand the topic 13:19:55 IgorYozhikov, would you explain 13:19:55 ? 13:19:56 we almost done with renderspec "deb" 13:20:38 and I want to discuss some features we already add and want to add in nearest future 13:21:18 zigo asked about auto-population of requirements from project requirements.tx file 13:21:35 let me show you how it works - http://paste.openstack.org/show/509202/ 13:22:29 also i asked our devops to provide access to our git repository, toabctl already checked it 13:22:40 and you could read the code 13:22:59 And I have a couple of questions here 13:23:50 1: as we discussed a week ago about bringing back code with debian style support to initial repository 13:24:21 dh-python needs py3 13:24:39 with py2 renderspec fails with encoding error 13:24:49 SyntaxError: Non-ASCII character '\xc2' in file /usr/share/dh-python/dhpython/__init__.py 13:26:35 2: question is about your thought/opinion about functionality we already made 13:27:44 I haven't looked at it, toabctl ? 13:27:54 3: blacklist file - list of pymodules that will be cut of from auto-population 13:28:32 debian style? 13:28:55 IgorYozhikov, m. I don't get the questions. about qeustion 1) - what's the question? to use renderspec with python3? 13:29:08 yes 13:29:46 having renderspec compatible w/ python3 is definitively a goal 13:30:08 but it should be running on both python2/3 for now 13:31:01 IgorYozhikov, as number80 said, afaik it is already working with py3. so just call it with python3 13:32:18 IgorYozhikov: we have a review open to add python 3 testing for renderspec changes 13:32:33 so just use it with python3 if thats what you need? 13:32:59 toabctl, just clarifying - if I || my colleagues will commit back renderspec with deb support it should be fine. because for debian it works fine only with py3 13:34:06 due limitation of dh-python 13:35:46 IgorYozhikov, py3 support should work and as dirk said, there will be a job to test with py3, too 13:35:48 IgorYozhikov: just a question, do you mean that renderspec would also generate debian packages? 13:36:29 number80, the goal here - add something like --spec-style debian - and yes 13:36:35 IgorYozhikov, regarding question 2) - I haven't looked into it in detail yet. tbh I would like to see a changeset on review.openstack.org to look into it. so others can comment on it, too 13:37:08 toabctl, sure, will do that on next week 13:37:12 IgorYozhikov: I don't mind, personally 13:37:17 number80, do you have an opinion about the debian support? we discussed that last week 13:37:19 ah.ok 13:37:31 IgorYozhikov: just split it in sensible hunks, and we'll handle it as reviews 13:37:43 toabctl: if renderspec can generate debian packages, I don't mind but it has to be properly done 13:37:43 I'm happy to make it more useable for others 13:37:44 dirk, I'll try 13:38:13 ok 13:38:27 for repo, I need more details because I'm not sure what I'd be signing for :0 13:39:20 IgorYozhikov, and I don't understand question 3) - what is auto-population? 13:39:43 number80, I can show you how it works, if any1 interested I can arrange a video call :) 13:39:55 toabctl, http://paste.openstack.org/show/509202/ 13:40:02 {{ req2pkgs() | indent(9) }} 13:40:05 function 13:40:22 IgorYozhikov: I'll ping you later about it, I'm multitasking again 13:40:31 which is populating requirements from project reqs txt file 13:41:02 where does the requirements file come from? 13:41:31 I use this command renderspec-deb --requirements global-requirements.txt --project-requirements ../oslo.db/requirements.txt -o - examples/oslo.db.control.j2 13:41:45 from source code project 13:42:20 IgorYozhikov, what's the difference between --requirements and --project-requirements ? 13:42:42 you can already use --requirements multiple times. 13:42:47 --requirements works as usual 13:43:25 --project-requirements is used for auto-population 13:44:01 so we no longer maintain the list of Requires but use this autopopulation thingy? 13:44:51 IgorYozhikov: but thats an independent feature .. (auto population) 13:44:54 we could maintain both in case of necessity 13:44:58 we could decide for or against that for rpm packages 13:45:00 as well 13:45:07 currently I was leaning towards not having auto population 13:45:13 me, too 13:45:15 to give a chance of opinionating the packaging 13:45:35 and just using requirements.txt from a project is not enough. there may be requirements in setup.cfg and other files 13:45:40 dirk, agree, and that is why I'm asking 13:45:45 but thats maybe a wrong approach if you think about the goal of having a genuine openstack packaging of openstack 13:46:17 getting requirements from a repo/sdist could be a own project imo 13:46:42 IgorYozhikov: is the project-requirements thing a requirement for zigo/the deb packaging folks? 13:46:54 dirk, yep 13:47:00 zigo asked about it 13:47:04 * number80 is found of autopopulation too 13:47:07 *not 13:47:31 it could be an option for debian support of renderspec though 13:47:52 yes, I can enable this only in case of style - debian 13:48:08 thanks number80 for suggestion 13:49:23 IgorYozhikov, has zigo already code to get requirements from a sdist ? 13:49:42 We don't use sdist binaries. 13:49:47 Just plain git... 13:50:17 zigo, hey 13:50:26 zigo, so same question - just replace sdist with git :) 13:50:47 toabctl, dirk are you fine if this function will available only with spec-style debian? 13:51:19 toabctl: I used to, but since the requirements.txt are full of != and python-version<3.3 stuff, what I wrote is broken... 13:51:43 zigo, there is the packaging module which handles the requirements markers . 13:51:59 toabctl: Using Python code? 13:52:04 zigo, yes 13:52:06 My stuff was in plain shell ... :P 13:52:14 heh 13:52:47 ISO shell, only for the true hackers (tm) 13:52:48 :) 13:53:07 More seriously: I was too lazy to write things correctly in Python. 13:53:18 It's good someone else has enough time to write it properly. 13:53:36 IgorYozhikov: well.. I would prefer to try to unify the approaches of requirements handling 13:54:00 in the long run it would be better I think. but if we can't agree then I'm not objecting to adding an option for satisfying conflicting needs 13:54:23 but still trying first to come to the same approach would be preferable 13:54:39 dirk, ok, I'll try to propose PRs 13:54:59 next topic? 13:56:07 yes 13:56:57 #topic reviews 13:57:10 since we're about to run out of time, can we do that topic in the rpm-packaging channel? 13:57:16 #link https://review.openstack.org/#/q/(project:openstack/rpm-packaging+OR+openstack/renderspec+OR+openstack/pymod2pkg)+AND+is:open 13:57:22 yes 13:57:25 ah.sure 13:57:31 Guys, could you please review these 2: https://review.openstack.org/#/c/278360/1 https://review.openstack.org/#/c/274077/6 13:57:41 ack 13:57:42 I already spent some time this week doing this 13:57:46 These are adding a --sysconfdir option in PBR. 13:57:54 IgorYozhikov: main open things are rebasings of the python*client spec templates.. are you guys going to do that? 13:58:00 ok, lets end the meeting here and move over 13:58:02 thanks! 13:58:04 #endmeeting