13:01:06 <jruzicka> #startmeeting rpm_packaging
13:01:07 <openstack> Meeting started Thu Aug  4 13:01:06 2016 UTC and is due to finish in 60 minutes.  The chair is jruzicka. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:11 <openstack> The meeting name has been set to 'rpm_packaging'
13:01:16 <astsmtl> Hi.
13:01:17 <toabctl> hi
13:01:20 <IgorYozhikov> hi folks, nice to see you all, just get back from vacations
13:01:22 <jruzicka> o/
13:01:40 <toabctl> I think dirk is on a conference
13:01:41 <mivanov> hi
13:02:10 <jruzicka> #chair IgorYozhikov astsmtl toabctl mivanov
13:02:11 <openstack> Current chairs: IgorYozhikov astsmtl jruzicka mivanov toabctl
13:02:40 * toabctl is sick and may not stay the whole meeting
13:02:44 <jpena> o/
13:03:33 <toabctl> jruzicka, do you want to lead the meeting?
13:03:51 <toabctl> or anybody else?
13:04:00 <jruzicka> toabctl, I rember volutneering
13:04:24 <jruzicka> please insert any interesting items into agenda if you have any
13:04:29 <jruzicka> https://etherpad.openstack.org/p/openstack-rpm-packaging
13:04:40 <IgorYozhikov> toabctl,I could lead it next time, just get back and collecting news and everything i missed :)
13:04:53 <jruzicka> #topic how to unit test https://review.openstack.org/#/c/347447/
13:05:11 <jruzicka> let's see if topics show up while I stall with this :)
13:05:37 <jruzicka> thing is... that code renders templates into blocks so I wonder howto unit test it without being dependent on the specific substitutions
13:05:44 <jruzicka> as those are subject to change
13:06:30 <jruzicka> IOW howto make the unit test in a way they don't need to be changed each time the distro specific template ({fedora,suse}.spec.j2) is changed?
13:08:06 * toabctl needs to look into that again
13:08:41 <jruzicka> yeah, it's more like a poke so that someone looks at it :)
13:08:47 <jruzicka> in related news
13:09:11 <jruzicka> #topic ordering of (Build)Requires
13:10:05 <jruzicka> Currently, we are forced to manually sort the requires in .spec because spec-cleaner requires it, is that correct?
13:10:11 <jruzicka> *in .spec.j2
13:10:17 <IgorYozhikov> jruzicka, does it mean that you proposition for block build_requires will autoadd predefined values from dist-templates/*?
13:10:38 <IgorYozhikov> sorry I'm about 1st topic
13:10:39 <toabctl> jruzicka, yes. spec-cleaner forces the sort currently
13:10:53 <jpena> jruzicka: yep, I found out today :)
13:11:01 <jruzicka> IgorYozhikov, block isn't powerful enough to solve that :) I'm cooking another patch to post-process the build-requires
13:12:07 <jruzicka> so we prefer to sort the requires logically
13:12:45 * toabctl is not sure if spec-cleaner is the best solution
13:13:03 <jruzicka> Sorting becomes kinda hard since the translated package names might differ to the project names
13:13:29 <jruzicka> So I suggest we allow any order and let renderspec order them, what do you think?
13:13:46 <IgorYozhikov> jruzicka, I just got thought - you could use blocks and just fill it with list of {block} py2pkg('..'),py2pkg('...') {endblock}-> it which will render like BuildRequires: translated-package-name
13:14:32 <IgorYozhikov> jruzicka, using sort as in requirements makes maintenance easier
13:14:36 <jruzicka> IgorYozhikov, note that there can be only one block but multiple block of requirements. amongs other things
13:14:48 <toabctl> jruzicka, for reviews I like things in order even in the spec.j2 templates
13:15:10 <jruzicka> IgorYozhikov, after thinking about it, solving the sorting via postprocessing is easiest
13:15:36 <jruzicka> toabctl, well yeah, it makes sense that you want to apply same rules as for .spec :)
13:16:04 <jruzicka> bad luck number80 is on flock
13:16:37 <jpena> why not both? I mean, let's enforce order for the py2pkg name in the jinja template, then let renderspec render them in the right order
13:16:58 <jpena> the current status could lead to trial and error
13:17:04 <jruzicka> jpena to save the day with the most complicated solution :D
13:17:07 <jruzicka> but yeah
13:17:30 <jruzicka> I personally prefer to group the requires logically
13:17:49 * toabctl has to leave. pardon
13:18:20 <IgorYozhikov> jruzicka, if you will pull all reqs inside blocks - might be easier to process ans sort values inside blocks?
13:18:36 <IgorYozhikov> s/ans/and/
13:18:39 <jruzicka> IgorYozhikov, that's not how they work.
13:19:03 <jruzicka> they don't allow post-processing, just inheritance
13:19:42 <IgorYozhikov> i c
13:20:30 <jruzicka> IgorYozhikov, either a macro (which would change the structure drasticly) or a simple post-processing in renderspec...
13:20:32 <IgorYozhikov> so, what are cons or pros for logical || alphabetical ordering?
13:21:09 <jruzicka> let's postpone this to a time when more people can express their opinion
13:22:39 <IgorYozhikov> just my opinion here:  since we are updating template manually - it is easier to track changes if reqs recorded almost in the same manner as in requirements file.
13:22:56 <IgorYozhikov> anyway, jruzicka , agree, let's wait here :)
13:23:21 <jruzicka> IgorYozhikov, yeah, I also prefer to have them in the same order as requirements.txt
13:23:42 <jruzicka> with the extra few of our special fedora-ish deps on top
13:23:51 <jruzicka> forced alphabetical order would break that
13:24:21 <IgorYozhikov> I'm just add non python stuff like zip or libs in the bottom of the reqs list
13:24:43 <IgorYozhikov> after all py2pkg()
13:24:58 <jruzicka> yeah, for example
13:25:11 <jruzicka> #topic reviews
13:26:05 <jruzicka> if you have some priority reviews you'd like to point to, here's your chance
13:26:58 <IgorYozhikov> astsmtl, mivanov, toabctl do you have anything 4 review?
13:27:55 <IgorYozhikov> might be this one - https://review.openstack.org/#/c/336151/
13:28:20 <jruzicka> that needs discussion, so also postponed till next time
13:28:25 <IgorYozhikov> dirk, commented it with - need discussion
13:28:27 <IgorYozhikov> ok
13:28:53 <jruzicka> because there seems to be too few people to discuss ATM :)
13:29:25 <IgorYozhikov> i c
13:29:48 <jruzicka> and so...
13:29:50 <jruzicka> #endmeeting