18:00:43 <alexsaezm> #startmeeting Go SIG meeting
18:00:43 <zodbot> Meeting started Mon Jun 20 18:00:43 2022 UTC.
18:00:43 <zodbot> This meeting is logged and archived in a public location.
18:00:43 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:43 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:00:53 <gotmax[m]> I also forgot about that...
18:00:59 <gotmax[m]> .hello gotmax23
18:01:00 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
18:01:07 <alexsaezm> #topic Roll Call
18:01:26 <alexsaezm> It's time for another Go SIG meeting :)
18:02:01 <gotmax[m]> alexsaezm: Can you please `#chair gotmax[m]`?
18:02:12 <alexsaezm> oh sure
18:02:20 <alexsaezm> #chair gotmax[m]
18:02:20 <zodbot> Current chairs: alexsaezm gotmax[m]
18:02:26 <alexsaezm> did it work?
18:02:27 <alexsaezm> yay
18:02:32 <mikelo> #chair mikelo
18:02:40 <gotmax[m]> Yes
18:03:01 <alexsaezm> did you get the chair? :D
18:03:23 <gotmax[m]> It looks like I did
18:03:35 <alexsaezm> and mikelo ?
18:03:51 <jcajka> #chair
18:04:13 <jcajka> only chairs can :)
18:04:15 <jcajka> hello
18:04:39 <gotmax[m]> #chair jcajka
18:04:39 <zodbot> Current chairs: alexsaezm gotmax[m] jcajka
18:04:40 <gotmax[m]> #chair
18:04:40 <zodbot> Current chairs: alexsaezm gotmax[m] jcajka
18:04:56 <alexsaezm> I was trying to find the information about the chairs...
18:04:57 <gotmax[m]> #chair mikelo
18:04:57 <zodbot> Current chairs: alexsaezm gotmax[m] jcajka mikelo
18:05:01 <alexsaezm> but I don't see it
18:05:16 <alexsaezm> oh
18:05:18 <alexsaezm> found
18:05:29 <alexsaezm> http://meetbot.debian.net/Manual.html
18:06:17 <alexsaezm> do we have like a guide for running these meetings? just to know who should get a chair and things like that
18:06:26 <alexsaezm> well, we can discuss that in the open floor I guess :)
18:06:51 <gotmax[m]> The topics I can think of to talk about today are golang 1.19, all the FTBFS packages, and CVEs
18:07:13 <gotmax[m]> Also, I still need jcajka to give me privs on go-srpm-macros :)
18:07:41 <jcajka> gotmax[m]: not a problem :), which one?
18:07:42 <alexsaezm> Ok, let's move to the first issue then :)
18:07:50 <alexsaezm> to make this a little more structure...
18:08:16 <alexsaezm> #meetingtopic go-srpm-macros
18:08:23 <gotmax[m]> jcajka: src.fedoraproject.org/rpms/go-srpm-macros
18:09:00 <gotmax[m]> I had planned to retire it, but I found out after last meeting that I didn't have access
18:09:56 <gotmax[m]> alexsaezm: Here is some documentation about meetbot https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
18:10:42 <alexsaezm> gotmax (He/Him): yeah I have that page open always but I was wondering if we should have a go sig document about that, but it's not important :)
18:10:53 <jcajka> gotmax[m]: hopefully I have enough access to it
18:11:15 <gotmax[m]> You're an admin
18:11:24 <alexsaezm> do you want me to create an action for remind it to you jcajka ?
18:12:55 <jcajka> gotmax[m]: I can orphan it, anyway I will give you admin rights and if we will need jchaloupka's help I can ping him
18:13:11 <gotmax[m]> jcajka: +1
18:13:34 <gotmax[m]> #action jcajka to orphan go-srpm-macros
18:13:46 <gotmax[m]> I don't think we will
18:13:51 <gotmax[m]> #undo
18:13:51 <zodbot> Removing item from minutes: ACTION by gotmax[m] at 18:13:34 : jcajka to orphan go-srpm-macros
18:13:57 <gotmax[m]> #action jcajka to retire go-srpm-macros
18:14:38 <alexsaezm> can we move to the next item then? :)
18:14:46 <gotmax[m]> You should be able to just run `fedpkg retire 'Superseded by go-rpm-macros'` on `rawhide`
18:14:51 <gotmax[m]> SGTM alexsaezm
18:15:15 <gotmax[m]> Use `#topic`
18:15:26 <alexsaezm> yeah I was thinking about that
18:15:36 <alexsaezm> that I used the meetingtopic and that wasn't the correct one
18:15:49 <gotmax[m]> Yeah, but it's no big deal :)
18:15:57 <alexsaezm> #meetingtopic Go SIG meeting
18:16:05 <alexsaezm> #topic Go 1.19
18:16:27 <alexsaezm> Do we have something to discuss? I'll plan to update it in Rawhide this week
18:16:34 <alexsaezm> is there any questions regarding the proposal?
18:16:59 <mikelo> will be update + mass rebuild, or the mass rebuild will be some days later?
18:17:21 <gotmax[m]> Yeah, I had the same question
18:17:46 <alexsaezm> didn't think about it...
18:17:48 <alexsaezm> I*
18:17:51 <alexsaezm> hmmmmm
18:17:55 <gotmax[m]> I think the current plan is that the packages will just be rebuilt as part of the standard F37 mass rebuild
18:18:01 <gotmax[m]> That was my interpretation
18:18:04 <alexsaezm> yeah I mean that was my initial idea
18:18:10 <gotmax[m]> But I'm not a change owner :)
18:18:19 <alexsaezm> do you need a mass rebuild earlier?
18:18:48 <mikelo> python sig is doing rebuilds for 3.11 before the f37 mass rebuild i think
18:19:15 <mikelo> but I don't need 2 rebuilds in the cycle, fine for me to wait until f37's rebuild
18:19:18 <gotmax[m]> Python does a separate mass rebuild, but they're situation is a bit different because of the way their inter-dependencies work
18:19:22 <jcajka> Will there be a regular Go release before mass rebuild
18:19:26 <jcajka> ?
18:19:39 <gotmax[m]> jcajka: You mean not a pre-release?
18:20:00 <gotmax[m]> s/they're/their/
18:20:00 <jcajka> yes
18:20:16 <alexsaezm> I was planning in doing a COPR rebuild to check for issues but if you like a mass rebuild once beta1 is on rawhide I can requested it, we can be sure that everything goes as planned and not have last minute surprises
18:20:31 <gotmax[m]> I like the COPR idea
18:20:49 <gotmax[m]> But we already have so many FTBFS packages, that it might not be super useful
18:21:19 <jcajka> gotmax[m]: do you have numbers?
18:21:34 <mikelo> +1 to COPR
18:21:38 <gotmax[m]> On minute
18:21:49 <gotmax[m]> *One
18:22:26 <mikelo> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=go-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals&list_id=12644423&query_format=advanced&short_desc=FTBFS&short_desc_type=allwordssubstr
18:22:29 <gotmax[m]> Amongst the packages that go-sig has access to, there are at least 98: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=go-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals&list_id=12672083&query_format=advanced&short_desc=FTBFS&short_desc_type=allwordssubstr
18:23:15 <gotmax[m]> Fale has a script that should produce more accurate numbers
18:23:34 <jcajka> gotmax[m]: that is not that much out of ordinary, it should be under 5% based on back of my head calculation
18:23:46 <mikelo> (rclone and golang-storj-common have PRs already to fix FTBFS)
18:24:07 <gotmax[m]> mikelo: Did you need packages reviewed for that?
18:24:44 <mikelo> gotmax[m], eclipseo was doing some related merges today, so they should be OK soon(tm)
18:25:34 <mikelo> I'll continue working on that list
18:25:35 <jcajka> if there were any significant issues I have seen failure rates above 10%, around 5% is usually "just" dependency and packaging issues
18:26:31 <gotmax[m]> I'm working on getting more accurate numbers. It might not be as bad as I thought
18:27:39 <alexsaezm> so, what about the COPR build and if we see tons of issues, we request a real mass rebuild?
18:28:13 <alexsaezm> (it's easier to start a COPR mass rebuild, that's the only reason :D)
18:28:24 <gotmax[m]> Either way, if we don't take action, the FTBFS packages will eventually get mass orphaned and then retired if nobody picks up the orphans
18:28:54 <gotmax[m]> alexsaezm: Yeah. Also, it would be nice to do the rebuilds with a final release if that will be available in time for the distro-wide mass rebuild.
18:29:34 <alexsaezm> sure, if the timing works, I'll try to have that ready for the official mass rebuild
18:29:48 <jcajka> Of course it matters what failures are those and it takes significant amount of time to check all the FTBFS, but delta with new Go should be more important.
18:30:23 <alexsaezm> #action alexsaezm will update Rawhide with Go 1.19 and perform a COPR mass rebuild. Then report the amount of issues to the Go SIG
18:30:39 <gotmax[m]> jcajka: Agreed. I think last time there were some go 1.18 related FTBFSs, but I'm not sure how many of the total were related to that.
18:31:50 <gotmax[m]> alexsaezm: Let me know if I can help in any way. I'm pretty familiar with COPR.
18:32:46 <alexsaezm> Sure, I hope I don't need any help after all these years using it :D but I'll let you know
18:33:15 <alexsaezm> anything else with this topic?
18:33:24 <gotmax[m]> I don't think so
18:33:30 <jcajka> Feel free to send any non-intel issues my way, hopefully I will be able to help.
18:33:32 <alexsaezm> awesome, to the next one!
18:33:41 <alexsaezm> #topic CVEs
18:33:49 <gotmax[m]> I guess do we want to wait to update it in Rawhide till after we test in COPR?
18:34:03 <mikelo> shouldn't the 1.19 go to copr + rebuild before hitting rawhide?
18:34:18 <alexsaezm> you mean to try out first go 1.19 on copr?
18:34:35 <alexsaezm> Yeah I always do that :)
18:34:35 <gotmax[m]> I guess
18:34:39 <mikelo> yes
18:34:41 <mikelo> ok
18:34:45 <gotmax[m]> mikelo and I keep saying the same things :)
18:34:58 <alexsaezm> I usually do COPR -> Scratch build -> build
18:34:58 <gotmax[m]> I mean do the entire rebuild first
18:35:15 <alexsaezm> and I usually have a fork of GO linked to a COPR repository but I think right now is off
18:35:16 <gotmax[m]> * entire rebuild in COPR first
18:35:17 <alexsaezm> oh
18:35:26 <alexsaezm> the whole mass rebuild on COPR? yeah sure
18:35:27 <alexsaezm> I can do that
18:35:46 <alexsaezm> go 1.19 and mass rebuild on copr, sure
18:35:47 <alexsaezm> I'll do that
18:36:17 <mikelo> +1
18:36:39 <gotmax[m]> The python sig has some docs here about how to compare the delta between two COPRs: https://hackmd.io/81DXky5lRj-cUiSTeiag2A?view
18:37:00 <alexsaezm> Thanks
18:37:02 <alexsaezm> I made a tool few months ago for that
18:37:04 <gotmax[m]> * has some good docs here, * COPRs: https://hackmd.io/81DXky5lRj-cUiSTeiag2A?view#Get-only-packages-that-fail-with-the-updated-thing-you-are-testing
18:37:17 <alexsaezm> and I know a guy making a new tool for exactly that
18:37:25 <alexsaezm> but thanks for the link I'll take a look
18:37:40 <jcajka> gotmax[m]: nice
18:37:41 <gotmax[m]> Cool
18:38:10 <alexsaezm> regarding the CVEs
18:38:18 <alexsaezm> I hate arm7hl
18:38:23 <alexsaezm> that's it, I said it
18:38:34 <alexsaezm> it keeps failing and failing in things that I cannot reproduce when I get a arm7hl
18:38:40 <gotmax[m]> At least we no longer build for it as of (I think) F36
18:38:52 <alexsaezm> we don't! <3
18:38:55 <alexsaezm> but f35...
18:39:23 <alexsaezm> right now it's failing, without patches, with patches... I just can't rebuild go on arm7hl on koji
18:39:34 <jcajka> alexsaezm: do you have link?
18:39:44 <alexsaezm> yes, let me find it
18:40:05 <alexsaezm> https://src.fedoraproject.org/rpms/golang/pull-request/29
18:40:08 <alexsaezm> there's a link in the PR
18:40:11 <alexsaezm> to the scratch build
18:40:26 <alexsaezm> https://koji.fedoraproject.org/koji/taskinfo?taskID=88294905
18:40:40 <alexsaezm> non related at all with the patches
18:41:14 <jcajka> thanks, looking
18:41:58 <gotmax[m]> It looks like it's failing in %check?
18:42:36 <gotmax[m]> We can disable `%check` just for arm7 if it's really needed to get it to build.
18:43:05 <alexsaezm> it fails a test at the end
18:43:09 <alexsaezm> multiple tests
18:43:10 <jcajka> alexsaezm: segfault in shared tests, I have faint memory that I have reported it to upstream, looking for it
18:43:32 <alexsaezm> I think I saw a few issues in gh when I searched
18:43:38 <alexsaezm> but all of them were old
18:44:27 <gotmax[m]> Or just disable the specific failing tests. I don't think the guidelines necessarily endorse disabling all tests just to get it to build, but skipping tests is better than CVEs in my book :D
18:45:27 <jcajka> or not :) IMHO it is fine to disable the tests suite on arm32 or rather not fail on it
18:45:39 <mikelo> yes, better skip tests for arm7hl than having CVEs for all archs
18:45:54 <jcajka> there should be option to ignore the results in the spec
18:46:03 <gotmax[m]> jcajka: Yeah, we could add `|| :` to arm32
18:46:13 <jcajka> added because of arm32... way back
18:46:26 <alexsaezm> that is what I was planning on doing but I preferred  to ask here first :) if everybody is happy with that...
18:46:28 <eclipseo> thanks mikelo for requesting the branch
18:46:41 <eclipseo> I'' work on storj once it is accepted
18:47:21 <gotmax[m]> alexsaezm: Not ideal, but I'm on board
18:47:36 <gotmax[m]> eclipseo: By the way, I think any go-sig member can request the branches
18:47:55 <gotmax[m]> fedscm-admin has the ability to figure that out
18:49:47 <alexsaezm> is the rest fine with skipping tests?
18:50:29 <mikelo> eclipseo, I also thought about dropping storj support from rclone, the stack is quite complex and I guess is not widely used. If it keeps getting more complex, and it may due to some asm related deps they're about to add, maybe that's the best option to go.
18:50:36 <mikelo> alexsaezm, fine for me
18:50:47 <jcajka> alexsaezm: +!
18:50:50 <mikelo> +1 to skip test for arm32
18:50:51 <jcajka> +1
18:50:55 <jcajka> :)
18:51:00 <alexsaezm> awesome
18:51:34 <alexsaezm> #action alexsaezm will skip the test suite for arm32 in order to avoid the current failures in the pr/29
18:52:01 <eclipseo> mikelo, I'll see, I didn;t check up on the latest deps, but I'm not keen of suppressing functionalities for users
18:52:05 <alexsaezm> any other topic before the open floor?
18:52:12 <eclipseo> yeah
18:52:14 <eclipseo> no
18:52:27 <gotmax[m]> eclipseo and I started talking about it, but there's some problems with the moby stack right now
18:52:39 <alexsaezm> #topic Open Floor
18:53:12 <eclipseo> Sooooo, I was away for a while and was wondering where were we on the Go modules front?
18:53:48 <gotmax[m]> I don't think we made any progress
18:53:57 <eclipseo> ok
18:54:24 <gotmax[m]> Where are we currently?
18:54:58 <eclipseo> IDK, there is old stuff by nim but nobody understand it fully and don't even know if it's  finished or not
18:55:34 <eclipseo> Then I don't remember who said they would take a look but I don't know if it went anywhere?
18:56:00 <gotmax[m]> https://pagure.io/fork/nim/go-rpm-macros/c/e876e2483cbe4443f4d7c18afad6227f4dd7c75c?branch=go-modules I think
18:56:19 <gotmax[m]> I think it required some changes in redhat-rpm-config that were never merged
18:56:38 <alexsaezm> eclipseo: if we are talking about the GOPATH deprecation, I did not touch anything :(
18:57:02 <gotmax[m]> I wonder what Debian is doing also. They also still depend on GOPATH and have unbundled dependencies like we do.
18:57:02 <eclipseo> to use with https://pagure.io/modist
18:57:39 <alexsaezm> gotmax (He/Him): that's a good point, I can check that
18:57:48 <gotmax[m]> I just don't like that it's a whole new set of macros that packagers would have to learn
18:58:21 <alexsaezm> hmmmm why you say that? what new set of macros?
18:58:55 <alexsaezm> I mean, we should avoid adding new stuff just for fixing this, this should be an internal fix without exposure to the packagers
18:58:57 <alexsaezm> imho
18:59:20 <eclipseo> well it kinda is needed if we woant both package to coexist for a while. And if we change the meaning of current macros that will be destabilizing too
19:00:23 <eclipseo> we can't just change the internal of the macros and make it work, a lot of time we will need to adjust the go.mod manually before AUTOBR
19:00:25 <jcajka> new implementation can live for some time in rawhide after release or in COPR
19:01:00 * gotmax yells at Element Desktop for crashing
19:01:25 <jcajka> but it will be huge amount of work anyway
19:01:46 * alexsaezm needs to start again working on this
19:02:48 <alexsaezm> I would like to reproduce again the problem (the future problem) and gather some notes for the next meeting
19:03:01 <alexsaezm> also, look into what Debian is doing
19:03:28 <gotmax[m]> +1
19:04:03 <gotmax[m]> Re CVEs, are we going to rebuild all dependents every time there's a golang CVE?
19:05:00 <gotmax[m]> As of now, we still haven't rebuilt for f36 and f35
19:05:31 <eclipseo> yeah we have more than 4,000 packages now. Most of them are "easy", the worse are a mess of cyclic deps. And Docker/K8S.
19:06:44 <eclipseo> we're supposed to rebuild all binaries any time oneof them  library has a CVE fixed
19:06:51 <eclipseo> never been applied though
19:07:21 <alexsaezm> eclipseo: is that written somewhere? out of curiosity
19:07:49 <eclipseo> nope it's just a consequence of not using shared libraries
19:08:29 <jcajka> unfortunately no manpower, tools: (
19:08:46 <eclipseo> which means the library code is directly in the resulting binary and needs to be be updated everytime there is a CVE unlike with shared libs where you only need to update the shared lib
19:09:05 <jcajka> even shared libs are not a silver bullet as Go doesn't have guaranteed stable abi
19:09:06 <gotmax[m]> The go ecosystem with all of its dependencies and static linking really is not very friendly to distro packagers :(
19:09:14 <jcajka> for them
19:09:33 <jcajka> they should work for the most part though
19:10:16 <alexsaezm> I mean, I can request a mass rebuild every time we update the Go package for a CVE... that's not an issue...
19:10:33 <gotmax[m]> That feels like a general theme with Google OSS projects (see Chromium)
19:10:44 <gotmax[m]> </rant>
19:11:47 <alexsaezm> it's not ideal, that's for sure
19:12:03 <jcajka> I have been toying with -linkshared like 6y ago
19:13:18 <gotmax[m]> We've gone a bit overtime...
19:14:39 <eclipseo> okidoki, see you next time then
19:14:55 <alexsaezm> thanks everyone!
19:14:59 <eclipseo> thanks
19:15:07 <alexsaezm> #endmeeting