18:00:09 <alexsaezm> #startmeeting Go SIG meeting
18:00:09 <zodbot> Meeting started Mon Aug  1 18:00:09 2022 UTC.
18:00:09 <zodbot> This meeting is logged and archived in a public location.
18:00:09 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:09 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:00:32 <alexsaezm> #topic Roll Call
18:00:45 <gotmax[m]> The bridge is very slow today
18:00:47 <alexsaezm> yeah...
18:00:55 <alexsaezm> I don't see the messages from the bot :-/
18:01:04 <alexsaezm> now, there we go
18:01:13 <gotmax[m]> Do we want to just do this from IRC?
18:01:28 <MarkEFuller[m]1> No, please
18:01:33 <gotmax[m]> People can be wherever they want
18:01:44 <gotmax[m]> I'm just saying it might be better if we're all on one side
18:01:48 <gotmax[m]> But whatever
18:01:51 <gotmax[m]> .hello gotmax23
18:01:52 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
18:01:59 <MarkEFuller[m]1> .hello fuller
18:02:00 <zodbot> MarkEFuller[m]1: fuller 'Mark E. Fuller' <mark.e.fuller@gmx.de>
18:02:02 <QuLogic> .hello qulogic
18:02:06 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
18:02:13 <gotmax[m]> Meh, seems a bit better now
18:02:16 <mikelo> .hello mikelo2
18:02:17 <zodbot> mikelo: mikelo2 'Mikel Olasagasti Uranga' <mikel@olasagasti.info>
18:02:21 <alexsaezm> gotmax (He/Him): it woke up
18:02:28 <MarkEFuller[m]1> gotmax[m]: I also haven't used IRC in forever
18:02:39 * gotmax[m] gives zodbot some extra coffee
18:02:47 <jcajka> .hello jcajka
18:02:48 <zodbot> jcajka: jcajka 'None' <jcajka@cajka.dev>
18:03:14 * alexsaezm regrets every single second he stays in matrix
18:03:27 <gotmax[m]> Nobody's making you :D
18:03:36 <alexsaezm> myself :D
18:03:38 <copperi[m]> .hello copperi
18:03:39 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
18:03:59 <gotmax[m]> It seems we've had more attendance recently, which is nice :)
18:04:21 <eclipseo> .hello eclipseo
18:04:22 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
18:04:35 <gotmax[m]> alexsaezm: Want to `#chair` people?
18:04:47 <eclipseo> fricking hotel wifi of ****
18:04:54 <MarkEFuller[m]1> gotmax[m]: you'll tire of me soon enough
18:04:59 <eclipseo> good evening/day
18:05:09 <MarkEFuller[m]1> night here
18:05:11 <mikelo> eclipseo, I'm waiting on https://bugzilla.redhat.com/show_bug.cgi?id=2103460 golang-github-git-5 for other packages, review has been approved
18:05:30 <alexsaezm> gotmax (He/Him): sure
18:05:33 <gotmax[m]> mikelo: Is that needed for gh?
18:05:34 <alexsaezm> #chair gotmax (He/Him)
18:05:34 <zodbot> Current chairs: (He/Him) alexsaezm gotmax
18:05:48 <mikelo> gotmax[m], no, gh should be fine after the other review
18:05:58 * alexsaezm wonders if we should have a chairing system and if chairing is even a verb
18:06:04 <gotmax[m]> You can do it one line if you want: `#chair one two three`
18:06:15 <gotmax[m]> I guess I can now too :)
18:06:28 <gotmax[m]> #chair gotmax
18:06:30 <mikelo> gh 2.14.3 built for f37, I'm having issues to override one of the packages (fedpkg errors and bodhi doesn't show the package), so once the update hits stable I'll push it for f36
18:06:51 <gotmax> #chair mikelo eclipseo copperi[m] jcajka
18:06:51 <zodbot> Current chairs: (He/Him) alexsaezm copperi[m] eclipseo gotmax jcajka mikelo
18:06:58 <QuLogic> why not use a side tag?
18:07:44 <mikelo> QuLogic, I usually do that way, but as I could create the override of the missing package it shouldn't be a probelm... until it's a problem
18:07:44 <gotmax> #chair QuLogic
18:07:44 <zodbot> Current chairs: (He/Him) QuLogic alexsaezm copperi[m] eclipseo gotmax jcajka mikelo
18:07:47 <alexsaezm> I think we should leave mikelo and Elliott Sales de Andrade talk and then go for other topics :)
18:08:03 <mikelo> alexsaezm, lol, sorry to jump in too early ;)
18:08:13 <gotmax[m]> Let's wait till open floor
18:08:48 <alexsaezm> unless they are in a hurry
18:09:26 <alexsaezm> we have two issues with the meeting tag
18:09:56 <alexsaezm> #topic Discuss dropping golang and go libraries/applications from %ix86 https://pagure.io/GoSIG/go-sig/issue/42
18:10:09 <gotmax[m]> Okay, so I made some progress on this
18:10:23 <alexsaezm> awesome :)
18:10:34 <gotmax[m]> #link https://pagure.io/go-rpm-macros/pull-request/48
18:10:43 * gotmax[m] also waits for bad hotel wifi
18:10:58 <gotmax[m]> So basically, I'd like to exclude all new go packages from i686
18:11:04 <eclipseo> ☹️
18:11:11 <eclipseo> ok
18:11:14 <gotmax[m]> Didn't you want to do that?
18:11:26 <gotmax[m]> Oh, the emoji is about the wifi?
18:11:30 <eclipseo> sorry I was referring to your wifi
18:12:02 <gotmax[m]> I created a new %gometa flag, so new packages just have to replace `%gometa` with `%gometa -f`.
18:12:25 <gotmax[m]> The main thing we have to decide is how to handle `-devel` packages
18:13:04 <gotmax[m]> Currently, they're `noarch`. Due to a deficiency in rpm/koji, they will be included in the buildroot for i686, whether or not we build them for that arch
18:13:36 <eclipseo> it's not really a problem
18:13:43 <gotmax[m]> I don't like that, as it means we can still have other i686 packages depend on them, they just won't be tested on that arch
18:14:02 <eclipseo> there aren't consummed by anything but us while building binaries
18:14:04 <QuLogic> Won't those other packages mostly just be Golang packages, anyway?
18:14:13 <gotmax[m]> Yes
18:14:55 <gotmax[m]> eclipseo: Well, yes, but it just shifts the responsibility of fixing architecture related bugs from the library maintainers to the application maintainers (if they're not already the same person :))
18:15:14 <gotmax[m]> And it makes it easier for things to continue being added to that architecture
18:15:19 <QuLogic> But we'd have to turn it off from the leaf packages, which would be the apps first, no?
18:15:24 <eclipseo> but we won't have application on ix86 either?
18:15:26 <MarkEFuller[m]1> gotmax[m]: What is the deficiency and is it possible to address this issue there?
18:15:35 <gotmax[m]> No
18:16:14 <gotmax[m]> And that doesn't really matter anyways. We have to choose whether we want them available for arches they aren't built for (leave them noarch) or not (make them arched)
18:16:17 <jcajka> I can't really see how the noarch package should be an issue
18:16:28 <gotmax[m]> Elliott Sales de Andrade: Yes, or we could do groups of apps once
18:16:57 <MarkEFuller[m]1> jcajka: I would agree
18:17:19 <alexsaezm> I'm looking for an old bug where it was a huge pain in the...
18:17:20 <jcajka> IMHO it answers itself, if they are built for an arch they are no longer noarch
18:17:21 <eclipseo> the goal was to move to arched with modules
18:17:43 <MarkEFuller[m]1> cccccbdvhhegcibenlcbhdltjnvujeubihjlhhkjuird
18:17:43 <gotmax[m]> I guess I don't feel that strongly (and I am a very hardheaded person), but I still think the two issues (lack of testing, makes it harder to remove golang in the future) are important.
18:17:45 <MarkEFuller[m]1> cccccbdvhheglhnncbhblfjtfkitfbnnrjknhtkvnidl
18:17:50 <alexsaezm> cat?
18:17:51 <alexsaezm> :D
18:18:11 <gotmax[m]> Or mock swearing?
18:18:38 <MarkEFuller[m]1> stuck yubikey and I needed some leverage
18:18:44 <MarkEFuller[m]1> sorry
18:19:09 <gotmax[m]> There's some user (or maybe a bot?) in the python channel with the nick mock who always makes comments when someone mentions mokc
18:19:12 <gotmax[m]> *mock
18:19:19 <gotmax[m]> It's both annoying and funny
18:19:23 <gotmax[m]> Anyways...
18:19:38 <gotmax[m]> eclipseo: Why do modules have to be arched again?
18:20:20 <eclipseo> well they don't, but it was discussed back then with nim, and the plan was to move to arched
18:21:04 <gotmax[m]> Well, would the people who don't think noarch is a problem want to expand on their reasoning?
18:21:37 <jcajka> re modules, I would think lack of tooling, go list is inherently arch-full, build environment dependent
18:21:54 <eclipseo> technically arched would be better for some packages, we wouldn't have to use hacks to make them cooperate with noarch like golang-x-sys
18:22:29 <eclipseo> and the work nim had don on modules implied the list of files couldn't be changed to fit all arches at once
18:23:28 <eclipseo> since we can't really move to arched like this, and that  with modules, we would have to reboot the whole ecosystem, moving to arched then would be "easier"
18:24:03 <gotmax[m]> Well, we can move the packages that are still included on i686 to arched, also
18:24:14 <gotmax[m]> And it won't break anything
18:24:31 <gotmax[m]> The only packages I'd like to remove first are those affected by the java disaster
18:25:04 <gotmax[m]> golang-github-google-cel has a build requirement on java, so we'd need to remove it if we want to update it and not have it retired in two releases
18:25:29 <gotmax[m]> It would be easier to just remove all of the dependents from i686, but keep -devel noarch
18:26:14 <gotmax[m]> I would like to start with removing moby-engine from i686, because I maintain it
18:26:30 <eclipseo> only golang-google-grpc depends on cel, but it's a central piece
18:26:31 <gotmax[m]> Exactly
18:26:37 <jcajka> gotmax[m]: +1, or something similar at compose level, is it possible to filter out packages there?
18:26:39 <gotmax[m]> There's like 300 packages if you query recursively
18:26:58 <gotmax[m]> Well, we don't want them built at all
18:27:05 <gotmax[m]> They're already excluded from the compose
18:27:31 <gotmax[m]> Another angle of the i686 problem: We're wasting build resources, as almost none of these packages are actually part of composes
18:28:29 <eclipseo> well, if we move to our new goarches, what would the problem be? 🤔 No building on i686, only noarch hanging around with no purpose
18:28:43 <eclipseo> i,m not sure I fully grasp the problem
18:28:48 <gotmax[m]> There's other packages from outside the go ecosystem that would break
18:29:10 <gotmax[m]> (They don't have ExclusiveArch: %{go_arches})
18:29:28 <gotmax[m]> For example, R-rmarkdown which Elliott Sales de Andrade maintains
18:30:05 <eclipseo> ok
18:30:54 <gotmax[m]> I would like to just start removing chunks of packages at a time
18:30:56 <eclipseo> it's only binary deps though, no library
18:31:18 <gotmax[m]> For example, moby-engine and its 5 dependents
18:31:47 <gotmax[m]> eclipseo: Yes, but e.g. R-rmarkdown will FTBFS if we remove golang-github-tdewolff-minify from i686
18:31:57 <gotmax[m]> Eh, maybe not
18:32:00 <gotmax[m]> It's noarch
18:32:06 <gotmax[m]> So, that's a bad example, I guess
18:32:10 <jcajka> gotmax[m]: IMO it is more correct to fix it at their level, if they can't work in the new state of go packages, but from that this look more like a change for a rawhide after branching f37
18:32:16 <gotmax[m]> But there are others
18:32:16 <eclipseo> yes yes i understand
18:33:05 <gotmax[m]> That's another thing: we'd have to choose whether to limit it to rawhide
18:33:45 <gotmax[m]> https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval is what allows us to do this without a bunch of paperwork
18:34:00 <gotmax[m]> It doesn't require limiting to rawhide, as I understand it
18:34:38 <eclipseo> well it would be easier for backporting
18:34:46 <gotmax[m]> It would
18:34:54 <eclipseo> when was i686 stopped form being distributed?
18:35:01 <gotmax[m]> But we'd have to be careful
18:35:16 <gotmax[m]> I believe after the kernel was removed from that arch
18:35:48 <gotmax[m]> https://fedoraproject.org/wiki/Changes/Noi686Repositories
18:37:51 <eclipseo> ok so were good, F35 is not concerned either, so nobody would be affected if we removed a few leaf here and there
18:39:18 <gotmax[m]> Perhaps we should vote on whether we're okay with me or whoever else going through our (go-sig co-maintained) packages and starting to exclude them?
18:39:45 <eclipseo> so technically, external packagess to the Go ecosystem can only depends on our binaries theorically, so then we identify all the binaries, see which ones are leaf packages, and cut off the rest
18:39:46 <gotmax[m]> And then how we want to handle the -devel case?
18:40:51 <jcajka> we don't care? as in if it works it works if not we don't care
18:40:55 <gotmax[m]> To put it differently, if we keep -devel packages noarch, we'd have to start querying at the application level (every dependent of the application needs to be removed). Otherwise, we'd also have to care about libraries that depend on other libraries.
18:41:03 <gotmax[m]> eclipseo: Basically
18:41:33 <gotmax[m]> jcajka: What part are you referring to?
18:42:28 <jcajka> gotmax[m]: noarch -devel packages on i686
18:42:39 <QuLogic> I don't understand the problem; the only users of the `-devel` packages are the applications, and the applications are dropping 32-bit support first
18:42:53 <QuLogic> so why should we worry about the noarch existing on 32-bit?
18:43:00 <QuLogic> * the noarch `-devel` existing on
18:43:03 <gotmax[m]> I guess you have a point
18:43:49 <gotmax[m]> But not every application will necessarily be removed at the same time
18:44:01 <gotmax[m]> I'm starting to think it's not a huge deal and that I might be overthinking it
18:46:03 <gotmax[m]> I guess that's settled
18:46:11 <alexsaezm> do we have any conclusion then? :)
18:46:42 <gotmax[m]> We should probably vote on:
18:46:43 <gotmax[m]> 1. Rules for new packages
18:46:43 <gotmax[m]> 2. The process for removing old packages
18:47:49 <alexsaezm> that sounds like something we should discuss in the mailing list or write in the issues for the next meeting
18:47:55 <gotmax[m]> That's fine.
18:48:10 <gotmax[m]> I can create an issue to vote on approving https://pagure.io/go-rpm-macros/pull-request/48 and the related PRs
18:48:23 <gotmax[m]> And then we can decide on existing packages
18:48:51 * gotmax[m] apologizes that this one issue took so long
18:49:13 <alexsaezm> meetings are for that :)
18:49:43 <alexsaezm> so...
18:50:10 <alexsaezm> #action gotmax (He/Him) will create an issue to vote on "Rules for new packages" and "The process for removing old packages"
18:50:32 <alexsaezm> next topic? or is there anything else in this one?
18:50:55 <gotmax[m]> Not really for this one. Docker next?
18:50:59 <alexsaezm> #topic Discuss current docker/moby/containerd ecosystem brokenness https://pagure.io/GoSIG/go-sig/issue/43
18:51:01 <gotmax[m]> Or anything else anyone else has...
18:51:38 <gotmax[m]> Are there any questions about the Docker issue?
18:52:00 <gotmax[m]> I can submit an example review for a bundled package, but I don't think that's a prereq to voting on this issue
18:52:27 <gotmax[m]> * for a simple bundled package, * bundled package to show an example, but
18:53:26 <eclipseo> well i was thinking of keeping it unbundeled
18:53:28 <MarkEFuller[m]1> gotmax[m]: I don't think it's a prereq, but tangentially, I would like to try to document the bundled/vendored build process and try to work towards a standard
18:53:36 <eclipseo> so far we have two docker
18:53:41 <mikelo> I wrote my questions/concerns on the ticket
18:53:48 <gotmax[m]> Mark E. Fuller: Agreed
18:53:55 <eclipseo> one bnary docker package that was always separate
18:53:57 <gotmax[m]> mikelo: I think I answered them all :)
18:54:27 <gotmax[m]> * them all? :)
18:54:35 <eclipseo> a second golang-github-docker package that was used for library consumption
18:55:00 <mikelo> gotmax[m], yes, but I think we should document it properly. For example having a comment on why it's bundled SHOULD be present in the .spec IMO
18:55:29 <gotmax[m]> mikelo: Do you want to create a separate issue for that?
18:55:29 <mikelo> but what worries me most is the amount of packages that need to be bundled if docker moves to bundled
18:55:50 <gotmax[m]> I don't think it's too useful if we "bundle" :D them together
18:55:56 <mikelo> I'm afraid that this may lead to more bundled packages in the future
18:56:00 <gotmax[m]> them = the issues
18:56:23 <gotmax[m]> mikelo: It will also lead to more bundled packages if all of the libraries get retired due to them FTBFS
18:56:53 <gotmax[m]> I think bundling is a necessary evil here.
18:57:08 <gotmax[m]> The unbundled docker packages are both broken and out of date
18:57:28 <eclipseo> https://src.fedoraproject.org/rpms/moby-engine/blob/rawhide/f/moby-engine.spec is bundled right?
18:57:41 <eclipseo> the docker libraries packges are unbundled
18:57:45 <gotmax[m]> And I don't want to disparage eclipseo who maintains them. It's a **gargantuan** effort
18:57:53 <gotmax[m]> Yes to moby-engine
18:58:16 <gotmax[m]> It includes docker-proxy in that package which is unbundled
18:58:17 <eclipseo> i think bundling them would coause problems
18:58:35 <gotmax[m]> Even if we remove all of the dependents?
18:59:13 <gotmax[m]> s/remove/bundle
18:59:53 <eclipseo> because in my experience, when you bundle, you bundle differents versions, and then the packages depending on it can't manage multiples versions
19:00:14 <jcajka> IMO if you have more than ~10 dependencies it is reasonable to bundle, assuming that there are bundled provides and they are properly version-ed
19:00:20 <gotmax[m]> We'd also remove the libraries
19:00:27 <eclipseo> differents versions than the one separately  in the distro I mean
19:00:34 <jcajka> eclipseo: I don't see that problem on go stack side
19:00:38 <gotmax[m]> jcajka: Agreed
19:00:52 <gotmax[m]> That's how all other go binaries work
19:02:01 <mikelo> what other binaries?
19:02:58 <gotmax[m]> Other unbundled distros (e.g. Arch or RHEL) and the ones upstreams distribute themselves
19:03:45 <alexsaezm> rhel is bundled
19:03:53 <gotmax[m]> Sorry, I meant bundled
19:04:05 * alexsaezm didn't know arch was bundled
19:04:29 <mikelo> and what about moving everything to bundled?
19:04:42 <gotmax[m]> I'm not saying that
19:04:55 <gotmax[m]> Generally, bundling is frowned upon in Fedora
19:05:17 <gotmax[m]> And I think there's a fair share of packages where unbundling is feasible
19:05:45 <jcajka> mikelo: honestly I'm worried that with module switch that will be only reasonable way forward. I hope I'm wrong.
19:06:21 <gotmax[m]> eclipseo: Also, we already have bundled and unbundled packages in the distro with different library versions.
19:06:29 <gotmax[m]> It works fine
19:06:30 <eclipseo> bundled package are not always checked for security fixes, since we build against the latest version, there are more chances that known security holes re patched
19:06:51 <gotmax[m]> eclipseo: Yes, I agree
19:07:06 <gotmax[m]> Although, docker actually tends to be pretty good about security
19:07:28 <gotmax[m]> And it this point, it seems that I'll be doing rebuilds every go release :(
19:07:33 <jcajka> Actually we always have had it in Go stack in Fedora, even prior bundling being allowed in Fedora
19:07:38 <eclipseo> i strugled a lot with docker cause many deps were out of date
19:07:46 <eclipseo> but it seems they have improved on that end
19:09:28 <gotmax[m]> golang-github-docker (20.10.12). Upstream (20.10.17)
19:09:39 <gotmax[m]> That package will be retired next release
19:09:47 <gotmax[m]> And I do not think we'll be able to fix anything
19:09:50 <gotmax[m]> *everything
19:11:03 <mikelo> do they've huge changes between minor releases?
19:11:49 <gotmax[m]> Not huge
19:11:59 <gotmax[m]> But not that this isn't semver
19:12:10 <gotmax[m]> At least I don't think
19:14:25 <gotmax[m]> It seems we have reached an impasse
19:15:53 <mikelo> all are thinking about these two topics
19:16:15 <eclipseo> well let us discuss this at a later point, i'm not convinced either way
19:16:34 <eclipseo> i'd like to try to traighten it up a bit
19:16:59 <gotmax[m]> I think that's reasonable
19:17:26 <gotmax[m]> I guess we can revisit it after f37 is released?
19:17:33 <eclipseo> but i'm gonna need help on reviews though
19:17:47 <MarkEFuller[m]1> it's not a hard standard, but I think we should accept (and consistently use) bundling for the "flagship" packages of docker, helm, and a few others - packages where we can argue that there is a large user base and a responsive and active upstream
19:18:09 <MarkEFuller[m]1> I don't know how to articulate that well, but I'm thinking of a set of packages that we really can't not have
19:18:28 <jcajka> darktable :)
19:18:39 <gotmax[m]> eclipseo: Ack. It's helpful if you do it in a COPR and enable the fedora-review option, so we don't have to build dependencies locally when reviewing.
19:18:39 <jcajka> package that caused bundling to be allowed in Fedora
19:19:02 <gotmax[m]> jcajka: What was?
19:20:05 <eclipseo> gotmax ok i'll think of that
19:20:09 <jcajka> gotmax[m]: just picee of useless trivia
19:20:17 <jcajka> piece
19:20:33 <gotmax[m]> But which package? Docker?
19:20:42 <jcajka> darktable, deemed to be too important to be dropped
19:20:55 <gotmax[m]> Ahh
19:22:21 <gotmax[m]> Mikelo, can I #action you to create the bundled guidelines discussion?
19:22:32 <gotmax[m]> And eclipseo for the docker thing?
19:22:42 <mikelo> gotmax[m], ok
19:22:47 <gotmax[m]> Or you can yourselves :)
19:22:47 <eclipseo> well for the docker thing i,m on it
19:23:14 <gotmax[m]> #action mikelo to create a separate ticket to discuss creating guidelines for bundled packages
19:23:16 <eclipseo> #action eclipseo do the docker bundling or unbundling
19:23:35 <eclipseo> i think the host have to do that
19:23:38 <eclipseo> no?
19:23:51 <gotmax[m]> #chair
19:23:55 <gotmax[m]> I think
19:24:11 <eclipseo> #chair eclipseo
19:24:11 <zodbot> Current chairs: (He/Him) QuLogic alexsaezm copperi[m] eclipseo gotmax jcajka mikelo
19:24:19 <gotmax[m]> #info We'll resume the docker discussion after the release of F37
19:24:34 <eclipseo> #action eclipseo do the docker bundling or unbundling
19:24:38 <eclipseo> ok
19:24:59 <gotmax[m]> Open floor?
19:25:18 <mikelo> eclipseo++, thanks for importing golang-github-git-5
19:25:45 <alexsaezm> #topic Open floor
19:26:08 <alexsaezm> FYI: go 1.18.5 was released 3 hours ago or so
19:26:18 <gotmax[m]> With more security fixes...
19:26:28 <alexsaezm> yes
19:26:42 <alexsaezm> already built, I need to push it to bodhi yet
19:26:45 <mikelo> if anyone has spare cycles, I just opened https://bugzilla.redhat.com/show_bug.cgi?id=2113045 for review. golang-github-marten-seemann-qtls-go1-XX releases a package for each major go version, so this one is for 1.19 that is required by golang-github-lucas-clemente-quic on rawhide or it FTBFS
19:26:57 <jcajka> partially related to the last topic, origin is fully bundled, I plan to orphan it as I don't have spare time for it. Anyone interested in taking it over?
19:27:21 <gotmax[m]> +1. Also, we should be able to close the bugs for the other CVEs.
19:27:53 <gotmax[m]> Honestly, I'm quite displeased about all of the spam prodsec sends
19:27:56 <eclipseo> sorry my plate is full
19:28:24 <MarkEFuller[m]1> mikelo: I've got a few hours on the train tomorrow
19:28:25 <mikelo> gotmax[m], I can tell you that some ppl at prodsec also is
19:29:14 <MarkEFuller[m]1> jcajka: I could certainly try - it would be an adventure
19:29:17 <gotmax[m]> A koji or copr build for all arches would be appreciated. `fbrnch create-review` or `fedora-create-review` will handle the koji build.
19:29:35 <gotmax[m]> If you use those tools to submit reviews
19:29:45 <mikelo> and I think we should deprecate golang-github-marten-seemann-qtls-go1-{15,16,17 and 18} for rawhide, I may send an email about that
19:29:58 <gotmax[m]> mikelo: +1
19:30:11 <gotmax[m]> mikelo: What is the actual email to reach them?
19:30:35 <gotmax[m]> Last time I tried emailing them with the email from Bugzilla, it bounced.
19:30:51 <mikelo> I mwan send an email to golist to let the team know about how to handle the package
19:31:07 <mikelo> because upstream they still plan to keep doing a release per golang major
19:31:17 <gotmax[m]> Also, I think we might want to meet weekly, now that we have more people and more to discuss.
19:31:23 <jcajka> MarkEFuller[m]1: it is all intricacies of Go stack merged with all the intricacies of the openshift :)
19:31:31 <gotmax[m]> them = prodsec
19:31:38 <jcajka> MarkEFuller[m]1: if you are more interested in having 4.X client, tools it is more suitable to package them under different name as origin is tight to the 3.X version of openshift
19:31:49 <MarkEFuller[m]1> jcajka: sounds fun (and how else am I going to learn?)
19:33:13 <MarkEFuller[m]1> jcajka: I'm having trouble parsing that right now - v4.x should be renamed from origin?
19:35:03 <jcajka> MarkEFuller[m]1:yes, I would argue that, even possible including dropping origin(3.X) from Fedora
19:36:21 <MarkEFuller[m]1> jcajka: so we can discuss offline - I'm not familair with all the details (my day job is vanilla k8s, not openshift)
19:36:46 <jcajka> MarkEFuller[m]1: sure
19:38:34 <alexsaezm> anything esle?
19:38:38 <alexsaezm> else*
19:39:47 <gotmax[m]> Scheduling? But I think we should wrap up...
19:40:30 <alexsaezm> we should vote for a reschedule (when and for how long) for sure
19:40:53 <alexsaezm> we are a lot more and the topics are quite heavy imo
19:41:04 <eclipseo> ok
19:41:17 <eclipseo> the hour is ok for me
19:41:38 <alexsaezm> we can create a poll (I don't recall the tool jcajka used last time)
19:41:55 <gotmax[m]> I don't like biweekly. I always get confused about which week, and I think we have enough to discuss.
19:42:10 <MarkEFuller[m]1> gotmax[m]: second weekly
19:42:10 <gotmax[m]> framadate is opensource :)
19:42:21 <jcajka> there might be issue with tools for that I have hard time seeking one this time around
19:42:29 <gotmax[m]> Yeah, wrong prefix :)
19:42:46 <eclipseo> https://framadate.org/abc/en/ ?
19:43:04 <gotmax[m]> Yeah
19:43:29 <alexsaezm> we can create one and send the poll to the mailing list
19:43:33 <alexsaezm> so more people can vote on it
19:43:35 <gotmax[m]> +1
19:44:20 <alexsaezm> #action alexsaezm will create a poll to decide the new schedule for the Go SIG meetings
19:44:23 <mikelo> so now that SPDX tags are required, is someone working to adapt go2rpm for it?
19:44:40 <alexsaezm> (I offered myself to do something in this meeting :D )
19:44:53 <gotmax[m]> Shouldn't be hard. We just have to remove the code.
19:45:33 <eclipseo> yeah removing the conversion code from rust2rpm and then plug the result from askalono directly
19:46:00 <gotmax[m]> Who wants to take it :D?
19:46:13 <eclipseo> i can take a look
19:46:54 <eclipseo> but i'd rather have you make all the prs you need to go2rpm if we need to cut a new release
19:47:24 <gotmax[m]> Can I merge the older one?
19:47:30 <gotmax[m]> https://pagure.io/GoSIG/go2rpm/pull-request/20
19:48:26 <mikelo> gotmax[m], fine for me
19:48:45 <QuLogic> eclipseo: on a somewhat unrelated note, if you can import vuln soon (I approved earlier today), then I can hopefully fix the tinygo FTBFS that they keep complaining about before branching/auto-retire
19:49:01 <eclipseo> ok, i don't like the no source numbering though, i need it if i have to mix multiple sources
19:49:18 <eclipseo> ok Elliott Sales de Andrade
19:51:10 <mikelo> some days ago I realized that there are some golang package for EPEL7 that are stuck in bodhi for +4 years
19:51:10 <gotmax[m]> Should we end this now?
19:51:15 <mikelo> https://bodhi.fedoraproject.org/updates/?search=&submitted_before=2022&status=pending&status=testing&releases=__current__&page=5
19:51:33 <gotmax[m]> :(
19:52:03 <gotmax[m]> 83 total...
19:52:12 <gotmax[m]> https://bodhi.fedoraproject.org/updates/?search=golang&submitted_before=2022&status=pending&status=testing&releases=EPEL-7
19:52:14 <mikelo> not sure whom should be pinged, the original author of the package or propose bodhi to autoclose things after a period
19:52:34 <eclipseo> epel7 is the last of my problems, these are libs we don't intend to package for epel7 theorically
19:53:18 <mikelo> yeah, epel7 is... well, epel7. But having those there for years doesn't seem to be useful to anyone either
19:53:30 <gotmax[m]> I can bring it to the EPEL SIG perhaps. They are basically unmaintained.
19:55:26 <mikelo> that would be great
19:56:14 <gotmax[m]> Anything else :)?
19:56:50 <eclipseo> ok for me
19:57:46 <alexsaezm> we can call it then? :)
19:57:55 <gotmax[m]> +1
19:58:01 <eclipseo> yeah 2hr meeting
19:58:16 <alexsaezm> a short one uh? :D
19:58:19 <gotmax[m]> A new record (for the go-sig)?
19:58:27 <alexsaezm> AFAIK yes
19:58:34 <alexsaezm> Thanks everyone!
19:58:36 <alexsaezm> #endmeeting