18:10:35 <gotmax[m]> #startmeeting Go SIG Meeting
18:10:35 <zodbot> Meeting started Mon Aug 15 18:10:35 2022 UTC.
18:10:35 <zodbot> This meeting is logged and archived in a public location.
18:10:35 <zodbot> The chair is gotmax[m]. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:10:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:10:35 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:10:49 <gotmax[m]> #topic Salutations
18:10:58 <gotmax[m]> .hello gotmax23
18:11:01 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
18:11:43 <eclipseo> .hello eclipseo
18:11:44 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
18:12:17 <gotmax[m]> #chair eclipseo
18:12:17 <zodbot> Current chairs: eclipseo gotmax[m]
18:12:26 <gotmax[m]> #chair gotmax
18:12:26 <zodbot> Current chairs: eclipseo gotmax gotmax[m]
18:12:32 <mroche> .hello mroche
18:12:32 <zodbot> mroche: mroche 'Michael Rochefort' <mike@michaelrochefort.com>
18:12:33 <mikelo_m[m]> Alex is out today, I’ll be intermittent
18:12:45 <gotmax[m]> Ack.
18:13:12 <gotmax> #chair mikelo_m[m]
18:13:12 <zodbot> Current chairs: eclipseo gotmax gotmax[m] mikelo_m[m]
18:13:14 <mikelo_m[m]> .hello mikelo2
18:13:15 <zodbot> mikelo_m[m]: mikelo2 'Mikel Olasagasti Uranga' <mikel@olasagasti.info>
18:13:48 <eclipseo> #chair mroche
18:13:48 <zodbot> Current chairs: eclipseo gotmax gotmax[m] mikelo_m[m] mroche
18:14:01 <gotmax[m]> I did some work towards https://pagure.io/GoSIG/go-sig/issue/46 . I'm not sure if anyone has anything else they'd like to bring up.
18:14:34 <gotmax[m]> I'll wait until :16 to start
18:15:59 <mroche> The only issues tagged for meeting is #42 which I think was discussed previously?
18:16:16 <mroche> That's great news, gotmax (He/Him)
18:16:40 <gotmax[m]> There's a short update, but I'll start with:
18:16:59 <gotmax[m]> #topic Universal bundled provides script - https://pagure.io/GoSIG/go-sig/issue/46
18:17:25 <eclipseo> so two words about his: !
18:18:05 <eclipseo> 1. Python 2. Reads modules.txt and not go.mod for more accuracy
18:18:12 <gotmax[m]> So, basically I started writing a dependency generator to generate these Provides. It requires that you add `%license vendor/modules.txt` and then it processes the file.
18:18:26 <gotmax[m]> Then, none of this would have to be done specfile side.
18:18:38 <gotmax[m]> Is that something people would be interested in?
18:19:09 <gotmax[m]> The underlying script that actually processes the modules.txt is based off of https://src.fedoraproject.org/rpms/syncthing/blob/rawhide/f/vendor2provides.py
18:19:25 <eclipseo> yeah but why add it to %license??
18:20:30 <gotmax[m]> Well, it needs to be somewhere in the buildroot for the dependency generator to find it and process it. I suppose it could be marked as `%ghost` and not installed in the package, but I think it's a good idea to include the data about the actual dependencies.
18:20:40 <eclipseo> LGTM to use that one
18:21:01 <gotmax[m]> When vendoring, we also really should be including the licenses of the vendored dependencies when calculating the License tag.
18:21:02 <gotmax[m]> I also looked into that
18:21:49 <eclipseo> in %doc maybe, but %license is specifically for license stuff, which vendor.txt is not, there is no license info in it
18:22:00 <gotmax[m]> %doc would work
18:22:44 <eclipseo> gotmax[m]: Problem with this is that some packages are pulling 600+ deps
18:22:54 <copperi[m]> .hello copperi
18:22:55 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
18:23:01 <gotmax[m]> It's more clean cut for vendoring
18:23:04 <eclipseo> or we only do the immediate layer of dep
18:23:08 <gotmax[m]> I also started working on a script for this
18:23:29 <eclipseo> Hello copperi
18:23:36 <eclipseo> #chair copperi
18:23:36 <zodbot> Current chairs: copperi eclipseo gotmax gotmax[m] mikelo_m[m] mroche
18:23:45 <gotmax[m]> For unbundled packages, I agree with you; it's not practical to calculate all of the licenses.
18:24:20 <mikelo_m[m]> eclipseo: I’ve been working to package tailscale, it takes ~640
18:24:41 <mroche> How are you planning on approaching determining dependency licenses?
18:24:52 <gotmax[m]> gotmax[m]: For vendoring, we also should include the licenses.
18:25:11 <gotmax[m]> I wrote a script that uses askalono to scan a vendor directory
18:25:32 <gotmax[m]> s/licenses/license files in the final package/
18:25:53 <mroche> Ah, couldn't remember if `go mod vendor` also included licenses or just necessary module code.
18:26:26 <gotmax[m]> I guess that's not too much to discuss here. I just wanted to point out the work I've been doing.
18:26:38 <gotmax[m]> s/./ and solicit feedback/
18:27:14 <eclipseo> thanks for all your work
18:27:44 <mroche> Something I've been meaning to look back on is whether the vendoring process in 1.18+ includes all deps. There was something that caught my eye about dependency tracking that I need to revisit.
18:27:44 <gotmax[m]> Sure :)
18:28:23 <mroche> Had to do with transitive deps and similar, but that might have just been go.mod related.
18:28:59 <gotmax[m]> Yeah, I'm pretty sure it includes everything, besides the go.mod files of the dependencies.
18:29:03 <gotmax[m]> Otherwise, it wouldn't be effective
18:29:24 <mroche> Based on the packages I build, it seems to catch everything and I've been using 1.18+
18:30:03 <gotmax[m]> What are those packages again? I believe they're not all in Fedora?
18:30:11 <gotmax[m]> (Just curious :-))
18:31:15 <mikelo> gotmax[m], if I want to build a bundled tailscale, that currently needs +600 deps, are all those deps need to be removed from Fedora? that's something that *I* still don't have clear
18:31:44 <gotmax[m]> mikelo: Nothing needs to be removed from Fedora to bundle.
18:31:51 <mikelo> gotmax[m], ack
18:31:52 <gotmax[m]> The bundled and non-bundled packages can live side by side
18:32:32 <mroche> Bunch of cloud native/focused tooling. https://pagure.io/mroche/cloud-native-utilities
18:32:35 <mikelo> this comment confuses me https://pagure.io/GoSIG/go-sig/issue/43#comment-807427
18:32:50 <gotmax[m]> mroche: Dead link
18:33:14 <mroche> https://pagure.io/mroche/cloud-utilities
18:33:22 <gotmax[m]> mikelo: That's if we bundled docker which already has a bunch of dependents
18:33:26 <mroche> Mixed my COPR name with the repo name
18:33:43 <gotmax[m]> Specifically, things depend on the -devel package which would go away if we bundled.
18:34:03 <gotmax[m]> For new packages, that's not a problem
18:34:19 <gotmax[m]> Maybe there was confusion between `dependents` and `dependencies`?
18:34:21 <mroche> Helm is the only one in Fedora, but it's several minor versions behind.
18:34:36 <mroche> If I remember correctly.
18:34:50 <gotmax[m]> I'm thinking we should bundle helm until the docker packages that are breaking it get sorted out, but not really my decision
18:34:58 <gotmax[m]> mroche: Yes, it's behind
18:35:44 <mroche> Hence why I have it bundled in my COPR. I believe Davide was doing the helm packaging work at one point
18:36:15 <davide> Helm is in pretty bad shape right now
18:36:23 * gotmax[m] waves to Davide Cavalca
18:36:25 <mikelo> gotmax[m], based on your comment for example bundling golang-github-spf13-viper would also require to bundle everything that depends on it? 13 direct deps based on my query
18:36:42 <davide> I spent a good amount of time a few weeks ago to try and get it sorted out, but I can't get the tests for one of the dependencies to pass properly
18:36:59 <davide> I put the details on the bugzilla, on a plane right now so I won't attempt to look it up
18:37:25 <gotmax[m]> Bugzilla barely even loads when I'm not on a plane...
18:37:33 <eclipseo> Davide Cavalca: link to the problematic build? It's ok to zap some test if it's not some ABI problem
18:37:50 <eclipseo> oki
18:38:00 <davide> so, the problem is that the test exercises code that's specifically used by helm
18:38:08 <davide> so it seemed like a bad idea to just neuter it
18:39:10 <mikelo> gotmax[m], what I'm afraid of is that if we start bundling things that touch too many parts, we may end bundling everything.. which I'm not sure if it's a good thing or not
18:39:24 <gotmax[m]> Davide Cavalca: Do you at least remember the name of the Bugzilla? I'm trying to search for it.
18:39:41 <gotmax[m]> mikelo: The list in that issue should include recurisve deps
18:39:45 <davide> it was oras
18:40:33 <gotmax[m]> #topic Bundling and helm
18:40:37 <mikelo> gotmax[m], doing: dnf repoquery --disablerepo="*" --enablerepo=rawhide --whatrequires "golang-github-spf13-viper-devel"  I see vultr-cli-devel that I don't see in the list
18:40:39 <mroche> https://bugzilla.redhat.com/show_bug.cgi?id=1971091
18:40:41 <gotmax[m]> Just switching the topic for organizational purposes
18:41:15 <mroche> davide: Was it the 32bit arch test failure BZ?
18:41:35 <mroche> Disregard, element lagged
18:41:47 <davide> it was an import conflict causing a failure in one of the docker-related tests
18:43:27 <gotmax[m]> mikelo: Hmm, I'll have to look. It might be needed to query deeper.
18:43:38 <mroche> I think I saw oras pop up as a dependency in several of my packages, will double check.
18:43:38 <gotmax[m]> Thanks for pointing that out
18:43:50 <davide> ok I dug it up: https://bugzilla.redhat.com/show_bug.cgi?id=2111089
18:45:14 <mroche> Nope, just helm
18:45:40 <gotmax[m]> Davide Cavalca: Nothing depends on golang-helm-3-devel, so if you need to bundle that, it won't affect other packages
18:45:41 <eclipseo> didn't I update oras a while ago?
18:46:35 <eclipseo> i dd not apparently
18:47:48 <gotmax[m]> Okay, just so I don't forget:
18:47:55 <eclipseo> ah yes, i've got oras in my package ready for upload
18:48:21 <gotmax[m]> #action gotmax[m] to continue working on Provides generator and license scanner for vendored go packages
18:48:46 <gotmax[m]> Ack. Do we want to continue to discussing here or should I move on?
18:49:06 <eclipseo> we can move on for me
18:49:30 <gotmax[m]> Ack
18:49:40 <gotmax[m]> Anything else from anyone else?
18:50:35 <gotmax[m]> #topic Discuss dropping golang and go libraries/applications from %ix86 - https://pagure.io/GoSIG/go-sig/issue/42
18:50:50 <gotmax[m]> #info A new version of go2rpm is out: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5904cd0e8f
18:51:11 <gotmax[m]> #info Testing would be appreciated
18:51:17 <gotmax[m]> #undo
18:51:17 <zodbot> Removing item from minutes: INFO by gotmax[m] at 18:51:11 : Testing would be appreciated
18:51:31 <gotmax[m]> Well, it's going to stable today, so not much to test
18:52:00 <gotmax[m]> The main change is the use of `%go2rpm -f` by default.
18:52:12 <gotmax[m]> And there's some bugfixes
18:52:24 <eclipseo> ell I've been usint it intensively this weekend with no issue
18:53:07 <gotmax[m]> By default, spoecfiles now have... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e55ca1bda1d018f2797f73625d1931a0f56b36b4)
18:53:13 <gotmax[m]> The warning can probably be made less intrusive
18:53:27 <gotmax[m]> But you can use `-q` for it to be excluded from the generated specfile
18:53:54 <gotmax[m]> Just wanted to let y'all know and see if there were questions
18:53:58 <gotmax[m]> or comments
18:54:02 <eclipseo> what's the policy for -f on updated packages?
18:54:03 <gotmax[m]> * By default, spoecfiles now have... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/24b2e0d098d0aeb21a31c9baea29ff8590634dce)
18:54:24 <MarkEFuller[m]1> typo in line 5
18:55:12 <gotmax[m]> If the package has dependents that still are built for i686, then it should stay on that arch
18:55:14 <MarkEFuller[m]1> .hello fuller
18:55:15 <zodbot> MarkEFuller[m]1: fuller 'Mark E. Fuller' <mark.e.fuller@gmx.de>
18:57:16 <gotmax[m]> For `-devel` only packages, the dependents will still be able to pull in the -devel packages on i686, but I don't want to rely on that or have library breakages on that arch that aren't caught until the dependents FTBFS.
18:57:25 <gotmax[m]> For cel, it's a bit of a different story
18:57:41 <gotmax[m]> Because of the whole java situation, and the amount of dependents it has
18:57:59 <gotmax> #chair MarkEFuller[m]1
18:57:59 <zodbot> Current chairs: MarkEFuller[m]1 copperi eclipseo gotmax gotmax[m] mikelo_m[m] mroche
18:58:43 <gotmax[m]> Mark E. Fuller: Indeed, I should fix that typo. Too bad I didn't catch it before :(.
19:00:06 * eclipseo posted a file: (6KiB) < https://libera.ems.host/_matrix/media/r0/download/fedora.im/36fc93e87225c742e4c9a7c2e754202b6a9cbe4c/Docker.md >
19:00:14 <eclipseo> status on Docker
19:00:32 <gotmax[m]> That is a huge list :(
19:00:33 <eclipseo> slow progress, but i'm updating a lot of stuff in the process
19:01:16 <eclipseo> i'm working on golang-x-build right now
19:01:29 <eclipseo> will continue docker after it
19:01:30 <gotmax[m]> #topic Docker ecosystem
19:01:40 <gotmax[m]> I don't think golang-x-build is needed for anything
19:03:43 <eclipseo> indeed -_-
19:03:56 <gotmax[m]> You want to orphan or retire it?
19:05:49 <eclipseo> it provides binaries but i'm not sure who is consuming them
19:06:19 <gotmax[m]> Wasn't it broken by that grpc package that was retired?
19:08:25 <eclipseo> don't see any indication of that
19:09:15 <gotmax[m]> Hmm, okay. I don't know if it was actually retired yet, but I think x-build depended on it.
19:09:48 <gotmax[m]> I might be confused with something else, though
19:10:39 <eclipseo> oh yes you're right
19:10:43 <eclipseo> the grpc.go4
19:10:49 <eclipseo> it was retired indeed
19:10:56 <eclipseo> but that why i'm updating
19:11:08 <eclipseo> it's not needed anymore in latest version
19:11:19 <gotmax[m]> Ack
19:11:26 <gotmax[m]> Alright, I think I'll move to open floor
19:11:28 <gotmax[m]> #topic Open Floor
19:11:42 <gotmax[m]> I plan to end this at 2:20
19:11:51 <gotmax[m]> I don't want to go too far overtime
19:12:35 <davide> not sure if this was already discussed, but I've seen a bunch of ftbfs after the mass rebuild for missing test dependencies
19:12:47 <davide> but these packages were building fine before, so I'm not sure what changed
19:13:05 <gotmax[m]> I think there might be some golist brokenness
19:13:10 <davide> https://bugzilla.redhat.com/show_bug.cgi?id=2113315 is an example (and my comment links to one I just fixed)
19:14:00 <eclipseo> yeah i've seen a few ftbfs like this, i think some test were skipped before so the problem wasn;t showing
19:14:11 <davide> ah that would explain it
19:14:29 <davide> it's not a big deal to add them, thought it'd be nice for the generator to pick them up automatically
19:15:18 <gotmax[m]> Last time, rebuilding golist with the new go version helped, I think
19:15:47 <gotmax[m]> (golist powers `%go_generate_buildrequires`)
19:16:23 <eclipseo> yeah but it happened with some with static buildrequires too, so something changed Go side
19:17:18 <gotmax[m]> Well, both the generator and go2rpm use golist to find the dependencies
19:21:41 <gotmax[m]> Anything else before I end the meeting?
19:22:17 <eclipseo> not ok for me
19:22:44 <eclipseo> *no
19:22:54 <MarkEFuller[m]1> nothing here
19:23:05 <gotmax[m]> Alright
19:23:09 <gotmax[m]> #endmeeting