16:00:54 <jcajka> #startmeeting Go SIG meeting
16:00:54 <zodbot> Meeting started Tue Nov 12 16:00:54 2019 UTC.
16:00:54 <zodbot> This meeting is logged and archived in a public location.
16:00:54 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:54 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:01:04 <jcajka> #topic Roll Call
16:02:39 <nim> .hello2
16:02:40 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:02:54 <jcajka> #chair nim
16:02:54 <zodbot> Current chairs: jcajka nim
16:05:54 <jcajka> welcome :)
16:06:23 <jcajka> let's move to the open floor as there are no tagged issues and to give others time to show up
16:06:30 <jcajka> #topic Open Floor
16:06:48 <jcajka> nim: thanks for the comment on the containerd bug
16:07:29 <jcajka> BTW what is your take on https://bugzilla.redhat.com/show_bug.cgi?id=1763889 ?
16:07:33 <nim> jcajka, np
16:08:11 <nim> jcajka, really go test is underspecified upstream and it's going to hurt us even more at module time
16:08:55 <jcajka> yeah, especially on the deps side
16:09:09 <jcajka> they kind of already do
16:10:02 <nim> concerning https://bugzilla.redhat.com/show_bug.cgi?id=1763889 it’s not really a problem Go or Go macro side
16:10:35 <nim> visibly, using the flag breaks the expectations of the tooling that generates debuginfo packages
16:11:11 <nim> so it's a discussion to be had with the maintainers of this tooling
16:11:19 <nim> maybe the expectations are wrong
16:12:00 <nim> or maybe the way -trimpath was implemented upstream is wrong.
16:12:13 <nim> I don't have an opinion about it right now
16:12:42 <nim> if you want I can try to track what Fedora macro generate the debuginfos, and who owns it
16:12:56 <jcajka> ack, I'm bit worried on the debug side, it will need investigation, otherwise it looks sane to me
16:13:04 <nim> though I'm pretty sure it will end up either gcc or linker side
16:14:05 <jcajka> IIRC it should be owned by mjw or has been last time I hit issue with debug info extraction on "Go compiler" level
16:17:38 <jcajka> to quickly note there has been another point release to Go 1.13.4/1.12.13 2w ago, fortunately not a security release this time and all Fedora updates should be stable now, that is really all from my side for past 2w
16:17:51 <nim> jcajka, well, probably best to ask him directly them
16:18:35 <nim> jcajka, on my side I haven't done any go work for quite a long time, I tried to focus on my other Fedora stuff
16:19:36 <nim> jcajka, and I badly underestimated how much switching tracks would cost me, so it took way longer than I expected
16:19:56 <nim> jcajka, though, I managed to push it all FPC-side yesterday
16:20:23 <nim> jcajka, after the usual review and fixing hastle I should be able to go back to Golang
16:20:57 <nim> jcajka, I'm seing nice advancement upstream on golang/x/mod though I'm not sure it's complete enough for our needs yet
16:21:48 <nim> jcajka, certainly, upstream is adding all kinds of features they swore they would never look at last spring
16:22:14 <nim> jcajka, I guess Fedora is not the only entity with those needs
16:22:25 <jcajka> ack, I think that for f32 there is plenty of time, to include any updates/improvements, change submission deadline is end of the year, I will surely submit go1.14
16:23:30 <nim> well given how much work last update was, I think we're already too late to make the switch to modules in 1.4 for the end of the year
16:23:38 <nim> but, we can certainly try
16:23:58 <jcajka> I would be surprised to be only ones, but we are usually ones that hit it first, it takes some time to get a comprehensive feedback, though
16:24:22 <nim> at minimum, I'd like to go over all the small fix requests that accumulated this summer in pagure
16:24:33 <jcajka> yeah, I would leave that decision on Go packagers
16:25:31 <nim> so, from my POW, fedora 32 is likely to be a consolidation release for Golang, with no huge changes in packaging policy
16:25:47 <nim> and fedora 33 will be the dangerous exciting release
16:25:50 <jcajka> but in upstreams modules seems to get decent amount of adoption solving some deps tracking issues, not that would solve all our issues
16:26:09 <nim> of course, it can change if more people want to work in infra this year
16:26:13 <jcajka> we will see :)
16:27:15 <nim> I'd certainly like to have eclipseo with us next time we do deep and exciting things:)
16:30:43 <jcajka> it would be cool to have some (semi-)automation for the transition, especially if it will involve rewriting most of the specs again, but I digress
16:31:40 <jcajka> it there any other topic?
16:35:05 <nim> jcajka, I don't think it will be hard to convert our specs automatically when we do the move, the current specs are very regular since they're all generated the same way and haven't got the time to diverge
16:35:55 <nim> but, under-defined things like tests are going to hit us hard. modules are a huge progress but they don't solve everything
16:36:13 <nim> anyway, I don't have any other topic to discuss today
16:37:59 <jcajka> ack
16:38:17 <jcajka> #endmeeting