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