18:00:19 <alexsaezm> #startmeeting Go SIG meeting
18:00:19 <zodbot> Meeting started Mon Jul 17 18:00:19 2023 UTC.
18:00:19 <zodbot> This meeting is logged and archived in a public location.
18:00:19 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:19 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:00:50 <alexsaezm> I don't see the bot's messages in Matrix... I think we are in the same situation as last week
18:00:55 <alexsaezm> sigh
18:01:29 <sub_pop[m]> mikelo_m[m]: Thank /you/ for the review.
18:01:34 <jcpunk> Hate to nag, but any updates on https://bugzilla.redhat.com/show_bug.cgi?id=2208339 ?
18:03:15 <BradSmith[m]> Lurking. Not a formal member of gosig but may have a question later
18:03:31 <Guest99> Testing
18:03:39 <alexsaezm> odd
18:03:43 <alexsaezm> again I cannot see IRC messages
18:03:53 <alexsaezm> I just typed as Guest99
18:04:01 <alexsaezm> from my phone
18:04:04 <alexsaezm> sigh, let's continue :)
18:04:07 <BradSmith[m]> Neither did i
18:04:11 <QuLogic> hmm, broken bridge is quite annoying
18:04:23 <alexsaezm> First of all... I see someone familiar... Hi there eclipseo !!
18:04:38 <eclipseo> Hi
18:04:38 <alexsaezm> yeah, last meeting was broken too :(
18:05:40 <alexsaezm> well, I'm monitoring the IRC channel from the phone (and outside my network because my ISP seems to enjoy playing with my IP and libera doesn't like it)
18:05:46 <alexsaezm> shall we jump into the first topic? :)
18:06:36 <alexsaezm> We only have two topics labeled for the meeting, https://pagure.io/GoSIG/go-sig/issue/42 and https://pagure.io/GoSIG/go-sig/issue/43
18:06:37 <alexsaezm> any preference?
18:07:04 <BradSmith[m]> none
18:07:14 <BradSmith[m]> none as in no preference :)
18:07:33 <alexsaezm> let's start with the lower in number then :D
18:07:48 <alexsaezm> #topic Meeting Topic: Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42
18:08:27 <alexsaezm> Does anyone have an update on this? (if not, we can move to the next one, this is for checking the state)
18:08:40 <mikelo_m[m]> I'm using gometa -f in all new packages and those that I'm updating
18:08:57 <mikelo_m[m]> I guess it's the new standard until x86 is completely removed from Fedora
18:09:35 <eclipseo> i do the same, when is ix86 planned to be phased out? F39 ?
18:11:04 <mikelo_m[m]> https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
18:12:05 <alexsaezm> This is quite relevant these days because it's been failing a lot recently due to a kernel issue
18:12:49 <mikelo_m[m]> I'm not able to find a newer proposal
18:12:49 <alexsaezm> I have a bunch of packages that still uses because another dependency use it too... not sure if I should start removing them
18:13:02 <mikelo_m[m]> I think after gotmax's PR was accepted most of us are using gometa -f
18:13:57 <mikelo_m[m]> next step could be to change macros to default to what "gometa -f" does
18:14:14 <alexsaezm> and what about the existing packages?
18:14:25 <alexsaezm> that already build there
18:14:49 <mikelo_m[m]> it should be a proposal for f39?
18:15:10 <alexsaezm> we are a little bit late for that I think :(
18:15:41 <QuLogic> Since everything ends up in a binary at the end, I think it might be a bit safe to toggle
18:15:57 <QuLogic> However, I think the problem may be things that depend on go apps that haven't dropped 32-bit
18:16:09 <mikelo_m[m]> https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
18:16:10 <QuLogic> much like pandoc in Haskell land
18:16:26 <mikelo_m[m]> not sure if changing macro would be a self-contained change
18:17:24 <QuLogic> Maybe we'd want a flag opposite to -f to keep 32-bit explicitly?
18:18:02 <mikelo_m[m]> that would make sense... but which packages would need to have it? how do we get a list of packages that require a 32bit build?
18:20:56 <mikelo_m[m]> maybe gotmax had a plan already, we can check in the ticket
18:21:38 <alexsaezm> good idea, I was trying to find a way using koji's cli but I don't see anything after a quick look
18:21:43 <alexsaezm> I'll update the ticket
18:23:02 <alexsaezm> #action alexsaezm will update the ticket proposing a way to invert the behaviour of the gometa -f and ask gotmax if we can retrieve the list of packages that still have a 32bit build
18:23:28 <alexsaezm> #topic  Discuss current docker/moby/containerd ecosystem brokenness https://pagure.io/GoSIG/go-sig/issue/43
18:24:04 <alexsaezm> any updates on this one?
18:24:41 <eclipseo> extremely time consuming
18:26:10 <alexsaezm> we can split the work there if there's a path to follow :)
18:27:51 <BradSmith[m]> alexsaezm: and I would recommend a coordinator of some sort
18:30:55 <eclipseo> step 1 : update all packages containing k8s in the name
18:30:56 <eclipseo> step 2 : update moby related packages
18:30:57 <mikelo_m[m]> on the techincal side of the proposa, one option would be to leverage copr and use dist-git+branches for all the packages, so for example if docker needs to be udpate to 23, create a branch on each package that requieres to be update to docker-23, create a copr project, add each package using dist-git with docker-23 branch. That way tracking packages can be easier
18:34:11 <alexsaezm> I guess the best thing we can do now is to update the ticket to have a clear path?
18:35:47 <eclipseo> not sure of the path yet. di we have a go-sig copr with public access for all of us?
18:36:01 <alexsaezm> if we have it, I never used it :D
18:36:13 <alexsaezm> I know LLVM has it, so maybe it is something interesting to have
18:39:16 <alexsaezm> should that be the next step (no matter what is the next one to that :D)
18:39:57 <QuLogic> sounds like a good idea, yea
18:40:15 <eclipseo> https://copr.fedorainfracloud.org/groups/g/go-sig/coprs/
18:40:28 <eclipseo> there's a go-sig group
18:40:48 <eclipseo> could probably use it to work together on k8s update for example
18:40:55 <alexsaezm> o:
18:41:24 * alexsaezm bookmarked it
18:42:01 <alexsaezm> I just realized I can see the copr group from my profile... silly me
18:42:25 <eclipseo> i made a k8s project
18:43:00 <alexsaezm> thank you!
18:43:30 <alexsaezm> so now that we have a k8s project... what would be the next step?
18:43:40 <BradSmith[m]> just an fyi I have https://copr.fedorainfracloud.org/coprs/buckaroogeek/copr-k8s/
18:45:01 <BradSmith[m]> tangentially related i suppose
18:46:06 <eclipseo> this is the binary package, my focus i was more on all the golang-k8s libraries too
18:47:07 <eclipseo> alexsaezm: decide which version we want to package, its a fast moving target, we should not pick the latest but rather the one which is stable and work well with the rest
18:48:05 <alexsaezm> sounds ok to me. Not really familiar with k8s son can't say which one is a stable one :) but I think for now, the best thing we can do, is to record that in the ticket and move on
18:48:49 <BradSmith[m]> Upstream K8S supports 3 concurrent versions
18:49:50 <eclipseo> ok
18:50:51 <alexsaezm> anyone wants to add that to the issue? I can do it if nobody wants :)
18:52:48 <alexsaezm> #action alexsaezm will update the ticket mentioning that we have a copr repository where we can update to a stable version k8s. We should also decide which version
18:53:01 <alexsaezm> and now, last but not least...
18:53:02 <alexsaezm> #topic Open floor
18:53:19 <BradSmith[m]> I have a related question
18:53:20 <mikelo_m[m]> can we start with the orphan status?
18:53:33 <alexsaezm> sure
18:53:58 <alexsaezm> BradSmith[m]: shoot :)
18:54:01 <mikelo_m[m]> I sent an email to all the maintainers affected by orphan packages. I plan to send another reminder after tomorrows data refresh.
18:54:12 <mikelo_m[m]> 5 days until ~500 packages are removed
18:54:22 <eclipseo> im working on that
18:54:30 <eclipseo> i took over some already
18:54:35 <BradSmith[m]> alexsaezm: After mikelo_m  :)
18:54:38 <alexsaezm> eclipseo: are you going to take all of them?
18:54:41 <alexsaezm> O:
18:54:57 <mikelo_m[m]> I hope you're not taking all!
18:55:11 <eclipseo> alexsaezm: i'm trying to establish all the dependencies needed by our current bonarie
18:55:23 <eclipseo> s/bonarie/binaries/
18:55:25 <mikelo_m[m]> if no-one has touched those packages for months/years, it shouldn't be an issue for them to get removed
18:55:47 <mikelo_m[m]> eclipseo: you can use the packager-dashboard for that
18:55:51 <eclipseo> mikelo_m[m]: indeed just trying to see which on we actually need
18:56:19 <mikelo_m[m]> i took +300 packages required by some of the binaries I maintain (gh, glab, doctl, ...)
18:56:25 <eclipseo> mikelo_m[m]: yes but i can't filter by binary package i think
18:56:34 <mikelo_m[m]> my list of affected packages by orphans is currently 0
18:56:38 <mikelo_m[m]> I think alexsaezm did the same
18:56:57 <mikelo_m[m]> it's possible to filter
18:57:07 <mikelo_m[m]> I mean, no by the dashboard
18:57:10 <mikelo_m[m]> but there is data also in https://pagure.io/GoSIG/go-leaves
18:57:24 <eclipseo> yes i took over my previous binary packages, and the deps needed by then
18:57:29 * alexsaezm still have like 5 packages affected :D
18:57:30 <mikelo_m[m]> you can check pckages with binaries there and binaries affected by orphans also
18:57:38 <eclipseo> but now i'm looking for the ones of others packagers
18:57:53 <mikelo_m[m]> other packages have been contacted by mail last week
18:57:58 <mikelo_m[m]> *packagers
18:58:30 <mikelo_m[m]> I sent this https://pagure.io/fesco/issue/3017#comment-864530
18:59:27 <eclipseo> yes i noted
19:00:49 <mikelo_m[m]> list has been reduced from 40 maintainers to 21
19:01:05 <QuLogic> OK, I've taken the 2 things that are causing trouble for mine
19:01:39 <QuLogic> nvml via qemu is also on the list, but I think the qemu maintainer is going to take care of it
19:03:18 <eclipseo> yes i saw his message
19:05:26 <alexsaezm> any more updates on this or we can allow Brad Smith to talk ? :D (just kidding)
19:05:47 <eclipseo> ok for me
19:06:38 <BradSmith[m]> Ok :)
19:07:06 <BradSmith[m]> Similar question to k8s discussion above.
19:07:10 <BradSmith[m]> I co-maintain kubernetes binary rpms for Fedora. Each version of Fedora has a version of K8S, e.g. F39 - 1.27, F37 - 1.26, etc. K8S 1.28 will likely go live before F39.  What would be the preferred tactic - drop 1.28 into COPR until F40?
19:08:25 <BradSmith[m]> Or adopt modules like cri-o? Or ???
19:09:08 <alexsaezm> it looks similar to the Go workflow, but  I wonder, k8s doesn't require a mass rebuild (which is the whole reason behind the workflow in the Go case), so why is a problem to update k8s on F39 when 1.28 comes out?
19:10:29 <BradSmith[m]> alexsaezm: I think it important to not drop 1.27 as it will be maintained upstream
19:12:11 <alexsaezm> So, let's say that F39 goes live and a month later 1.28 appears. Following that approach, I understand that rawhide would have 1.28
19:12:24 <alexsaezm> what I meant is... As far as I understand the workflow, rawhide should point to the latest stable version
19:12:43 <mikelo_m[m]> ideal solution would be modules I guess... but may require extra work
19:12:53 <mikelo_m[m]> what about having versiones packages?
19:12:55 <alexsaezm> aren't they going away?
19:13:07 <BradSmith[m]> gotmax discouraged me from modules :)
19:13:09 <mikelo_m[m]> they're going away from RHEL, not sure about Fedora
19:13:55 <mikelo_m[m]> I wouldn't mind to have "k8s-1.27" and "k8s-1.28" as packages
19:13:56 <mikelo_m[m]> it's extra work also, but less than modules I would say
19:13:57 <BradSmith[m]> mikelo_m: yes that is what i am leaning to
19:14:12 <alexsaezm> I think the problem of that approach is that it creates a lot of work in each package
19:14:22 <BradSmith[m]> Do not mind the work
19:14:34 * alexsaezm likes modules a lot, I will miss them in rhel
19:14:40 <gotmax23> https://fedoraproject.org/wiki/Changes/RetireModularity
19:14:47 <gotmax23> Modules in Fedora are no more
19:14:54 <mikelo_m[m]> they're binary bundled packges, I don't think that other than having to create the repo every 4 months and retiring old releaess
19:15:07 <alexsaezm> gotmax23: that was my understanding
19:15:11 <mikelo_m[m]> wow, we summoned gotmax23
19:15:20 * gotmax23 didn't know that modules were going away in RHEL and now has something to be happy about
19:16:11 <alexsaezm> gotmax23: > * <@gotmax:matrix.org> didn't know that modules were going away in RHEL and now has something to be happy about
19:16:11 <alexsaezm> they are still on rhel 9 but almost removed (at least in the vast majority of the packages), and they will probably go away for sure following this trend
19:16:37 <eclipseo> wirking with module on Go is damn near impossible due to some bootstrap packages
19:17:19 <alexsaezm> right... never thought about that. Versioning becomes tricky
19:17:49 <alexsaezm> If you don't like to have 1.28 in rawhide, I guess the only thing is a copr repo or what mikelo_m said about the naming in the packages
19:18:40 <BradSmith[m]> > If you don't like to have 1.28 in rawhide, I guess the only thing is a copr repo or what mikelo_m said about the naming in the packages
19:18:40 <BradSmith[m]> Ok. Thanks. I will write up a proposal for review
19:19:00 <BradSmith[m]> i have the copr repo already and that will be a stop gap
19:19:32 <BradSmith[m]> thanks - i have what i need for now
19:19:43 <alexsaezm> awesome
19:20:12 <alexsaezm> I think we can call it now :)
19:20:28 <eclipseo> ok great!
19:20:47 <alexsaezm> FYI: I'll push 1.21rc3 to rawhide tomorrow (my tomorrow) and 1.20.6 and 1.19.11 are in bodhi now.
19:20:50 <jcpunk> any chance for https://bugzilla.redhat.com/show_bug.cgi?id=2208339 ?
19:21:12 <alexsaezm> * rawhide tomorrow morning (my tomorrow, * (my tomorrow morning is in 10 hours or so :D) and
19:21:27 <gotmax23> Cool!
19:21:52 <gotmax23> The mass rebuild is Wednesday I believe
19:21:54 <mikelo_m[m]> I'm looking for reviewers for some packages I've pending required mainly for rclone, but also restic or subfinder/dnsx
19:21:54 <mikelo_m[m]> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&component=Package+Review&email1=mikel%40olasagasti.info&emailreporter1=1&emailtype1=substring&known_name=my-reviews-pending&list_id=13267055&or
19:21:54 <mikelo_m[m]> der=status%2C+assigned_to%2C+id%2C+&product=Fedora&query_based_on=my-reviews-pending&query_format=advanced
19:22:14 <alexsaezm> gotmax23: yes, they approved my proposal today, I think is still unannounced
19:22:24 <BradSmith[m]> i use restic a lot
19:23:28 <mikelo_m[m]> iirc restic only missing azure's packages that alexsaezm should review at some point ;)
19:23:45 <mikelo_m[m]> rclone requires others like stoj-picobuf or quic
19:23:52 <alexsaezm> I'll review those packages tomorrow too, fedora-review is a little bit broken :')
19:25:53 <alexsaezm> I'll end the meeting here (I need to drop), thank you all for attending today! glad to see (read) you all :)
19:26:03 <alexsaezm> #endmeeting