18:00:08 <alexsaezm> #startmeeting Go SIG meeting
18:00:08 <zodbot> Meeting started Mon Jul  4 18:00:08 2022 UTC.
18:00:08 <zodbot> This meeting is logged and archived in a public location.
18:00:08 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:08 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:00:30 <alexsaezm> #topic Roll Call
18:00:39 <gotmax[m]> .hello gotmax23
18:00:40 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
18:00:47 <gotmax[m]> How's everyone doing?
18:00:55 <gotmax[m]> Everyone in this case is just you :)
18:01:02 <alexsaezm> Can't complain :) you?
18:01:14 <alexsaezm> Hope more people attend, if not, it's going to be quick I guess...
18:01:43 <gotmax[m]> There was a mass shooting here at a 4th of July parade here, so I'm a bit shaken, but I'm good besides that.
18:01:59 <alexsaezm> oh my
18:02:09 <gotmax[m]> Sorry to be a bit of a downer
18:02:27 <alexsaezm> no no!, hope everything is ok, or at least, as good as it can be given the situation :(
18:03:39 <gotmax[m]> jcajka_, eclipseo, mikelo, Fale: Ping
18:03:59 <gotmax[m]> Also, do you want to `#chair` me?
18:04:01 <Fale[m]> @[gotmax (He/Him)] pong
18:04:12 <alexsaezm> #chair gotmax (He/Him)
18:04:12 <zodbot> Current chairs: (He/Him) alexsaezm gotmax
18:04:14 <alexsaezm> worked?
18:04:17 <gotmax[m]> Hi Fale!
18:04:26 <Fale[m]> .hello fale
18:04:27 <zodbot> Fale[m]: fale 'Fabio Alessandro Locati' <me@fale.io>
18:05:11 * alexsaezm never realized that he has the same as Fale
18:05:27 <gotmax[m]> #chair Fale
18:06:03 <Fale[m]> @alexsaezm I think you are missing a world in that message... the same what?
18:06:13 <alexsaezm> true
18:06:14 <alexsaezm> name
18:06:31 <gotmax[m]> Fale: There seems to be something wrong with your nick on IRC
18:06:38 <alexsaezm> I usually short my name to Alex, but it's Alejandro which is the Spanish version of Alessandro :D
18:06:40 <gotmax[m]> Because charing you and karma doesn't seem to work
18:06:44 <gotmax[m]> #chair
18:06:48 <Fale[m]> part of it :-D. My first name is "Fabio Alessandro", but still part of it is the same
18:06:57 <alexsaezm> haha
18:07:13 <Fale[m]> @[gotmax (He/Him)] yeah, not sure how to convince FAS that I'm myself :-D
18:07:21 <gotmax[m]> You also share part of your name with decathorpe
18:07:34 <gotmax[m]> Who you took the spring cleaning thing from :)
18:07:56 <alexsaezm> we are everywhere! :D
18:08:19 <gotmax[m]> Meanwhile, I'm not aware of any other Maxwells in the project
18:08:35 <alexsaezm> Sounds uncommon to me
18:08:38 <Fale[m]> also true :-D
18:08:43 <gotmax[m]> Actually, scratch that
18:08:49 <gotmax[m]> There maxamillion
18:09:21 <gotmax[m]> But I guess their first name is Adam according to FAS
18:09:34 <gotmax[m]> Anyways...
18:09:46 <alexsaezm> yeah, 10 minutes for the roll call :)
18:09:49 <gotmax[m]> I tagged 3 issues with meeting in the issue tracker
18:09:54 <alexsaezm> I guess we can move to the next thing
18:09:55 <alexsaezm> yes
18:09:59 <alexsaezm> let me put the correct topic...
18:10:27 <gotmax[m]> `#topic figuring out who shares names with eachother`
18:10:46 <alexsaezm> I don't think we have actions for that, but we can do that :D
18:10:56 <alexsaezm> #topic EPEL 9 https://pagure.io/GoSIG/go-sig/issue/37
18:11:28 <gotmax[m]> So currently, there's a few issues with the go-rpm-macros in RHEL that are stalling this
18:12:29 <gotmax[m]> It would be nice to get the fixes into c9s soon, but there's a problem with EPEL 9 Next that would cause problems if we tried to build against there.
18:12:38 <alexsaezm> what problem?
18:12:42 <gotmax[m]> EPEL * Next  builds against Stream instead of RHEL
18:13:03 <gotmax[m]> With the EPEL 9 Next buildroot or with the RHEL go-rpm-macros?
18:13:13 <gotmax[m]> * the RHEL's go-rpm-macros?
18:13:29 <alexsaezm> the epel9 one
18:13:42 <gotmax[m]> Let me find it
18:13:45 <alexsaezm> thanks
18:14:12 <gotmax[m]> https://pagure.io/releng/issue/10852
18:14:18 <Fale[m]> I wonder what's the effort we are willing to put into this. Maintaining EL9N is going to be massive, are we willing to put ourself into it? Shall we try to optimize our Fedora workflow before adding more (problematic, in the long term) branches?
18:14:49 <gotmax[m]> The other solution would be to add a temporary fix to epel-rpm-macros and not build in Next at all
18:14:58 <gotmax[m]> I agree, Fale.
18:15:14 <gotmax[m]> There's a lot of FTBFS packages in the go ecosystem
18:15:26 <gotmax[m]> That I think should be our priority
18:15:54 <Fale[m]> yeah, and if my calculation are right we maintain ~2k packages for ~500 binaries (ie: applications useful for the users). Is this really sustainable
18:16:23 <gotmax[m]> I think it's closer to 400
18:16:26 <gotmax[m]> But you're right, it's a lot
18:16:50 <Fale[m]> the 4:1~5:1 ratio I think it's very different from any other in Fedora space
18:17:06 <gotmax[m]> You mean in terms of libraries to useful applications?
18:17:12 <Fale[m]> yes
18:17:32 <gotmax[m]> Yeah, I wanted to bring this up later through the lens of the docker ecosystem.
18:17:44 <gotmax[m]> But having this many libraries is the cost of unbundling
18:18:11 <gotmax[m]> Go projects often have very large dependency sprawls
18:18:20 <Fale[m]> sorry for having anticipating it then, my point was on the time we have and where we want to focus it, otherwise we risk to do many branches, but poorly
18:18:58 <gotmax[m]> Nah, you didn't really anticipate it. I was going to talk about something related but slightly different
18:19:16 <gotmax[m]> I think we really need to include eclipseo in this conversation, who maintains a majority of go packages
18:19:41 <gotmax[m]> He said he wasn't going to be around this week
18:19:54 <alexsaezm> We can defer this to the next meeting
18:20:27 <alexsaezm> but it has a difficult fix...
18:20:27 <gotmax[m]> At least, I will try to get a temporary fix into epel-rpm-macros.
18:20:41 <gotmax[m]> For the macro issues until they're fixed in RHEL
18:20:56 <gotmax[m]> But I agree we should have a larger conversation about this
18:21:38 <alexsaezm> out of curiosity, Fale how did you evaluate the ratio? the applications useful for the users
18:22:30 <Fale[m]> @alexsaezm ~500 is the number of packages containing a binary file. The "useful ones" are probably even lower than that
18:22:43 <alexsaezm> hahaha got it
18:23:02 <gotmax[m]> And then the total is the amount of packages that depend on golang at buildtime
18:23:05 <gotmax[m]> I would guess
18:23:12 <Fale[m]> exactly
18:23:56 <alexsaezm> I would like to see how other ratios for other packages like python or ruby
18:24:12 <alexsaezm> for nothing special, just sounds interesting
18:24:14 <gotmax[m]> I would guess python is lower
18:24:20 <gotmax[m]> I don't maintain any ruby packages
18:24:53 <alexsaezm> Anyway... do we have any next action for this topic?
18:25:12 <gotmax[m]> I started writing a summary in the issue
18:25:20 <alexsaezm> lovely
18:25:38 <gotmax[m]> I will work on getting a temporary fix into epel-rpm-macros to fix the issues with RHEL's go-rpm-macros. We would like to have a larger conversation regarding whether this (maintaining the go ecosystem in EPEL 9) is worth our time and how we want to direct our efforts considering the amount of packages we already maintain in Fedora.
18:25:49 <gotmax[m]> Is that good with you all?
18:25:57 <alexsaezm> Sounds awesome to me
18:26:26 <Fale[m]> wfm
18:26:43 <gotmax[m]> #action gotmax to get a temporary fix for RHEL's go-rpm-macros issues into epel-rpm-macros
18:27:31 <gotmax[m]> #agreed defer discussion about how/should we branch for EPEL 9 to next meeting
18:28:00 <gotmax[m]> I probably should've checked before marking that as agreed
18:28:13 <alexsaezm> sounds good to me :)
18:28:24 <alexsaezm> next one?
18:28:28 <gotmax[m]> +1
18:28:38 <alexsaezm> #topic F35 Go Mini Mass Rebuild https://pagure.io/GoSIG/go-sig/issue/41
18:28:47 <gotmax[m]> Not a lot to discuss here
18:28:57 <gotmax[m]> I just wanted to inform you all
18:29:09 <gotmax[m]> And possibly get people to review the announcement text if they'd like to
18:30:05 <Fale[m]> what's the strategy for the packages not controllable by go-sig? I've seen you are checking them out in a different folder, but not sure what will happen to them
18:30:20 <gotmax[m]> That's in the linked announcement text
18:30:25 <gotmax[m]> I will ask a PP to handle it
18:30:43 <gotmax[m]> I might consider applying to be one, but I'm not sure they'd accept me
18:30:47 <Fale[m]> sorry for that, I've missed it, but thanks for clarifiing it :-)
18:30:56 <Fale[m]> same here
18:31:02 <gotmax[m]> #info https://pad.snopyta.org/jReaqbfeSmSikZdD1RuD2A#
18:31:10 <alexsaezm> oh damn, I realized I didn't finish my packages... sorry Fale , I'll do it this week
18:32:10 <gotmax[m]> That's all from me for this topic
18:33:18 <alexsaezm> awesome
18:33:23 <gotmax[m]> Oh, also there's the other CVE
18:33:24 <gotmax[m]> in golang
18:33:29 <alexsaezm> which one?
18:33:34 <gotmax[m]> https://bugzilla.redhat.com/show_bug.cgi?id=2103255
18:33:44 <gotmax[m]> I don't think that's been backported
18:33:45 <alexsaezm> oh that one...
18:34:19 * gotmax[m] is not happy with all of the emails he gets from prodsec's bugs
18:34:46 <alexsaezm> hmmmm no it's not backported
18:34:57 <alexsaezm> I'll evaluate it this week
18:35:19 <alexsaezm> right... I need to talk with prodsec, I have the task burried in my to-do list
18:35:53 <gotmax[m]> It looks like they sent `This bug is now closed. Further updates for individual products will be
18:35:53 <gotmax[m]> reflected on the CVE page(s):` like a billion times
18:36:11 <Fale[m]> Mikelo and myself had calls with productsec on a different CVE. Do you have contancts there @alexsaezm or do you need a connection?
18:36:47 <gotmax[m]> I think their emails DOSed someone's mail server
18:36:56 <alexsaezm> Mikelo sent me information but I didn't have the time to read it, I don't usually talk with product sec on daily basis
18:37:40 * alexsaezm hopes mikelo doesn't read meeting log...
18:37:46 <alexsaezm> logs*
18:37:56 <gotmax[m]> :)
18:38:02 <Fale[m]> :-D
18:38:46 <alexsaezm> #action alexsaezm will read the information mikelo sent him and contact product security
18:38:47 <gotmax[m]> When you fix golang CVEs, it would be helpful if you could create buildroot overrides so all new package builds pick up the patches
18:39:17 <alexsaezm> hmmm, nice idea
18:39:27 <alexsaezm> do we have information about that?
18:39:29 <gotmax[m]> `fedpkg override create --duration 10` in the dist-git clone on the correct branch
18:39:31 <gotmax[m]> WDYM?
18:39:35 <gotmax[m]> By information
18:39:41 <alexsaezm> just that :D
18:39:44 <alexsaezm> thanks
18:39:58 <gotmax[m]> You can also use the Bodhi web interface
18:40:03 <gotmax[m]> But it's quicker on the CLI
18:40:08 <alexsaezm> cli ftw
18:40:28 <alexsaezm> #info fedpkg override create --duration 10 in the dist-git clone on the correct branch
18:40:56 <alexsaezm> any next action for this topic?
18:41:14 <gotmax[m]> #action alexsaezm to look into fixing https://bugzilla.redhat.com/show_bug.cgi?id=2103255 in f35 before the mini mass rebuild
18:41:23 <alexsaezm> oh right, thanks
18:41:24 <gotmax[m]> Is that good with you?
18:41:29 <alexsaezm> it's perfect
18:42:01 <gotmax[m]> This time I actually don't have anything else to add :)
18:42:18 <alexsaezm> for the next topic?
18:42:27 <gotmax[m]> To this topic
18:42:35 <alexsaezm> oh got it
18:42:39 <alexsaezm> so... to the next one!
18:42:43 <alexsaezm> #topic Meeting Topic: Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42
18:42:57 <gotmax[m]> This is going to be harder than it initially seems
18:42:58 <alexsaezm> I think this topic is better for another time when we are more than 3 :)
18:43:09 <alexsaezm> why is that?
18:43:09 <alexsaezm> oh
18:43:35 <gotmax[m]> We take need to add `ExcludeArch: %{ix86}` to every package that (build)requires golang in any way, whether or not it's shipped
18:43:44 <alexsaezm> damn...
18:44:00 <gotmax[m]> We can't just remove `%{ix86}` from `%{golang_arches}` or that would break a lot of things
18:44:19 <gotmax[m]> s/take/would/
18:44:40 <gotmax[m]> * We would need to add `ExcludeArch: %{ix86}` to every package that (build)requires golang or any other go package in any way, whether or not it's shipped
18:44:45 <alexsaezm> but fedora still ships 32bits?
18:45:03 <alexsaezm> I mean, for the end user
18:45:10 <alexsaezm> I don't think so...
18:45:16 <gotmax[m]> They ship certain i686 bit packages in the x86_64 repos for multilib
18:45:26 <alexsaezm> right
18:45:28 <alexsaezm> the wine thingy
18:45:35 <gotmax[m]> Yes, wine and steam
18:45:48 <alexsaezm> steam? the videogame platform?
18:45:49 <gotmax[m]> But all packages that don't have ExcludeArch still get built
18:45:58 <gotmax[m]> alexsaezm: Yes
18:46:06 <alexsaezm> is it in the repos? :-/
18:46:25 <gotmax[m]> I think it's in RPMFusion
18:46:46 <alexsaezm> got it, that makes more sense
18:46:55 <gotmax[m]> There are other more niche usecases for 32-bit, but those are the main two
18:47:18 <alexsaezm> ok, so hard solution here... we don't do anything at all... or we change every single package
18:47:26 <alexsaezm> ;-/
18:47:26 <gotmax[m]> Not every package
18:47:31 <gotmax[m]> But a good amount
18:48:21 <Fale[m]> all the ones that have compiled binaries, I guess
18:48:28 <Fale[m]> so the usual ~500
18:48:57 <gotmax[m]> Well all packages that have `%gometa` already have ExclusiveArch: %{golang_arches}
18:49:17 <Fale[m]> ok, so it should be way less
18:49:35 <gotmax[m]> This is just about other golang packages that don't follow the guidelines and do their own thing or packages that depend on other go packages but aren't written in go
18:50:42 <Fale[m]> from what I've seen the packages related to the container/k8s world (cri-o, etcd, k8s, runc, ...) are the ones less following the guidelines
18:50:48 <gotmax[m]> https://paste.sr.ht/~gotmax23/caa7b8f4179554f0950f1351da65b054929127f6 is a list of all packages that depend on golang at buildtime but don't have the proper ExclusiveArch lines
18:51:01 <gotmax[m]> This doesn't include packages that depend on built go binaries
18:51:20 <gotmax[m]> And not golang itself
18:51:43 <gotmax[m]> By depend, on talking about at buildtime
18:51:50 <gotmax[m]> s/on/I'm/
18:52:09 <gotmax[m]> Fale[m]: Yeah, you're right.
18:53:08 <gotmax[m]> On another note, I got the RedHat containers people to add go-sig to runc, but no dice on the others
18:53:17 <gotmax[m]> * On a related note, I got the RedHat containers people to add go-sig to runc, but no dice on the others
18:55:24 <alexsaezm> I guess we should continue the conversation in the mailing list so others can add their opinion
18:55:31 <gotmax[m]> Yeah, I agree
18:55:38 <gotmax[m]> I just wanted to bring it up here
18:55:44 <gotmax[m]> I hope I explained it well enough :)
18:55:49 <alexsaezm> oh yes, thanks
18:56:15 <gotmax[m]> There's also a related discussion happening on devel@
18:56:50 <gotmax[m]> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/V3RXECZQJJNJPDTAYXXKTRWPLJ5LTR7A/
18:57:18 <gotmax[m]> #link https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/thread/7B4NJCY6NCK6P4NAPPPV24XTEO2KO5ZA/
18:57:47 <alexsaezm> thanks for the links
18:57:53 <gotmax[m]> Sure
18:58:14 <gotmax[m]> Sorry for talking so much. I guess it's not much different here than in real life :)
18:58:33 <alexsaezm> that's what the meetings are  for :)
18:58:44 <alexsaezm> it's not fun when the meeting is quick :)
18:59:04 <alexsaezm> So... there's nothing else with the meeting tag
18:59:12 <alexsaezm> it's... open floor time!
18:59:13 <alexsaezm> #topic Open floor
18:59:39 <gotmax[m]> I wanted to talk about the issues with the docker/moby/containerd ecosystem, but eclipseo isn't here
18:59:46 <Fale[m]> iirc, we discussed about polling for the best meeting time... have I missed it or it did not happened?
18:59:57 <alexsaezm> Fale: didn't happen
18:59:57 <gotmax[m]> Never happened
19:00:10 <alexsaezm> gotmax (He/Him): do you want to add that as an item to the next meeting?
19:00:48 <gotmax[m]> Yeah, I guess
19:01:31 <alexsaezm> I'm very interested in those issues so if it can be a mail thread or a chat for the next meeting... (to avoid missing it)
19:02:21 <gotmax[m]> https://pagure.io/GoSIG/go-sig/issue/43
19:02:32 <alexsaezm> awesome <3
19:04:33 <alexsaezm> I have nothing interesting to add. I realized I did the go1.19 mass rebuild in copr not that correct (missing dependencies somehow) and I'm running it again right now. Worked a little on bring back from the other life Delve, and... pretty much that
19:05:12 <gotmax[m]> Thanks for working on that (both things :)), alexsaezm
19:05:30 <Fale[m]> I have another question: we do have a lot of people in the go-sig, and it's very easy to join it (just a message in a ticket). Does this still make sense, considering that go-sig gives power over 2k+ packages? Should we start implementing some pruning procedures for non-active maintainers?
19:05:45 <gotmax[m]> I was also thinking that
19:06:01 <gotmax[m]> The other language sigs have stricter procedures for joining, I believe
19:06:09 <alexsaezm> do they?
19:06:31 <alexsaezm> I'm just only here so I'm not aware of other procedures to be honest
19:06:50 <alexsaezm> I guess a little of structure in general doesn't hurt
19:07:26 <gotmax[m]> The things is, it's challenging to maintain unbundled go packages if you're not able to easily update your dependencies
19:07:55 <alexsaezm> right, I'm afraid about Delve for example... and it's not by far the biggest one
19:08:29 * gotmax[m] gets distracted by a news conference for the shooting
19:08:47 <alexsaezm> that sounds more important than this :)
19:10:18 <alexsaezm> we can create a next action for the next meeting in case more people appear, to discuss how can we or if we should make stricter procedures for joining or staying
19:10:55 <alexsaezm> also... we should talk about the time meeting again
19:11:02 <Fale[m]> +1
19:11:50 <alexsaezm> #action alexsaezm will send a mail to the go sig list to discuss new times for the meeting
19:12:36 <alexsaezm> #action alexsaezm will create a go sig issue to discuss in the next meeting if we should make the rules for joining and saying in the group stricter
19:12:41 <alexsaezm> sounds right?
19:13:14 <Fale[m]> s/saying/staying/
19:13:23 <alexsaezm> silly me...
19:13:31 <Fale[m]> :-D
19:13:51 <alexsaezm> is there a delete action action? :D
19:14:16 <alexsaezm> I don't see it...
19:14:34 <alexsaezm> anyway
19:14:39 <alexsaezm> is there anything else?
19:15:27 <alexsaezm> thanks a lot for everything Fale ++ and gotmax (He/Him) ++ as always, it was a nice chat :)
19:15:49 <Fale[m]> nice chat indeed :-)
19:16:00 <Fale[m]> I'll try tobetter convince zodbot of my identity
19:16:22 <alexsaezm> hahah
19:16:23 <alexsaezm> #endmeeting