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