13:00:57 #startmeeting rpm_packaging 13:00:58 Meeting started Thu Aug 11 13:00:57 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:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:01 The meeting name has been set to 'rpm_packaging' 13:01:08 toabctl, dirk, aplanas, IgorYozhikov, jruzicka, number80: ping 13:01:23 I'm in another meeting currently. sorry 13:01:32 o/ 13:01:56 #chair number80 IgorYozhikov 13:01:57 Current chairs: IgorYozhikov dirk number80 13:02:01 #topic roll call 13:02:34 #chair jpena 13:02:35 Current chairs: IgorYozhikov dirk jpena number80 13:03:58 anyone from mirantis there? 13:04:03 IgorYozhikov: ? 13:04:10 o/ 13:04:14 ah, hey :) 13:04:18 hi :) 13:06:35 any topics to add to 13:06:40 #link https://etherpad.openstack.org/p/openstack-rpm-packaging 13:06:45 otherwise we start with the agenda 13:07:50 #topic https://review.openstack.org/#/c/349069/ 13:07:54 I'll just put this one first 13:07:57 as it is a short one 13:08:24 this is about the outcome of the cross project goal setting discussion (ref mailing list discussion) 13:08:29 I've been invited to review the proposal 13:08:40 everyone else here please feel invited to review it as well 13:09:26 dirk, it is huge change. As I remember right we've been discussing it in Tokyo 13:09:36 ack 13:10:18 zigo++ 13:10:25 number80: o/ 13:10:31 I haven't seen his last comment on that discussion :) 13:10:54 (about project not supporting latest python) 13:11:57 number80: FYI, we're up to speed. I'm currently preparing the Gerrit repo to start packaging upstream. All of our environment is working! :) 13:11:58 IgorYozhikov: sure 13:12:24 dirk, thanx for updates 13:12:37 zigo: is it documented somewhere? 13:12:43 zigo: we'd like to copy that for rpm packaging I guess 13:12:46 dirk: Not before I have all repo uploaded. 13:12:52 so it looks like we need to be prepared 4 py3 13:13:07 dirk: I don't think there's much to copy, the sbuild thing is very Debian centric. 13:13:24 and might be it will require to introduce py3 support in j2 templates 13:13:56 The reprepro thing too. 13:14:00 with something like py3-2pkg() 13:14:07 pabelanger was super helpful. 13:14:14 Big up to him! 13:15:28 IgorYozhikov: globally python3 support will require advanced spec file parsing 13:15:44 number80, I understand this 13:16:07 zigo: well, the concepts could be copied 13:16:08 anyway 13:16:17 we're side tracking 13:16:24 lets add that as a topic under the open discussion later 13:16:48 number80: yep, but we agree we need to do that, right? so we need to define blue prints / features for being able to handle python 3.5 spec file packages going forward 13:16:50 #info everyone review cross project goals setting proposal 13:17:34 dirk: yes, it's not difficult but if renderspec has no knowledge of subpackage blocks, it'll be difficult 13:17:46 dirk, agree, and where are we going to publish BP? 13:17:49 to LP? 13:17:57 * number80 is fine with that 13:18:10 https://launchpad.net/rpm-packaging 13:19:34 number80: there are a couple of variants 13:19:43 IgorYozhikov: no idea, I ghink we could also create a -specs git repo 13:19:47 I would actually prefer that 13:19:59 variants? 13:20:20 like per each python3 stack supported or implementation strategies? 13:20:49 different implementation strategies on how to enable pthon3/2 side building 13:21:10 dirk, yes it could be -specs repo, just want to say that LP already have everything for that :) 13:21:12 we could have two j2 templates, one for python2 / 3 (as the most stupid implementation) 13:21:48 right, this can be implemented as policies but still requires spec file proper parsing 13:22:06 dirk, do you mean py2-foo.spec.j2 & py3-foo.spec.j2 ? 13:22:37 there 13:22:42 and run rendering with py2 and py3 renderspecs ? 13:22:51 's not much difference to have different specs 13:23:28 should we create an etherpad about this? 13:23:37 +1 good start 13:23:44 yep 13:23:51 I currently have no clue about complexities regarding common py2/py3 packaging so I'd need someone with more experience to start on that 13:24:16 I'll give it a shot 13:24:24 I believe that we and fedora already building py3 rpms 13:24:28 https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec 13:24:51 #link https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec 13:24:51 I meant mirantis 13:28:30 number80: would you start writing some thoughts there? 13:28:34 can we move on topics? 13:28:37 moving next || brainstorming etherpad? 13:31:17 number80: are you okay with taking the action item to start with the etherpad? 13:32:21 * dirk needs to move on as he has a hard stop 13:32:42 #action dirk ping people for https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec 13:33:56 dirk, I can write some thoughts about py3 13:34:20 and ping number80 4 review || advices 13:34:54 tes 13:35:10 #action number80 starts the the python3 packaging etherpad 13:35:24 ok, thanks 13:35:32 IgorYozhikov: you're welcome to help :) 13:35:43 sure 13:35:45 #topic Deps ordering (IgorYozhikov) 13:36:10 yes, this was postponed from last meeting due absence of people 13:36:58 was discussed which type ordering is better to be used 13:37:17 alphabetical || as in requiremetns file 13:38:10 since this topic was raised, want to clarify and write in wiki 13:38:42 you mean in the spec file? 13:38:47 sorry, the spec.j2 template? 13:38:49 yes 13:38:53 well, thats what the lint / spec-cleaner verfies 13:39:02 it requires alphabetical on the package names 13:39:05 topic: - ordering of (Build)Requires from last meeting 13:39:22 so you currently can not create a spec file with dfiferent ordering.. 13:39:28 are you asking to change that? whats the advantage? 13:39:53 no, I do not asking about changing it 13:40:12 just clarifying 13:41:01 it is sometime confusing because pypi name could be differ from resulting package name 13:41:20 yes 13:41:23 and linter job will be marked as failed 13:41:23 it is a bit confusing right now 13:41:28 I hope it will not become a problem :/ 13:41:51 basically we're verifying on the suse naming schema, which is python-$pypi name, so it is effectively ordering on $pypi name 13:42:08 any concerns about that? 13:42:49 not now, i learned how to read linter logs :) so I'll handle it 13:43:36 let's move next 13:44:26 can we move to open floor? 13:44:31 #topic open floor 13:44:49 I'd like to have some background on https://review.openstack.org/343343 13:44:57 (openstacksdk rename to python-openstacksdk) 13:45:27 * dirk too 13:45:42 what is the naming convention? pypi or openstack project name? 13:46:10 I believe pypi 13:46:18 the thing is, it should be the same but some projects change name in pypi 13:46:52 here we have to deal with a rename 13:47:14 keystoneauth1 is in a similar situation, btw 13:47:58 yeah 13:48:09 imho we should follow pypi nameing schema 13:49:19 well, why not 13:49:25 I can adapt DLRN to that, so we can live with pypi naming schema 13:49:26 jpenas commit found bug in our CI and it is already fixed. 13:50:30 I'm about 'rename of openstacksdk' 13:51:15 so, rename is not necessary and could be abandoned, right? 13:51:27 based on the discussion, yes 13:51:52 number80? ^^ 13:52:18 wfm 13:54:08 anything else 13:54:14 can we do the reviews later? 13:54:16 * dirk has to run 13:55:20 ok for me 13:56:27 ok 13:56:44 thanks 13:56:46 #endmeeting