18:01:02 #startmeeting Go SIG meeting 18:01:02 Meeting started Mon Sep 12 18:01:02 2022 UTC. 18:01:02 This meeting is logged and archived in a public location. 18:01:02 The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:01:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:02 The meeting name has been set to 'go_sig_meeting' 18:01:17 #topic Roll Call 18:01:22 .hello mikelo2 18:01:23 mikelo: mikelo2 'Mikel Olasagasti Uranga' 18:01:24 .hello gotmax23 18:01:27 gotmax[m]: gotmax23 'Maxwell G' 18:02:11 .hello fuller 18:02:13 MarkEFuller[m]: fuller 'Mark E. Fuller' 18:02:34 I've been away a these past weeks so not sure if we have something relevant to discuss... so let's check the issues :) 18:02:56 two issues tagged with meeting 18:03:05 is there anything we should talk before starting with those two? 18:03:17 I don't think there's anything else to talk about for those two 18:03:46 #topoc Meeting Topic: Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42 18:03:50 I think mikelo had an update about unnecessary packages 18:03:53 #topicc Meeting Topic: Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42 18:03:59 #topic Meeting Topic: Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42 18:04:05 three attempts... 18:04:11 Third time's the charm! 18:04:24 .hello copperi 18:04:25 copperi[m]: copperi 'Jan Kuparinen' 18:04:34 * gotmax[m] waves 18:05:04 Does anyone have anything for this topic? 18:05:47 nothing from my side 18:05:53 I would suggest moving to open floor 18:06:17 there's another issue about x-build 18:06:41 We discussed that last time 18:06:47 oh got it 18:07:06 People seemed to agree to drop it, but it's up to eclipseo (the maintainer) what to do 18:07:27 got it :) so... open floor then :) 18:07:34 #topic Open Floor 18:08:03 #link https://src.fedoraproject.org/rpms/go-rpm-macros-epel 18:08:45 It's a go macros backport for EPEL 9 18:09:00 It fixes the issues we were having with RHEL's package and backports some new stuff 18:09:05 That sounds great 18:09:11 Feel free to read the description 18:09:27 I tried to be detailed :) 18:09:54 awesome 18:10:42 I am considering backporting %gometa -f and the new Provides generator to EPEL 8 as well. 18:11:03 I was also thinking about adding %goprep and %gocheck which don't exist at all in RHEL 8 18:11:17 But I'm not sure the latter is worth the effort 18:11:31 For EPEL 9, I think we should just vendor 18:11:55 But %go_generate_buildrequires and the other stuff needed for unbundling is now fixed in EPEL 9 18:12:12 In RHEL 9 proper, it's still very broken 18:13:42 mikelo: I can create a PR for the duf package to show what vendoring for EPEL 9 would look like if you'd like 18:14:22 So I don't presently use any *EL systems (anymore), but I still would be happy to actively support them however possible 18:14:32 gotmax[m]: I wuld also be interested in seeing this 18:14:46 great, it was requested by someone with Almalinux email address, he might benefit from that for other packages he may want 18:14:47 * gotmax[m] realizes he forgot his laptop charger and it's going to die soon... 18:16:28 mikelo: Did you want to bring up the thing about leaf packages? 18:16:44 #action gotmax to create example vendored duf package 18:17:08 I was not able to check much, I created the script, realized some packages could be removed, but I'm unsure how to report them 18:18:03 should we use something like a wiki to list those that can be removed and ask people to verify? 18:18:05 Yeah, I think we should have a process. We'd probably need the maintainer's ack for each package we want to remove 18:19:09 correct, that's the part I'm missing, how should we proceed ? 18:19:23 That would work. We should have some easy way to list all of the packages and track the status. 18:19:37 I like issue trackers, but I'm open to ideas 18:20:09 I was checking only those that are FTBFS, there was the rust script that QuLogic (iirc) tried last week for all packages 18:20:19 but starting from those in FTBFS I think is a great first step 18:20:43 by the way, just for the record of the meeting: we're <200 FTBFS! \o/ 18:21:04 Where was the list that you posted earlier this week? 18:21:21 https://mikel.olasagasti.info/tmp/fedora/goquery/ 18:21:26 https://mikel.olasagasti.info/tmp/fedora/goquery/possible_retirable.txt 18:21:53 #link https://mikel.olasagasti.info/tmp/fedora/goquery/possible_retirable.txt 18:25:07 but BZ tracker could help to keep better track 18:25:25 https://pad.snopyta.org/Flk58UZUSJC6YDtgpnQVTw 18:25:44 Here's a checklist with all of the packages you found if that helps 18:26:14 I've checked a couple that I know for sure provide binaries 18:27:07 ok 18:27:41 * gotmax[m] mourns the passing of his laptop's battery 18:28:03 I'm on my phone now 18:29:20 is there anything else? 18:29:50 nothing on my side 18:29:59 Zero 18:30:08 I plan to continue fixing FTBFS packages, focusing on packages that are depended by >1 packages 18:30:08 You mean for this issue or the meeting? 18:30:20 Thank you for doing that! 18:30:20 and hopefully doing reviews 18:30:32 :) 18:30:49 I'll try to look at more of the FTBFS ones when I get a chance 18:30:49 :) thanks a lot 18:31:19 Note thst you have to close the FTBFS bugs yourself. They don't get closed automatically like the FTI ones 18:32:29 FTI stands for? 18:32:38 Fails to install 18:32:55 oh, yes, I'm adding "closes rhbz#XXXXX" to the commit to fix them 18:33:10 but I realized that in the packages that are not using rpmautospec that doesn't work, so I'm manually closing them 18:33:11 👍 18:33:55 Yeah, when they don't use rpmautospec, you have to add the bug number to the normal changelog 18:34:17 * mikelo is used to rpmautospec already 18:34:48 I use it for my go packages, but I prefer manual changelogs otherwise 18:36:15 if everybody is ok, we can call it and end the meeting :) 18:36:21 SGTM 18:36:58 Ending early will compensate for all of our meetings that went over :) 18:37:13 gotmax[m], I saw you updated golang-github-emersion-pgpmail to 0.2.0, I created a PR for it https://src.fedoraproject.org/rpms/golang-github-emersion-pgpmail/pull-request/1 planning ot merge it once golang-github-protonmail-crypto was stable, I think this will be required https://src.fedoraproject.org/rpms/golang-github-emersion-pgpmail/pull-request/1#_3__55 for next rebuild (koschei?) 18:38:13 I just set manual priority to it in koschei to check if it is required 18:38:45 mikelo: Sorry, I didn't mean to step on your toes. It built successfully. 18:39:16 no worries! was it with current protonmail-crypto ? 18:39:35 if so I'll close the PR (can't be merged cleanly anyway) 18:39:38 I think so 18:39:58 awesome then 18:40:05 I didn't do anything special. I just built it in the normal buildroot. 18:41:18 I have some local changes to aerc, so I'll submit a PR once we have all of the 0.12.0 deps 18:41:35 (Or whatever the new version number is...) 18:41:43 ack 18:41:58 if I see a FTBFS report for emersion-pgpmail I'll take care of it 18:43:23 gotmax[m], what about the new macro to have arched devel packages? should we open a ticket to track it? 18:43:24 mikelo2++ 18:44:27 I thought we weren't doing that 18:45:29 not currently 18:46:09 We wanted to allow certain packages that have arch specific header or s files to be arched 18:46:16 Like golang-x-sys 18:46:35 Or the one that Mikelo was working on 18:48:18 got it 18:48:27 thanks for clarifying 18:48:30 Sure 18:48:57 mikelo: Feel free to file a ticket in pagure.io/go-rpm-macros 18:50:27 I'd like to hear what eclipseo thinks before we add it 18:50:27 anything else? (looks like I want to close the meeting :D) 18:50:35 I thought we already closed it 18:50:44 no, we are still on the open floor 18:51:24 is there anything relevant for the meeting? we can close it and of course keep using the chat :D 18:51:24 Yeah, that's what I thought was happening in the first case 18:51:41 * gotmax[m] is a bit discombobulated 18:51:57 :D I'll close it then. thanks! 18:52:02 #endmeeting