13:01:44 <jpena> #startmeeting rpm_packaging
13:01:44 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:48 <openstack> The meeting name has been set to 'rpm_packaging'
13:01:48 <jpena> ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof, ykarel
13:02:05 <jpena> remember, the agenda is available at https://etherpad.openstack.org/p/openstack-rpm-packaging, and we can add last-minute items
13:05:00 <jruzicka> o/
13:05:45 <dirk> o/
13:05:45 <jpena> #chair jruzicka
13:05:46 <openstack> Current chairs: jpena jruzicka
13:05:49 <jpena> #chair dirk
13:05:49 <openstack> Current chairs: dirk jpena jruzicka
13:07:12 <ykarel> o/
13:07:17 <jpena> #chair ykarel
13:07:18 <openstack> Current chairs: dirk jpena jruzicka ykarel
13:07:59 <jpena> ok, let's start with the agenda
13:08:07 <jpena> #topic Fedora 28-based VM and 3rd party CI job
13:08:39 <jpena> We have completed the repo bootstrap, and now have a working 3rd party CI job using Fedora
13:08:51 <jpena> You can see it in action at https://review.openstack.org/570920, for example
13:09:08 <jpena> For now, the Fedora job will be non-voting, as we can expect some bumps
13:09:40 <jpena> once we move more content (services) to python3-only, we'll consider enabling votes for the job
13:10:56 <jpena> 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 <jpena> any doubts?
13:12:11 <jpena> #info Fedora-based 3rd party CI job now available, non-voting for now
13:15:06 <jpena> ok, let's go to the next item
13:15:13 <jpena> #topic doc package naming
13:15:25 <jpena> dirk, I think this is yours ^^
13:15:57 <dirk> jpena: sec
13:18:22 <dirk> jpena: the question was on the -doc package nameing. we have currently sometimes python-$foo-doc and sometimes {{ py2name() }}-$foo-doc
13:18:35 <dirk> I think python-$foo-doc should be the better thing (currently both expands to the same thing though)
13:18:45 <dirk> do we want to align the existing reviews / specs on one or the other?
13:19:39 <jpena> I like python-$foo-doc (looks more explicit to me)
13:21:00 <jpena> ykarel, jruzicka: any preference?
13:21:52 <ykarel_> jpena, python-$foo-doc looks fine to me
13:22:41 <dirk> sounds we're in agreement. thanks :)
13:23:10 <jruzicka> if it's the same thing, pyton-$foo-doc is more readable
13:23:34 <jpena> #agreed use python-$foo-doc for documentation packages
13:23:42 <jpena> ok, let's move on
13:23:48 <jpena> #topic Reviews
13:24:22 <jpena> 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 <jpena> I have a specific doubt about the pycadf review: https://review.openstack.org/570886
13:25:13 <jpena> 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 <jpena> 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 <jpena> is there any better solution?
13:27:21 <dirk> I don't have an answer to this
13:27:40 <dirk> we could do -common or we coud do update-alternatives (which makes less sense here I think)
13:27:50 <dirk> I'll research this after my meeting marathon
13:28:08 <jpena> ok, thanks :)
13:28:12 <dirk> added it to my review queue
13:28:36 <jpena> any other review we'd like to get attention to?
13:28:47 <dirk> 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 <dirk> https://review.openstack.org/#/c/568850/
13:29:25 <ykarel> jpena, using python-pycadf-common create issues?
13:29:53 <jpena> ykarel: yes, the singlespec macros tried to convert it into python2-pycadf-common and python3-pycadf-common
13:30:04 <ykarel> jpena with -n
13:30:11 <dirk> 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 <ykarel> singlespec ignores it
13:30:34 <jpena> ykarel: mmm let me try that, maybe I did it wrong the first time
13:30:45 <dirk> jpena: it does only for requires:/provides:/conflicts:
13:30:51 <dirk> so you have to unexpand it via
13:30:55 <dirk> %global oldpython python
13:31:05 <dirk> Requires: %{oldpython}-pycadf-common
13:31:11 <dirk> then its not doing the magic replace
13:31:12 <jpena> ohh that was it
13:31:23 <jpena> dirk: I'll try that
13:31:26 <jpena> thanks!
13:31:39 <dirk> 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 <ykarel> ack
13:34:11 <jpena> dirk: I updated https://review.openstack.org/568850 with your comments
13:37:02 <dirk> jpena: thanks.. any idea what we do instead?
13:37:21 <dirk> 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 <dirk> the proper solution I guess would be to extract the lower-constraints.txt and add it as >= minimum
13:38:03 <jpena> dirk: maybe we could take lower-constraints, and update renderspec to convert its === into >=
13:38:40 <jruzicka> sounds doable
13:38:41 <dirk> yeah, originally we wanted to avoid downlaoding and extracting tarballs, but now renderspec does that anyway already
13:39:18 <dirk> so its a task to add this to renderspec. any volunteers?
13:39:30 <jruzicka> also very magical... that wouldn't produce consistent results as lower-constraints.txt changes
13:39:48 <dirk> well, lower-constraints.txt as part of the tarball, so it only changes when the code changes
13:39:57 <jruzicka> is it? oh...
13:40:25 <jruzicka> sounds a lot like what rdopkg does for reqcheck/query, I should volunteer I guess ;)
13:41:02 <dirk> I like when its not me who is volunteering ;)
13:41:08 <dirk> I volunteer for reviewing it
13:41:39 <jpena> #action jruzicka to adapt renderspec to the new requirements.txt situation
13:41:46 <jruzicka> aye
13:42:02 <jruzicka> what exactly is the goal here, to sum up?
13:42:54 <jpena> 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 <dirk> 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 <jruzicka> OK. should the old method be supported as well? howto select the one to use?
13:45:33 <jruzicka> should this be a new default or an explicit option?
13:48:08 <jpena> in the current renderspec it's an explicit option, so I expect it to remain the same
13:50:05 <jruzicka> OK, I'm on it once distroinfo shenanigans are complete ;)
13:50:52 <jruzicka> we'll discuss the details on first review :)
13:51:18 <jpena> cool, then it's time for the open floor
13:51:21 <jpena> #topic open floor
13:58:17 * dirk has nothing
13:58:21 <jpena> let's close, then
13:58:23 <jpena> #endmeeting