13:01:44 #startmeeting rpm_packaging 13:01:44 Meeting started Wed May 30 13:01:44 2018 UTC and is due to finish in 60 minutes. The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:48 The meeting name has been set to 'rpm_packaging' 13:01:48 ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof, ykarel 13:02:05 remember, the agenda is available at https://etherpad.openstack.org/p/openstack-rpm-packaging, and we can add last-minute items 13:05:00 o/ 13:05:45 o/ 13:05:45 #chair jruzicka 13:05:46 Current chairs: jpena jruzicka 13:05:49 #chair dirk 13:05:49 Current chairs: dirk jpena jruzicka 13:07:12 o/ 13:07:17 #chair ykarel 13:07:18 Current chairs: dirk jpena jruzicka ykarel 13:07:59 ok, let's start with the agenda 13:08:07 #topic Fedora 28-based VM and 3rd party CI job 13:08:39 We have completed the repo bootstrap, and now have a working 3rd party CI job using Fedora 13:08:51 You can see it in action at https://review.openstack.org/570920, for example 13:09:08 For now, the Fedora job will be non-voting, as we can expect some bumps 13:09:40 once we move more content (services) to python3-only, we'll consider enabling votes for the job 13:10:56 some packages (Horizon and derivatives) are failing, due to the django situation in Fedora, but we're not worried about it for now 13:11:13 any doubts? 13:12:11 #info Fedora-based 3rd party CI job now available, non-voting for now 13:15:06 ok, let's go to the next item 13:15:13 #topic doc package naming 13:15:25 dirk, I think this is yours ^^ 13:15:57 jpena: sec 13:18:22 jpena: the question was on the -doc package nameing. we have currently sometimes python-$foo-doc and sometimes {{ py2name() }}-$foo-doc 13:18:35 I think python-$foo-doc should be the better thing (currently both expands to the same thing though) 13:18:45 do we want to align the existing reviews / specs on one or the other? 13:19:39 I like python-$foo-doc (looks more explicit to me) 13:21:00 ykarel, jruzicka: any preference? 13:21:52 jpena, python-$foo-doc looks fine to me 13:22:41 sounds we're in agreement. thanks :) 13:23:10 if it's the same thing, pyton-$foo-doc is more readable 13:23:34 #agreed use python-$foo-doc for documentation packages 13:23:42 ok, let's move on 13:23:48 #topic Reviews 13:24:22 ykarel and I have proposed several reviews to enable python3 in packages: https://review.openstack.org/#/q/status:open+project:openstack/rpm-packaging+branch:master+topic:enable-py3 13:24:40 I have a specific doubt about the pycadf review: https://review.openstack.org/570886 13:25:13 there are several config files located under /etc, and when moving to singlespec we had a conflict, since they were present in both the python2 and python3 subpackages 13:25:42 as a solution, I have created a pycadf-common package with them (it could not be python-pycadf-common because the singlespec macros would mess with it) 13:25:51 is there any better solution? 13:27:21 I don't have an answer to this 13:27:40 we could do -common or we coud do update-alternatives (which makes less sense here I think) 13:27:50 I'll research this after my meeting marathon 13:28:08 ok, thanks :) 13:28:12 added it to my review queue 13:28:36 any other review we'd like to get attention to? 13:28:47 thakns for all the work on this, I'll try to get anothe rpass at reviews (and making sure the CI is passing on it) 13:29:25 https://review.openstack.org/#/c/568850/ 13:29:25 jpena, using python-pycadf-common create issues? 13:29:53 ykarel: yes, the singlespec macros tried to convert it into python2-pycadf-common and python3-pycadf-common 13:30:04 jpena with -n 13:30:11 jpena: for the singlespec macros mess, its usually something like defining a macro that expands to "python" and use the macro to avoid the magic autoreplace 13:30:14 singlespec ignores it 13:30:34 ykarel: mmm let me try that, maybe I did it wrong the first time 13:30:45 jpena: it does only for requires:/provides:/conflicts: 13:30:51 so you have to unexpand it via 13:30:55 %global oldpython python 13:31:05 Requires: %{oldpython}-pycadf-common 13:31:11 then its not doing the magic replace 13:31:12 ohh that was it 13:31:23 dirk: I'll try that 13:31:26 thanks! 13:31:39 and, yes, it was confusing the hell out of me as well when I saw that the first time (until I understood why that is..) 13:31:40 ack 13:34:11 dirk: I updated https://review.openstack.org/568850 with your comments 13:37:02 jpena: thanks.. any idea what we do instead? 13:37:21 I think it will break various bits in the suse ci that I need to adjust first (we're pulling in the requirements file for >= generation) 13:38:00 the proper solution I guess would be to extract the lower-constraints.txt and add it as >= minimum 13:38:03 dirk: maybe we could take lower-constraints, and update renderspec to convert its === into >= 13:38:40 sounds doable 13:38:41 yeah, originally we wanted to avoid downlaoding and extracting tarballs, but now renderspec does that anyway already 13:39:18 so its a task to add this to renderspec. any volunteers? 13:39:30 also very magical... that wouldn't produce consistent results as lower-constraints.txt changes 13:39:48 well, lower-constraints.txt as part of the tarball, so it only changes when the code changes 13:39:57 is it? oh... 13:40:25 sounds a lot like what rdopkg does for reqcheck/query, I should volunteer I guess ;) 13:41:02 I like when its not me who is volunteering ;) 13:41:08 I volunteer for reviewing it 13:41:39 #action jruzicka to adapt renderspec to the new requirements.txt situation 13:41:46 aye 13:42:02 what exactly is the goal here, to sum up? 13:42:54 be able to define the minimum required versions of a package in renderspec using the lower-constraints.txt file from the tarball (maybe requirements.txt?), just like we do today with global-requirements.txt 13:43:05 goal is to have a new option/new behavior in renderspec to automatically extract the requirements not based on requirements.txt in rpm-packaging anymore but based on the tarball-embedded lower-constraints.txt 13:45:21 OK. should the old method be supported as well? howto select the one to use? 13:45:33 should this be a new default or an explicit option? 13:48:08 in the current renderspec it's an explicit option, so I expect it to remain the same 13:50:05 OK, I'm on it once distroinfo shenanigans are complete ;) 13:50:52 we'll discuss the details on first review :) 13:51:18 cool, then it's time for the open floor 13:51:21 #topic open floor 13:58:17 * dirk has nothing 13:58:21 let's close, then 13:58:23 #endmeeting