13:01:04 #startmeeting rpm_packaging 13:01:05 Meeting started Thu Aug 25 13:01:04 2016 UTC and is due to finish in 60 minutes. The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:09 The meeting name has been set to 'rpm_packaging' 13:01:13 #topic roll call 13:01:15 o/ 13:01:17 o/ 13:01:35 hi 13:01:43 #chair IgorYozhikov jpena toabctl jruzicka 13:01:44 Current chairs: IgorYozhikov jpena jruzicka number80 toabctl 13:01:49 agenda is here 13:01:52 https://etherpad.openstack.org/p/openstack-rpm-packaging 13:02:29 o/ 13:02:30 let's start 13:02:42 #topic python3/renderspec 13:03:17 IgorYozhikov: ? 13:03:49 number80, I wrote my thoughts and want to discuss them 13:04:13 https://etherpad.openstack.org/p/openstack-rpm-packaging-python3-renderspec 13:04:57 We can discuss topics from etherpad 1 by 1 13:05:05 yeah please go on 13:05:13 I don't have enough context to just answer inline 13:05:51 Having done a fair amount of python3 packaging, I think this is something that could be fully automated 13:06:10 the only blocker is that we have no good rpm spec file parser 13:06:31 jruzicka, dirk 2 weeks ago informed us about possibility of py3 usage in openstack starting from O release 13:06:56 number80, what for? 13:07:38 rdopkg has some codez to modify .spec, spec-cleaner also parses it 13:07:40 jruzicka: you need to be able to manipulate concepts like subpackages and stuff 13:07:49 no parser does that 13:07:51 oh, so a real parser 13:07:55 yes 13:07:57 not a piece of hacked crap 13:08:17 number80, we could go the other way and regenerate the spec always from a template. then you don't need a parser 13:08:22 if you look AIO packages, it basically duplicating subpackages 13:09:09 toabctl: we'd still need that, we have this requirement of one source == one package 13:09:18 *source package 13:09:43 I'm quite unsure howto proceed here 13:09:47 it ensures that you don't package different versions of same sources 13:09:59 toabctl wants to implement {{ requires }} macro to generate all 13:10:12 and handle irregularities with override configs 13:10:21 that would work for me 13:10:35 that's my current pain point when I need to update packages... 13:10:38 problem is howto distribute deps between subpackages 13:10:50 jruzicka, this requires macro - what will it do? 13:10:59 jruzicka, with a config file (could be a global one and then, if needed, one per spec) 13:11:03 and howto corretly override projects that don't follow conventions and all the special cases 13:11:32 jruzicka, the good thing in openstack is that there are not so much special cases. if we get 90% automated we did a huge step forward imo 13:11:36 IgorYozhikov, basically generate {Build,}Requires from tarball 13:11:51 from req and test-reqs? 13:11:52 I think it works fine for oslo libs and clients 13:12:04 toabctl, agreed but I still think supporting mixed approach between full automation and what we have now 13:12:06 but services will not work with that macros due to splitting 13:12:22 yep. 13:12:35 but if we can first automate oslo + clients that would be imo reat 13:12:41 but well, it doesn't hurt having such macro and use it when it makes sense 13:12:43 jruzicka, btw I started this morning https://github.com/toabctl/metaextract 13:12:50 jruzicka, toabctl if you remember I showed you auto-generation from reqs files 13:13:11 a couple of months ago 13:13:15 number80, yeah I'm all for that, just not sure that we want to have only that macro and oboslete current way 13:13:35 IOW I'd rather have the extra metadata about special cases directly in the .spec.j2 13:13:48 as opposed to some magical config for the {{ requires }} macro(s) 13:13:49 and we use py3 in our version of renderspec-deb 13:14:02 jruzicka, fine for me 13:14:18 IgorYozhikov, you mean renderspec runs on py3 or it creates py2 specs? 13:14:44 IgorYozhikov, wait you have a tool to convert the .spec to .deb? :D 13:14:48 IgorYozhikov, not all projects use req-files. some use setup.cfg to define requirements and extras_require 13:15:00 toabctl, yep runs on py3 13:15:18 and created deb/controls for both py2 and py3 13:15:26 IgorYozhikov, I think renderspec is able to run with py3, too. and if not it should be easy to fix it. 13:15:29 ah.ok 13:15:54 is it somewhere public? 13:16:05 toabctl I believe has access 13:16:11 let me check 13:16:28 https://review.fuel-infra.org/gitweb?p=packaging%2Frenderspec-deb.git;a=summary 13:16:37 jruzicka, ^^^^^ 13:17:03 Not Found 13:17:05 for me 13:17:07 yep 13:17:17 you need login 1st 13:17:21 anyway, I'm just glad to know such thing exists 13:17:24 anyway - should we go back to the etherpad points? 13:17:27 yes 13:17:28 let's continue 13:17:50 #topic mock hardcoded options for tmpfs 13:17:52 IgorYozhikov: ? 13:17:55 ye 13:18:31 I found that hard coded self.optArgs = ['-o', 'nr_inodes=0'] doesn't work on u16.04 13:18:46 mount -t tmpfs -o mode=0755 -o nr_inodes=0 -o size=1g mock_chroot_tmpfs /mnt/ 13:18:46 mount: wrong fs type, bad option, bad superblock on mock_chroot_tmpfs, 13:18:46 missing codepage or helper program, or other error 13:19:09 this is not critical but very annoying 13:19:38 code here https://git.fedorahosted.org/cgit/mock.git/commit/?h=mock-1.2.14&id=de710c5b7d3a4e563c372a796f5305fa9cf17241 13:20:02 IgorYozhikov: I think you can submit a patch to msuchy to allow mock usage on other distros 13:20:21 not sure this is relevant to that meeting but we can discuss this 13:20:40 ok 13:21:12 let's move to the next topic 13:21:34 yes 13:21:39 #topic reviews: pymod2pkg 13:21:45 https://review.openstack.org/#/q/project:openstack/pymod2pkg+status:open 13:21:56 (None) 13:22:05 we cleaned up the queue, toabctl has submitted a new release 13:22:06 has anybody requested a new release? 13:22:12 I didn't 13:22:27 toabctl: ok, I'll take care of that then 13:22:33 number80, ok. thx 13:22:40 #action number80 request a new pymod2pkg release 13:23:01 #topic reviews: renderspec 13:23:03 https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:23:14 any comments? 13:23:36 https://review.openstack.org/#/c/357733/ 13:23:42 first one still needs discussion :) 13:23:44 looking 13:24:25 https://github.com/openstack/rpm-packaging/blob/master/openstack/python-neutronclient/python-neutronclient.spec.j2 13:24:39 yeah, just giving a change to allow people to push for specific stalled reviews 13:24:42 IgorYozhikov: ? 13:25:11 (spec reviews are next, I left it explicitly at the end, since it's biggest chunk) 13:25:19 v 5.0.0 13:25:20 Error: No Package found for python-neutronclient >= 5.1.0 13:25:45 number80, nothing to discuss in renderspec, go on 13:25:49 number80, we need to update used as dependencies py*clients 1st 13:26:04 #topic reviews: specs 13:26:15 https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open 13:26:22 I would abandon both renderspec review tbh 13:26:40 toabctl, me too :) 13:27:06 but we can leave them a little longer, wait for dirk... dunno 13:27:18 toabctl: we need to have a timeout policy for reviews 13:27:24 yeah 13:27:31 for both - dirk and timeout 13:27:43 let's discuss the spec reviews 13:27:48 yep 13:28:02 toabctl, as I remember it there are no any movements for 2 weeks - core can merge with 1 +2 13:28:08 IgorYozhikov, what's the problem with neutronclient other then a spec.j2 update is needed? 13:28:20 IgorYozhikov, for which review? 13:28:35 yes, I agree that we just need to update neutronclient 13:29:00 there are plenty of updates needed - see http://toabctl.de/openstack/rpm-packaging-status-newton.html 13:29:21 IgorYozhikov, so which one has no progress that you want to merge? 13:30:01 toabctl, not now - I'm about policy, we discussed it more them half year ago 13:30:14 s/them/than/ 13:30:41 IgorYozhikov, yeah. I'm still fine with that policy. but in my experience we usually response in 2 weeks at least on irc. 13:31:35 ok, getting back to updates. about py*clients, please do not be swift with update of openstackclient 13:31:54 I faced issue - https://bugs.launchpad.net/python-openstackclient/+bug/1615988 13:31:54 Launchpad bug 1615988 in python-openstackclient "[osclient v3.x.x]Default auth type is not detected in case when os-token and os-url is used " [High,In progress] - Assigned to Dean Troyer (dtroyer) 13:32:19 IgorYozhikov, please add these kind of comments to the corresponding review. that's much easier :-) 13:32:22 2.6.0 - latest working one 13:32:46 IgorYozhikov, btw we don't even have openstackclient in git iirc 13:33:02 toabctl, i c 13:33:11 it's https://review.openstack.org/#/c/357733/ 13:33:28 IgorYozhikov: I added a -W until we update neutronclient 13:33:46 number80, I saw, thanks 13:34:13 I think we can merge https://review.openstack.org/#/c/279477/ 13:34:13 ok, any specific review, you want to mention? 13:34:26 https://review.openstack.org/#/c/358816/ 13:34:37 dirk made comment about sphinx 13:35:06 does it means that we need to propose a patch to cliff directly? 13:35:57 and it is also mentioned here https://github.com/openstack/requirements/blob/master/global-requirements.txt#L351 13:36:09 sphinx>=1.2.1,!=1.3b1,<1.3 # BSD 13:36:34 * toabctl wonders what's special about cliff here...hm 13:37:16 toabctl bugs :) 13:37:20 special bugs I mean 13:37:27 or I missed something 13:37:33 especially in 1.3b1 13:37:35 jruzicka, :) 13:37:35 :D 13:38:38 I'd see a history of that line and how it got there 13:39:31 jruzicka, I think the problem was pbr and the doc build feature. i tried to fix that month ago but the patch was not accepted iirc 13:39:38 I don't get why we need to patch cliff 13:40:01 number80, I think we should try to get rid of the < 1.3. 13:40:21 in the SUSE CI I think we use a newer version of sphinx. I wonder why that works with other packages... 13:40:22 toabctl: yes, but should happen in global-requirements 13:40:28 number80, yes 13:40:57 oh. pbr supports now sphinx 1.4 13:41:01 https://review.openstack.org/#/c/229951/ 13:41:02 toabctl: for now, can't we just fix our copy of requirements? 13:41:29 number80, hm. that should work I guess 13:42:54 number80, you r now about - https://github.com/openstack/rpm-packaging/blob/master/global-requirements.txt right? 13:43:34 IgorYozhikov: yes, I think we should temporarily override it (with a comment) 13:44:12 number80, looks like it should work 13:44:14 toabctl: please add me as a reviewer for the g-r review, we should hurry to have this change accepted in newton 13:44:28 number80, the sphinx thing? 13:44:38 yes, we'll be freezing things soon 13:44:49 number80, yeah. 13:44:55 yey 13:46:04 #action toabctl to override sphinx upper bound in rpm packaging g-r copy :) 13:46:14 let's move on as everyone agreed on that 13:46:25 well - IgorYozhikov - could you just add this to your changeset for cliff to see if that works? 13:46:26 any other specific review to peek on? 13:48:04 toabctl, what exactly do you want to be add? 13:48:26 IgorYozhikov, remove the <1.3 from Sphinx in out global-requirements.txt copy. 13:49:04 oh, ok, will propose PR soon 13:49:05 I'd prefer a separate changeset as it's easier to grep it in git log 13:49:19 but that personal pref 13:49:20 number80, ok 13:49:38 then the cliff one can depend on the requirements one 13:49:40 fine for me 13:49:49 number80, I can do it for test and remove after without merge 13:50:02 IgorYozhikov, we can add a DependsOn: line 13:50:03 toabctl: yes, we should use more special keywords! 13:50:28 ok 13:51:34 next? 13:51:50 https://review.openstack.org/#/c/343335/ 13:52:45 looks like hanging too much time :0 13:52:57 dirk has arguments, so I'm fine with keeping the discussion open 13:53:12 iirc we had that last week and wanted to wait for dirk. not sure 13:53:42 let's revisit this next week, and if no strong opposition, we can merge it 13:53:49 so let's wait 4 dirk with this 13:53:51 ok 13:53:53 yes 13:54:09 funny, problems with cliff are now discussed independently on two channels I am on :) 13:56:23 we have 4 min to go, anything else? 13:56:26 I suggest that we close the meeting as we're reaching the hour 13:56:57 yes 13:56:59 anyway, we're all on #openstack-rpm-packaging if we need to discuss specific item 13:57:08 thank you gentlemen for attending 13:57:15 #endmeeting