17:01:14 <jcajka> #startmeeting Go SIG meeting
17:01:14 <zodbot> Meeting started Mon Jul  6 17:01:14 2020 UTC.
17:01:14 <zodbot> This meeting is logged and archived in a public location.
17:01:14 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:14 <zodbot> The meeting name has been set to 'go_sig_meeting'
17:01:22 <jcajka> #topic Roll Call
17:01:37 <Eighth_Doctor> .hello ngompa
17:01:38 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:48 <jcajka> #chair Eighth_Doctor
17:01:48 <zodbot> Current chairs: Eighth_Doctor jcajka
17:02:07 <alexsaezm> o/
17:02:15 <jcajka> #chair alexsaezm
17:02:15 <zodbot> Current chairs: Eighth_Doctor alexsaezm jcajka
17:03:43 <nim> .hello2
17:03:44 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
17:04:05 <jcajka> #chiar nim
17:04:11 <jcajka> #chair nim
17:04:11 <zodbot> Current chairs: Eighth_Doctor alexsaezm jcajka nim
17:04:15 <jcajka> sorry
17:05:44 <jcajka> welcome everybody, there are not tagged issue this week so I guess we can move to Open Floor
17:05:49 <jcajka> #topic Open Floor
17:08:41 <nim> nothing much to say on my side, ffesti is looking at  backporting the redhat-rpm-config current Go macros depend on to EL8
17:09:08 <nim> and the redhat-rpm-config bits future Go macros depend on have been finished and posted as a F33 change
17:09:12 <alexsaezm> oh I'm interested in that
17:09:35 <nim> which I guess everyone who follows thse things know by now
17:09:52 <alexsaezm> is there any place where I can read about that F33 change?
17:11:29 <nim> alexsaezm, wait a sec
17:12:23 <nim> alexsaezm, it’s https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
17:12:40 <nim> alexsaezm, you won’t find anything go specific in there though
17:13:03 <nim> alexsaezm, it’s just the general mecanism to register processing at various stages of the rpm build
17:13:17 <nim> and a clean up of forge macros to use it
17:13:50 <nim> alexsaezm, the examples are done with font packages because i18n wanted to do a refresh in F33
17:14:08 <nim> alexsaezm, but most of the code is actually a backport of code I had written for Go modules
17:15:09 <nim> alexsaezm, a complete working solution will be to use the generic framework to orchestrate the very low level go module processing bits I showed up the other day
17:16:04 <alexsaezm> nice, thanks for the link I'll take a deep look into it. I'm really interesting in digging deeper in the redhat-rpm-config file
17:16:32 <nim> alexsaezm, right now the smallish F34 follow-up seems to passionate more devel reviewers
17:16:47 <nim> than the hardcore infra it builds upon
17:16:49 <nim> https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
17:17:14 <eclipseo> hey
17:17:28 <nim> alexsaezm, Eighth_Doctor can give you another perspective
17:17:33 <eclipseo> the new hours is not good for me
17:17:36 <nim> eclipseo, hey good to see you
17:17:46 <alexsaezm> Oh I saw that thread today nim. Didn't have the time to read it.
17:17:58 <Eighth_Doctor> I don't know what to make of it
17:18:19 <Eighth_Doctor> I'm really nervous about having the spec files essentially become unreadable goop with macro invocations
17:18:26 <nim> alexsaezm, not sure it’s very relevant to Go, 90% of the things in it deal with the F34 release bumping part
17:18:29 <eclipseo> there's a lot of bishedding on this
17:18:32 <Eighth_Doctor> I've been burned too much by Debian-style automagic
17:19:05 <nim> Eighth_Doctor, it’s the opposite of goop, it’s structured processing
17:20:00 <nim> Eighth_Doctor, one reason I wrote it is that between GOPATH subpackages and Module subpackages the result was becoming a bit too much for me to handle manually
17:20:26 <nim> Eighth_Doctor, so I gave scheduling of the various processing bit to a generic pile of loops
17:20:54 <nim> Eighth_Doctor, so I could focus on the Go macro logic and not the assembling of the various logic bits
17:21:08 <Eighth_Doctor> I'd be a lot more comfortable if the standard preamble was still defined by hand
17:21:19 <Eighth_Doctor> a spec file with basically no declarative portions in it is frankly very scary
17:21:36 <jcajka> Eighth_Doctor: +1 kind of my worry too
17:21:46 <nim> Eighth_Doctor, that ship sailed away when Panu refused to fix tag ordering
17:21:56 <eclipseo> i second this I fear it might be too unwelcoming for newbs
17:22:07 <Eighth_Doctor> hell, I'm scared and I'm far from being a newbie at this
17:22:08 <nim> Eighth_Doctor, and insisted tags had to happen in the exact order he wanted them to
17:22:31 <nim> Eighth_Doctor, so now you can check in the spec files, everything is aligned like at the parade
17:22:49 <nim> Eighth_Doctor, because everything is always generated in the same order without human messiness
17:22:54 <Eighth_Doctor> yeah, but there's also work upstream to add a spec section for generating subpackages based on built package content (ie. after %prep, %generate_buildrequires, %build, and %install have occurred)
17:23:19 <Eighth_Doctor> https://github.com/rpm-software-management/rpm/pull/1239
17:23:33 <nim> Eighth_Doctor, well when that happens, if it is usefull I will make use of it
17:23:49 <Eighth_Doctor> you should be engaging with ffesti now about it
17:24:03 <Eighth_Doctor> he's specifically asking for testing and feedback on the feature
17:24:11 <Eighth_Doctor> don't be lazy about it like you were with genbr
17:24:49 <nim> Eighth_Doctor, look I was not lazy with genbr, you can check the issue in github, I drove the implementation
17:25:04 <nim> Eighth_Doctor, before people decided they had all invented themselves
17:25:43 <nim> Eighth_Doctor, but anyway ffesti’s implementation is dealing with subpackages only, the bits I posted are a lot more generic than that
17:25:49 <Eighth_Doctor> okay, that's unfair, you did actually give feedback during genbr dev
17:26:02 <Eighth_Doctor> I'm more annoyed we don't have a genbr thing for Go already
17:26:10 <nim> Eighth_Doctor, we have one
17:26:24 <Eighth_Doctor> talk to him about expanding the scope
17:26:28 <Eighth_Doctor> he's not even fully settled on its scope
17:26:48 <nim> Eighth_Doctor, it’s just eclipseo felt umconfortable with the newness of generic buildrequires, so he did not put it in guidelines
17:26:56 <Eighth_Doctor> ah
17:27:53 <nim> Eighth_Doctor, but we have genbrs today, what do you think I used when arguing the design in upstream issue tracker?
17:28:25 <nim> Eighth_Doctor, of course the main problem with a GOPATH genbr, is that GOPATH has no notion of versions
17:28:25 <jcajka> it rather unfortunate to have that as a hidden feature....
17:29:35 <nim> jcajka, well eclipseo felt it was too new, for me it was old news already, and we both moved on
17:29:48 <nim> jcajka, it is documented in go-rpm-templates though
17:30:48 <eclipseo> We have a genbr thing
17:30:48 <nim> https://pagure.io/go-rpm-macros/blob/master/f/templates/rpm/spectemplate-go-0-source-minimal.spec#_103
17:31:23 <eclipseo> it's just that I personnally don't loke to use it, and since I rewrote almost all SPEC, it does not appear
17:31:28 <eclipseo> *like
17:31:33 <nim> Eighth_Doctor, but anyway what I wanted to say, is my stuff is both more generic and more limited than what ffesti is working on
17:32:03 <nim> Eighth_Doctor, i can’t do the kind of dynamic subpackage he can do with his project
17:32:15 <Eighth_Doctor> but you want to
17:32:36 <Eighth_Doctor> most of the stuff you've done in the past two years has been edging around that
17:32:40 <nim> Eighth_Doctor, and he can’t do 90% of what my code does because subpackaging is just one application of my code
17:33:22 <nim> Eighth_Doctor, dynamic subpackaging is one thing I’d like to integrate yes, but I’m not sure what ffesti is doing is sufficient
17:33:32 <nim> Eighth_Doctor, or that it will useful at all to me*
17:33:36 <Eighth_Doctor> test it and give feedback
17:33:44 <Eighth_Doctor> otherwise you'll never know until it's too late
17:34:03 <nim> Eighth_Doctor, what use is a subpackage section if the lua code it runs is evaluated at preamble time like now?
17:34:24 <nim> Eighth_Doctor, might as well keep everything in the preamble like we do today
17:35:08 <nim> Eighth_Doctor, I’ve already told those things in issues ffesti follows up, don’t want to tell and re tell the same things all over again
17:35:19 <nim> Eighth_Doctor, if you wish I’ll make another pass
17:35:24 <Eighth_Doctor> please do so
17:35:42 <jcajka> nim: it would be great if you could help him to make that code do what yours already is doing, if if will be there it would makes everyone's live better
17:36:19 <nim> jcajka, well, like I said we are targetting overlapping, but not the same problem spaces
17:37:00 <nim> jcajka, so, don’t expects ffesti’s code to replace everything I do soonish unless he decides to broaden the scope a lot
17:37:53 <jcajka> yeah, and I think if you are more aware of each others problem space so  you will be less likely to stumble on each others toes
17:37:59 <nim> jcajka, you see, in my code subpackage headers are just one another thing that needs to be generated in the spec file
17:38:55 <nim> jcajka, why I think ffesti only targets subpackage headers (and not even sure if he wants to generate them or expects domain macros to generate domain-specific headers like the genr stuff did)
17:39:49 <nim> to put things another way, ffesti is working on generalizing the kind of thing debuginfo subpackages use
17:40:06 <jcajka> nim: it seems to me, that you need to talk about more broadly about it
17:40:07 <nim> he’s not working on writing the debuginfo logic himself
17:40:15 <jcajka> provide feedback to each other
17:40:51 <nim> jcajka, also (and I already told him), he’s thinking in package vs subpackage terms
17:41:28 <nim> while they are really the same thing, when you have a single generated subpackage you want the srpm to mirror this subpackage, not declare the same things twoce
17:41:31 <nim> twice
17:42:12 <nim> jcajka, anyway i have no problem working with ffesti if he wantss to, he’s always been nice and helpful to me
17:43:14 <jcajka> if you don't iron out that you will have to deal with that at the change time, which might be impossible, but I think that we can't do much more here really about it at least not now
17:44:23 <jcajka> from me,  I just want to  mention that alexsaezm got sponsored as packager and he is already helping me with golang, big thanks to him and all that helped :)
17:44:37 <nim> alexsaezm, congratulations!
17:44:42 <alexsaezm> thanks :D
17:45:27 * alexsaezm is afraid of the ~1400 packages in src.fedoraproject.org
17:47:16 <jcajka> for the record work on go1.15 so far looks good(but that might be that I haven't yet checked the scratch rebuild details :D, just finished now)
17:49:22 <jcajka> alexsaezm: it should be just bit over 1300 active packages on rawhide :)
17:49:30 <eclipseo> great thx alexsaezm
17:50:54 <alexsaezm> jcajka, easy peasy :D
17:51:10 <jcajka> :D
17:51:16 <alexsaezm> eclipseo, thanks. sounds naive but I'm really happy to be able to help :D
17:57:30 <jcajka> eclipseo: ad the meeting time, could you fill https://xoyondo.com/dp/Y9j5f0YpiF0a6fl ? or let me know
17:57:52 <jcajka> do we have other topics for last ~3mins ?
18:00:04 <jcajka> last call! :)
18:00:26 <jcajka> #endmeeting