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