16:02:41 <jcajka> #startmeeting Go SIG meeting
16:02:41 <zodbot> Meeting started Wed Nov 14 16:02:41 2018 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:46 <eclipseo> .hello2
16:02:47 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:02:54 <jcajka> #topic Roll Call
16:03:02 <jcajka> #chair eclipseo
16:03:02 <zodbot> Current chairs: eclipseo jcajka
16:05:30 <nim> .hello2
16:05:31 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:05:51 <jcajka> #chair nim
16:05:51 <zodbot> Current chairs: eclipseo jcajka nim
16:06:20 <nim> sorry I’m a tad late
16:07:08 <jcajka> nim: np let's wait a minute and then get started
16:08:18 <jcajka> so let's go ahead
16:08:40 <eclipseo> ping pgier: esm  deparker_  Pharaoh_Atem
16:09:58 <eclipseo> ok let's go then
16:10:04 <jcajka> #topic Action items from "last"/first meeting
16:11:05 <jcajka> eclipseo: I guess we now have the packager group, right? :)
16:11:27 <jcajka> ...we have...
16:11:57 <eclipseo> yeah all is almost well, I have requested a Koschei group since last time and added all our packages
16:12:17 <eclipseo> only issue now is that we don't get any mails
16:12:28 <eclipseo> I filed a bug with infra
16:13:04 <jcajka> awesome, thanks
16:13:06 <eclipseo> https://pagure.io/fedora-infrastructure/issue/7329
16:13:08 <nim> I receive lots of mails about your builds ;)
16:13:09 <jcajka> eclipseo++
16:13:09 <zodbot> jcajka: Karma for eclipseo changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:13:59 <eclipseo> nim: yeah I'm in the process of reviewing all of our packages
16:14:05 <eclipseo> done 75 for now
16:14:56 <eclipseo> I'll need some muscles for the Review Request at one point
16:15:16 <nim> that’s a saner Go package set in Fedora than we had in years, thanks!
16:16:28 <nim> eclipseo, I hope I’ll be able to move to reviewing eventually. Probably not soon though :(
16:17:34 <jcajka> eclipseo: do you have list of what is review and what needs to be reviewed?
16:17:36 <nim> eclipseo, hope to make it less lines to review in the meanwhile
16:20:02 <jcajka> anyway let's move on, another is me with the voting guidelines
16:20:43 <jcajka> there is PR for them https://pagure.io/GoSIG/go-sig/pull-request/15, as we don't have quorum, I would propose to do the in ticket voting based on the proposal, opinions?
16:20:47 <eclipseo> jcajka: I have a text file, https://eclipseo.fedorapeople.org/TODO5%20cadvisor.md
16:21:10 <eclipseo> jcajka: all right
16:22:05 <jcajka> eclipseo: thanks
16:22:10 <nim> eclipseo, jcajka: probably possible to just save a bugzilla query
16:22:28 <jcajka> nim: yup
16:22:37 <nim> anything that matches the Fedora Product
16:22:45 <nim> Package review component
16:22:57 <nim> in New or ASSIGNED status
16:23:01 <jcajka> and have a weird name with golang in it ;)
16:23:06 <nim> that contains golang in the summary
16:23:31 <nim> I have this save query with fonts for the fonts SIG
16:23:39 <nim> unfortunately not much time to look at it
16:23:59 <nim> The query itself works fine
16:24:22 <jcajka> nim: are you fine with the in ticket voting?
16:24:51 <nim> jcajka, never bothered with it myself
16:25:14 <jcajka> nim : i will take it as yes :)
16:25:23 <nim> jcajka, ticker voting is when you have lots of people to vote
16:25:32 <jcajka> or no quorum
16:25:36 <jcajka> in the meeting
16:25:44 <jcajka> as of now
16:25:52 <nim> yes
16:25:58 <jcajka> so
16:26:02 <jcajka> #action jcajka to announce in ticket voting about the voting proposal
16:26:23 <nim> another way to match reviews would be to cc the sig in the review ticket systematically
16:26:49 <nim> don't need it for font packages because theyr require a fonts suffix
16:27:07 <nim> for golang apps, the srpm is not necessarily named golang-something
16:28:22 <jcajka> nim: might be worth awhile mentioning that in the (Go) packaging guidelines, as way to get the review done faster
16:29:10 <nim> jcajka, not sure that FPC will accept those in a guidelines page
16:29:32 <nim> jcajka, at some point we'll need to split guidelines stuff from SIG stuff
16:31:00 <jcajka> nim: probably, not that it is mangled together now
16:31:08 <jcajka> so let's move to the next part of meeting as last action item have a tracking issue
16:31:42 <nim> jcajka, and in fact, the shorter the section we keep under FPC review, the easier it will be to manage our changes
16:31:58 <jcajka> agreed
16:32:23 <jcajka> first issue
16:32:27 <jcajka> #topic Covering Devconf.cz 2019 conference https://pagure.io/GoSIG/go-sig/issue/16
16:32:53 <jcajka> I have opened that one, I will be there and I have submitted talk about Go and Go in Fedora
16:33:41 <jcajka> I have also spoke with Container-SIG and they will be happy to host us as part of their events/talks
16:33:49 <eclipseo> I have no plan to be there, I don't have the time nor the ressources
16:34:15 <eclipseo> What's the topic you plan to cover?
16:34:32 <jcajka> Go in general and what we are doing with it in fedora
16:34:46 <nim> jcajka, I won't be there either, FOSDEM is sufficient to cram my brain with ideas each year
16:35:02 <nim> jcajka, and I love chocolate and waffles ;)
16:35:23 <jcajka> nim: cool, are you planing to be there mainly on the Go track?
16:35:47 <jcajka> I'm still deciding if i will go to the FOSDEM, I want for few years
16:35:53 <nim> jcajka, I'll move between confs as usual
16:36:55 <nim> jcajka, fosdem is basically, you identify two or free overlapping confs you want to listen to every hour, and then the one you end up in is the one with remaining seats
16:37:33 <nim> jcajka, or the one closer to the previous one if you're getting tired of running around the campus
16:37:34 <jcajka> eclipseo: it might be possible to ask fedora-mindshare(or how the group is called) for sponsoring for FOSDEM or Devconf.cz(or even Flock)
16:38:14 <jcajka> nim: :) devconf is also turning to something like that, although probably in smaller scale
16:38:31 <jcajka> eclipseo: although I haven't tried, myself
16:40:04 <jcajka> i will get back to the ticker when I will know if it got accepted,  if you have anything that I should cover(in more detail), please let me know
16:40:27 <nim> jcajka, you need to go to FOSDEM at least once, even though it is exhausting
16:40:59 <jcajka> nim: I will try
16:41:03 <jcajka> on to the next one
16:41:09 <nim> jcajka, you learn the most interesting things, usually not where you though you would, quality of speaker matters more than subject
16:42:19 <jcajka> :)
16:42:33 <jcajka> we covered the voting so let's go to the final issue
16:43:05 <jcajka> #topic Move relevant upstreams of Go tools and macros used in Fedora under Go SIG namespace in Pagure https://pagure.io/GoSIG/go-sig/issue/8
16:43:38 <jcajka> nim: so I guess what is the status? do you want to work on that?
16:43:56 <nim> so status is
16:44:18 <nim> I think I'm finally arriving at stabilized package naming and layout
16:45:06 <nim> at least tibbs was nice enough to give some naming recommendations in the FPC ticket and no one went against it, it I'm applying his recipes
16:46:00 <nim> based on what tibs suggested I{g going with a go-rpm-macro srpm and project name
16:46:07 <nim> I'm going
16:47:32 <nim> what I'm not sure yet is if I need to host the auto-buildrequires part, or scrap it while mock or rpm get the hardening fixes requested by FESCO
16:48:03 <nim> or make it optional so people can run it on their own build server, just not on the Fedora buildsys
16:48:41 <nim> it's real annoying because FESCO didn't ask for much to approve the feature, but it depends on mock/rpm maints to do the fixes
16:48:51 <jcajka> nim: cool, so we will have two packages go-{rpm|srpm}-macros, right?
16:48:53 <nim> anyway, I disgress
16:49:35 <nim> jcajka, we will have one srom that generates go-srpm-macros, go-rpm-macros, go-filesystem, and go-rpm-templates
16:49:40 <jcajka> I'm really curios how the build time BRs in general will turn out as there seems to be more pressure on it
16:50:11 <nim> jcajka, everyone needs it but forgot to ask for it releng side
16:50:29 <nim> jcajka, it's sad, I had warren ping me he needed it 1à years ago :(
16:50:34 <nim> 10
16:50:51 <jcajka> *sigh*
16:51:33 <nim> but anyway that does not block the rehosting, the only blocker was the srpm name and go-rpm-macros seems to be fine with everyone so I'm going with that
16:52:14 <nim> and I'm combing old macro issues to make sure I ahven't forgotten something
16:52:56 <jcajka> I still think that the srpm-macros, part should be part of the different package so we can have stricter access control(no easy way how to break the whole buildroot)
16:53:21 <jcajka> anyway I'm looking forward to your proposal/PoC
16:53:42 <nim> one nasty ticket was that golist produces arch-specific packages, so /usr/share/gocode needs to move to %{libdir}/gocode
16:54:10 <nim> and I think I've automated the transition safely but I need to test it some more
16:54:48 <nim> jcajka, if you have some time you can look at the current state here
16:54:51 <nim> https://github.com/nim-nim/go-macros/tree/dev/templates/rpm
16:55:24 <nim> jcajka, really, it is all becoming nice and packager friendly
16:56:05 <jcajka> I think that one thing that somewhere popped out is that src/devel packages have been arch-specific too, is it still an issue?
16:56:21 <nim> jcajka, but one of the costs is that the srpm and rpm macro parts need to be kept synchronised, and that's horrible to do with two srpms
16:56:46 <nim> jcajka, that's how golist works, the result is arch-specific
16:56:55 <nim> jcajka, at least for some packages
16:57:17 <nim> jcajka, so the easiest way to hangle it is to make every devel package arch specific and forget about it
16:57:21 <nim> handle
16:57:50 <jcajka> IMO they need to be noarch, i.e. be same on all arches, so you can actually use them for normal devel as you would "go getted" sources
16:58:15 <nim> jcajka, that's kot how the language works unfortunately
16:58:28 <nim> jcajka, you can have arch-specific go files
16:58:29 <jcajka> otherwise we will not be able to really provide supported libraries to devel agains in the future
16:58:38 <nim> jcajka, and golist identifies them nicely
16:59:11 <jcajka> nim: or tag specific, but we still need to have the whole tree to provide all the feature of the Go
16:59:20 <nim> jcajka, and I haven't checked, but I suppose that if you try to builkd a Go project with arch-specific files for an arch not covered in those files it just does not work
16:59:54 <jcajka> nim: it will be the case, if you strip them
17:00:15 <nim> jcajka, I don't strip then Jan does in golist
17:01:29 <nim> jcajka: and I'm not even sure that it's his choice, it's probably the golang engine underneath that does the stripping
17:01:38 <jcajka> I don't blame you not Jan it is probably feature of the go tool and go list will need to be adjusted as it could happen even with build tags(as arch specific stuff is just another build tag)
17:02:03 <jcajka> s/not/nor/
17:02:26 <jcajka> or os dependent files
17:02:43 <nim> jcajka, but anyway, with golist as it stands now we generate arch-specific devel packages, so better put them all in  %{libdir}/gocode and call the resulting packages archful
17:03:27 <jcajka> IMO it is blocking and it needs to be fixed, I will look in to that later in the December
17:03:37 <nim> I don't know if golist could be changed to not strip the other files, or if it even would be a good idea
17:04:08 <jcajka> striping the files is bad idea
17:04:21 <jcajka> or rather removing
17:04:22 <nim> jcajka, it would be actually simpler for me macro-side if it was all noarch all the time
17:04:36 <jcajka> it should be
17:04:56 <jcajka> I guess we agree :)
17:05:17 <nim> jcajka, golist does not work like that, you ask it "what are the project go files that need installing" and then wen puth the result in the devel package
17:05:19 <eclipseo> will the fully noarch packages stay in share?
17:05:43 <eclipseo> Will th GOPATH handles bth lbdir and sfare?
17:05:43 <nim> eclipseo, it will be all noarch or all archfull
17:06:25 <nim> eclipseo, trying to manage two gopath levels would just add bugs all over the place
17:06:31 <eclipseo> mehe the archhul packages are such a minority I wonder if it's worth the hassle
17:07:07 <nim> eclipseo, an exception actually costs you more than treating everything the same
17:07:09 <eclipseo> and anyway they are "arched" but it's still text fales in the end, not bytecode
17:07:40 <nim> eclipseo, anyway, don't panic, if we go archfull that will be all automated
17:07:58 <nim> eclipseo, and just a masse rebuild off the nice specs you're doing now
17:07:59 <jcajka> eclipseo: exactly and in some situations you need all the files that we remove in the archful situation
17:08:09 <eclipseo> I hope I don't want to have to remodiy all the specs
17:08:28 <eclipseo> btw where are we on the EPEL front?
17:08:37 <nim> eclipseo, with a symlink to libdir dropped in so you don't need to worry about build order
17:09:06 <jcajka> we are over the time, but let's move to the open floor
17:09:13 <nim> eclipseo, right now finish stuff in devel first, then push to stable, then try epel
17:09:47 <nim> eclipseo, The new stuff works in epel, our internal builds @work atregt epel
17:09:50 <nim> target
17:10:02 <jcajka> #topic Open Floor
17:10:30 <nim> eclipseo, so there's no technical blocker at all, pushing to epel will just be an horrible admin work
17:10:35 <eclipseo> all right that's great
17:10:48 <jcajka> ad EPEL7 I'm working on resurrecting golang there as with 7.6 golang is dropped from RHEL
17:11:09 <jcajka> it now depends on approval of EPEL packaging committee
17:11:10 <nim> eclipseo, you will eventually need to modify the specs if you wnat to make use of the simplifications
17:11:37 <jcajka> we could eventually introduce all the packaging macros there
17:11:44 <nim> eclipseo, but right now I'm trying to target a codebase that builds both the kind of spec you're used to and simplified ones
17:11:50 <eclipseo> My plans for next month is to ccontinue my reviews of packages then after that move to unbundle the "big" packages there's lot of wor' there
17:12:41 <nim> I'll probably publish a copr without the auto-buildrequires stuff so you can all look at the other parts without worrying about autobrs
17:12:49 <eclipseo> yeah I saw that Does it simplix our work now that it is dropped?
17:13:03 <nim> though I can tell you autobrs are awfully nice to have my team loves them
17:13:04 <eclipseo> will we be able to have a recent toolchain?
17:13:45 <jcajka> eclipseo: in EPEL7? if it gets approved, yes
17:14:07 <nim> eclipseo, it simplifies my internal reviewing work, less manual spec lines to check for warts
17:14:49 <nim> eclipseo, EPEL, unfortunately, is doable technically (I'm doing i) but organisationnally? I don't know
17:15:45 <eclipseo> nim Having BRs helps see which one are missing. If we remove them, not sure how easx it will be tofind the missing ones?
17:16:34 <nim> eclipseo, the long-term upstream rpm paln is to have two srpm stages
17:16:47 <nim> eclipseo, one where autobrs have not been computed
17:17:01 <nim> eclipseo, and another where the srpm contains the autobr list
17:17:08 <eclipseo> ok
17:18:03 <jcajka> nim, eclipseo:?
17:18:18 <nim> short term that does not exist so you'll need to run a rpmbuild -ba or mock to see the br list being computed and failing because one of them does not exist
17:18:18 <jcajka> I guess it is time to end the meeting
17:18:41 <nim> eclipseo, anyway, since you're going through many specs
17:19:06 <eclipseo> yes
17:19:07 <nim> eclipseo, take a look at the simplified spec templates on https://github.com/nim-nim/go-macros/tree/dev/templates/rpm
17:19:24 <eclipseo> I'll have a look
17:19:29 <nim> and tell me if there are things you'd like to be changedin the proposed syntax
17:19:30 <jcajka> ending it in a minute, if there are no objections
17:19:52 <nim> I'll make a formal RFC call when the copr is done
17:20:13 <nim> jcajka, no objections, we just had a lot more things to discuss than last time
17:20:29 <jcajka> #endmeeting