17:01:35 <jcajka> #startmeeting Go SIG meeting
17:01:35 <zodbot> Meeting started Mon Jun  8 17:01:35 2020 UTC.
17:01:35 <zodbot> This meeting is logged and archived in a public location.
17:01:35 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:35 <zodbot> The meeting name has been set to 'go_sig_meeting'
17:01:41 <jcajka> #topic Roll Call
17:01:53 <jcajka> #chair Eighth_Doctor
17:01:53 <zodbot> Current chairs: Eighth_Doctor jcajka
17:01:54 <Eighth_Doctor> .hello ngompa
17:01:54 <zodbot> Eighth_Doctor: [hellomynameis ngompa]
17:01:57 <nim__> .hello2
17:01:57 <zodbot> nim__: [hellomynameis nim__]
17:02:05 <Eighth_Doctor> whoa
17:02:14 <jcajka> #chair nim__
17:02:14 <zodbot> Current chairs: Eighth_Doctor jcajka nim__
17:02:18 <Eighth_Doctor> that's broken
17:02:45 <jcajka> __ in nick?
17:03:10 <alexsaezm> o/
17:03:37 <jcajka> better than backtrace :D
17:03:53 <jcajka> no chair for alexsaezm, yet :)
17:05:06 <alexsaezm> I have a virtual IRC standing desk :P
17:06:16 <jcajka> no tagged issues so it is
17:06:17 <jcajka> #topic Open Floor
17:06:39 <nim__> https://paste.centos.org/view/f360f38c
17:07:26 <nim__> line 161 is nice
17:08:08 <alexsaezm> go mod tidy ?
17:08:20 <nim__> in mock
17:08:24 <jcajka> that is in offline env?
17:08:38 <nim__> that is a real mock with no cheating
17:09:04 <nim__> you see line 158 there is no network access
17:09:32 <nim__> I got it to work 15 min ago
17:10:43 <nim__> golang.org/x/sys/unix is provided by another package
17:11:03 <QuLogic> .hello qulogic
17:11:03 <zodbot> QuLogic: [hellomynameis qulogic]
17:11:15 <jcajka> unpatched golang?
17:11:19 <jcajka> #chair QuLogic
17:11:19 <zodbot> Current chairs: Eighth_Doctor QuLogic jcajka nim__
17:11:51 <nim__> all packages from F33 koji, except for my own stuff
17:12:22 <nim__> QuLogic, https://paste.centos.org/view/f360f38c
17:12:29 <jcajka> "own stuff" sounds extensive ;)
17:12:33 <jcajka> what it does?
17:13:09 <nim__> own stuff is modist + the go rpm macros + some bits in redhat-rpm-config I need to get merged
17:13:15 <nim__> that’s all
17:13:21 <jcajka> all and all looks cool :)
17:13:50 <nim__> if copr was not slow as molasses it would have finished building in the last 15 min
17:14:34 <nim__> jcajka, 1 year of work, more or less
17:15:17 <nim__> maybe more, don’t want to remember how long I waited for upstream to publish golang/x/mod in a usable state
17:15:55 <jcajka> oh... uses local file based GOPROXY for providing the packages, right?
17:16:34 <nim__> line 146
17:19:06 <nim__> anyway you have the whole stack in https://copr.fedorainfracloud.org/coprs/nim/go-modules/builds/
17:19:14 <nim__> it just did not finish building yet
17:19:43 <nim__> copr is sloooow
17:19:57 <jcajka> might be interesting for the devs too(developing against distro packages in Fedora, CentOS,...), especially if there might be the way to provide "rpm backend" for go command's deps solving, for use in local environments
17:20:33 <jcajka> if we wan to dive rabbit hole
17:20:37 <jcajka> awesome :)
17:21:01 <jcajka> that might be the DC move
17:21:29 <nim__> jcajka, well that exposes the fact that upstream’s dependency graph is a mess full of cycles, not sure devs will like it
17:22:07 <nim__> I had to create 5 submodules in gloang.org/x/net to unbreak it
17:22:33 <jcajka> hopefully upstream able ;)
17:22:44 <nim__> jcajka, that’s the dc and the fact F33 deadlines  are approaching
17:22:45 <jcajka> do you have your fork somewhere?
17:23:30 <nim__> creating submodules is just doing a go mod init in the parts that need to be separated to keep the graph sane
17:24:21 <jcajka> ah...
17:25:07 <nim__> you don{t need a line of code changes
17:25:23 <nim__> just putting go.mods in the right places
17:26:25 <nim__> if the graph was not splittable at the package level the go compiler could not compute its own execution plan
17:26:26 <jcajka> that sound that it might hit some possibly undefined behaviors or bugs, but good to catch them I guess
17:27:48 <nim__> ok golang/x/sys built in corp, so you have a real checkable build
17:28:12 <nim__> i’s less interesting than net because sys does not have dependencies itself
17:28:49 <nim__> so it does not show how the dep automation works
17:29:55 <nim__> anyway, here you are
17:29:56 <nim__> https://download.copr.fedorainfracloud.org/results/nim/go-modules/fedora-rawhide-x86_64/01432260-golang-x-net/
17:30:34 <nim__> a real module build in official fedora copr using offixial fedora packages except for the 3 tooling packages in that were builr first
17:32:23 <nim__> first day it works, so still raw and ugly and in need of testing and polishing, but the core logic works
17:34:08 <jcajka> I'm looking forward to see it unwind
17:35:17 <nim__> thank you
17:35:50 <nim__> once I finish the initial testing, and build enough go bits so it is self-hosting
17:36:33 <nim__> we will need to rebuild everything in module mode
17:37:10 <nim__> which will be a huge amount of work too
17:37:30 <nim__> but today, it’s no longer a matter of will we manage to do it
17:37:35 <nim__> but how we will do it
17:38:09 <nim__> the macro code is even nice and easy to read
17:38:24 <nim__> all the ugliness is in modist because I{m not a go coder
17:38:36 <nim__> I learnt the language while coding modist
17:39:03 <nim__> so, the result is probably fairly ugly
17:40:24 <nim__> anyway, that’s all I had to say or show up today :)
17:41:54 <jcajka> :)
17:45:12 <jcajka> any comments, new topics?
17:45:41 <Eighth_Doctor> well
17:46:02 <Eighth_Doctor> do we know when Go 1.14.x will show up in RHEL8?
17:46:29 <Eighth_Doctor> carlwgeorge and I would like to get caddy2 in EPEL 8, and that's our blocker
17:46:48 <alexsaezm> which RHEL 8?
17:47:48 <jcajka> Eighth_Doctor: would EPEL do?(if that is technically possibly, I don't have that many spare cycles to really tend to EPEL much :/)
17:47:56 <Eighth_Doctor> jcajka: we can't override RHEL modules
17:48:12 <jcajka> doh... though so
17:48:19 <jcajka> thought
17:48:27 <Eighth_Doctor> EPEL policy says if RHEL provides a supported module, we can't override it
17:48:35 <Eighth_Doctor> alexsaezm: honestly, sooner the better
17:48:45 <Eighth_Doctor> 8.2 is already out, so I'd hope for 8.3
17:48:55 <alexsaezm> yes, 8.2 is out with go 1.13
17:49:09 <alexsaezm> checking with my manager if I can talk about it (honestly I don't know sorry :( )
17:49:27 <Eighth_Doctor> I still don't understand why AppStreams don't let you ship new versions of this stuff out of band of RHEL point releases
17:49:46 <Eighth_Doctor> it seems like this cycle blockage defeats a good part of the value of having "independent lifecycles" with modules
17:50:43 <alexsaezm> Checked
17:50:52 <alexsaezm> so yeah, RHEL 8.3 will ship go 1.14
17:50:53 <jcajka> Eighth_Doctor: it might not be module in EPEL, "just" regular package, but i still believe that would require changes to the rpm/BR configs...
17:51:12 <Eighth_Doctor> modules autoshadow
17:51:18 <alexsaezm> we rebase every ~6 months Eighth_Doctor
17:51:31 <Eighth_Doctor> yeah, I know
17:52:02 <alexsaezm> I did the rebase past week but I think 8.3 is still a little far away in time
17:54:39 <alexsaezm> Eighth_Doctor, take my will ship as a possibility of course. but it's in the planning (don't have on top of my head the dates either)
17:55:09 <Eighth_Doctor> well, too late, I told caddy folks it's coming :P
17:55:18 <jcajka> alexsaezm: thanks for the info, although it is kind out of scope of the SIG, but still related ;)
17:55:37 <Eighth_Doctor> well, caddy is in go, it uses go modules, it's golang-y enough for the SIG :D
17:56:02 <alexsaezm> Eighth_Doctor, lol not a problem. We want to, but with me in the team, you can expect a lot of issues :)
17:56:07 <jcajka> and alexsaezm will have to deliver now :D
17:57:43 <alexsaezm> I'm afraid I'm not familiar with caddy
17:57:54 <Eighth_Doctor> https://caddyserver.com/
17:57:58 <jcajka> any other topics? we are approaching the hour
17:58:29 <Eighth_Doctor> so I discovered a slight incompatibility between Fedora and openSUSE Go compiler packages
17:58:44 <Eighth_Doctor> in openSUSE, they've got this golang(API) Provides that specifies the Go language version
17:58:58 <Eighth_Doctor> most of their packages that BR the go compiler actually BR that provides
17:59:38 <Eighth_Doctor> is there a Go-native construct we can wrap in golang() to represent the go language version?
17:59:50 <Eighth_Doctor> I have a feeling "API" isn't the correct one :)
18:00:15 <nim__> Eighth_Doctor, we can, invent a new provides
18:00:18 <alexsaezm> Eighth_Doctor, thanks for the link
18:00:23 <nim__> but not golang(foo)
18:00:45 <nim__> the thing in golang() is supposed to be a package path
18:00:56 <jcajka> Eighth_Doctor: we have "go", from the golang() point "std" would make sense
18:01:23 <jcajka> senses as IMO that is mostly the "API"
18:01:39 <jcajka> try go test std
18:01:41 <nim__> right now we have golang() golang-ipath() golang-module() feel free to requisition a new namespace
18:02:55 <jcajka> I have no objection to add "std" wrapped in anything that is in use in guidelines currently
18:04:52 <nim__> jcajka, yes it would be possible to do a golang(std) = something as long as nothing else will ever want to export a package named stf
18:04:52 <nim__> std
18:04:52 <nim__> jcajka, which mainly means you, because upstream made sure to break non FQDNed package names for everything except the core golang package
18:06:40 <jcajka> Eighth_Doctor, nim: maybe I have miss understood the use case, but that is basically to request exact version of the compiler/std API, right?
18:06:52 <Eighth_Doctor> yeah
18:07:12 <Eighth_Doctor> openSUSE uses this because they package multiple versions of the Go compiler (for reasons I cannot fathom) and they need a way to get the right one selected at build-time
18:09:07 <Eighth_Doctor> jcajka: slightly less golang-core related, but we should probably make kubernetes packages parallel installable
18:09:52 <Eighth_Doctor> upgrading kubernetes is extraordinarily painful if you can't keep the old binaries around while you have the new binaries in place to migrate kubelet, workloads, etc.
18:10:45 <jcajka> Eighth_Doctor: feel free ;) it is unfortunately rather big can of worms...
18:10:55 <Eighth_Doctor> I know
18:11:07 <Eighth_Doctor> I need to sit down and think about it... at least now our k8s package is up to date
18:11:20 <jcajka> BTW do we have some way to install packages in parallel?
18:11:25 <jcajka> (in Fedora)
18:12:09 <Eighth_Doctor> well, we could do the way we do it for kernels
18:12:18 <Eighth_Doctor> or we could just make each package have versioned names
18:12:38 <jcajka> I can currently only thing about creating relocatable package(not sure if that is not explicitly forbidden by guidelines), or (modules and) containers...
18:13:07 <jcajka> that can also work, with alternatives
18:13:24 <nim__> jcajka, relocatable does not work in real life
18:13:44 <jcajka> yeah, kind of the point unfortunately...
18:13:49 <nim__> Eighth_Doctor, you don’t even want to try to get the privileges of the kernel package
18:14:14 <nim__> so basically, making parallel installable requires makeing sure all paths are separate
18:14:17 <Eighth_Doctor> kernel package requires a provides that marks it as a multiversioned package, and you need to construct file paths so that they're uniquely versioned on every update
18:14:38 <nim__> with maybe some user friendly alternatives slapped as entry point
18:16:14 <nim__> and alternatives are going to be a miser to manage, so you want to keep the alternattive paths to the bare minimum
18:16:55 <nim__> I did it for java 20 years ago, the packaging was mostly nice once we had good versioned path conventions
18:17:06 <nim__> but alternatives kept breaking all the time
18:17:43 <nim__> because there was too much drift between the things each java implementation wanted to expose as alternatives
18:18:06 <Eighth_Doctor> jcajka, hmm: https://lists.opensuse.org/opensuse-kubic/2020-03/msg00018.html
18:18:41 <Eighth_Doctor> this basically describes the problem I'm talking about
18:19:30 <jcajka> if that is just about the binaries, alternatives are IMHO fairly straight forward, anything beyond that I would be worried(but I don't have experience beyond the "simple", see golang x gcc-go)
18:20:09 <Eighth_Doctor> yeah
18:20:39 <jcajka> that sounds as alternatives with extra steps, but I don't know what all is really needed per version for k8
18:21:00 <Eighth_Doctor> I don't either
18:21:18 <Eighth_Doctor> what I do know is that having containerized parts of k8s in k8s makes upgrades very hard
18:21:37 <jcajka> :)
18:26:01 <jcajka> would be interesting to see how the SUSE will do it
18:26:18 <jcajka> even more topics?
18:27:49 <alexsaezm> nope from my side
18:31:05 <jcajka> last call :)
18:31:32 <Eighth_Doctor> jcajka: this was implemented already, apparently: https://build.opensuse.org/package/show/devel:kubic/kubernetes
18:31:44 <Eighth_Doctor> but other than that, I got nuttin' :D
18:32:45 <jcajka> #endmeeting