19:00:06 <alexsaezm> #startmeeting Go SIG meeting
19:00:06 <zodbot> Meeting started Mon Jan 30 19:00:06 2023 UTC.
19:00:06 <zodbot> This meeting is logged and archived in a public location.
19:00:06 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:06 <zodbot> The meeting name has been set to 'go_sig_meeting'
19:00:17 <alexsaezm> #topic Roll Call
19:00:24 <alexsaezm> Hi there! :)
19:00:42 <gotmax[m]> .hello gotmax23
19:00:42 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
19:01:37 <copperi[m]> .hello copperi
19:01:41 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
19:02:19 <gotmax[m]> mikelo eclipseo_ Fale: Are any of you around?
19:03:49 * alexsaezm will give until 05 so people can arrive :)
19:03:57 <gotmax[m]> Ack
19:05:37 <alexsaezm> we have a bunch of stuff in the Go SIG issue tracker. Any preference?
19:05:50 <gotmax[m]> My Change Proposal :) ?
19:07:01 <alexsaezm> Sounds like an awesome starting point :D
19:07:05 <gotmax[m]> (https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves is the link)
19:07:22 <alexsaezm> #topic  Leaf Go library packages
19:08:10 <gotmax[m]> Also, do mind doing #chair gotmax[m] ?
19:08:10 <copperi[m]> It look good to me
19:08:36 <gotmax[m]> #link https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
19:08:44 <alexsaezm> #chair gotmax[m]
19:08:44 <zodbot> Current chairs: alexsaezm gotmax[m]
19:08:47 <alexsaezm> did it work?
19:08:49 <alexsaezm> it did!
19:08:50 <alexsaezm> yay
19:08:54 <gotmax[m]> 👍️
19:08:57 * alexsaezm is always afraid of zodbot
19:09:06 <copperi[m]> Don't be
19:09:33 * gotmax[m] hopes that zodbot won't rise up and kill us all
19:09:50 <alexsaezm> haha
19:10:01 <alexsaezm> gotmax (He/Him): I checked the proposal and I really liked it
19:10:10 <gotmax[m]> thanks :)
19:10:42 <gotmax[m]> I wanted to bring it up in the meeting before I submitted it
19:11:35 <gotmax[m]> does anyone have any specific questions or concerns?
19:11:36 <alexsaezm> LGTM, can't think of anything bad to say :D
19:12:42 <gotmax[m]> cool. I'd also like to highlight the opt-out process.
19:13:07 <gotmax[m]> It's at the end of the https://pagure.io/GoSIG/go-leaves/tree/main README
19:13:42 <alexsaezm> I really like that
19:13:57 <alexsaezm> that's a clever idea
19:14:17 <gotmax[m]> I wanted something that was easy to parse and was auditable
19:15:16 <gotmax[m]> I guess it's harder for others than creating a wiki page and allowing them to put package names there, but this makes my job easier :)
19:15:44 <gotmax[m]> Anyways, I'll submit this proposal to releng and then submit it to the Program Manager
19:16:52 <alexsaezm> thank you very much
19:16:55 <alexsaezm> gotmax (He/Him): ++
19:18:06 <alexsaezm> anything else with this topic?
19:18:44 <gotmax[m]> I don't think so
19:19:34 <gotmax[m]> Re. other topics, I think we've covered merging specfiles, golang-race was already removed, and I don't have any updates on %ix86 (I'm working on this first).
19:19:46 <alexsaezm> I was gonna say exactly that
19:19:51 <gotmax[m]> :)
19:19:58 <alexsaezm> docker brokenness then?
19:20:17 <gotmax[m]> I don't have much here either
19:20:28 <gotmax[m]> sergiomb: has been maintaining moby-engine
19:20:36 <gotmax[m]> Meh, I guess I have some
19:20:49 <alexsaezm> #topic Discuss current docker/moby/containerd ecosystem brokenness
19:20:52 <alexsaezm> #link https://pagure.io/GoSIG/go-sig/issue/43
19:21:35 <gotmax[m]> A non-packager has been submitting PRs to update containerd that I've been merging (Robert is the primary maintainer).
19:21:39 <gotmax[m]> Maybe I'll offer to sponsor them
19:22:25 <alexsaezm> that is great :D
19:22:28 <copperi[m]> +1
19:23:06 <gotmax[m]> golang-github-docker and golang-github-docker-cli have been updated to the next major version (v20 -> v22). They are a couple betas behind. I think the dependencies are in a little bit better shape, but still many are out of date and/or FTBFS.
19:24:01 <gotmax[m]> Once v22 is officially released, we should update moby-engine. I can try to help out a little with that.
19:24:25 <gotmax[m]> There's been a change to how it handles bundled dependencies. We might also be able to unbundle it.
19:24:26 <gotmax[m]> * bundled dependencies in v22. We
19:24:48 <copperi[m]> so should they be vendored ?
19:25:55 <gotmax[m]> moby-engine is currently built from vendored deps. golang-github-docker and golang-gthub-docker-cli contains the same code but not the binaries. They're used as libraries for other go packages.
19:26:25 <gotmax[m]> copperi[m]: not necessarily
19:26:40 <gotmax[m]> unbundling will require somewhat large packaging changes
19:28:02 <defolos> When it comes to unbundling, I'd like to suggest that you think whether unbundling adds any value and whether that is worth it
19:28:34 <gotmax[m]> Well, it's more in the spirit of Fedora packaging guidelines. Those large vendor tarballs are a bit dubious.
19:29:05 <defolos> packaging guidelines can be changed
19:29:20 <defolos> I know it's very much against the spirit of the Fedora packaging guidelines
19:29:39 <defolos> but the packaging story for go, rust, node, etc. is not getting any easier
19:30:02 <gotmax[m]> we are already maintaining the unbunled golang-github-docker anyways, because other packages need to import its code.
19:30:25 <defolos> then unbundling that could make sense
19:30:56 <gotmax[m]> They've gotten rid of unbundled node libraries, and I don't think that's really increased nodejs packaging
19:33:12 * gotmax[m] goes to check something. brb
19:34:40 <gotmax[m]> also, moby-engine bundled tini-static, which I really don't like. it's used for docker run --init. it should be possible to add Requires: tini-static package and add --init-path /usr/bin/tini-static to dockerd.service
19:39:16 <alexsaezm> is there anything else to talk about this topic?
19:39:27 * gotmax[m] doesn't think so
19:39:43 <alexsaezm> then...
19:39:44 <alexsaezm> #topic Open floor
19:41:08 <alexsaezm> I just have one question. I think eclipseo_ it's quite busy these days I have a package review that I would love to merge. Is anyone interested it taking a look at https://bugzilla.redhat.com/show_bug.cgi?id=2102388 ?
19:41:55 <alexsaezm> he was reviewing it
19:43:25 <gotmax[m]> I can maybe take a look later this week. Anyone else is free to go ahead.
19:43:40 <alexsaezm> thank you
19:45:47 <gotmax[m]> I've filed https://pagure.io/releng/issue/11253 to get releng approval
19:47:48 <sergiomb> hi, yes I'm trying to maintain docker . the problem of unbundle things like go packages is that we will have a bunch of packages, yet another day I approved one package that the code was 50 lines or less , so is not about the spirit
19:49:22 <alexsaezm> Just in case, this might be relevant for you https://fedoraproject.org/wiki/Bundled_Libraries
19:51:11 <gotmax[m]> Hmm, I didn't know about that page, but looks informative
19:52:32 <alexsaezm> It's a hot topic and I have mixed feelings but I think it's a really interesting take on the matter
19:54:43 <gotmax[m]> I think that having dependency trees this large is a problem that's orthogonal to bundling. It makes it hard to audit and way too easy for some hidden transitive dependency of a transitive dependency of transitive dependency to push a malicious update and rm -rf your whole system.
19:55:46 <alexsaezm> yeah, I think we are reaching if not already reached the point of "too many"
19:56:28 <alexsaezm> RHEL does the opposite but the surface is way smaller
19:59:08 <alexsaezm> Is there anything else we want to discuss?
19:59:19 * gotmax[m] shakes his head
20:00:12 <alexsaezm> in that case... I think we can call it a day :)
20:00:25 <alexsaezm> thank you a lot and see you in the next one!
20:00:25 <alexsaezm> #endmeeting