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