#meeting-1:fedoraproject.org log

<@alexsaezm:fedora.im>

19:00:03

!startmeeting Go SIG meeting

<@meetbot:fedora.im>

19:00:05

Meeting started at 2025-11-03 19:00:03 UTC

<@meetbot:fedora.im>

19:00:05

The Meeting name is 'Go SIG meeting'

<@alexsaezm:fedora.im>

19:00:09

!topic Roll Call

<@alexsaezm:fedora.im>

19:00:14

Hi everyone! As always we'll wait ~5 minutes for everyone to join.

<@alexsaezm:fedora.im>

19:06:04

Looks like it is going to be a quick one :)

<@alexsaezm:fedora.im>

19:06:17

I'll wait a little more and if not, call it :)

<@mikelolasagasti:matrix.org>

19:09:17

!hello

<@zodbot:fedora.im>

19:09:19

Mikel Olasagasti Uranga (mikelo2)

<@mikelolasagasti:matrix.org>

19:10:05

I’m alive, but been busier than expected lately :(

<@alexsaezm:fedora.im>

19:10:34

I'm glad you are alive :)

<@alexsaezm:fedora.im>

19:10:45

(can't do anything about the busy part though)

<@alexsaezm:fedora.im>

19:11:24

Is there anything you want to bring to the meeting? It looks like nobody else will come

<@gotmax:matrix.org>

19:11:44

!hi

<@zodbot:fedora.im>

19:11:46

Maxwell G (gotmax23) - he / him / his or they / them / theirs

<@gotmax:matrix.org>

19:11:48

Sorry, me got distracted

<@gotmax:matrix.org>

19:11:52

Sorry, I got distracted

<@alexsaezm:fedora.im>

19:12:05

oh hi!

<@mikelolasagasti:matrix.org>

19:12:33

Nothing on my side. Tons of updates pending, will check them during the week

<@mikelolasagasti:matrix.org>

19:13:10

I saw gotmax23 announcing the new doc which is great. Sad I couldn’t help with it though

<@mikelolasagasti:matrix.org>

19:13:25

(And I owe you a mail reply 🤦‍♂️🤦‍♂️)

<@gotmax:matrix.org>

19:13:35

<@gotmax:matrix.org>

19:13:41

Yes, the new guidelines are out 🎉

<@gotmax:matrix.org>

19:14:04

And package retirements of orphaned golang libraries are starting again in six weeks

<@gotmax:matrix.org>

19:14:44

There's some small remaining tasks to do with Go Vendor Tools, but it's mostly complete now

<@gotmax:matrix.org>

19:14:54

I think we have 99 packages that have adopted it last i checked

<@zodbot:fedora.im>

19:15:32

mikelo2 gave a cookie to gotmax23. They now have 50 cookies, 1 of which were obtained in the Fedora 43 release cycle

<@zodbot:fedora.im>

19:15:42

alexsaezm gave a cookie to gotmax23. They now have 51 cookies, 2 of which were obtained in the Fedora 43 release cycle

<@alexsaezm:fedora.im>

19:15:47

that's great news!

<@mikelolasagasti:matrix.org>

19:17:17

Looking forward the retirement of those orphan packages to start having a cleaner packager-dashboard

<@gotmax:matrix.org>

19:18:14

We still have to rename https://gitlab.com/fedora/sigs/go/package-data/-/blob/main/go-vendor-tools-users?ref_type=heads#L47-58

<@alexsaezm:fedora.im>

19:18:14

yeah, the dashboards right now looks a little crazy

<@gotmax:matrix.org>

19:18:26

And I think there's the proposal about multiple golang versions

<@gotmax:matrix.org>

19:18:44

But other than that, we're in pretty good shape

<@alexsaezm:fedora.im>

19:18:55

if you are talking about mine, I was writing it right now

<@gotmax:matrix.org>

19:19:00

Everything has been a lot more stable without all the dependency churn from the -devel packages

<@gotmax:matrix.org>

19:19:26

Yeah

<@gotmax:matrix.org>

19:19:43

I still think updating the Go compiler to new major versions in the middle of a release is a bad idea

<@gotmax:matrix.org>

19:19:55

It always breaks some packages

<@alexsaezm:fedora.im>

19:21:47

Yeah, I am scare of that part to be honest but on the other hand, for example the golang-latest approach has a drawback, that maybe you know how to avoid. My concern with having a golang-latest package is a) duplication of the specfile (although I guess I can check the python approach for this), and b) if people point to that package to build their packages, the result is not that much different from having golang in the same version everywhere

<@alexsaezm:fedora.im>

19:22:46

to be fair, I am writing two proposals. The simple classic one for upgrading go to 1.26 and the unified version. I am not doing the clip technique and try to force the idea :D

<@gotmax:matrix.org>

19:23:10

Right, but I think it's a problem if packages start to FTBFS in the middle of a release

<@alexsaezm:fedora.im>

19:23:20

100%

<@gotmax:matrix.org>

19:23:26

But I also recognize the need for some packages to use a newer supported Golang version for security updates

<@gotmax:matrix.org>

19:23:40

So that's why I lean toward a compat package

<@gotmax:matrix.org>

19:24:42

Or it'd be nice if we could plug into the GOTOOLCHAIN=auto toolchain selection to use toolchains built by Fedora and shipped as RPMs instead of downloading binaries from Google

<@gotmax:matrix.org>

19:25:15

But I understand that either solution would create more work for you who actually maintains golang :)

<@alexsaezm:fedora.im>

19:25:33

hmmmm but the GOTOOLCHAIN would require internet during the build, or you mean change that and integrate it with our build system?

<@alexsaezm:fedora.im>

19:26:24

it would be way simplier with what I propose... but it will be simplier for me and that's not the point :D if I am going to make other's people miserable by FTBFS constantly... no thanks

<@alexsaezm:fedora.im>

19:26:51

I am not familiar with compat packages though, and I wonder if I can do the GOTOOLCHAIN approach, didn't think about that tbh

<@gotmax:matrix.org>

19:27:27

That compat package approach (two conflicting packages that each contain different version of `go`) would be easier

<@gotmax:matrix.org>

19:28:13

But it'd be kind of cool if GOTOOLCHAIN=auto could find toolchains built as RPM and installed somewhere on the filesystem instead of always downloading them from Google

<@gotmax:matrix.org>

19:28:33

But that is not a short term solution, since it'd require upstream code changes

<@gotmax:matrix.org>

19:28:37

But it would be nice :)

<@alexsaezm:fedora.im>

19:29:43

it would be cool... I understand you mean with that approach that our release system will be the same, a version of golang per fedora release, but GOTOOLCHAIN auto will pull rpms into the systems

<@alexsaezm:fedora.im>

19:29:50

only for the end user

<@gotmax:matrix.org>

19:30:46

Basically, but I envision that the user would have to install the RPMs but then `go` would be able to find toolchains installed in another directory instead of requiring the different versions to conflict with each other

<@gotmax:matrix.org>

19:30:59

But conflicting compat packages is a perfectly acceptable approach for now

<@alexsaezm:fedora.im>

19:31:26

I will give it a thought to the GOTOOLCHAIN idea, I like it.

<@alexsaezm:fedora.im>

19:31:35

Do you have an example of a compat package btw?

<@gotmax:matrix.org>

19:33:46

There's a couple ways you can do it

<@buckaroogeek:fedora.im>

19:34:16

Late. Sorry. With respect to GOTOOLCHAIN: a short thread on this topic with kubernetes contributors: https://github.com/kubernetes/kubernetes/issues/135013#issuecomment-3481062906

<@gotmax:matrix.org>

19:34:48

Usually compat packages are named something like `golang1.25` (`<name><version>`) with no separator and they'd all have the appropriate Provides and Conflicts

<@gotmax:matrix.org>

19:35:00

Usually compat packages are named something like `golang1.25` (`<name><version>` without a separator) and they'd all have the appropriate Provides and Conflicts

<@gotmax:matrix.org>

19:35:29

Sometimes there is a default that is just `golang` (`<name>`) without a version suffix

<@gotmax:matrix.org>

19:35:43

I think Brad Smith maintains some versioned compat packages like this for the kubernetes stack

<@gotmax:matrix.org>

19:36:05

https://src.fedoraproject.org/rpms/nodejs24/blob/rawhide/f/nodejs24.spec#_175 is what nodejs does

<@alexsaezm:fedora.im>

19:37:03

but does that mean we need multiple repos?

<@buckaroogeek:fedora.im>

19:37:15

Compat in the sense that kubernetes1.34 and kubernetes1.33 rpms install different versions of the same binary

<@gotmax:matrix.org>

19:37:39

No, the different packages are allowed to conflict with each other

<@alexsaezm:fedora.im>

19:38:26

but how does that work with for example the source file?

<@alexsaezm:fedora.im>

19:38:54

like I don't see in nodejs24 any other version

<@alexsaezm:fedora.im>

19:39:04

so my understanding is that we would need several different repositories

<@alexsaezm:fedora.im>

19:39:09

one per go version

<@gotmax:matrix.org>

19:39:38

Oh, by repositories, you mean package/distgit repositories?

<@alexsaezm:fedora.im>

19:39:42

yes

<@alexsaezm:fedora.im>

19:39:49

git stuff :D

<@gotmax:matrix.org>

19:39:58

Ah right. Yes, each version would have a separate SRPM and spec file.

<@buckaroogeek:fedora.im>

19:40:19

This is what i do with kubernetes, cri-o, and cri-tools

<@alexsaezm:fedora.im>

19:40:19

then there is duplication of the code... and I wonder how it would affect ELN

<@alexsaezm:fedora.im>

19:40:52

also, go versions last for very few months, we would be deprecating packages each 6 months

<@gotmax:matrix.org>

19:40:56

Well, you could use templating or copy-paste, but naturally, there'd be some duplication since each package is different

<@gotmax:matrix.org>

19:41:19

For ELN, the golang<version> packages would just be excluded from content resolver

<@alexsaezm:fedora.im>

19:41:33

oh right

<@alexsaezm:fedora.im>

19:41:38

because we still have golang

<@alexsaezm:fedora.im>

19:41:46

so the latest version is always in golang

<@buckaroogeek:fedora.im>

19:42:14

I use a template for the spec file. the template is the same across all kubernetes repos for example (or can be)

<@gotmax:matrix.org>

19:43:01

I would suggest having a `golang` package at Version `1.x` that stays the same throughout the entire release. Then, we could introduce `golang1.<x+2>` once the shipped version goes EOL.

<@gotmax:matrix.org>

19:43:13

So we would have at most two packages at any given time in a release

<@gotmax:matrix.org>

19:43:36

And I guess when we introduced the second version, if the first one is EOL, you would still only need to update one version

<@alexsaezm:fedora.im>

19:46:07

so if a package breaks during the mass rebuild, could the author go back and select the previous go version?

<@alexsaezm:fedora.im>

19:46:36

so we could find ourselves with go packages in different versions in the same fedora release?

<@gotmax:matrix.org>

19:47:25

I would personally prefer to start each Fedora release with the latest golang and create a compat package for a newer version later int he release cycle

<@gotmax:matrix.org>

19:48:05

I would prefer to not have older Golang versions that will go EOL less than half way through a Fedora release

<@alexsaezm:fedora.im>

19:48:23

that's why I was asking

<@gotmax:matrix.org>

19:49:04

If you feel strongly that having one Golang version that's always up to date is more logical, we can try to get an exception from FESCo, but it'd be important that the Go SIG does mass prebuilds and fixes things before pushing it

<@alexsaezm:fedora.im>

19:49:27

I think is a quite complex process and I am not sure about the benefits (apart from the obvious big one which is not create FTBFS in the middle of the release)

<@alexsaezm:fedora.im>

19:49:47

on the other hand, your compat idea would be the first step to try the GOTOOLCHAIN approach

<@gotmax:matrix.org>

19:49:48

And I guess with vendored packages using go modules mode that enforces compatibility with the minimum `go` version in `go.mod`, it'd be less disruptive

<@gotmax:matrix.org>

19:50:19

But it's just no fun when things break in the middle of a release, that why I'm pushing back a bit against the original proposal :)

<@alexsaezm:fedora.im>

19:50:44

I am only suggesting this idea because we now have the go vendor tools and ideally that fixes the main problem (very ideally of course)

<@gotmax:matrix.org>

19:51:24

I wouldn't say the compat approach is hugely complex once it's set up, but it is admittedly more to think about up frontand the Provides and Conflicts need to be thought out

<@gotmax:matrix.org>

19:51:54

But I guess we can try going forward with mass prebuilds and hoping that it won't find too much breakage now that we're building with go modules

<@gotmax:matrix.org>

19:52:11

But I don't think pushing new golang versions to stable releases that break existing packages is a good idea

<@alexsaezm:fedora.im>

19:52:29

I wish we could run the mass prebuild automatically though

<@alexsaezm:fedora.im>

19:52:50

I trully want to find a middle ground here (ok that sounds too much like a manager :-/ )

<@alexsaezm:fedora.im>

19:53:17

I will write the proposal and bring it to FESCo if you don't mind, and we can discuss it there, mostly because this meeting is getting long :)

<@alexsaezm:fedora.im>

19:53:37

just to be clear, I am not 100% sure about the idea because I don't want FTBFS everywhere

<@alexsaezm:fedora.im>

19:53:49

not trying to push it in any way

<@alexsaezm:fedora.im>

19:53:59

our current approach is nice to me and the golang-latest copr is fine by me

<@alexsaezm:fedora.im>

19:54:06

but discoverability is a problem I guess

<@gotmax:matrix.org>

19:55:01

I guess the middle ground between having no updates at all and making the main `golang` package rolling _is_ compat packages, but I'm not sure what's the middle ground between maintaining multiple packages and making the main `golang` package rolling

<@gotmax:matrix.org>

19:55:11

But I recognize all approaches have downsides

<@gotmax:matrix.org>

19:55:25

And I'm happy to discuss further async on the mailing list :)

<@alexsaezm:fedora.im>

19:55:36

epic, thank you <3

<@alexsaezm:fedora.im>

19:55:59

I will bring this to FESCo

<@alexsaezm:fedora.im>

19:56:08

thank you

<@gotmax:matrix.org>

19:56:31

Yeah, sure, thanks for discussing it!

<@alexsaezm:fedora.im>

19:56:43

thank you for your ideas!

<@alexsaezm:fedora.im>

19:56:48

and I guess we can call it

<@gotmax:matrix.org>

19:56:48

One note is that FESCo tends to prefer RFCs to happen on the mailing list over in their issue tracker

<@alexsaezm:fedora.im>

19:57:13

ok then to the mailing list!

<@gotmax:matrix.org>

19:57:17

So unless you have a concrete Change proposal to submit using that process, following up on the ML is also fine

<@gotmax:matrix.org>

19:57:32

Works for me :)

<@alexsaezm:fedora.im>

19:57:47

I was writing the proposal in the wiki but too formal too soon I guess

<@alexsaezm:fedora.im>

19:57:53

I will send an email right away

<@alexsaezm:fedora.im>

19:57:59

thanks everyone!

<@alexsaezm:fedora.im>

19:58:15

!endmeeting