16:01:13 <jcajka> #startmeeting Go SIG meeting
16:01:13 <zodbot> Meeting started Wed Apr 10 16:01:13 2019 UTC.
16:01:13 <zodbot> This meeting is logged and archived in a public location.
16:01:13 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:13 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:01:22 <jcajka> #topic roll call
16:01:39 <jcajka> Hello, everybody
16:02:34 <nim> .hello2
16:02:34 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:02:41 <jcajka> #chair nim
16:02:41 <zodbot> Current chairs: jcajka nim
16:03:06 <jcajka> ping Pharaoh_Atem eclipseo
16:05:15 <nim> hello jcajka
16:05:33 <jcajka> hello, it seems it will be just two of us today
16:05:58 <jcajka> ping QuLogic just to be sure
16:08:22 <jcajka> nim: if you are not against it, let's keep it short today and I will schedule next meeting for next week in slot based of the poll https://framadate.org/QX6R7hxJ2mM6HO8m, Tue 1600h UTC and will set it biweekly
16:08:37 <nim> jcajka, ok
16:09:20 <jcajka> ok :)
16:09:37 <nim> not much to report anyway
16:09:56 <nim> QuLogic has taken ownership of golist and started merging fixes
16:10:08 <nim> rpm & mock are actively
16:10:18 <nim> working on dunamic buildrequires
16:10:54 <nim> I expect the first specs to build with dynamic buildrequires in upstream rpm + mock in the next weeks
16:11:22 <jcajka> #action jcajka To reschedule meeting based on the poll https://framadate.org/QX6R7hxJ2mM6HO8m for the next week, send out email about it to the Fedora's golang ML
16:11:35 <nim> So that just leaves making use of the fixed code
16:11:58 <jcajka> nim: cool. it would be great (system-wide) change for the F31
16:12:23 <nim> I've started assembling a copr with Qulogic changes here
16:12:24 <nim> https://copr.fedorainfracloud.org/coprs/nim/macros-ng/
16:12:43 <nim> rebasing all the PRs and rebuilding all the tooling
16:13:07 <nim> when it's finished it will contain the candidate golist, golang and go macro packages
16:13:25 <nim> so anyone who wants to can test its specs against them
16:13:25 <eclipseo> yo
16:13:36 <jcajka> #chair eclipseo
16:13:36 <zodbot> Current chairs: eclipseo jcajka nim
16:13:36 <eclipseo> .hello2
16:13:37 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:13:42 <nim> anyone being eclispeo usually :)
16:13:49 <eclipseo> sorry forgot we were the 10 already
16:14:22 <jcajka> nim: do you have link for the tracking issues in the upstream for the RPM and mock?
16:14:26 <nim> eclipseo, I was saying I'm assemnling a copr with candidate golist, golang and go macro packages
16:14:39 <eclipseo> I'm ready to test specs
16:14:48 <eclipseo> great
16:15:11 <eclipseo> are we close to getting them accepted?
16:15:20 <eclipseo> the macros I mean
16:15:23 <nim> jcajka, it's https://github.com/rpm-software-management/rpm/pull/593
16:15:36 <nim> and https://github.com/rpm-software-management/mock/issues/245
16:15:42 <jcajka> nim: thanks
16:16:10 <nim> eclipseo, once I've finished assembling the copr it will be time for final tests
16:16:20 <nim> eclipseo, and decide if we want to push to devel or not
16:17:04 <nim> if we don't push the PRs will rot as usual and will require another rebasing retesting round sometime in the future
16:17:49 <eclipseo> The faster the better, it will be easier to work around cyclic deps
16:18:06 <nim> so that's more for the rest of the sig to decide if we want to push as soon as the technical test are green, or do more documentation, or whatever
16:18:34 <eclipseo> I wish there was a way to rebuild our stack from scratch, with no Go packages available, to be able to detect cyclic deps
16:18:42 <eclipseo> in order to tackle bug like
16:19:06 <eclipseo> .bug 1691796
16:19:08 <zodbot> eclipseo: 1691796 – Circular build dependency between golang-googlecode-tools and golang-googlecode-net - https://bugzilla.redhat.com/1691796
16:19:29 <eclipseo> The docs are ready I think
16:19:38 <nim> eclipseo, I hate those too. cycles are a big reason I invested all this time in tooling
16:19:54 <eclipseo> QuLogic sent me a PR with corrections
16:20:02 <nim> anyway, once we push the new tooling specs, we will be back to a sane
16:20:25 <nim> fix macro or golist code / rebuild macro or golist srpm
16:20:27 <nim> workflow
16:20:38 <nim> not the insane tangle we have right now
16:21:02 <jcajka> eclipseo: you can try it do it naively locally, but probably you would want your own koji instance, it could be possible to ask for private target on stg.koji for such experiments
16:21:52 <nim> so that's all I have to say about current tooling
16:22:02 <nim> now, about future tooling
16:22:05 <jcajka> IIRC unfortunately work on periodically bootstrap Fedora have died some time ago(~4y?)
16:22:19 <nim> the future after the future just discussed
16:22:38 <nim> I have a toy Go module tool here
16:23:11 <nim> it's whoefully undertested and probably incomplete
16:23:26 <nim> but it's sufficient to generate Go modules from sources
16:23:29 <nim> https://pagure.io/modist/
16:23:51 <nim> and put them in a GOPROXY directory
16:24:03 <nim> and index the GOPROXY directory
16:24:12 <jcajka> nim: will it digest something more complex like GC, etcd, kube, delve?
16:24:35 <eclipseo> I haven't got time to test it this w-e sonny
16:24:36 <jcajka> hm.... GC is is probably too non-standard
16:24:54 <nim> jcajka, it will digest anything with go.mod files in its source tree
16:25:06 <nim> jcajka, will the result work that's another question
16:25:43 <nim> one big question is how to feed the go compiler one or several GOPROXY directories
16:25:55 <nim> since upstream didn't provision for more than one
16:26:08 <QuLogic> .hello qulogic
16:26:09 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:26:19 <nim> and when building in Fedora, we have the modules provided by others somewhere in the filesystem
16:26:23 <jcajka> #chair QuLogic
16:26:23 <zodbot> Current chairs: QuLogic eclipseo jcajka nim
16:26:35 <nim> QuLogic, you're very welcome
16:26:36 <QuLogic> but do we need more than one?
16:26:55 <nim> and the modules we're creating in the rpm
16:26:56 <jcajka> ^^ +1
16:27:27 <nim> so two sets of modules: read-only modules provided by other rpms, and the modules we're creating
16:27:52 <nim> an awful kludge would be to copy all the system modules in the WIP module dir
16:27:57 <nim> but that's pretty awful
16:28:20 <nim> anyway the toy tooling is done
16:28:59 <nim> getting go to accept a system module dir and a staging building dir is more in jcajka 's ballpark
16:29:33 <eclipseo> nim: do you think you could convince upstream to implement a way to distinguish tests dependencies? I see a bug arguing that somewhere
16:29:39 <nim> when I'm finished with the current tooling copr, the near future dynamic BRs
16:29:56 <nim> I will focus on writing the macro glue around the toy tooling
16:30:07 <jcajka> nim: I think that best place to start is if you can file upstream issue with all your requirements
16:30:10 <nim> assuming the go compiler side get fixed by someone else
16:30:56 <jcajka> or at least BZ against golang
16:31:32 <eclipseo> nim https://github.com/golang/go/issues/26913
16:31:49 <nim> jcajka, all done
16:31:51 <nim> https://groups.google.com/d/msg/golang-dev/DD88cds-LuI/1b2ZfyvWBgAJ
16:32:20 <nim> at this stage, everything in here is kludgeable by my toy tooling
16:32:57 <nim> or by horrible workaround like copying system modules inside the buildroot because go can only deal with one goproxy
16:33:18 <nim> of course the more kludges you add on top of one another the more risky and inconvenient it gets
16:34:34 <nim> eclipseo, since upstream didn’t want to touch go.mod I just asked them a command to output module deps with and without tests
16:35:18 <nim> I'm pretty sure they will realise themselves that putting the info in the module file is more convenient when they get around to coding the command
16:35:49 <nim> anyway, that's one of the sub-optimal behaviour we'll have
16:36:14 <nim> no ability to filter out test if upstream does not make an effort
16:36:35 <nim> https://github.com/golang/go/issues/31300
16:36:56 <nim> and that's all I had to report, present, near-future and futurer future
16:37:37 <nim> please all review and complete the go upstream tickets if you want them to be taken into account
16:37:40 <eclipseo> ok good
16:37:48 <nim> otherwise that's just me asking for things
16:38:51 <nim> unless anyone has a question about all that, I'm finished
16:40:22 <eclipseo> how hopeful are you the August target?
16:40:32 <eclipseo> *about
16:40:40 <nim> eclipseo, no idea
16:40:47 <QuLogic> as to GOPROXY, I did write a super simple PoC
16:40:55 <QuLogic> probably even less complete than modist
16:41:19 <nim> eclipseo, modist outputs modules, but I haven't tried to make use of them yet
16:41:36 <nim> eclipseo, that requires the macro glue to be testable
16:41:48 <QuLogic> the problem in general is that what we have doesn't match go.sum
16:42:11 <nim> It will probably work fine, except for the usual suspects (docker, k8s, etc)
16:42:19 <QuLogic> possibly because of the missing other-tagged files
16:42:34 <QuLogic> but I'm not exactly sure what goes into the hash
16:42:36 <nim> QuLogic, I agreed with upstream we just have to nuke the sum file
16:43:12 <nim> we're not trying to reproduce upstream builds, we're trying to build against out own modules
16:43:26 <QuLogic> ok, that makes things easier then
16:44:07 <nim> the whole go.sum dance would prevent jcajka from making emergency crypto fixes when needed
16:44:29 <nim> crypto or security in general
16:44:37 <jcajka> or anyone else any other emergency fixes
16:45:36 <nim> so anyway, if you get bored one day, you can play with modist outside rpm
16:46:01 <nim> while I get around to writing the macro layer
16:46:58 <nim> other questions?
16:47:22 <nim> QuLogic, https://copr.fedorainfracloud.org/coprs/nim/macros-ng/build/881617/ is your stuff, thanks
16:47:40 <QuLogic> yep, saw it earlier
16:47:48 <QuLogic> let me know if there are any problems
16:47:59 <nim> sure
16:48:16 <QuLogic> I think I have a preliminary fix for the file list as well, but have to test it out
16:48:44 <nim> but, will probably use it more to iron out rpm and mock new dynamic BR code, than to test existing specs
16:48:57 <eclipseo> What's the next blocker for the new macros to go in?
16:50:13 <nim> eclipseo, there's a small bit of macro code still waiting merging in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
16:50:34 <nim> if you know people redhat-rpm-config side now is the time to ask
16:50:57 <nim> appart from this small bit there are not technical blockers that I know of
16:51:26 <nim> just assemble a COPR with the latest PRs, test it one last time, and push it to rawhide if everyone agrees
16:51:57 <nim> jcajka, do you have other blockers in mind?
16:52:29 <jcajka> nim: I don't know that block you and your work
16:52:48 <jcajka> sorry what blocks...
16:53:01 <nim> jcajka, I mean before pushing it to rawhide
16:53:23 <jcajka> change proposal?
16:53:39 <nim> technically, I don't remember anything except the small remainer of https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
16:53:59 <nim> eclipseo, nudge
16:55:23 <jcajka> eclipseo: I'm sorry that I haven't got around to send explicit feedback to the new guidelines and few minor PRs... I got sick last week and now I'm mostly catching up...
16:55:27 <nim> I think it was agreed last time I was the wrong person for doc stuff
16:55:27 <eclipseo> i don't know anyone with redhat-rpm-config
16:55:33 <eclipseo> will ask Igor maybe
16:55:58 <eclipseo> jcajka: no worries
16:55:59 <nim> Igor is full on dynamic Br stuff right now :(
16:56:07 <eclipseo> yes
16:56:13 <eclipseo> he likes new toys
16:57:21 <nim> eclipseo, jcajka hinted at a change proposal
17:00:07 <eclipseo> sorry I didn't see
17:00:33 <eclipseo> a change proposal?
17:01:42 <nim> I think jcajka wants a change proposal before pushing the new golist and macros to devel
17:02:07 <jcajka> eclipseo, nim: https://fedoraproject.org/wiki/Changes/Policy
17:02:16 <eclipseo> yes I'm reading this
17:02:32 <eclipseo> never done that
17:02:37 <eclipseo> you want me to do it?
17:02:41 <eclipseo> I'll look into it
17:03:26 <nim> eclipseo, we need a nice and friendly person like to to stand in the front line
17:03:38 <eclipseo> lol that's not me
17:03:47 <nim> eclipseo, I'm not a nice and friendly person, I'd attract rotten tomatoes
17:03:56 <nim> and green eggs
17:04:12 <jcajka> eclipseo: I don;t want it, but if means all the changes that nim proposes, he(or somebody who will be willing) need to own them and sum up all the impacts, work that needs to be done by non-owners, etc.
17:04:49 <jcajka> ...s/if means//... sorry
17:05:10 <eclipseo> I'm not sure I have all the consequences of that change in mind.
17:05:19 <eclipseo> But I'll try to do it
17:05:19 <nim> I'm not sure the change is needed, there are no official Fedora Go packaging guidelines to obsolete, and Go is pretty much its own world
17:05:40 <jcajka> and it will promote that changes, we can get something like article @lwn or phoronix ;)
17:05:45 <nim> so IMHO it's more internal go SIG problems
17:06:05 <nim> but I agree with jcajka that a change would be nicer
17:06:08 <eclipseo> shit it's already 7PM
17:06:13 <eclipseo> I need to go now
17:06:26 <eclipseo> That's why I wanted a later schedule
17:06:27 <jcajka> nim if you&co will do all the work then yes, other wise it is system wide change
17:06:52 <eclipseo> Anyhow I'll try to draft some thing
17:07:03 <eclipseo> I don't think this is a system wide change
17:07:14 <eclipseo> it umpacts packager only not end users
17:08:48 <jcajka> eclipseo: but all package using Go, kind of
17:09:47 <nim> jcajka, glory is overrated, even if it gets reported, they'll pass to another subject the week after
17:09:48 <jcajka> if I over simplify it a bit, it will impact like ~600 out of ~700 Go packages in the way they will need to be changed
17:11:27 <nim> jcajka, very minimal changes, since a lot of effort was put it keeping the macro entry points as compatible as possible
17:11:27 <jcajka> nim: it makes the changes more visible to the more wider audience(that would for example never considered such issues), I'm not talking about glory or fame
17:12:25 <nim> jcajka, I know, just kidding, I've already did it once, it felt good, but didn't stay long in the spotlight
17:12:55 <jcajka> IMO 600 a little is not that small, it is like golang re-base it actually doesn't require any change of the packages(in ideal world) yet it is system wide change
17:13:28 <nim> jcajka, and anyway, the huge big-bang and rebase will happen with modules
17:13:48 <jcajka> yeah :)
17:14:11 <nim> jcajka, since upstream module-aware commands refuse to ackowledge GOPATH, so we'll have to rebootstrap everything
17:14:42 <jcajka> we are well over the 1h slot
17:14:57 <jcajka> can we continue next week?
17:15:04 <nim> we can
17:15:11 <jcajka> awesome :)
17:15:14 <nim> it was nice to have so many participants
17:15:29 <jcajka> see you all next week on Tue 1600h UTC
17:15:36 <nim> I hope newt week I'll be the one asking questions ;)
17:15:42 <jcajka> #endmeeting