12:07:30 <jpena> #startmeeting rpm_packaging
12:07:31 <openstack> Meeting started Thu Jun  8 12:07:30 2017 UTC and is due to finish in 60 minutes.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:07:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:07:34 <openstack> The meeting name has been set to 'rpm_packaging'
12:07:38 <jpena> ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof
12:08:34 <jpena> The meeting agenda is available at https://etherpad.openstack.org/p/openstack-rpm-packaging , please feel free to add your topics
12:13:14 <cousin_luigi> Hello.
12:13:53 <jpena> #chair cousin_luigi
12:13:55 <openstack> Current chairs: cousin_luigi jpena
12:14:50 <cousin_luigi> Not sure how to add a topic to that:| So green.
12:15:43 <jpena> cousin_luigi: just add a line at https://etherpad.openstack.org/p/openstack-rpm-packaging
12:17:08 <cousin_luigi> jpena: Right above #startmeeting?
12:17:29 <jpena> cousin_luigi: no, look for the "Meeting June 8th" line, and add it to the agenda
12:17:40 <jpena> the lines above are general information
12:19:03 <cousin_luigi> jpena: Ouch. Right. Like I said, I'm a newbie and I have a splitting headache to boot.
12:19:16 <jpena> no prob :)
12:19:34 <jpena> ok, let's start with the agenda
12:19:44 <jpena> #topic Building from master vs tagged releases
12:20:39 <jpena> I have a question here, specially for disk and toabctl. We are becoming inconsistent in what we build: most of the time we build packages from tagged releases, but in some cases (first on stable releases and now also on master) we are building from master
12:21:13 <jpena> I'm fine with both, but we should propose some guidelines, so we can be consistent and avoid package build issues
12:26:24 <dirk> jpena: I guess 'disk' means me
12:26:31 <jpena> oops
12:26:40 <dirk> jpena: thats a good topic
12:26:49 <dirk> here's what I think the current state of affairs is:
12:27:08 <dirk> a) for everything in a dvsm gate job installed from pip, we package the pip version from pypi.org
12:27:33 <dirk> b) for everything in a dvsm gate job that is installed from git, we package the tarballs..../project/project-$branch.tar.gz
12:27:43 <dirk> does that match your expectation?
12:28:37 <dirk> the underlying rationale is that we're packaging what is tested successfully together upstream
12:28:55 <jpena> dirk: ok, that makes sense to me
12:29:08 <dirk> b) mostly means the services (e.g. nova,glance,cinder,mistral,keystone..) are coming from -master.tar.gz
12:29:18 <dirk> and everything else python-* and clients etc from the releases
12:30:03 <dirk> to be honest I'm not perfectly happy about that, because this way changes sneak in that we don't see in the CI
12:30:29 <dirk> like the keystone problem.. some new dependency got merged, that is not in the spec.j2 template, so a rebuild of the package fails
12:30:54 <dirk> and the suse ci always does a full rebuild (with some optimisations), so then "unrelated" changes are getting a -1 vote
12:31:00 <dirk> I don't have a good solution for that problem atm though
12:32:13 <jpena> when tracking master, the RDO CI rebuilds the package with every new commit, so we should be able to catch those
12:32:32 <jpena> that's what we do for RDO Trunk packages
12:33:46 <dirk> jpena:  the missing bit is someone fixing those issues :)
12:33:57 <dirk> like e.g. mistral right now.. its been breaking every change the last two weeks
12:34:10 <dirk> hopefully the current patch series solves that issue
12:34:17 <jpena> it's more notifying (I forget to check from time to time), but I can fix that
12:34:46 <dirk> jpena: the plan b would be that we don't package daily git of the services but the releases
12:35:00 <dirk> for many projects I don't see releases that would work against the latest oslo releases
12:35:04 <dirk> so it's a bit of an issue right now
12:35:19 <dirk> hopefully when the pike releases are being started we could be using that instead
12:36:25 <dirk> jpena: record the current state as #agreed ?
12:36:41 <jpena> ok
12:37:35 <jpena> #agreed package oslo projects, clients, and everything installed from pip in a dvsm gate from tagged release, everything else from branch (master or stable)
12:38:17 <jpena> let's move on to the next topic
12:38:50 <jpena> #topic Status of singlespec in openSUSE
12:39:34 <jpena> cousin_luigi: ^^
12:39:37 <cousin_luigi> In that regard, I'd like to know if the Provides: python2-module workaround that was talked about on the 18th is going to be implemented in time for 42.3.
12:39:44 <cousin_luigi> Or any other solution.
12:42:20 <dirk> just to add context, cousin_luigi is asking for a Provides python2-$foo = $version in every spec for master and stable/ocata
12:42:49 <dirk> unless we choose to adopt the openSUSE singlespec approach also for rpm-packaging (which I have no strong opinion about)
12:42:57 <jpena> I created https://review.openstack.org/465971 last time we discussed this
12:43:20 <dirk> right, and I had a brain coredump when trying to understand it
12:43:31 <dirk> how can we achieve above with the macro? can you make an example?
12:43:56 <jpena> sure, if we do the following:
12:44:00 <jpena> %package -n python2-%{srcname} Summary: %{sum} %{?python_provide:%python_provide python2-%{srcname}}
12:44:13 <jpena> nope, let me paste it
12:44:41 <jpena> http://paste.openstack.org/show/611894/
12:44:53 <jpena> with that, we are defining package python2-xyz
12:45:03 <jpena> and the %python_provide macro will also create
12:45:15 <jpena> Provides: python-xyz = %{version}-%${release}
12:45:31 <jpena> Obsoletes: python-xyz < %{version}-%{release}
12:56:13 <dirk> jpena: ah, nice
12:56:16 <dirk> jpena: that works for me
12:56:31 <dirk> cousin_luigi: jpena: can you paste a review that makes use of it?
12:56:50 <jpena> dirk: ok, I'll do it
12:56:56 <cousin_luigi> Thanks:)
12:57:29 <jpena> we're almost out of time, so...
12:57:32 <jpena> #topic open floor
12:57:38 <dirk> jpena: thanks!
12:57:48 <jpena> anything else?
12:58:07 <dirk> jpena: not from me
12:58:12 <dirk> and we're running out of time
12:58:13 <cousin_luigi> Neither.
12:58:47 <jpena> let's end the meeting, then
12:58:50 <jpena> #endmeeting