17:01:14 #startmeeting Go SIG meeting 17:01:14 Meeting started Mon Jul 6 17:01:14 2020 UTC. 17:01:14 This meeting is logged and archived in a public location. 17:01:14 The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:14 The meeting name has been set to 'go_sig_meeting' 17:01:22 #topic Roll Call 17:01:37 .hello ngompa 17:01:38 Eighth_Doctor: ngompa 'Neal Gompa' 17:01:48 #chair Eighth_Doctor 17:01:48 Current chairs: Eighth_Doctor jcajka 17:02:07 o/ 17:02:15 #chair alexsaezm 17:02:15 Current chairs: Eighth_Doctor alexsaezm jcajka 17:03:43 .hello2 17:03:44 nim: nim 'None' 17:04:05 #chiar nim 17:04:11 #chair nim 17:04:11 Current chairs: Eighth_Doctor alexsaezm jcajka nim 17:04:15 sorry 17:05:44 welcome everybody, there are not tagged issue this week so I guess we can move to Open Floor 17:05:49 #topic Open Floor 17:08:41 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 and the redhat-rpm-config bits future Go macros depend on have been finished and posted as a F33 change 17:09:12 oh I'm interested in that 17:09:35 which I guess everyone who follows thse things know by now 17:09:52 is there any place where I can read about that F33 change? 17:11:29 alexsaezm, wait a sec 17:12:23 alexsaezm, it’s https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs 17:12:40 alexsaezm, you won’t find anything go specific in there though 17:13:03 alexsaezm, it’s just the general mecanism to register processing at various stages of the rpm build 17:13:17 and a clean up of forge macros to use it 17:13:50 alexsaezm, the examples are done with font packages because i18n wanted to do a refresh in F33 17:14:08 alexsaezm, but most of the code is actually a backport of code I had written for Go modules 17:15:09 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 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 alexsaezm, right now the smallish F34 follow-up seems to passionate more devel reviewers 17:16:47 than the hardcore infra it builds upon 17:16:49 https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping 17:17:14 hey 17:17:28 alexsaezm, Eighth_Doctor can give you another perspective 17:17:33 the new hours is not good for me 17:17:36 eclipseo, hey good to see you 17:17:46 Oh I saw that thread today nim. Didn't have the time to read it. 17:17:58 I don't know what to make of it 17:18:19 I'm really nervous about having the spec files essentially become unreadable goop with macro invocations 17:18:26 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 there's a lot of bishedding on this 17:18:32 I've been burned too much by Debian-style automagic 17:19:05 Eighth_Doctor, it’s the opposite of goop, it’s structured processing 17:20:00 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 Eighth_Doctor, so I gave scheduling of the various processing bit to a generic pile of loops 17:20:54 Eighth_Doctor, so I could focus on the Go macro logic and not the assembling of the various logic bits 17:21:08 I'd be a lot more comfortable if the standard preamble was still defined by hand 17:21:19 a spec file with basically no declarative portions in it is frankly very scary 17:21:36 Eighth_Doctor: +1 kind of my worry too 17:21:46 Eighth_Doctor, that ship sailed away when Panu refused to fix tag ordering 17:21:56 i second this I fear it might be too unwelcoming for newbs 17:22:07 hell, I'm scared and I'm far from being a newbie at this 17:22:08 Eighth_Doctor, and insisted tags had to happen in the exact order he wanted them to 17:22:31 Eighth_Doctor, so now you can check in the spec files, everything is aligned like at the parade 17:22:49 Eighth_Doctor, because everything is always generated in the same order without human messiness 17:22:54 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 https://github.com/rpm-software-management/rpm/pull/1239 17:23:33 Eighth_Doctor, well when that happens, if it is usefull I will make use of it 17:23:49 you should be engaging with ffesti now about it 17:24:03 he's specifically asking for testing and feedback on the feature 17:24:11 don't be lazy about it like you were with genbr 17:24:49 Eighth_Doctor, look I was not lazy with genbr, you can check the issue in github, I drove the implementation 17:25:04 Eighth_Doctor, before people decided they had all invented themselves 17:25:43 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 okay, that's unfair, you did actually give feedback during genbr dev 17:26:02 I'm more annoyed we don't have a genbr thing for Go already 17:26:10 Eighth_Doctor, we have one 17:26:24 talk to him about expanding the scope 17:26:28 he's not even fully settled on its scope 17:26:48 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 ah 17:27:53 Eighth_Doctor, but we have genbrs today, what do you think I used when arguing the design in upstream issue tracker? 17:28:25 Eighth_Doctor, of course the main problem with a GOPATH genbr, is that GOPATH has no notion of versions 17:28:25 it rather unfortunate to have that as a hidden feature.... 17:29:35 jcajka, well eclipseo felt it was too new, for me it was old news already, and we both moved on 17:29:48 jcajka, it is documented in go-rpm-templates though 17:30:48 We have a genbr thing 17:30:48 https://pagure.io/go-rpm-macros/blob/master/f/templates/rpm/spectemplate-go-0-source-minimal.spec#_103 17:31:23 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 *like 17:31:33 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 Eighth_Doctor, i can’t do the kind of dynamic subpackage he can do with his project 17:32:15 but you want to 17:32:36 most of the stuff you've done in the past two years has been edging around that 17:32:40 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 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 Eighth_Doctor, or that it will useful at all to me* 17:33:36 test it and give feedback 17:33:44 otherwise you'll never know until it's too late 17:34:03 Eighth_Doctor, what use is a subpackage section if the lua code it runs is evaluated at preamble time like now? 17:34:24 Eighth_Doctor, might as well keep everything in the preamble like we do today 17:35:08 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 Eighth_Doctor, if you wish I’ll make another pass 17:35:24 please do so 17:35:42 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 jcajka, well, like I said we are targetting overlapping, but not the same problem spaces 17:37:00 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 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 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 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 to put things another way, ffesti is working on generalizing the kind of thing debuginfo subpackages use 17:40:06 nim: it seems to me, that you need to talk about more broadly about it 17:40:07 he’s not working on writing the debuginfo logic himself 17:40:15 provide feedback to each other 17:40:51 jcajka, also (and I already told him), he’s thinking in package vs subpackage terms 17:41:28 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 twice 17:42:12 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 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 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 alexsaezm, congratulations! 17:44:42 thanks :D 17:45:27 * alexsaezm is afraid of the ~1400 packages in src.fedoraproject.org 17:47:16 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 alexsaezm: it should be just bit over 1300 active packages on rawhide :) 17:49:30 great thx alexsaezm 17:50:54 jcajka, easy peasy :D 17:51:10 :D 17:51:16 eclipseo, thanks. sounds naive but I'm really happy to be able to help :D 17:57:30 eclipseo: ad the meeting time, could you fill https://xoyondo.com/dp/Y9j5f0YpiF0a6fl ? or let me know 17:57:52 do we have other topics for last ~3mins ? 18:00:04 last call! :) 18:00:26 #endmeeting