13:31:21 <jpena> #startmeeting rpm_packaging
13:31:22 <openstack> Meeting started Thu Oct 15 13:31:21 2020 UTC and is due to finish in 60 minutes.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:31:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:31:25 <openstack> The meeting name has been set to 'rpm_packaging'
13:31:25 <jpena> ping toabctl, dirk, apevec, jpena, number80, kaslcrof,  rha, hberaud, sboyron
13:31:28 <jpena> #topic roll call
13:31:40 <jpena> Remember to add any last-minute topic to the agenda at https://etherpad.opendev.org/p/openstack-rpm-packaging
13:31:44 <hberaud> o/
13:32:34 <jpena> #chair hberaud
13:32:35 <openstack> Current chairs: hberaud jpena
13:35:36 <hberaud> how are you?
13:36:52 <sboyron> o/
13:37:49 <jpena> #chair sboyron
13:37:50 <openstack> Current chairs: hberaud jpena sboyron
13:37:57 <jpena> hberaud: doing well, can't complain :)
13:38:20 <hberaud> it's a good start
13:38:25 <hberaud> :)
13:38:45 <jpena> we don't have a lot in the agenda, so we're going straight to open floor
13:38:47 <jpena> #topic open floor
13:38:53 <jpena> Anything to discuss?
13:39:19 <apevec> jpena, I missed who is PTL now :)
13:39:21 <hberaud> nothing on my side
13:39:42 <jpena> apevec: we're a SIG rather than an official project, so there's no PTL
13:39:52 <jpena> we can have one or many chairs
13:39:54 <apevec> ah cool
13:39:56 <jpena> which reminds me
13:40:16 <jpena> I'm currently the only listed chair, if anyone else wants to join just raise your hand
13:40:43 <apevec> do you have a link to the SIG process docs?
13:40:46 <sboyron> I've got a point to discuss
13:42:13 <jpena> apevec: https://governance.openstack.org/sigs/
13:42:24 <jpena> sboyron: go ahead, the stage is yours
13:42:27 <apevec> thanks jpena++
13:42:41 <sboyron> I would like to talk quickly about https://review.opendev.org/#/c/756383/, hbereaud seems taking a lot of time working on a tool to be used locally during dev or in CI to check dependencies and ensuring we do not miss any dependencies in .spec to avoid relying on packages deps to work
13:42:49 <sboyron> *hberaud
13:43:43 <apevec> oh we have rdopkg reqcheck
13:43:55 <hberaud> sboyron: thanks for all your useful comments on :)
13:44:03 <apevec> also Fedora py pkgs now all autogenerates deps
13:44:33 <hberaud> yep it could be a way to follow here too
13:44:47 <sboyron> oh, thx for the info apevec
13:45:02 <jpena> I'll have a look at the review, it escaped from my radar
13:45:06 <apevec> I'll add Joel to that review
13:45:18 <sboyron> maybe there is a way to mutualize the job done on it
13:45:21 <apevec> mostly he now maintaines rdopkg
13:45:30 <sboyron> ok
13:45:33 <hberaud> +1 to mutualize
13:45:36 <apevec> sboyron++ yes that
13:45:58 <hberaud> I don't want to reinvent the wheel
13:46:41 <apevec> esp. not squarer ones ;)
13:47:31 <hberaud> also I was thinking about a CI cron too automatically sync our spec to avoid to update version manually
13:47:40 <sboyron> apevec++ yep good one, thanks for pointing rdopkg
13:47:51 <hberaud> I need to deep dive on that
13:48:11 <apevec> amoralej, ^ do we have rdopkg reqcheck job now?
13:48:11 <sboyron> yep that's was my second point I intended to discuss hberaud thx
13:48:23 <hberaud> to observe how to setup zuul cron
13:48:33 <hberaud> or something like that
13:48:57 <amoralej> apevec, yes, but only to check status, not to automatically sync deps
13:49:09 <sboyron> I'v got a script which is reading output from https://toabctl.de/openstack/rpm-packaging-status-victoria.html and update version and proposee patch automatically
13:49:12 <jpena> I'm usually scared by the amount of corner cases that can break that kind of automated dep sync
13:49:50 <hberaud> spec file could be autogenerated by scanning projects their requirements in the right version
13:49:59 <sboyron> I am hesitating to commit it since I always have to perform several manual checks for now to ensure this is ok before pushing a new version
13:50:06 <hberaud> and we could only maintain a jinja template
13:50:12 <apevec> amoralej, a-ha so https://review.rdoproject.org/r/#/q/topic:victoria-branching+Requirement+Sync+for+Victoria are scripted?
13:50:24 <amoralej> nop
13:50:59 <amoralej> well, i'm not sure if jcapitao has some local script to help
13:51:05 <amoralej> but not as ci bot, i meant
13:51:40 <hberaud> openstack/release give us the version and update and all rest could be generated directly from projects repos
13:52:28 <hberaud> so we could abandon our "database" of version
13:54:00 <hberaud> to avoid to duplicate all package info in many places
14:08:27 <hberaud> anything else?
14:14:04 <sboyron> hberaud: I do not understand everything I think, what is your proposition, having a single jj2 file to trplace all .spec.jj2 files and generating everything from some config files and getting versions from openstack/release and rest from project repos ?
14:14:29 <hberaud> exactly
14:15:20 <hberaud> We could only maintain a single jinja file and extract the context from openstack/release + project sources
14:20:13 * hberaud school run
14:27:00 <sboyron> hberaud: my think is that in this type of config, we will have to maintain more than only that ... there is a lot of corner case.. I think we can automate more things, requirements, %files vs entrypoints, version bump etc ... but I am not sure we can automate absolutely everything
14:36:02 <jpena> oops, I didn't realize we had to end the meeting, sorry :o)
14:36:05 <jpena> #endmeeting