16:01:25 <jcajka> #startmeeting Go SIG meeting
16:01:25 <zodbot> Meeting started Tue Jun 11 16:01:25 2019 UTC.
16:01:25 <zodbot> This meeting is logged and archived in a public location.
16:01:25 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:25 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:01:42 <jcajka> #topic Roll Call
16:03:26 <bexelbie> .hello bex
16:03:27 <zodbot> bexelbie: bex 'Brian (bex) Exelbierd' <bexelbie@redhat.com>
16:06:53 <QuLogic> .hello qulogic
16:06:54 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:07:16 <jcajka> hello, bex, nice to see you here :)
16:07:21 <jcajka> #chair QuLogic
16:07:21 <zodbot> Current chairs: QuLogic jcajka
16:07:25 <bexelbie> ahoj
16:10:59 <jcajka> it seems that not much people is around today, we don't have quorum, and there are not really any open issues for todays meeting
16:11:42 <jcajka> so let's move to the open floor
16:11:54 <bexelbie> I had a few questions about the specs if we have time for them/people present
16:12:14 <jcajka> #topic Open Floor
16:13:12 <bexelbie> I've been working on trying to get some golang packages into Fedora so I can land gocryptfs.  There are about 8 of them, so I have been trying to get one right to use as a model for the others.  I am worried that the new macros will restrict my packages to rawhide.  Is this the case?
16:13:15 <jcajka> bexelbie: nim seems to be not around atm, I hope other will be able to help you put
16:14:24 <jcajka> others... out...
16:14:56 <QuLogic> I don't think we will be backporting the macros?
16:15:24 <QuLogic> so for <f31 you'd have to work with the old ones
16:16:30 <bexelbie> hmm, ok.  That does seem like it will make package review harder potentially or am I missing something?
16:16:44 <bexelbie> ultimately, I want to write an article and be able to use Fedora as my example
16:17:19 <bexelbie> in fact, I am not sure how to review the package for inclusion in F30 using the old macros when everyone seems to want to see things built in rawhide first
16:17:21 <bexelbie> any advice?
16:19:13 <jcajka> bexelbie: that is interesting, what I have understood from nim is that the new macros should be backwards compatible to some extend, i.e. they will not break the old packages, it is pity the he is not around atm
16:20:22 <bexelbie> sounds like I need to wait on nim - I'll keep pushing to get the packages into rawhide
16:20:26 <QuLogic> they weren't supposed to, iirc, and I guess they might not, but they all need %goprep now, so the specs are all effectively broken
16:20:30 <bexelbie> QuLogic, thank you in advance for your help and continuing help
16:21:28 <QuLogic> the _older_ Go spec template might still be working
16:22:58 <bexelbie> would it be a good path to first deal with F31 and then backport and request the F30 branch
16:23:11 <bexelbie> thinking about it more, it isn't clear that requires a formal re-review
16:23:58 <QuLogic> i.e., all these are failing from the same thing https://apps.fedoraproject.org/koschei/affected-by/go-srpm-macros?epoch1=0&version1=2&release1=19.fc30&epoch2=0&version2=3.0.8&release2=3.fc31&collection=f31
16:25:33 <QuLogic> bexelbie: backport what?
16:26:48 <jcajka> QuLogic: hm... you have landed go-srpm-macros replacement with out coordinating on retiring the old package?
16:27:30 <QuLogic> jcajka: that was nim  with the go-rpm-macros package
16:27:55 <jcajka> hm... this is weird, we shouldn't really have both around
16:28:48 <jcajka> IMO this creates unnecessary confusion
16:29:36 * bexelbie is back - sorry unexpected local issue
16:30:10 <bexelbie> QuLogic, if I meant if I start by getting my package into F31/rawhide then create an F30 branch that has to use the older macros
16:30:53 <QuLogic> oh, I guess formally it doesn't even require a review for F30 then
16:31:21 <QuLogic> it might be helpful for you, thouh
16:31:25 <QuLogic> though*
16:31:32 <bexelbie> QuLogic, my intention was to get someone to look at what I did
16:31:39 <bexelbie> but not create a whole new review step
16:31:46 <bexelbie> but first I have to get F31 right :P
16:31:59 <bexelbie> I'd rather get it built in rawhide and then F30 instead of trying to do both at once
16:32:59 <jcajka> QuLogic: formally yes, but technically it kind of would be good practice if we are landing disruptive change, and generally people want they package in all current releases
16:34:07 <QuLogic> jcajka: iirc, nim&eclipseo wanted everything in one package, but I think because of rpm issues it had to be split in two subpackages
16:35:05 <QuLogic> unfortunately they aren't here to confirm, but I believe it was https://github.com/rpm-software-management/rpm/issues/674
16:35:20 <jcajka> QuLogic: just to be exact what do you mean as one package in this context?
16:35:47 <jcajka> subpackage rpm-macros/srpm-macros spit or repo split between those
16:36:04 <QuLogic> jcajka: all the macros go in go-rpm-macros without a go-srpm-macros at all
16:37:10 <jcajka> QuLogic: ack, then this is to minimize build root as AFAIK they would be pulling more deps in to all build roots in Fedora without the split, but you need bits to build srpm in minimal build root
16:37:25 <jcajka> QuLogic: and then it is not really my issue
16:38:45 <QuLogic> jcajka: right, exactly, that's why
16:41:46 <jcajka> eclipseo: real issue is lack of communication from nim, it is really disturbing if we are supposed to be collaborating and coordinating on the changes that you are executing(BTW kudos for doing the work ;))
16:41:54 <jcajka> QuLogic... sorry ^^
16:42:26 <jcajka> prior notice would be nice to, but it is not really a big deal
16:42:42 <jcajka> general prior notice, be it
16:43:11 <jcajka> to devel
16:43:38 <QuLogic> well, I'm in agreement there, it'd have been nice to have go-rpm-macros built only when eclipseo was ready to rebuild everything
16:44:30 <QuLogic> especially since koschei thinks it broke everything, so we're getting piecemeal fixes by other out-of-the-loop packagers
16:48:31 <jcajka> for me it seems as recurring theme in my experience working with nim, unfortunately  when he has the power to push his ends, he ignores everyone and everything else, that is my fear and main motivation to have rpm and srpm packages split, so there is no distro wide buildroot breakage because of Go packaging changes
16:53:40 <jcajka> anyway I'm getting bit carried away
16:53:59 <bexelbie> Does the Go SIG have enough proven packagers to help fix these potential distro-wide issues?
16:54:16 <bexelbie> it's one thing to break my package due to a macro change, but another if you expect me to fix it wihtout notice versus you pushing the fix
16:54:31 <jcajka> bexelbie: I think we have none
16:54:43 <QuLogic> there are at least three of us, I think
16:54:44 * jcajka should finally peruse that
16:55:01 <bexelbie> That alone may be a reason to adopt a different release policy - if there are no proven packagers to help clean things up
16:55:17 <jcajka> QuLogic: oh... great
16:55:49 <QuLogic> because nim pushed a bunch of changes before, so I think he has pp, and eclipseo got it a month or two ago, and I have for some time
16:58:21 <QuLogic> I only wait because eclipseo has everything updated for the test in copr, so I expect it'd be easier to let him just push everything
16:59:55 <QuLogic> and I assume it was all scripted and done automatically to avoid any issues
17:03:14 <jcajka> QuLogic: side tag rebuild has been supposed to happen base of what have been said here and I should co-ordinate that with eclipseo along with the Go rebase, it sounds to me that there is need to coordinate bit more on your change proposal execution with rest of the Fedora
17:04:47 <QuLogic> jcajka: my change proposal?
17:05:56 <jcajka> nim's and eclipseo's? you are the change owner too right?
17:06:32 <jcajka> https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
17:06:38 <QuLogic> ah, that one, yes, I guess I am
17:08:10 <QuLogic> yea, I do believe it was supposed to be a side tag rebuild, from what I recall here
17:08:58 <jcajka> interesting that FESCO accepted it as not a system wide change as it is clearly system wide...
17:09:25 <jcajka> especially if Golang rebase is one
17:09:51 <nim> .hello2
17:09:52 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
17:10:04 <nim> sorry I had a bus problem
17:10:05 <jcajka> QuLogic: anyway we are on top of the hour and other are not here, i will rise my concerns on devel list
17:10:48 <jcajka> nim: sorry to hear that, unfortunately I will have to run now
17:11:31 <nim> jcajka, sure, my problem, not yours
17:11:56 <nim> bexelbie, both eclipseo and me are proven packagers
17:12:27 <jcajka> #endmeeting