16:02:41 <jcajka> #startmeeting Go SIG meeting
16:02:41 <zodbot> Meeting started Tue Apr 30 16:02:41 2019 UTC.
16:02:41 <zodbot> This meeting is logged and archived in a public location.
16:02:41 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:41 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:02:48 <jcajka> hello everybody
16:02:57 <jcajka> #topic Roll Call
16:04:00 <nim> .hello2
16:04:01 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:04:20 <jcajka> #chair nim
16:04:20 <zodbot> Current chairs: jcajka nim
16:07:09 <jcajka> decathorpe QuLogic deparker Pharaoh_Atem meeting ;)
16:07:24 <jcajka> eclipseo
16:07:55 <decathorpe> .hello2
16:07:58 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
16:08:06 <decathorpe> I don't know how long I'll be able to attend though
16:08:44 <deparker> I have tools team meeting right now :(
16:08:46 <nim> #chair decathorpe
16:08:46 <zodbot> Current chairs: decathorpe jcajka nim
16:09:18 <jcajka> #chair deparker
16:09:18 <zodbot> Current chairs: decathorpe deparker jcajka nim
16:09:32 <nim> deparker, decathorpe a little is better than none
16:10:30 <jcajka> IMO lurking is good enough :)
16:11:18 <eclipseo> .hello2
16:11:18 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:11:34 <eclipseo> shit I'm late sorry didn't see the time pass
16:11:55 <jcajka> #chair eclipseo
16:11:55 <zodbot> Current chairs: decathorpe deparker eclipseo jcajka nim
16:12:14 * Pharaoh_Atem sighs wearily
16:13:03 <jcajka> I guess we can start as we don't have really anything on planed agenda
16:13:19 <jcajka> #topic Open Floor
16:13:22 <eclipseo> Let's start with PR51
16:13:26 <eclipseo> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
16:13:44 <eclipseo> Igor merged the last bits except the templates
16:13:56 <nim> yes
16:14:14 <nim> really the only thing we'd need now is the variable with template location
16:14:18 <eclipseo> which nim should see with the rpmdevtools maintainer
16:14:31 <nim> Pharaoh_Atem, that's up to you I'm afraid
16:14:34 <Pharaoh_Atem> yep
16:14:52 <nim> Pharaoh_Atem, just tell what you want in the PR so it can be finished
16:14:52 <Pharaoh_Atem> I need to fix rpmdevtools to do this properly first
16:15:06 <jcajka> #chair Pharaoh_Atem
16:15:06 <zodbot> Current chairs: Pharaoh_Atem decathorpe deparker eclipseo jcajka nim
16:15:07 <nim> Pharaoh_Atem, I activelly don't care as long as the location is fixed
16:15:09 <jcajka> sorry
16:15:41 <nim> Pharaoh_Atem, can you just decide on the target so it can be done in rpmdevtools?
16:15:55 <nim> Pharaoh_Atem, in redhat-rpm-config sorry
16:16:04 <eclipseo> Pharaoh_Atem: what's your ETA about fixing rpmdevtools?
16:16:04 <nim> Pharaoh_Atem, no need to change rpmdevtools at once
16:16:25 <nim> Pharaoh_Atem, we just need a forwrd-thinking decision
16:16:48 <Pharaoh_Atem> eclipseo: I need to just get some breathing room to think about it and just commit the change
16:17:34 <eclipseo> ok
16:18:01 <nim> Pharaoh_Atem, you know that if you don't decide, we'll have to guess a location, and it won't be the correct one :)
16:18:18 <nim> Pharaoh_Atem, for ou that is :)
16:18:40 <Pharaoh_Atem> I'm pretty sure I'm going to do something like /usr/share/rpmdevtools/<RPMCANONVENDOR>/ for distro templates to override the base ones
16:19:09 <eclipseo> Topic #2: Fixing go-rpm-macros/go-srpm-macros split.
16:19:19 <nim> Pharaoh_Atem, so our go templates would go in  /usr/share/rpmdevtools/fedora ?
16:19:21 <eclipseo> Read the problem here https://github.com/rpm-software-management/rpm/issues/674
16:19:39 <nim> Pharaoh_Atem, ok
16:19:50 <nim> Pharaoh_Atem, I'll update the PR with this
16:20:24 <nim> eclipseo, rpm upstream was not nice
16:20:31 <eclipseo> Since rpm upstream won't change their mind, the last recourse we have is to move the declaration of %gopkg from go-rpm-macros to go-srpm-macros
16:20:49 <eclipseo> so that it can be evaluated at SRPM build time
16:21:13 <eclipseo> nim that's your area of expertise
16:21:29 <eclipseo> I read the macros a bit, Iqm not sure of the implications
16:21:35 <jcajka> eclipseo: IIRC %gopkg has more external dependencies right?
16:21:36 <eclipseo> but it seems feasible
16:21:51 <nim> eclipseo, I don't like reworking this to workaround rpmbuild behaviour
16:21:53 <eclipseo> not sure
16:22:03 <Pharaoh_Atem> rpm upstream was perfectly reasonable
16:22:18 <eclipseo> nim we don't have others choices and we are time constrained
16:22:18 <jcajka> Pharaoh_Atem: +1
16:22:28 <eclipseo> I can do any testing in my COPR
16:22:46 <nim> Pharaoh_Atem, rpm upstream is not reasonable to evaluate subpackage bits at srpm creation time, srpm has not subpackages
16:23:25 <eclipseo> their position is that the SRPM must also be correct
16:23:37 <nim> Pharaoh_Atem, I'm wuite sure we'll hit the same problem in another form in the future if they don't dissociate cleanly srpm and rpm parts
16:24:00 <nim> eclipseo, their position is that they didn't want to think it over
16:24:33 <eclipseo> Anyhow let's not bikeshed on that, what are the dependencies of gopkg we need to pull? is it easily "splitable"?
16:24:42 <nim> eclipseo, I'll look at restructuring the macros, but again, I'm pretty sure it's something that will bite us again
16:24:51 <nim> in the future
16:25:02 <Pharaoh_Atem> we're going to need all these for generating builddeps dynamically anyway
16:25:23 <eclipseo> we'll advise then, we are limited by the F31 schedule right now
16:25:49 <eclipseo> we need to be able to be up and running before our mass rebuild and before F31 mass rebuild
16:26:33 <nim> eclipseo, that's the spirit! I'm afriad I lost much of it after months of waiting
16:26:40 <eclipseo> nim you agree to take up this task of moving gopkg to srpm-macros?
16:27:09 <eclipseo> I'll help testing on my COPR
16:27:32 <nim> eclipseo, I wrote I will do it. Not sure what can of worms it will open, the current layout has been designed to separate srpm and rpm parts
16:27:46 <nim> eclipseo, because that's what rpm maints wanted
16:27:54 <nim> eclipseo, as lon as they were not doing the work
16:28:10 <eclipseo> ok
16:28:35 <eclipseo> Topic 3: FPC review of the proposed guidelines
16:28:36 <jcajka> nim: I would say that I see it more as the design of the RPM rather as something arbitrary that the RPM devs want
16:29:16 <eclipseo> So last meeting went well but Igor wanted to add more inline comments
16:29:57 <eclipseo> I reminded it yesterday night and he added it to his calendar. So far I'm waiting for comments to address them before the next meeting
16:30:06 <nim> jcajka, for something as old as rpm, there are lots of shades of gray between what the original deisgners wanted and what current maintainers want
16:30:16 <eclipseo> Hopefully the FPC will then approve our Guidelines
16:30:54 <decathorpe> we're almost ready to approve them
16:31:09 <jcajka> nim: I don't disagree :), but you are basically aiming to shift the design(which is big task on its own)
16:31:10 <nim> eclipseo, do look at the dynamic buildrequires stuff, it's progressing in parallel, it may end up being approved before your guidelines
16:31:41 <nim> both features are in "almost done" state
16:31:42 <decathorpe> guys, I need to go. sorry :) see you next time
16:31:50 <eclipseo> nim I fixed the Dynamic BR stuff to match upstream and updated the templates accordingly
16:32:00 <nim> decathorpe, thanks for comming
16:32:01 <jcajka> eclipseo: sorry, I haven't yet got around to send the feedback, PRs..., but is it still on my backlog :)
16:32:04 <eclipseo> see you decathorpe
16:32:20 <jcajka> decathorpe: np, thanks see you in two weeks
16:32:36 <decathorpe> o/
16:33:17 <nim> eclipseo, you did your work, they asked to make dynamic Brs optional, that will change as soon as the dynamic BR stuff is approved
16:33:28 <nim> eclipseo, thanks for playing the approval game
16:34:51 <eclipseo> personally I'm not so keen on using them, I prefer to have my BR laid out in the SPEC to be able to plan my dependencies building *and* to be able to search them with grep to see what packages might be broken by an update for examble
16:34:57 <jcajka> yup, thanks.  it will be good to have something approved, we can always improve on that later on
16:36:31 <jcajka> eclipseo: tbh I have same preference
16:36:51 <nim> you don't have to *use* them
16:37:03 <jcajka> which is great
16:37:21 <nim> however they make mass updates just a lot of version bumps
16:37:33 <nim> without requiring lots of ne BR lines
16:37:57 <eclipseo> yeah but you still need to check for new deps
16:38:03 <jcajka> and when we will have more packaging automation they will make more sense to me
16:39:05 <nim> sure, they're just one step in the whole automation thing
16:39:46 <eclipseo> speaking of which we will need to update all BR for modules? from golang(foo) to golang-module(foo) >= X-Y?
16:40:17 <nim> eclipseo, if you don't use automated br yes
16:40:35 <nim> eclipseo, no way out of it since modules won't read GOPATH
16:40:57 <nim> eclipseo, so they can't share provides
16:41:12 <eclipseo> ok, not sure yet how I'll implement that in go2rpm
16:41:44 <nim> eclipseo, honestly, even if I was full time on modules
16:41:55 <nim> which I can't afford to
16:42:05 <jcajka> nim, eclipseo: I'm still not sure if it will be possible to continue in GOPATH mode after modules get to be default
16:42:09 <nim> full module automation is at least a month away
16:42:12 <jcajka> \me need to check
16:42:36 <jcajka> it would give us bit more head room
16:42:54 <nim> jcajka, already looked, GOPATH is dead for modules
16:43:09 <eclipseo> Is there a way we could set GO111MODULE=off globally while we get ready for modules?
16:43:20 <nim> jcajka, they simplified module design by making them ignore everything that happened before
16:43:51 <jcajka> nim: yeah, but that doesn't have to mean that you can't consume the base source tree
16:44:21 <jcajka> eclipseo: most probably via the macros, probably by ones invoking go command
16:44:51 <nim> jcajka, not that easy, rpm resets env variables in each section
16:45:14 <jcajka> nim, thus every macro that invokes go command
16:45:33 <jcajka> aren't we doing already?
16:45:39 <nim> so you'd need to set  GO111MODULE in %pre %build %install %check and in dep calculation
16:46:09 <nim> jcajka, we set a lot of vatiables when people use macros
16:46:14 <jcajka> for some other things, LDFLAGS etc
16:46:28 <nim> jcajka, for building for example we don't set anything
16:46:44 <jcajka> it should be "just" few one liners
16:47:08 <eclipseo> So far I have to set it in %build, I thought it will be the defaults in 1.13, but in 1.12 package with go.mod file default to GO111MODULE=on
16:48:21 <jcajka> eclipseo: I should be able to set it in the rpm macros
16:48:26 <nim> it's doable buut it will mess things up in a major way
16:48:41 <nim> just like GOPATH messes things up
16:49:03 <eclipseo> I have 23 packages with GO111MODULE=off
16:49:14 <nim> that's the closest thing we have to a variable that needs setting up today and it's very very messy
16:49:58 <eclipseo> Anyhow we're not ready for module yet, that should be the goal for F32
16:50:43 <eclipseo> Last topic: Status update about upgrading the SPEC to new macros
16:50:44 <jcajka> eclipseo: I will set it in the gobuild and gotest macro, is that enough for you?
16:51:06 <nim> jcajka, https://github.com/golang/go/issues/31302 and https://github.com/golang/go/issues/31304 are what is needed to consume the base source tree in module mode
16:51:12 <eclipseo> eclipseo: yes so far no other step requires it
16:51:24 <jcajka> eclipseo: ack, will
16:51:51 <jcajka> #action jcajka set GO111MODULE=off in current gobuild and gotest macros
16:51:58 <jcajka> will do :)
16:52:58 <eclipseo> So I've been updating SPEC for 14 days, so far: 10 to bootstrap, 138 done, 177 new or to rename via a Review Request, 9 to retire, 467 remaining to update
16:53:25 <eclipseo> You can see the result here: https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/
16:53:40 <ajeddeloh> howdy. Several questions: 1) I notice gofed generates Provides/requires/etc like `Provides: bundled(golang(github.com/aws/aws-sdk-go/private/protocol)) = <VER>` but the package in fedora is golang-github-aws-aws-sdk-go
16:53:41 <jcajka> eclipseo: great :) thank you for the hard work
16:53:41 <nim> jcajka, goenv is the macro that sets this kind of stuff, but it's not used by gobuild
16:53:47 <ajeddeloh> which is correct?
16:54:01 <jcajka> ajeddeloh: both
16:54:18 <jcajka> nim: is it already in fedora?
16:54:40 <eclipseo> ajeddeloh: sorry we have meeting right now, can you wait a little bit?
16:54:50 <ajeddeloh> sure, sorry, didn't realize
16:54:54 <nim> jcajka, it's in the new macro package
16:55:07 <jcajka> nim: which one?
16:55:09 <nim> jcajka, I consolidated env setup to keep sane
16:55:40 <eclipseo> I will need all hands on deck to process the Review Request fast, any volunteer?
16:55:46 <nim> jcajka, https://pagure.io/go-rpm-macros/blob/master/f/rpm/lua/rpm/go.lua#_48
16:56:02 <nim> jcajka, used by all the other macros except gobuild
16:56:12 <jcajka> nim:AFAIK but that is not part of current fedora
16:56:16 <jcajka> right?
16:56:22 <nim> jcajka, no
16:57:01 <jcajka> no? as it is not part of current Fedora
16:57:40 <nim> jcajka, if you want to change behaviour of current macros just before they get replaced things will get difficult
16:58:25 * nim has not fond remembrances of hunting down macro history in 4 different git repos, and trying to merge the result
16:58:42 <jcajka> nim: you can apply the same change, and if you have good enough abstraction it should be easy one liner at one spot
16:59:35 <jcajka> this is really nothing architectural and will probably be obsoleted by the new macros anyway(read, it will not be needed)
17:01:03 <nim> jcajka, at least take a look at the new macro repository, it does not bite
17:01:33 <jcajka> nim: you don't plan anymore changes?
17:01:59 <nim> jcajka, there is the stuff eclipseo requested for its pre problems
17:02:07 <nim> jcajka, and then there are modules
17:02:35 <nim> jcajka, but the base code has pretty much kept unchanged since november
17:02:41 <jcajka> nim: I plan to spend time on learning lua when they are finished
17:03:21 <nim> all the recent commits are just bugfixes for exlipseo and Qulogic, the base structure is stable
17:03:29 <nim> (pre problems excepted)
17:03:35 <jcajka> tbh they seems to me unreadable at first glance as I'm not really familiar with lua
17:04:06 <nim> jcajka, the problem is not lua, it's all the layers of arg and env passing
17:04:15 <nim> jcajka, lua is very simple and stupid
17:04:29 <eclipseo> bbl
17:04:30 <jcajka> it probably contributes to that, reminds me of the rpm macro magic
17:04:37 <eclipseo> So I was saying, I will need all hands on deck to process the Review Request fast, who can actually do this in time?
17:05:20 <jcajka> eclipseo: not in short term, actually I will be gone on PTO for the next meeting
17:05:43 <jcajka> #action jcajka find chair for the next meeting as jcajka will be on PTO
17:06:15 <nim> eclipseo, I'll be on reduced activity till mid may
17:06:39 <eclipseo> okay I'll try to fish more people later then
17:06:56 <eclipseo> that's all for me and I got to go
17:07:10 <nim> eclipseo, I think you'd rather I fixed the %pre problem  anyway :)
17:07:12 <eclipseo> see you in two weeks?
17:07:21 <eclipseo> nim yes please
17:08:12 <jcajka> we are well on top of the hour, if there are no more topics I want to mention new upstream proposal for new "Google" notary/proxy for modules https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md
17:08:45 <jcajka> from the upstream dev ml it seems that Google doesn't plan to release it as open source, at least yet
17:10:40 <jcajka> if there is nothing else I will close the meeting
17:11:10 <nim> jcajka, that's not terribly useful to us, because it requires publishing our modules outside koji before being able to use them, so it's a mass rebuild killer
17:12:08 <nim> jcajka, and it still has the "just rename everything you don't want to be affected" core concept
17:12:25 <nim> which makes it a PITA for distributions
17:12:58 <jcajka> nim: yeah, and it will be governed by Google privacy policy(more in the lines we will gather about you as much as possible), that leans me on disabling it by default in Fedora's go compiler anyway... :/
17:13:18 <jcajka> so user can enable it if they really want
17:13:52 <jcajka> but don't leak anything they don't want by mistake
17:14:36 <nim> jcajka, but by all means, try to figure out how it interacts with our build processes, that will help you understand where https://gist.github.com/nim-nim/9f72827d7cba9637dfe1492364ad9adf is coming from
17:16:18 <jcajka> nim: my naive view at the moment is that if we de-configure we have no issues in our build system with it, apart any other modules stuff, I will definitively try it out
17:16:40 <nim> Our core objectives diverge quite far from the "centralize everything in the cloud" and "make sure no one uses anything expect cloud-approved parts" Google objectives
17:17:17 <nim> jcajka, sure, the more you play with it, the better you'll understand the problem space
17:18:01 <nim> that's why I wrote modist in the first place, to understand how all the various go module concepts intercected with rpm mock and koji
17:19:11 <nim> unfortunately, it turns out that in practice, the divergence is quite huge, that's how I endend up with more than a dozen tickets
17:19:42 <nim> anyway, see you in two weeks
17:19:53 <jcajka> nim: I don't disagree, see you too
17:19:59 <nim> got to buy something to eat :)
17:19:59 <jcajka> #endmeeting