18:12:44 <alexsaezm> #startmeeting Go SIG meeting
18:12:44 <zodbot> Meeting started Mon Oct 24 18:12:44 2022 UTC.
18:12:44 <zodbot> This meeting is logged and archived in a public location.
18:12:44 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:12:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:12:44 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:12:51 <gotmax[m]> .hello gotmax23
18:12:53 <zodbot> gotmax[m]: Something blew up, please try again
18:12:56 <zodbot> gotmax[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:13:03 <gotmax[m]> .ping
18:13:03 <zodbot> pong
18:13:08 <gotmax[m]> .hello gotmax23
18:13:09 <zodbot> gotmax[m]: Something blew up, please try again
18:13:12 <zodbot> gotmax[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:13:13 <copperi[m]> .hello copperi
18:13:16 <zodbot> copperi[m]: Something blew up, please try again
18:13:17 <gotmax[m]> Meh
18:13:18 <zodbot> copperi[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:14:04 <gotmax[m]> .hellomynameis gotmax23
18:14:05 <zodbot> gotmax[m]: Something blew up, please try again
18:14:08 <zodbot> gotmax[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:14:16 <mikelo_m[m]> .hello mikelo2
18:14:17 <zodbot> mikelo_m[m]: Something blew up, please try again
18:14:20 <zodbot> mikelo_m[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:14:39 <alexsaezm> zodbot hates us (again)
18:14:57 <gotmax[m]> At least it doesn't call you None
18:16:59 <gotmax[m]> Kevin fixed zodbot
18:17:21 <gotmax[m]> Anyways...
18:17:27 <MarkEFuller[m]> .hello fuller
18:17:28 <zodbot> MarkEFuller[m]: fuller 'Mark E. Fuller' <mark.e.fuller@gmx.de>
18:17:47 <gotmax[m]> eclipseo isn't here to discuss the Docker stuff, so we can skip that
18:18:10 <alexsaezm> we can jump into open floor?
18:18:42 <gotmax[m]> I guess
18:19:30 <gotmax[m]> I did some more repo querying and it turns out there's a lot more recursive deps of docker and containerd than I thought
18:20:25 <gotmax[m]> 348 source packages. 127 application packages.
18:20:26 <gotmax[m]> https://paste.sr.ht/~gotmax23/0945741ebdd0a0d239e6e31fbe2835ec219ad0f6
18:21:47 <gotmax[m]> Many of these are transitive dependencies which we can reduce by splitting up -devel packages so the import paths that need moby aren't depended on by everything
18:22:07 <gotmax[m]> Suffice to say, it will not be easy to vendor Docker/Moby
18:22:18 <gotmax[m]> without breaking everything
18:24:28 <alexsaezm> what a bummer :(
18:25:05 <gotmax[m]> It will be orphaned and retired if it doesn't get fixed, but eclipseo has been working on this, so hopefully it doesn't come to that
18:26:12 <copperi[m]> so goal is to vendor the package ?
18:26:46 <gotmax[m]> Also, the moby-engine and containerd application packages have been orphaned
18:27:03 <gotmax[m]> copperi: See https://pagure.io/GoSIG/go-sig/issue/43
18:27:27 <gotmax[m]> Ideally, we can keep containerd unbundled, but there's a lot of dependencies
18:28:50 <gotmax[m]> <gotmax[m]> "Many of these are transitive..." <- I will try to look into this, but I'd rather wait to put a lot of effort into it until there's a more concrete plan/decision
18:29:46 <gotmax[m]> (I think) That's all I have to say about the vendoring topic, but there's more to discuss about containerd and moby-engine being orphaned
18:29:56 <alexsaezm> sure :) hope eclipseo brings good news
18:31:10 <gotmax[m]> gotmax[m]: I have been de-facto maintaing those two packages for ~6 months. They have been orphaned by the primary maintainer (non-responsive maintainer process), and I'm not super interested in becoming the primary maintainer
18:32:25 <alexsaezm> is containerd really in use?
18:32:34 <gotmax[m]> Yes, it's needed by moby-engine
18:32:46 <alexsaezm> and what are the implications of missing both packages?
18:32:53 <gotmax[m]> No docker
18:32:54 <alexsaezm> I don't use neither of those so I don't know
18:33:01 <gotmax[m]> But there's still podman
18:33:08 <copperi[m]> docker is used by CoreOS
18:33:40 <copperi[m]> == moby-engine
18:34:03 <gotmax[m]> A while ago, the package was maintained by the RH container people, but now there's podman so...
18:36:16 <gotmax[m]> I asked if any of the coreos developers were interested in helping maintain them. They just created an issue in their tracker and asked me when I was going to pick it up 🤷.
18:36:22 <MarkEFuller[m]> I don't really want to be that guy, but the whole Go ecosystem is kind of a mess. Maybe letting Docker go as long as Podman is available is a reasonable line to draw?
18:37:08 <alexsaezm> without docker we'll have a smaller set of packages, that's for sure...
18:37:13 <gotmax[m]> I'm happy to help review PRs and onboard contributors to those packages, but I don't have time/interest to dedicate to properly maintaining the packages
18:37:18 <MarkEFuller[m]> It's not like it won't be installable from outside the Fedora repos
18:37:20 <alexsaezm> but I bet a lot of people still uses docker
18:37:41 <alexsaezm> oh right, they has external repositories
18:37:53 <MarkEFuller[m]> alias docker='podman'
18:38:04 <gotmax[m]> golang-github-docker-devel is still depended on by a bunch of stuff.  But the maintenance of moby-engine is a separate problem.
18:39:02 <gotmax[m]> MarkEFuller[m]: The podman developers like to advertise that, but it's really not that simple
18:39:14 <alexsaezm> I think it gives bad image to drop it but tbh I think most people will use the official guide from Docker -> https://docs.docker.com/engine/install/fedora/
18:39:27 <gotmax[m]> Yeah, a lot of people use the external repository
18:39:55 <gotmax[m]> And I'm not sure how that would work for CoreOS and ostree stuff
18:41:27 <gotmax[m]> We could look into making docker-ce an official third-party repository: https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/
18:42:02 <alexsaezm> why that would be an option? what that solves?
18:42:21 <alexsaezm> at least compare with the official Docker repos
18:43:12 <gotmax[m]> Yeah, I'm talking about the official Docker CE repository
18:43:28 <alexsaezm> oh sorry, I misread you
18:43:30 <alexsaezm> that would be interesting
18:44:22 <gotmax[m]> So that repository would be available OOTB for people who enabled third party repositories
18:44:47 <gotmax[m]> * party repositories at install
18:45:15 <alexsaezm> I like that approach as a middle ground thing. but... one question and, if someone picks the packages, apart from all that work, can it leave for a while in a "just updates" state?
18:46:23 <gotmax[m]> Somewhat. There's a new Docker major release on the horizon that will require some packaging changes.
18:46:57 <MavJS> hi, just a fedora user (since 2011/2012), i've mostly stuck with Docker repo from docker, although now i just mainly use podman for what i need. I understand alis docker="podman" does not always work, therefore, I think Docker CE as 3rd party repo would be very interesting from a user perspective, and hope that alleviate the golang packagers.
18:47:19 <gotmax[m]> And the package needs to be cleaned up:
18:47:20 <gotmax[m]> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DMPZRAUO3H5EHOCZDULYORYJVQU2WBIJ/
18:47:50 <gotmax[m]> #link https://github.com/coreos/fedora-coreos-tracker/issues/1291
18:47:53 <gotmax[m]> #link https://pagure.io/GoSIG/go-sig/issue/43
18:48:34 <gotmax[m]> (The first link talks about the cleanup needed; the other two are what we've already discussed)
18:49:00 <gotmax[m]> MavJS: Ack. Thanks for the feedback.
18:49:06 <MavJS> although in my previous experience, Docker CE repos for Fedora versions aren't immediately available when it first comes out, (that was maybe 2-3 years ago?) but maybe now it's better (?)
18:49:37 <MavJS> gotmax[m]: thank you and the folks here doing the packaging work. <3
18:50:09 <gotmax[m]> MavJS: Hmm, you're right. The official repositories are not always available for branched releases and Rawhide.
18:51:47 <MavJS> in which case, putting Docker CE as 3rd party repo is a bit of an annoyance for people that like to update as new releases come out
18:52:12 <gotmax[m]> E.g. the F37 packages might work on Rawhide, because it's just statically linked binaries, but maybe someone could ask Docker to make the repos available for Rawhide
18:52:44 <gotmax[m]> Currently, docker-ce is available for F37 https://download.docker.com/linux/fedora/37/
18:52:59 <gotmax[m]> Architecture support might also be a problem :(
18:53:15 <alexsaezm> oh they only support two
18:53:18 <alexsaezm> hmmm
18:53:27 <alexsaezm> aarch64 and x86_64
18:54:25 <alexsaezm> I would love to take the packages but I have plenty on my plate at the moment :( and even with that I'm not sure if that's the best approach... to be honest I don't know which is the best path to follow...
18:54:47 <alexsaezm> I like the idea of asking for a third party repo
18:55:23 <gotmax[m]> These are my thoughts/ideas if anyone wants to push them forward :). These packages have a place in my heart, because they were one of the first things I maintained in Fedora, but I don't really have the time to keep doing it properly.
18:55:30 <alexsaezm> It's a way to make Docker repository more present and easy to install, but the lack of other architectures might be a problem
18:56:17 <alexsaezm> gotmax (He/Him): did you discuss the idea of the third party repo in the mailing list?
18:56:43 <gotmax[m]> I don't know if supporting every arch is a requirement for including third-party repositories, but it would be a loss for certain users
18:56:53 <gotmax[m]> alexsaezm: I did not
18:57:25 <alexsaezm> I asked because someone might has pros/cons about it
18:57:33 <alexsaezm> and perhaps bring more awareness of the issue
18:58:08 <gotmax[m]> I came up with the idea of including the third-party repository in Fedora Workstation after I was reminded of it in the meeting
18:58:14 <MavJS> does Workstation support more than x86_64 and aarch64 ? if not, maybe that's the target y'all would want to get to anyway?
18:58:27 <gotmax[m]> But yes, that would be a good idea
18:59:29 <alexsaezm> MavJS: you can install the server version as a minimal one and then install stuff on it, so s390x and ppc64le
18:59:44 <alexsaezm> although I'm not sure if for example GNOME works on those architectures, I only work on those as servers
18:59:52 <MavJS> hhhmmmm
19:00:14 <alexsaezm> and perhaps you want containers on those architectures
19:00:37 <alexsaezm> I know, x86_64 population is way bigger than any other architecture but...
19:00:48 <gotmax[m]> I think the Workstation edition (where this would be shipped) is only available on those two architectures
19:01:08 <alexsaezm> yes, the workstation is only for x86_64 and aarch64
19:01:12 <gotmax[m]> But even if the repository definition isn't shipped on those, the lack of docker would still be a loss for those users
19:01:57 <alexsaezm> I do really like in theory the third party approach :)
19:02:11 <MavJS> hehehe
19:02:50 <gotmax[m]> It's the library packages that are difficult to maintain/broken, but moby-engine and containerd shouldn't be too difficult for someone to pick up.
19:03:02 <alexsaezm> and Docker maintains those repos, they deserve more recognition. I think third party repos look cool in the software store when you install (it's not a really technical reason but sounds nice to me)
19:03:10 <gotmax[m]> But the third party repo approach is better than nothing
19:03:38 <gotmax[m]> We would have to make sure that there's no trademark or other legal issues, though
19:04:42 <gotmax[m]> I think we should move on/wrap up and bring this to the ML
19:04:44 <alexsaezm> yes
19:04:44 <gotmax[m]> The issue could really use more visability
19:04:47 <alexsaezm> sounds good to me
19:04:57 <alexsaezm> it's a package that I bet a lot of people use
19:05:16 <MavJS> yeah, let the people decide and hopefully someone else steps up :>
19:05:23 <copperi[m]> I did not se any tm-issues, should all be good ...
19:06:44 <gotmax[m]> Anyone feel like summarizing this for the ML or should I?
19:07:21 <alexsaezm> I don't want to skip that bullet but you are probably the best one for that task as you understand the whole problem better than the rest :)
19:07:35 <MavJS> indeed
19:08:08 <gotmax[m]> Fair enough :D
19:08:38 <gotmax[m]> #action gotmax to bring the Docker discussion to the ML
19:08:57 <alexsaezm> thanks a lot
19:09:00 <alexsaezm> gotmax (He/Him): ++
19:09:06 <alexsaezm> any other stuff to discuss? :)
19:10:41 * gotmax[m] has to leave soon
19:10:42 <gotmax[m]> There's  #48 [Tracker] Leaf Go library packages, but I think we should punt that
19:10:49 <alexsaezm> me too
19:11:02 <alexsaezm> We can skip it to the next meeting
19:11:09 <gotmax[m]> Before I forget:...
19:11:10 <copperi[m]> yes
19:11:33 <gotmax[m]> moby-engine in f35 has a CVE or two
19:11:41 <gotmax[m]> There's an incompatibility with Go 1.16
19:12:17 <alexsaezm> oh... moby-engine doesn't support go 1.16?
19:12:20 <gotmax[m]> They vendor a modified version archive/tar and they updated it to the Go 1.18 version
19:12:29 <gotmax[m]> So it's a release or two behind
19:12:38 <gotmax[m]> * modified version of archive/tar and
19:12:58 <copperi[m]> I believe there were loads of missing packages in f35, but could be wrong
19:13:49 <gotmax[m]> It might be possible to `rm -r vendor/archive/tar` and use the builtin version or revert the upstream changes, but I haven't tried anything
19:14:30 <alexsaezm> how critical is the CVE?
19:14:40 <alexsaezm> oh is the tar's CVE?
19:15:17 <gotmax[m]> gotmax[m]: Or cheat by tagging F36's golang into a F35 side tag...
19:15:44 <alexsaezm> that sounds like a lot of cheating :D
19:16:09 <gotmax[m]> alexsaezm: I think there's a CVE in moby itself
19:16:17 <alexsaezm> are we talking about this CVE-2022-2879?
19:16:45 <alexsaezm> https://github.com/golang/go/issues/54853
19:16:50 <gotmax[m]> See https://github.com/moby/moby/releases/tag/v20.10.20
19:17:14 <alexsaezm> oh ok
19:17:21 <gotmax[m]> They updated the vendored archive/tar because of the CVE, but that's separate
19:18:38 <alexsaezm> I see... hmmm
19:19:01 <gotmax[m]> F35 will be dead soon, so 🤷
19:19:06 <alexsaezm> Soon f37 will be out so not sure if it worth the time to fix it
19:19:10 <alexsaezm> yeah
19:19:27 <alexsaezm> it sounds bad but it's true... unless it's really critical...
19:21:19 <gotmax[m]> I'm not exactly familiar with golang's release schedule, but we might want to consider a mid-release golang rebase if this happens again
19:22:41 <alexsaezm> and update to a newer version?
19:22:45 <alexsaezm> like from 1.16 to 1.17?
19:22:45 <gotmax[m]> I mean in a future Fedora release, not F35
19:22:54 <gotmax[m]> Yes
19:23:03 <alexsaezm> as far as I understood that is against the guidelines
19:23:12 <gotmax[m]> * release, not necessarily in F35
19:23:13 <alexsaezm> but I might be wrong here
19:23:29 <gotmax[m]> Yes, but we could get an exception if there's not too many breaking changes
19:23:44 <gotmax[m]> FESCo is pretty amendable to these kind of things
19:24:00 <alexsaezm> then sounds good, I never tried because I thought wasn't possible to be honest
19:24:41 <gotmax[m]> I think we should wrap up
19:24:48 <gotmax[m]> I need to leave about now :)
19:25:24 <alexsaezm> ok :)
19:25:32 <alexsaezm> thanks everyone!
19:25:50 <alexsaezm> #endmeeting