#meeting-1:fedoraproject.org log

<@alexsaezm:fedora.im>

18:00:11

!startmeeting Go SIG meeting

<@meetbot:fedora.im>

18:00:12

Meeting started at 2025-08-25 18:00:11 UTC

<@meetbot:fedora.im>

18:00:12

The Meeting name is 'Go SIG meeting'

<@alexsaezm:fedora.im>

18:00:16

!topic Roll Call

<@alexsaezm:fedora.im>

18:00:21

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

<@buckaroogeek:fedora.im>

18:00:27

!hi

<@zodbot:fedora.im>

18:00:29

Brad Smith (buckaroogeek)

<@alexsaezm:fedora.im>

18:00:50

<@buckaroogeek:fedora.im>

18:01:17

Greetings!

<@qulogic:fedora.im>

18:01:39

!hi

<@zodbot:fedora.im>

18:01:40

Elliott Sales de Andrade (qulogic)

<@mikelolasagasti:matrix.org>

18:02:32

!hi

<@zodbot:fedora.im>

18:02:37

Mikel Olasagasti Uranga (mikelo2)

<@alexsaezm:fedora.im>

18:05:27

I see several issues in the tracker; two of them were updated a a few minutes ago.

<@gotmax:matrix.org>

18:05:58

!hello

<@zodbot:fedora.im>

18:06:00

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

<@alexsaezm:fedora.im>

18:06:04

<@alexsaezm:fedora.im>

18:06:18

!topic Wrong naming for binary packages

<@alexsaezm:fedora.im>

18:06:21

!link https://pagure.io/GoSIG/go-sig/issue/63

<@alexsaezm:fedora.im>

18:06:32

I think this one is by mikel

<@mikelolasagasti:matrix.org>

18:06:41

yes, just opened it

<@mikelolasagasti:matrix.org>

18:06:57

we've a bunch of binary packages with the wrong naming after adopting go-vendor-tools or in the process of doing it

<@mikelolasagasti:matrix.org>

18:07:41

does it make sense to track it on a main BZ ticket and have a BZ per package that is wrong ?

<@alexsaezm:fedora.im>

18:08:04

hmmmmm that's going to be a lot of BZ 😄

<@gotmax:matrix.org>

18:08:13

https://gitlab.com/fedora/sigs/go/package-data/-/blob/main/go-vendor-tools-users?ref_type=heads#L35-44

<@gotmax:matrix.org>

18:08:16

It's only 9 so far

<@gotmax:matrix.org>

18:08:27

And golang-x-mobile which hasn't been built yet

<@gotmax:matrix.org>

18:08:46

https://src.fedoraproject.org/rpms/golang-github-containerd-continuity/pull-request/1 is in progress, and I'd rather rename that package instead of merging that PR and doing it later

<@mikelolasagasti:matrix.org>

18:08:57

I believe many binaries are going to disappear sooner or later, I believe lot of helper/test binaries have been built that might not have any real usage

<@gotmax:matrix.org>

18:09:10

Agreed

<@gotmax:matrix.org>

18:09:26

go2rpm included those binaries by default for library packages, but that didn't necessarily mean that anyone was using them

<@alexsaezm:fedora.im>

18:09:26

I have a question about renaming them... what happens with ELN?

<@alexsaezm:fedora.im>

18:09:35

they will change

<@gotmax:matrix.org>

18:09:45

(See the situation where there are three docker-distribution packages, for example)

<@mikelolasagasti:matrix.org>

18:09:59

ELN... I guess so

<@gotmax:matrix.org>

18:10:07

Which are the packages that are in ELN again?

<@gotmax:matrix.org>

18:10:13

ipp-usb and md2man?

<@alexsaezm:fedora.im>

18:10:18

yep

<@mikelolasagasti:matrix.org>

18:10:18

it's being tracked in https://github.com/fedora-eln/eln/issues/240 iiuc

<@alexsaezm:fedora.im>

18:10:23

and I third one I think

<@buckaroogeek:fedora.im>

18:10:29

I need to contact the maintainers on one of those

<@mikelolasagasti:matrix.org>

18:10:30

git-lfs

<@gotmax:matrix.org>

18:10:41

git-lfs doesn't have the golang-* name so that's alright

<@gotmax:matrix.org>

18:10:58

ipp-usb is a subpackage of golang-github-openprinting-ipp-usb but that source package name would also change

<@alexsaezm:fedora.im>

18:11:04

cc yselkowitz:

<@gotmax:matrix.org>

18:11:13

Ha, I was about to tag him also

<@gotmax:matrix.org>

18:11:45

But I don't think it's a huge deal; I think it's mainly making a simple change to the content-resolver data, not sure if anything else is needed

<@alexsaezm:fedora.im>

18:12:43

oh no no, but I was reading Mikel's ticket, and I saw the md2man reference, which is kinda critical in centos/rhel and I just wondered.

<@gotmax:matrix.org>

18:14:11

So back to Mikel's ticket...

<@gotmax:matrix.org>

18:14:37

You are suggesting filing Bugzillas against only those ~10 packages that I linked to?

<@mikelolasagasti:matrix.org>

18:15:37

yes... it may not make sense, but we need somehow to fix it so that was one idea to push for it

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-prometheus-prom2json

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-evanw-esbuild

<@mikelolasagasti:matrix.org>

18:16:11

golang-x-*

<@mikelolasagasti:matrix.org>

18:16:11

golang-honnef-tools

<@mikelolasagasti:matrix.org>

18:16:11

I recognize the following packages:

<@mikelolasagasti:matrix.org>

18:16:11

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-acme-lego

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-prometheus-alertmanager

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-prometheus

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-projectdiscovery-chaos-client

<@mikelolasagasti:matrix.org>

18:16:11

golang-mvdan-gofumpt

<@mikelolasagasti:matrix.org>

18:16:11

golang-github-cpuguy83-md2man

<@gotmax:matrix.org>

18:16:52

golang-mvdan-gofumpt does not use go-vendor-tools yet

<@gotmax:matrix.org>

18:17:06

But should be renamed as part of that change

<@mikelolasagasti:matrix.org>

18:17:36

that's what I meant, not only for those that already changed, but as all of them will be (or not) converted they'll need to be renamed

<@alexsaezm:fedora.im>

18:18:11

I think I prefer several bugs (we can always have a bug tracking all together), we can keep tabs on the state of each one of them (not sure how much time renaming will take).

<@gotmax:matrix.org>

18:18:38

I don't want to file any tickets against packages that have not been converted yet, as that's currently opt-in until the Guidelines are approved and Go Vendor Tools becomes more official

<@gotmax:matrix.org>

18:19:23

But creating a tracking bug against go-vendor-tools and then filing bugs against the existing packages that have been improperly converted and need to be renamed that block the tracking bug now is probably fine

<@gotmax:matrix.org>

18:19:43

But I agree with your point about packages with random test/utility binaries

<@gotmax:matrix.org>

18:20:15

If those packages are not used and/or are broken, they should just be orphaned and allowed to be automatically retired instead of spending time converting them to go-vendor-tools or renaming them

<@alexsaezm:fedora.im>

18:21:42

I bet there are several ones in this situation

<@mikelolasagasti:matrix.org>

18:22:43

last FESCo minutes were reporting non-responsive process for Eclipseo has been approved, so that one will orphan lot of those packages

<@gotmax:matrix.org>

18:23:01

That's true

<@alexsaezm:fedora.im>

18:23:02

*sigh* hope he is ok

<@gotmax:matrix.org>

18:23:45

Although he has so many packages that the Pagure API timed out when they tried to retrieve the list of packages that he maintains to orphan

<@gotmax:matrix.org>

18:24:17

But anyways, I do hope he is okay and am very appreciative of all the work he's done over the years to help the Go ecosystem in Fedora

<@mikelolasagasti:matrix.org>

18:24:50

it was great to meet him in-person for a few minutes at FOSDEM

<@mikelolasagasti:matrix.org>

18:25:27

I really hope he is doing great and also thankful for all his help when I started

<@mikelolasagasti:matrix.org>

18:26:15

so, regarding the ticket... I'll open a BZ main ticket against go-vendor-tools and create for the packages already converted

<@gotmax:matrix.org>

18:26:39

!action mikelo2 "so, regarding the ticket... I'll open a BZ main ticket against go-vendor-tools and create for the packages already converted"

<@gotmax:matrix.org>

18:26:43

Thanks

<@gotmax:matrix.org>

18:27:06

I retired a bunch of golang-* leaves yesterday as part of the orphaned packages process

<@gotmax:matrix.org>

18:27:33

Any orphaned golang-* package that is not a leaf is temporarily exempt from retirement

<@mikelolasagasti:matrix.org>

18:27:38

106 of them 😅

<@mikelolasagasti:matrix.org>

18:27:39

https://gitlab.com/fedora/sigs/go/package-data/-/commit/fe3dfb551f738b03ce391a9712a0ec746ca6d964

<@gotmax:matrix.org>

18:28:15

So once they figure out the Pagure API issue, any package of eclipseo's that is still used will remain in limbo until that exemption is lifted

<@gotmax:matrix.org>

18:28:42

There's a note about it at the top of the orphaned packages report now; I assume people have seen it...

<@gotmax:matrix.org>

18:29:12

Okay... so it sounds like we made a decision about #63 and can move on?

<@mikelolasagasti:matrix.org>

18:29:33

yes

<@alexsaezm:fedora.im>

18:30:49

yep

<@alexsaezm:fedora.im>

18:30:52

let me....

<@alexsaezm:fedora.im>

18:31:07

!topic Perform mass rebuild after golang 1.25.0 GA is released

<@alexsaezm:fedora.im>

18:31:12

!link https://pagure.io/GoSIG/go-sig/issue/62

<@gotmax:matrix.org>

18:32:04

I finished this last weekend (not yesterday, the one before...)

<@gotmax:matrix.org>

18:32:44

I closed I think over 100 FTBFS tickets that were broken because of the debuginfo thing, so I'd consider it a success

<@gotmax:matrix.org>

18:33:40

https://floss.social/@maxgot/115051191834620501 is the retrospective

<@gotmax:matrix.org>

18:33:52

It thankfully all worked out in the end...

<@gotmax:matrix.org>

18:35:07

I'm not sure if this is something we want to do in the future so that we don't have any packages built with pre-release Go compilers (the mass rebuild usually happens before the Go GA)

<@gotmax:matrix.org>

18:35:11

or if this should just be a one time thing because of the debuginfo problem that broke a bunch of packages that would've otherwise succeeded

<@mikelolasagasti:matrix.org>

18:36:24

I don't track how many changes exist between RC and GA, but if there are a few it makes sense to rebuild with final GA

<@alexsaezm:fedora.im>

18:38:03

I think we already discussed in the past doing mass rebuilds here and there. From the perspective of the ABI, it shouldn't be necessary, but we all know that there are always weird changes not only in the toolchain but in relation to other packages (like gcc in the previous release and debuginfod in this one). Also, I am considering moving everything to one single version of Go instead of one per release, so I guess mass rebuilds are a nice plus

<@gotmax:matrix.org>

18:42:32

Okay, so I guess we can consider it on a case-by-case basis (e.g., if there's some major bug or problem in one of the Go 1.26 RCs and we need to do it again next cycle)

<@alexsaezm:fedora.im>

18:43:09

Yeah, or if there is a disgusting, huge CVE, for example.

<@gotmax:matrix.org>

18:43:29

Exactly

<@alexsaezm:fedora.im>

18:43:42

if you prefer to make it a routine thing... not sure if there is any value on that apart from having an schedule?

<@alexsaezm:fedora.im>

18:44:02

like every month we do a mass rebuild

<@gotmax:matrix.org>

18:44:20

(I also have some updates about the Go Vendor work but have a hard cut off at 21:00 CEST)

<@alexsaezm:fedora.im>

18:44:49

I don't think there is anything else to discuss if you want to move to the go vendor topic

<@gotmax:matrix.org>

18:45:37

I tagged https://pagure.io/GoSIG/go-sig/issue/51 for meeting if we want to discuss that more next time

<@gotmax:matrix.org>

18:46:11

There are some questions about how to handle stable branches, as it's pretty unusual to make mass changes (e.g., rebuilds) to branches other than rawhide

<@alexsaezm:fedora.im>

18:46:50

Do we move to open floor then and talk about the go vendor work?

<@gotmax:matrix.org>

18:47:09

SGTM, we can always come back to the other issue :)

<@alexsaezm:fedora.im>

18:47:25

!topic Open floor

<@gotmax:matrix.org>

18:48:27

I guess I'll start by copying what I wrote in the Golang channel yesterday

<@gotmax:matrix.org>

18:48:34

I started working on a %gocheck2 macro/script with a similar interface to %gocheck but that uses Go modules mode and doesn't rely on the golist project

<@gotmax:matrix.org>

18:48:40

The current draft of the Packaging Guidlines are rendered at https://fedora.gitlab.io/sigs/go/packaging-guidelines-fork/packaging-guidelines/Golang/. I haven't had a ton of time to work on them, but they're coming along nicely.

<@gotmax:matrix.org>

18:48:57

!info The current draft of the Packaging Guidlines are rendered at https://fedora.gitlab.io/sigs/go/packaging-guidelines-fork/packaging-guidelines/Golang/.

<@alexsaezm:fedora.im>

18:49:47

so no golist after this?

<@qulogic:fedora.im>

18:49:53

Is this different from the `%gotest` I've been seeing?

<@gotmax:matrix.org>

18:50:17

%gotest has "always" been around

<@gotmax:matrix.org>

18:50:31

It's just `go test` with linker flags and such

<@qulogic:fedora.im>

18:51:10

right, and in module mode, what specifically do we need extra?

<@gotmax:matrix.org>

18:51:11

This new script provides a similar interface to `%gocheck` with the ability to ignore specific import paths (the `-d` and `-t` flags)

<@gotmax:matrix.org>

18:51:55

I wanted to just switch the guidelines to only mention `%gotest`, but people seemed to rely on `%gocheck`'s features, so I didn't want to get rid of it completely

<@gotmax:matrix.org>

18:52:05

I originally wanted to just switch the guidelines to only mention `%gotest`, but people seemed to rely on `%gocheck`'s features, so I didn't want to get rid of it completely

<@mikelolasagasti:matrix.org>

18:53:09

does it make sense to hide the "awk" method to skip tests behind a macro?

<@gotmax:matrix.org>

18:53:48

It also no longer relies on the goipath macro or any of the `-z` lua stuff or assume that `%goprep` has been run

<@gotmax:matrix.org>

18:54:07

It just reads the go path from the go.mod file in the current directory

<@qulogic:fedora.im>

18:54:57

latest Go has a `-skip` flag, I wonder it that should be preferred now?

<@gotmax:matrix.org>

18:55:17

Is it `-skip` or `-ignore`?

<@qulogic:fedora.im>

18:55:50

it's `-run` to select, `-skip` to ignore

<@gotmax:matrix.org>

18:55:59

But yes, that's usually better, but sometimes those awk invocations are easier to format when there's a lot of test skips

<@gotmax:matrix.org>

18:56:29

Currently, `%gocheck2 -- -skip TestSomething -skip TestSomethingElse` works

<@gotmax:matrix.org>

18:56:39

(Anything after `--` is passed directly to `go test`)

<@gotmax:matrix.org>

18:56:46

But we could probably make that nicer

<@gotmax:matrix.org>

18:57:08

What about a `-s` flag?

<@gotmax:matrix.org>

18:57:21

So `%gocheck2 -s TestSomething -s TestSomethingElse`?

<@gotmax:matrix.org>

18:57:56

Okay, I can add that

<@alexsaezm:fedora.im>

18:58:58

to skip? I like it

<@alexsaezm:fedora.im>

19:00:17

we are at the top of the hour btw

<@alexsaezm:fedora.im>

19:00:31

do we want to keep going? or we should leave it for the next meeting?

<@gotmax:matrix.org>

19:01:21

I have to get somewhere, so maybe next metting?

<@alexsaezm:fedora.im>

19:01:30

sure

<@mikelolasagasti:matrix.org>

19:01:33

I just wanted to ask gotmax23 about the removal of `-x` flag. Do you plan to merge it soon?

<@gotmax:matrix.org>

19:01:39

But please take a look at https://fedora.gitlab.io/sigs/go/packaging-guidelines-fork/packaging-guidelines/Golang/ and provide feedback!!

<@gotmax:matrix.org>

19:01:58

I'm waiting for alexsaezm's feedback on that

<@alexsaezm:fedora.im>

19:02:22

answered

<@mikelolasagasti:matrix.org>

19:02:24

he added a +1 a few minutes ago, so I guess we're good

<@gotmax:matrix.org>

19:03:03

To be clear, you support removing it entirely, even on RHEL 19?

<@gotmax:matrix.org>

19:03:06

*RHEL 10

<@alexsaezm:fedora.im>

19:04:01

yeah

<@gotmax:matrix.org>

19:04:19

Okay, cool. I'll get on that.

<@gotmax:matrix.org>

19:04:20

Thank you

<@alexsaezm:fedora.im>

19:04:43

well it won't go away as easily on RHEL, but yes, it's too verbose and people can always add it

<@gotmax:matrix.org>

19:06:31

Well, I'd like it if we could continue backporting go-rpm-macros releases to RHEL, and I plan to remove the flag entirely from the next release

<@alexsaezm:fedora.im>

19:06:59

sure, it wont be a problem

<@gotmax:matrix.org>

19:06:59

So if it would prevent rebasing the RHEL package to the next release, I can be flexible and disable the flag conditionally

<@gotmax:matrix.org>

19:07:09

Okay, got it

<@alexsaezm:fedora.im>

19:07:30

it's just a matter of the schedule, but I don't see any reason why we don't want it remove

<@alexsaezm:fedora.im>

19:08:05

we are going to keep rebasing the package for sure, the last thing we want is to be away from Fedora with random changes that don't add any value to people

<@gotmax:matrix.org>

19:08:39

Cool, sounds like we're on the same page

<@alexsaezm:fedora.im>

19:09:08

yep

<@alexsaezm:fedora.im>

19:09:20

we should call it for today 🙂

<@gotmax:matrix.org>

19:09:26

Indeed

<@alexsaezm:fedora.im>

19:09:31

Thanks everyone!

<@alexsaezm:fedora.im>

19:09:38

and sorry for making this so long 🙂

<@alexsaezm:fedora.im>

19:09:49

we'll see each other in the next meeting!

<@alexsaezm:fedora.im>

19:09:52

!endmeeting