| *** gyee has quit IRC | 01:04 | |
| *** ykarel|away has joined #openstack-rpm-packaging | 01:29 | |
| *** ykarel|away is now known as ykarel | 01:31 | |
| openstackgerrit | zhangyc proposed openstack/rpm-packaging master: Remove setuotppls Requirement from karbor https://review.opendev.org/758310 | 02:12 |
|---|---|---|
| *** ykarel_ has joined #openstack-rpm-packaging | 04:12 | |
| *** ykarel has quit IRC | 04:14 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #openstack-rpm-packaging | 04:33 | |
| *** ykarel has joined #openstack-rpm-packaging | 04:49 | |
| *** ykarel_ has quit IRC | 04:51 | |
| *** ykarel has quit IRC | 05:13 | |
| *** sboyron has joined #openstack-rpm-packaging | 05:31 | |
| *** jaicaa has quit IRC | 06:00 | |
| *** jaicaa has joined #openstack-rpm-packaging | 06:02 | |
| *** amoralej|off is now known as amoralej | 06:10 | |
| *** ykarel has joined #openstack-rpm-packaging | 06:29 | |
| *** ykarel is now known as ykarel|afk | 07:10 | |
| *** ykarel|afk has quit IRC | 07:11 | |
| *** jpena|off is now known as jpena | 07:19 | |
| *** rpittau|afk is now known as rpittau | 07:22 | |
| *** apevec has joined #openstack-rpm-packaging | 07:37 | |
| *** sboyron has quit IRC | 11:15 | |
| *** sboyron has joined #openstack-rpm-packaging | 11:16 | |
| *** jpena is now known as jpena|lunch | 11:32 | |
| openstackgerrit | zhangyc proposed openstack/rpm-packaging master: Remove setuotppls Requirement from karbor https://review.opendev.org/758310 | 11:40 |
| *** amoralej is now known as amoralej|lunch | 12:10 | |
| *** jpena|lunch is now known as jpena | 12:32 | |
| *** amoralej|lunch is now known as amoralej | 12:59 | |
| *** ykarel has joined #openstack-rpm-packaging | 13:01 | |
| jpena | it's meeting time | 13:31 |
| jpena | #startmeeting rpm_packaging | 13:31 |
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:31 |
| *** openstack changes topic to " (Meeting topic: rpm_packaging)" | 13:31 | |
| openstack | The meeting name has been set to 'rpm_packaging' | 13:31 |
| jpena | ping toabctl, dirk, apevec, jpena, number80, kaslcrof, rha, hberaud, sboyron | 13:31 |
| jpena | #topic roll call | 13:31 |
| *** openstack changes topic to "roll call (Meeting topic: rpm_packaging)" | 13:31 | |
| jpena | Remember to add any last-minute topic to the agenda at https://etherpad.opendev.org/p/openstack-rpm-packaging | 13:31 |
| hberaud | o/ | 13:31 |
| jpena | #chair hberaud | 13:32 |
| openstack | Current chairs: hberaud jpena | 13:32 |
| hberaud | how are you? | 13:35 |
| sboyron | o/ | 13:36 |
| jpena | #chair sboyron | 13:37 |
| openstack | Current chairs: hberaud jpena sboyron | 13:37 |
| jpena | hberaud: doing well, can't complain :) | 13:37 |
| hberaud | it's a good start | 13:38 |
| hberaud | :) | 13:38 |
| jpena | we don't have a lot in the agenda, so we're going straight to open floor | 13:38 |
| jpena | #topic open floor | 13:38 |
| *** openstack changes topic to "open floor (Meeting topic: rpm_packaging)" | 13:38 | |
| jpena | Anything to discuss? | 13:38 |
| apevec | jpena, I missed who is PTL now :) | 13:39 |
| hberaud | nothing on my side | 13:39 |
| jpena | apevec: we're a SIG rather than an official project, so there's no PTL | 13:39 |
| jpena | we can have one or many chairs | 13:39 |
| apevec | ah cool | 13:39 |
| jpena | which reminds me | 13:39 |
| jpena | I'm currently the only listed chair, if anyone else wants to join just raise your hand | 13:40 |
| apevec | do you have a link to the SIG process docs? | 13:40 |
| sboyron | I've got a point to discuss | 13:40 |
| jpena | apevec: https://governance.openstack.org/sigs/ | 13:42 |
| jpena | sboyron: go ahead, the stage is yours | 13:42 |
| apevec | thanks jpena++ | 13:42 |
| 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 |
| sboyron | *hberaud | 13:42 |
| apevec | oh we have rdopkg reqcheck | 13:43 |
| hberaud | sboyron: thanks for all your useful comments on :) | 13:43 |
| apevec | also Fedora py pkgs now all autogenerates deps | 13:44 |
| hberaud | yep it could be a way to follow here too | 13:44 |
| sboyron | oh, thx for the info apevec | 13:44 |
| jpena | I'll have a look at the review, it escaped from my radar | 13:45 |
| apevec | I'll add Joel to that review | 13:45 |
| sboyron | maybe there is a way to mutualize the job done on it | 13:45 |
| apevec | mostly he now maintaines rdopkg | 13:45 |
| sboyron | ok | 13:45 |
| hberaud | +1 to mutualize | 13:45 |
| apevec | sboyron++ yes that | 13:45 |
| hberaud | I don't want to reinvent the wheel | 13:45 |
| apevec | esp. not squarer ones ;) | 13:46 |
| hberaud | also I was thinking about a CI cron too automatically sync our spec to avoid to update version manually | 13:47 |
| sboyron | apevec++ yep good one, thanks for pointing rdopkg | 13:47 |
| hberaud | I need to deep dive on that | 13:47 |
| apevec | amoralej, ^ do we have rdopkg reqcheck job now? | 13:48 |
| sboyron | yep that's was my second point I intended to discuss hberaud thx | 13:48 |
| hberaud | to observe how to setup zuul cron | 13:48 |
| hberaud | or something like that | 13:48 |
| amoralej | apevec, yes, but only to check status, not to automatically sync deps | 13:48 |
| 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 |
| jpena | I'm usually scared by the amount of corner cases that can break that kind of automated dep sync | 13:49 |
| hberaud | spec file could be autogenerated by scanning projects their requirements in the right version | 13:49 |
| 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:49 |
| hberaud | and we could only maintain a jinja template | 13:50 |
| apevec | amoralej, a-ha so https://review.rdoproject.org/r/#/q/topic:victoria-branching+Requirement+Sync+for+Victoria are scripted? | 13:50 |
| amoralej | nop | 13:50 |
| amoralej | well, i'm not sure if jcapitao has some local script to help | 13:50 |
| amoralej | but not as ci bot, i meant | 13:51 |
| hberaud | openstack/release give us the version and update and all rest could be generated directly from projects repos | 13:51 |
| hberaud | so we could abandon our "database" of version | 13:52 |
| hberaud | to avoid to duplicate all package info in many places | 13:54 |
| *** apevec has quit IRC | 14:05 | |
| *** apevec has joined #openstack-rpm-packaging | 14:05 | |
| hberaud | anything else? | 14:08 |
| 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 |
| hberaud | exactly | 14:14 |
| hberaud | We could only maintain a single jinja file and extract the context from openstack/release + project sources | 14:15 |
| * hberaud school run | 14:20 | |
| 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:27 |
| jpena | oops, I didn't realize we had to end the meeting, sorry :o) | 14:36 |
| jpena | #endmeeting | 14:36 |
| *** openstack changes topic to "https://etherpad.openstack.org/p/openstack-rpm-packaging - Regular IRC Meeting Thursdays 13:30 PM UTC in openstack-rpm-packaging" | 14:36 | |
| openstack | Meeting ended Thu Oct 15 14:36:05 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:36 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/rpm_packaging/2020/rpm_packaging.2020-10-15-13.31.html | 14:36 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/rpm_packaging/2020/rpm_packaging.2020-10-15-13.31.txt | 14:36 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/rpm_packaging/2020/rpm_packaging.2020-10-15-13.31.log.html | 14:36 |
| hberaud | sboyron: yep absolutely, some points will stay there, by example, specific file/dirs access rights to manage or also deactivated tests (for some reasons) and things like that, but the majority of the informations in specfile are duplicated, I think that the goal of this team is to handle these specific points, not to simply sync things, and this kind of path could help us to reduce our scope | 14:46 |
| sboyron | hberaud: yes I've got the point, you propose to templatize the whole structure. it could be worth I think | 14:51 |
| sboyron | hberaud: IIUC it will equire some descriptives file for each project ni yaml for example | 14:53 |
| hberaud | sboyron: and specific case (file access, etc...) could be stored in a local yaml structure as you already suggested previously | 14:53 |
| hberaud | yep exact | 14:53 |
| sboyron | I donnow yet all the bit and bytes of this projects, but this is the role of renderspec if I understand well, so this will imply a new major version of renderspec to generate these new specfiles | 14:54 |
| hberaud | sboyron: could be an intermediate layer between renderspec and there | 15:00 |
| hberaud | sboyron: to avoid to reinvent everything | 15:00 |
| hberaud | sboyron: a smooth test could be to start to create an experimental structure/branch and to iterate over it | 15:01 |
| hberaud | s/to create/by creating/ | 15:01 |
| hberaud | sboyron: keep the current behave and smoothly migrate from A to B | 15:03 |
| sboyron | hberaud: I think this should be discussed and defined maybe with more core teams, jpena, dirk, to define the global target before investing so much time on it ? But I'm in if you are motivated to start something | 15:03 |
| hberaud | sboyron: I don't know if we have blueprint here, but it could be a good starting point | 15:04 |
| hberaud | sboyron: blueprint a good entrypoint point to trigger specific discussions and design things | 15:05 |
| hberaud | sboyron: and take the temperature without wasting lot of time in a born dead code | 15:07 |
| hberaud | sboyron: example of blueprint => https://blueprints.launchpad.net/openstack/ | 15:08 |
| hberaud | sboyron: on oslo we use blueprint with our own specification repo => https://specs.openstack.org/openstack/oslo-specs/ | 15:09 |
| hberaud | sboyron: source repos > https://opendev.org/openstack/oslo-specs | 15:10 |
| sboyron | jpena: is there anyone for rpm-packaging ? | 15:11 |
| hberaud | sboyron: and how we manage our reviews on specifications => https://review.opendev.org/#/q/project:openstack/oslo-specs | 15:11 |
| jpena | we have not created any design specs, at least not that I can remember | 15:11 |
| openstackgerrit | Merged openstack/rpm-packaging stable/ussuri: openstackdocstheme: update to 2.0.2 https://review.opendev.org/757723 | 15:22 |
| *** gyee has joined #openstack-rpm-packaging | 15:39 | |
| *** rpittau is now known as rpittau|afk | 15:52 | |
| *** jpena is now known as jpena|off | 16:35 | |
| *** amoralej is now known as amoralej|off | 16:40 | |
| dirk | sboyron: hberaud: so far "specs" have been mostly discussed in wiki or etherpad and then implemented or at the summit sessions | 17:14 |
| dirk | the project has been pretty much on autopilot mode for the last couple of cycles however, so most of it isn't relevant anymore | 17:14 |
| dirk | if its okay, I wouldn't mind adding or extending the documentation in tree however | 17:15 |
| sboyron | dirk ok, thx for these informations, which etherpad are you talking about ? | 17:16 |
| hberaud | dirk: ack thx for info | 17:18 |
| dirk | sboyron: etherpad.openstack.org. we typically used the design summit namespaces for an etherpad then | 17:19 |
| *** ykarel is now known as ykarel|away | 17:19 | |
| dirk | sboyron: hberaud: so if you're referring to the "generate all the spec files from yaml / releases etc" information, then that was discussed right at the inception of the project, and it was a requirement agreed back then to use spec files, as that is the language most people that were contributing were most familiar with | 17:27 |
| dirk | we did have various iterations on that, renderspec(1) was the driving tool for that. in the end we ended up with jinja2 and a very small macro set to handle differences | 17:27 |
| dirk | the goal was back then to have spec files that feel "native" to red hat and suse users | 17:27 |
| dirk | I agree that many of the requires: or buildrequires: could be generated from some .yaml file for example | 17:28 |
| dirk | but we didn't want to use 1:1 the upstream (test-*)requirements.txt as they were often too concrete/too large | 17:28 |
| dirk | e.g. if some project cross tests against other things that we don't package or don't intend to allow, then all those requirements would have to be removed / blacklisted | 17:29 |
| dirk | I'm all for automating more of the update work, but so far the actual "update" was not a main problem, the main problem was having all the stuff that openstack does not care about (like bindep dependencies for example) handled properly, requirements associated with the right subpackages and so on | 17:30 |
| dirk | I don't remember 100% anymore how we ended up on jinja2 templates other than the stated requirement was from both sides to keep what we maintain as close to a normal spec file as posslbe | 17:33 |
| dirk | renderspec(1) was done to abstract away anything that would end up in a lot of %if / %else / %endif sections | 17:33 |
| dirk | and the request/requirement was to do everything that can be a rpm macro as an rpm macro, rather than a domain specific language on top of the spec templates | 17:34 |
| dirk | I think it is possible to extend renderspec with things that make life easier. for example suse added the "versioned dependencies" stuff and for red hat / fedora the epoch handling, which suse doesn't care about , has been added | 17:34 |
| dirk | requirements/buildrequirements could be expanded from a separate foo.yaml file into the spec file, I have no issues with that | 17:35 |
| hberaud | dirk: awesome, that was a great explanation | 17:39 |
| hberaud | dirk: got it | 17:40 |
| hberaud | extending renderspec could be a good approach | 17:40 |
| hberaud | I need to dive deep into renderspec to see how it works and how we could extend it | 17:42 |
| hberaud | sorry I need to dash for now, let's discuss about this later | 17:45 |
| sboyron | dirk awsome! thanks a lot for this historic on the project. +1 to discuss about it later | 17:58 |
| sboyron | wont work tomorrow, I'll be available from monday. Have a good day. | 17:59 |
| *** ykarel|away has quit IRC | 18:43 | |
| *** apevec has quit IRC | 20:53 | |
| *** sboyron has quit IRC | 21:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!