18:11:19 <alexsaezm> #startmeeting Go SIG meeting
18:11:19 <zodbot> Meeting started Mon Jul  3 18:11:19 2023 UTC.
18:11:19 <zodbot> This meeting is logged and archived in a public location.
18:11:19 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:11:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:11:19 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:11:27 <alexsaezm> #topic Roll Call
18:12:13 <alexsaezm> For the record the Matrix bridge seems to be not working properly. I'll give a few minutes but I don't think this will be a productive meeting and some messages might go missing
18:13:07 <mikelo> .hello mikelo2
18:13:08 <zodbot> mikelo: mikelo2 'Mikel Olasagasti Uranga' <mikel@olasagasti.info>
18:13:31 <mikelo_m[m]> messages from matrix->irc are working, but irc->matrix not
18:13:32 <copperi> .ehlo here as well :)
18:14:59 <alexsaezm> Hi copperi (quite weird to read you from the phone but answer from the laptop)
18:15:08 <alexsaezm> I checked libera-matrix and seems to be some issue
18:15:28 <alexsaezm> perhaps we should talk to Fedora infra? not sure if they handle this kind of things
18:17:13 <alexsaezm> Anyway, we have two tagged issues and another one that I think is way more relevant these days
18:17:41 <alexsaezm> but first... someone has updates that we should discuss about any of these two issues:
18:17:42 <alexsaezm> https://pagure.io/GoSIG/go-sig/issue/42 & https://pagure.io/GoSIG/go-sig/issue/43
18:17:58 <alexsaezm> If not, we can jump into the orphaning situation and then open floor
18:18:01 <alexsaezm> if that sounds good
18:19:17 <mikelo_m[m]> issue #43 is linked with the orphan status, as many of the packages are related to the docker/moby/containerd ecosystem
18:19:36 <alexsaezm> two for the price of one :D
18:20:39 <mikelo_m[m]> the approach by gotmax, bundling everything, should ease things for those packages, but lot of work would be required for the current packages depending on them
18:20:40 <alexsaezm> well, let's jump into the issue then
18:20:44 <alexsaezm> #topic Orphan packages https://pagure.io/fesco/issue/3017
18:21:30 <alexsaezm> so bundle everything in the containerd ecosystem?
18:22:09 <copperi[m]> Yes, I think that would be best.
18:22:58 <copperi[m]> Should keep packages more up to date that way?
18:23:06 <mikelo_m[m]> I don't think it's that easy
18:23:20 <mikelo_m[m]> as said, lot of other packages require some of the packages of that ecosystem
18:23:45 <mikelo_m[m]> bundling them should ease the maintenance of those bundled packages, but if the rest of the packages require to be adapted then it will take more time
18:24:16 <alexsaezm> and if we bundle dependencies that right now are packages, we should provide them from the package too
18:24:31 <alexsaezm> so we don't break other packages
18:28:30 <mikelo_m[m]> I was re-reading the #43 ticket to better undrstand what is the current approach
18:29:17 <mikelo_m[m]> eclipseo was supposed to work in the bundling of those packages
18:30:28 <mikelo_m[m]> and the packaging guideline says packages it SHOULD be unbundled
18:30:44 <mikelo_m[m]> I'm not sure how to feel about it
18:31:26 <mikelo_m[m]> bundling all binaries will reduce the amount of packages by a lot, but that would be against the guideline
18:32:00 <mikelo_m[m]> but if something requires some kind of integration with cointainerd, k8s or alike, the dep chain is huge
18:32:00 <alexsaezm> yeah, and I don't think we can just go there and say pretty please let me ask for 50 bundled packages :D
18:32:01 <mikelo_m[m]> some packages are pulling +700 packages to be built for example
18:32:01 <alexsaezm> oh
18:32:04 <alexsaezm> 700?!
18:32:09 <mikelo_m[m]> yep
18:33:35 <mikelo_m[m]> something as "simple" as doctl, the CLI for DigitalOcean pulled 725 deps last month https://kojipkgs.fedoraproject.org//packages/doctl/1.96.0/1.fc38/data/logs/x86_64/root.log
18:33:55 <alexsaezm> (:
18:33:58 <alexsaezm> great
18:34:33 <mikelo_m[m]> 770 for the rclone update I'm working on https://download.copr.fedorainfracloud.org/results/mikelo2/rclone/fedora-rawhide-x86_64/06137213-rclone/builder-live.log.gz
18:35:32 <mikelo_m[m]> some of those deps could be removed, as they may be pulled by a package in the chain requiring something for %check, but not an easy task
18:37:25 <alexsaezm> I honestly don't know what is the best approach here... if we follow that path we will end bundling the whole Go ecosystem
18:37:49 <mikelo_m[m]> that's my feeling also
18:38:25 <mikelo_m[m]> but, it's not like go-sig plenty of people to manage all the issues
18:38:51 <mikelo_m[m]> maybe after July 22nd, when many of the orphan packages are retired, then we can think what  would be next
18:39:58 <alexsaezm> feels bad to wait for everything to fall to evaluate what can be then saved but it's a lot of packages
18:40:07 <alexsaezm> and if we adopt all of them we will never clean up the old ones
18:40:29 <mikelo_m[m]> and maybe the SHOULD UNBUNDLED decision has to be changed, I don't know who took it, but worth to explore the option of reverting it
18:40:48 <mikelo_m[m]> as mentioned in the FESCO ticket, I don't all the orphan should be adopted
18:41:29 <mikelo_m[m]> but all the binaries that someone want to maintain should be clean of orphan deps by then or it will be problematic
18:42:15 <alexsaezm> hmm but for example, I have a package, golang-x-perf
18:42:30 <alexsaezm> that is affected by 4 direct orphan packages
18:42:50 <alexsaezm> and by like 200 indirect packages
18:43:15 <alexsaezm> if I wait... :'D
18:43:35 <alexsaezm> so should I take those indirect dependencies :D
18:43:44 <mikelo_m[m]> anything depending on golang-google-grpc creates a HUGE chain
18:44:54 <alexsaezm> but golang-google-grpc is not orphaned
18:46:19 <mikelo_m[m]> but something that depends on something that depends on something that is required by google-gprc is orphan
18:46:30 <alexsaezm> got it
18:47:24 <alexsaezm> well... I guess we need to just wait to the 22th
18:47:46 <mikelo_m[m]> for that golang-x-exp package the question would be, why does it require golang-cloud-google ?
18:48:12 <alexsaezm> I checked but I don't recall it now, one sec
18:50:52 <alexsaezm> https://github.com/golang/perf/blob/master/go.mod
18:51:06 <alexsaezm> I was talking about perf not exp :D
18:51:11 <alexsaezm> exp is ok now
18:51:22 <alexsaezm> perf has a lot of cloud dependencies
18:51:27 <mikelo_m[m]> me--, I was looking at exp rather than perf
18:51:38 <alexsaezm> it's the same scenario tho
18:52:04 <alexsaezm> it depends on oauth2
18:52:25 <alexsaezm> https://github.com/golang/oauth2/blob/master/go.mod
18:52:30 <alexsaezm> and both has a nice dependency tree
18:53:18 <alexsaezm> hmmm but I checked
18:53:25 <alexsaezm> and nobody uses golang-x-perf
18:53:39 <alexsaezm> nor golang-x-oauth2
18:53:40 <alexsaezm> :-/
18:54:15 <mikelo_m[m]> check with dnf repoquery --repo=rawhide{,-source} --whatrequires 'golang(golang.org/x/oauth2/*)' | grep '.src$' | pkgname | sort -u
18:54:58 <alexsaezm> nice, the script I did is wrong :D
18:55:15 <alexsaezm> thanks, I'll update mine
18:55:22 <mikelo_m[m]> but golang/x/perf is not used by anyone, that's true
18:56:03 <alexsaezm> well in any case, that is now offtopic I think...
18:56:14 <alexsaezm> what's your take? what should be our next action?
18:56:30 <mikelo_m[m]> what I don't get is why moby-engine, that is bundled, is reported as an affected package
18:57:45 <mikelo_m[m]> my take would be the one I wrote in the FESCO ticket
18:57:57 <mikelo_m[m]> we can try to contact all the binary owners to see what's their plan
18:58:11 <mikelo_m[m]> and those packges with binaries that are orphan will die
18:58:39 <mikelo_m[m]> https://pagure.io/fesco/issue/3017#comment-863134
18:58:42 <mikelo_m[m]> this for now
18:58:47 <mikelo_m[m]> and later re-discuss about bundling things
18:58:52 <alexsaezm> ok
18:59:04 <alexsaezm> I'll do it then
18:59:47 <alexsaezm> #action alexsaezm will write to the owners of a package with binaries to check what they want to do with the orphaning
19:00:07 <mikelo_m[m]> I don't know if any of those packages are usd by anyone
19:00:20 <alexsaezm> we'll find out that
19:00:35 <mikelo_m[m]> but if people are impacted by those orphans.. well.. expect some extra bad press :D
19:00:55 <alexsaezm> :'D
19:01:18 <mikelo_m[m]> some stats, when all the packages were orphaned, ~2200 packages were impacted, that has been reduced to ~1400
19:01:31 <alexsaezm> that's great somehow :D
19:01:45 <mikelo_m[m]> there are some binary packages that are safe already
19:03:26 <alexsaezm> we are over the hour... I guess is time to call it :) we won't fix it anything today and we have a next action
19:04:40 <mikelo_m[m]> fine for me
19:04:53 <alexsaezm> thanks a lot mikelo_m ++
19:05:01 <copperi[m]> Thanks alex
19:05:11 <alexsaezm> nothing to thanks :)
19:05:20 <alexsaezm> we'll see how this thing is in two weeks
19:05:22 <alexsaezm> thanks everyone
19:05:31 <alexsaezm> #endmeeting