Meeting started at 2026-07-27 18:00:22 UTC

The Meeting name is 'Go SIG meeting'

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

!hi

Vít Smolík: Vít Smolík (smoliicek) - he / him / his

!hi

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

o/

We have two issues tagged (labels?) for the meeting

!forge issue go sig 67

● **Assignee:** Not Assigned

**go/sig #67** (https://forge.fedoraproject.org/go/sig/issues/67):**Evaluate setting CGO_CFLAGS (and related) to Fedora standards**

● **Opened:** 3 months ago by buckaroogeek

● **Last Updated:** 3 months ago

uuuuuuh

I have not had a chance to work on this

didn't know that!

I was working on it few minutes ago

(the didn't know that was for the forge command)

But we could set these flags in either %gobuild or globally in redhat-rpm-config

Or maybe in go.env that we ship by default?

need to flex my zodbot command knowledge

And we'd probably want to test to make sure this doesn't break a bunch of things

meant

That was what

> Impact analysis needed per comment from @gotmax.

I've been thinking about this and I have something but I want you to yell at me first 😄 what about something like:

```

+%go_set_cgo_flags\

+ CGO_CFLAGS="${CGO_CFLAGS:-%{build_cflags}}" ; export CGO_CFLAGS ;\

+ CGO_CXXFLAGS="${CGO_CXXFLAGS:-%{build_cxxflags}}" ; export CGO_CXXFLAGS ;\

+ CGO_FFLAGS="${CGO_FFLAGS:-%{build_fflags}}" ; export CGO_FFLAGS ;\

+ CGO_FCFLAGS="${CGO_FCFLAGS:-%{build_fflags}}" ; export CGO_FCFLAGS ;\

+ CGO_LDFLAGS="${CGO_LDFLAGS:-%{build_ldflags}}" ; export CGO_LDFLAGS ;

```

and then add that to the gobuild and gotest macros?

Yeah, I think something like that makes sense. We'd probably need a way to allow individual packages to disable this

already thought about it 😄

(I mean I have a patch that I didn't submit)

okay, so I think we're in agreement here, just need someone to work on all this?

I can do it myself (the patch is already locally, I just need to figure out how to properly test this locally first, because I don't trust myself writing this without testing on a real package)

if you prefer the go.env approach for any reason...

Testing would be patching go-rpm-macros and doing a mass prebuild, I think

If you file a PR against go-rpm-macros, I can review it first

!hi

Sure, I will also mass prebuild it against a small subset of packages

mikel: Mikel Olasagasti Uranga (mikelo2)

Thanks for taking care of that package review I mailed you about :)

We can move to the next item in the list (which I think has nothing new on it) and then to the open floor.

ack

!forge https://forge.fedoraproject.org/go/sig/issues/60

● issue <namespace> <project> <issue_id> - return a forge issue

**Usage:** !forge <subcommand> [...]

● pr <namespace> <project> <issue_id> - return a forge pull request

oh is just the id

silly me

I think we were mostly in agreement on, although not sure how necessary membership is in the first place now that everything is getting vendored

I think we were mostly in agreement on the new policy, although not sure how necessary membership is in the first place now that everything is getting vendored

!forge issue go sig 60

● **Assignee:** Not Assigned

● **Opened:** a year ago by mikelo2

● **Last Updated:** a year ago

**go/sig #60** (https://forge.fedoraproject.org/go/sig/issues/60):**go-sig new membership policy**

not a member of the sig, but i fo think it looks reasonable

not a member of the sig, but i do think it looks reasonable

np, I had it on my list already, but summer is a challenge for my agenda

+1 to the membership policy

+1

now the question would be... how to "apply it"? manually?

I think I'm +1 to the policy and just adding it to the end of our README as a separate heading. But maybe can we add a section about having some concrete version for needing these elevated privs?

iirc you contacted all current members to see if they’re still active in order to keep them or not

That's something that FESCo usually asks for when evaluating provenpackager applications

Or maybe it was another ticket other than 60 for that?

and this is effectively provenpackager access for all go packages

(because we have the SIG Policy that auto-adds go-sig to everything)

I did (a year ago?)

Maybe try again and is final?

I recall I got a bunch of answers... but I don't recall what I exactly did. I thought I removed some people but I am not sure right now.

(for the record, If I did it, it was because they were not participating at all. But I don't know of the top of my head)

Stuff like this worries me https://src.fedoraproject.org/rpms/gif2png/pull-request/2

A PP touching Go packages to fix something the wrong way (IMO) for the second time

why the need of moving it to a subpackage?

wait... is this a topic for the open floor ? 😛

No, sorry

I mean, because if so, we should move to it already 🙂

Or wait were we not done with the previous topic?

Can we !action someone to file a PR with the proposed policy. And maybe add thing I mentioned about having a justification for requesting elevated privs?

And then move on to open floor (actually)?

the PR is against FESCo?

the PR is against FESCo's?

no, this is about the proposal to create a new policy for Go SIG membership

I was suggesting we add something *inspired* by a different FESCo policy

sorry, that was confusing

yeah I mean, the file PR with aproposed policy... the PR... where?

oh, probably against https://forge.fedoraproject.org/go/sig?

got it, so, if I understood the whole thing, as we seem to be in favor of the change in the policy the best way to move the conversation to a final state is to redact it as a part of the go/sig by a PR... did I get it right?

yes, I think so, since we'd want to document the policy somewhere permanent

now, real open floor 😄

Go ahead

mikel: also had something for after?

wondering if we could find a way forward here?

we need to know if we can get a minimal GVT in RHEL 11 for building vendored go packages or not, and preferably this year

I guess is doable, but [gotmax23](https://matrix.to/#/@gotmax23:fedora.im) might know if there is any challenge with that

I left some feedback on your PR

I think some of the problem is that I'm not 100% sure what RHEL's requirements actually are here

(isn't g-v-t only needed at update preparation time, and not at build-time?)

parts are needed at build time

no, there are also macros to verify licensing and install all the license files for dependencies automatically at buildtime

my two cents: The tooling for helping packaging should be imo in EPEL and just the macros in RHEL

the macros call one of the tools though

and licesing also out of RHEL because of the workflow

if RHEL doesn't want any of this at buildtime, you could ship no-ops for all the macros

But I think you do have to include licenses for dependencies as part of the RPM

Since they're bundled into the package

yes this part we need

but we don't need the tooling for the license checkers, right?

correct

So basically, anything to create a vendored package can be considered a tool and that shouldn't be part of RHEL. But an already prepared package should be able to be built in RHEL without EPEL. This is what I understood from the whole thing when we previously talk about it

correct

What current dependencies of go-vendor-tools (the ELN version) are unwanted in RHEL? There is already functionality to automatically remove the license scanner dependencies that are generated during buildtime.

My other requests was that we have some proper tests to make sure the slimmed down version works. And that we can keep go-vendor-tools up-to-date in CentOS Stream since EPEL packages would use it too.

The go_vendor_archive portion shouldn't need any other external deps, so maybe it would be possible to ship in CRB without a lot of additional headache

didn’t I sent a PR for that?

(On my phone, can’t check much)

the only PR I'm aware of for RHEL is https://gitlab.com/fedora/sigs/go/go-vendor-tools/-/merge_requests/81 from yselkowitz

That PR currently breaks CI for the entire project. It makes an invalid change to the gitlab-ci config

https://gitlab.com/fedora/sigs/go/go-vendor-tools/-/merge_requests/79

But the other parts of the PR (not shipping additional optional deps) on RHEL is fine, I think

oh, yeah, that's already been merged

it disables any (build) dependencies on askalono, trivy, or scancode in ELN and RHEL

which was the main blocker here afaiu

So first we we need to rebase the PR. After that, fix the ci?

for starters at least

yselkowitz: I know I always say this , can I continue your work on this PR?

yselkowitz: can I push to your fork? I don't mind fixing the part of this that's breaking CI

sure

does it have the project contributors can push to fork thing enabled (or whatever the setting is called on Gitlab)?

idk

once that's fixed, I think we can merge this, but I'd really like to get some minimal integration tests written here so I don't have to test it myself (or unknowingly push things that break RHEL)

I can write them

I will be the first using this feature in RHEL with delve

RHEL/CentOS

maybe we can move this to a branch within the main repo so it's easier to collaborate?

and I can add yselkowitz as a commiter if he wants

+1

also, I'd really like to move this off of Gitlab, but there's no Packit support on Fedora Forge :(

that would be ❤️

forgejo is way nicer

nicer/simplier

definitely

I think the Packit team is currently working on some "agentic" RHEL packaging automation ;)

anyways, I think we have a plan here

thank you

Sound good?

sounds perfect to me

any other topics? mikel ?

I mean, any other open floor topics 😛

yeah, one important

go-1.27 broke a few packages. I sent patches upstream for 3 packages, but did not have time to update them downstream

there was a bunch of problems with json v2 as far as know, anything weird?

packages like opentofu are broken until some dependencies support 1.27, I don't recall which big module (grpc?) doesn't support 1.27 yet

for now the problems I saw are rleated to private fields change (xq) or `compress/flate` changes (rclone, some other)

Checked: `vendor/google.golang.org/grpc/internal/transport/handler_server.go:271:18: undefined: http2.TrailerPrefix`

grpc as you said

I am fixing mines, if you are afk I can check yours too

I wanted to mention something if there's a minute in open floor

not afk, just busy with kids with summer holidays :D

go ahead Fabio Valentini 🌈

way more important then 😄

with askalono being the default backend in g-v-t and it being a useful tool, I forked the project since it was unmaintained and now archived on GitHub

I'm planning on tagging a first release soon and packaging it for Fedora then. it would be great if you could send any issues you had with askalono my way so I can fix them :)

ack, thanks for working on that!

I meant to ask if there was any chance to just take over the askalono namespace

taking ownership of Rust crates is annoying so I didn't bother

it requires either cooperation of the original owner *or* the package being obviously name squatting

So, if you do cargo install it is not your fork right?

yes. it has a different name

okay, makes sense. I'll have to think about how to handle the name change in g-v-t

so you have to rename it? askalono-ng? askalono-3000? super-askalono?

I assume you eventually intend to retire the original in Fedora?

askfabio?

😄

and the fact that it starts with SCA only occured to me after it was done

also onion-themed

I named it scallion

yes, eventually, though that's not urgent

> and the fact that it starts with SCA only occured to me after it was done

ooh that's nice

askfabio was good, but I can live with scallion 😅

I don't know if we eventually want to do mass packaging changes to update the name in all go-vendor-tools.toml files, but we can keep `detector = "askalono"` working for now and maybe eventually point it to the new binary and package name

we can add a compat symlink. the CLI is (mostly) compatible.

need help with some tasks?

btw, we are over the hour, not sure if there is anything to discuss, if so and it's not critical we can move it to the go sig issue tracker for the next meeting.

compat symlink would be good for now, but I'll probably eventually get annoyed by the naming and mass change the go-vendor-tools.toml files that specify askalono :D

ack

I've https://forge.fedoraproject.org/go/sig/issues/63 & https://gitlab.com/fedora/sigs/go/go2rpm/-/work_items/60 in my TODO list, but don't know when I'll revisit them

well, if there's nothing else... we can call it for today

fine for me

Today was a very productive chat! Thanks a lot everyone for joining! See you next time!