19:00:32 <jcajka> #startmeeting Go SIG meeting
19:00:32 <zodbot> Meeting started Mon Dec 20 19:00:32 2021 UTC.
19:00:32 <zodbot> This meeting is logged and archived in a public location.
19:00:32 <zodbot> The chair is jcajka. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:00:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:32 <zodbot> The meeting name has been set to 'go_sig_meeting'
19:00:55 <jcajka> Hello and welcome to the last Go SIG meeting of the 2021
19:00:58 <eclipseo_> .hello2
19:00:59 <zodbot> eclipseo_: Sorry, but user 'eclipseo_' does not exist
19:01:01 <jcajka> #topic Roll Call
19:01:06 <jcajka> #chair eclipseo_
19:01:07 <zodbot> Current chairs: eclipseo_ jcajka
19:02:49 <eclipseo_> ping alexsaezm gotmax
19:02:53 <copperi[m]> .hello copperi
19:02:55 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
19:03:00 <gotmax> .hello gotmax23
19:03:01 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email>
19:03:45 <jcajka> #chair copperi[m], gotmax
19:03:45 <zodbot> Current chairs: copperi[m] eclipseo_ gotmax jcajka
19:04:12 <gotmax> eclipseo: alexsaezm said "I don't think I'll be able to attend today's meeting :( (Needless to say, I'll read the log)"
19:04:30 <jcajka> seems we have plenty of attendance today, although some might regret
19:04:42 <jcajka> there is one open and tagged issue in the tracker
19:04:44 <eclipseo_> I had things to ask him :(
19:05:00 <jcajka> #topic  Fedora 36 changes
19:05:05 <jcajka> https://pagure.io/GoSIG/go-sig/issue/36
19:05:21 <eclipseo_> yes I responded I was ok with 1.18 if we had a beta already
19:05:33 <jcajka> I'm not sure if there is anything more that I can add.
19:05:37 <eclipseo_> otherwise it will be oo risky inho
19:05:54 <jcajka> beta seems to be in koji already https://koji.fedoraproject.org/koji/buildinfo?buildID=1867773
19:05:56 <gotmax> alexsaezm Already pushed 1.18 beta to Rawhide
19:06:00 <gotmax> Yeah
19:06:10 <eclipseo_> well then it is already decided
19:07:01 <gotmax> The update did cause a couple FailToInstall bugs
19:07:11 <gotmax> https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/message/GZAWALM7P77IVMTEHYT5BJO3GIIGELMG/
19:08:13 <eclipseo_> it was fixed afterwards yes? with a rebuild of golist
19:08:25 <gotmax> Yeah, but the affected packages still need to be rebuilt
19:08:30 <jcajka> missing provides?
19:08:51 <gotmax> For some reason, golist was incorrectly returning requires from the stdlib that are not provided by any package
19:09:10 <gotmax> https://bugzilla.redhat.com/show_bug.cgi?id=2033978
19:09:11 <jcajka> go macros stack then?
19:09:17 <eclipseo_> I wanted to ask him about the work on Go modules macros, does anyone know what the status is? Has anyone done some work on this?
19:11:11 <jcajka> I don't know
19:12:15 <jcajka> the go list changes might be worth an upstream report, as it is rather significant shift and it is not documented in the release notes of go1.18
19:12:45 <gotmax> I have another issue to bring up. Can I do so now or should I wait until open floor?
19:13:24 <jcajka> if it is not directly related to go1.18, please wait a bit for open floor
19:13:51 <eclipseo_> nothing was said about this in the previous meeting?
19:14:10 <jcajka> ?
19:14:13 <gotmax> jcajka: golist is something that we maintain. For some reason, rebuilding the package fixed the issue.
19:15:39 <jcajka> gotmax: ok, so i guess it is using some internal parts of the std lib? to provide "go list" like output, right?
19:16:09 <gotmax> Not sure :)
19:16:27 <gotmax> Here is the source code: https://pagure.io/golist
19:19:12 <jcajka> I bit remember, but really this might be bit to much relying on some implementation details
19:19:24 <jcajka> of go compiler, stdlib
19:19:38 <jcajka> that would explain why rebuild fixed it, if that changed
19:20:18 <copperi[m]> it does
19:22:59 <jcajka> might would make sense to extend "go list" with functionality that golist does, but I guess  this is tangential to current topic
19:25:54 <jcajka> I guess we all stuck on this one, could we continue in ticket and move to more topics?
19:25:59 <eclipseo_> ok
19:28:22 <jcajka> Open floor be it
19:28:23 <jcajka> #topic Open Floor
19:29:07 <eclipseo_> gotmax: you had a topic I believe
19:29:10 <gotmax> Yeah
19:29:29 <gotmax> I recently became maintainer of "moby-engine" and was surprised to realize that we have duplicate moby packages
19:29:47 <gotmax> moby-engine, golang-github-docker, golang-github-docker-cli
19:31:31 <eclipseo_> moby-engine is the binaries ie the real package used by end users, i believe it is bundled. golang-github-docker is a library only version used to build other packages. it is unbundled.
19:31:38 <gotmax> Yes
19:32:01 <gotmax> I think it might make sense to have moby-engine provide the binaries and source packages
19:32:49 <eclipseo_> i didn't touch moby engine because it was taken care of by a team at that time. And unbundling it would be a pain
19:33:22 <eclipseo_> even golang-github-docker is missing deps like heketi i believe
19:36:06 <gotmax> Can we do something like this[1] and keep the vendoring?
19:36:09 <gotmax> [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang_templates/#_multi_package
19:37:21 <eclipseo_> i don't see what you want to do with this?
19:37:31 <eclipseo_> it is not a multi package
19:38:46 <gotmax> moby-engine contains both github.com/moby/moby and github.com/docker/cli
19:38:58 <jcajka> IMHO it would be better to debundle moby-engine, if I get correctly that those packages are parts of it
19:39:02 <eclipseo_> the problem is if you keep the vendoringm the libs won't be accessible by other packages to build stuff
19:39:31 <gotmax> I was thinking moby-engine could provide golang-github-moby-devel and golang-github-docker-cli-devel instead of having separate packages
19:39:35 <eclipseo_> jcajka: yes but that's an enor;ous task made of old packages
19:39:44 <jcajka> but I understand that it might not be best from perspective of work needed to accomplish that
19:39:58 <gotmax> I don't think it makes sense to debundle moby-engine
19:40:25 <gotmax> github.com/moby/moby and github.com/docker/cli are always updated at the same time
19:40:37 <gotmax> And need to be tested and built together
19:40:38 <jcajka> eclipseo_: agreeing to that
19:41:11 <eclipseo_> docker-cli is only one piece of the puzzle
19:41:28 <gotmax> moby-engine also bundles tini-static
19:41:34 <gotmax> I think that makes sense to unbundle
19:42:30 <gotmax> Right now we are installing it to /usr/libexec/docker/docker-init
19:42:35 <jcajka> gotmax: IMHO from the perspective of the rpm you either have theses 3 packages(+ more if other package debundle and need part of mobi) or you debundle the mobi-engine, then you have the 3+ packages and lot of work
19:42:38 <gotmax> But I think we can replace that with a symlink
19:45:02 <eclipseo_> i don't see how
19:45:15 <gotmax> How to do what?
19:46:39 <eclipseo_> we have the thing for k8s btw, we have a kubernetes package which is bundled, and various golang-k8s- packages unbundled
19:47:14 <eclipseo_> the separation between the two is mostly because of the "hacks" used to unbundle libraries
19:48:29 <jcajka> eclipseo_: and reducing amount of work, number of packages, right?
19:48:29 <eclipseo_> we don't know if these hack would impact the function of k8s and it would create issues if bugs are reported upstream and the cause is our unconventional method of building
19:50:06 <gotmax> It looks like the podman packagr does something similar to what I'm suggesting
19:50:08 <eclipseo_> the best possible thing zould be to be able to package the actual dependencies defined in go.mod, as currently we only support the latest version
19:50:30 <eclipseo_> we don't really do compat packages because that would be a mess
19:51:06 <gotmax> The spec builds the podman binaries with the vendored libs and then creates a devel package w/o them
19:51:32 <gotmax> But for some reason the devel package is disabled with %bcond_with.
19:51:38 <eclipseo_> hmm this spec uses old old way of packagin Go, it's icky
19:51:51 <gotmax> So I'm not sure if that's because it doesn't work
19:52:06 <gotmax> Yeah I agree. It's messy.
19:52:22 <gotmax> I think part of the reason they do it like that is for RHEL compatibility
19:53:10 <eclipseo_> he does the ln -s vendor src
19:53:18 <eclipseo_> yes i think
19:53:49 <gotmax> Unrelated, but it looks like RH packaged our macros for EL 9
19:54:01 <eclipseo_> i had hope we could have modules for rhel9 but we're not even ready with Fedora
19:54:16 <jcajka> for build or equivalent go commands
19:54:59 <jcajka> "ln -s"^^
19:56:06 <eclipseo_> the problem with doing the "ln -s vendor src" is that other go package might already exists at that location
19:56:54 <gotmax> Currently, moby-engine doesn't actually use %gobuild, anyways
19:56:54 <eclipseo_> for example if you have a bundled golang-x-sys and the actual golang-x-sys package is installed, there would be conflict
19:56:58 <jcajka> sure, you can't use any packaged src dependencies
19:58:08 <jcajka> but for fully vendored package with bundled provides it seems sensible choice
20:00:06 <jcajka> it seems that we are not really moving forward here. It seems to me that you  gotmax and eclipseo_ need to talk about moby and we should look in to the general Go packaging, talk with alexsaezm when he will be around.
20:00:32 <jcajka> And we are running out of time. I will have to step away in a bit.
20:00:36 <gotmax> Fair enough
20:00:38 <eclipseo_> ok
20:00:47 <eclipseo_> i'll send a mail to alex
20:00:56 <copperi[m]> thanks jcajka
20:01:09 <gotmax> You should also copy moby-engine's co-maintainer, @olem.
20:01:13 <eclipseo_> i will think about docker too
20:01:31 <gotmax> The source docker packages are out of date, so I will update them in the meantime
20:01:43 <eclipseo_> good luck
20:01:53 <gotmax> Thanks!
20:02:08 <gotmax> I'm busy after this, so it will probably be later today
20:02:22 <jcajka> thank you all, happy and of the year :)
20:02:30 <jcajka> I will end the meeting in 3mins.
20:02:38 <gotmax> If you have time to take a stab at it, that would be helpful also
20:02:43 <jcajka> happy end of the year...
20:03:02 <gotmax> Happy new year, everyone!
20:03:23 <copperi[m]> Same to you too!
20:04:10 <eclipseo_> have great holidays
20:05:03 <jcajka> #endmeeting