16:02:02 <jcajka> #startmeeting Go SIG meeting
16:02:02 <zodbot> Meeting started Tue Jan  7 16:02:02 2020 UTC.
16:02:02 <zodbot> This meeting is logged and archived in a public location.
16:02:02 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:02 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:02:09 <jcajka> #topic Roll Call
16:02:16 <jcajka> #chair Eighth_Doctor
16:02:16 <zodbot> Current chairs: Eighth_Doctor jcajka
16:02:28 <QuLogic> .hello qulogic
16:02:29 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:02:34 <jcajka> #chair QuLogic
16:02:34 <zodbot> Current chairs: Eighth_Doctor QuLogic jcajka
16:04:17 * j^2 is just a fly on the wall to see what yall are talking about
16:05:14 <jcajka> Welcome all to new year :) there seems to be no tagged issues so let's jump straight on to the open floor
16:05:25 <jcajka> #topic Open Floor
16:06:09 <QuLogic> not too much it seems
16:06:18 <QuLogic> won't be here next two weeks
16:08:09 <jcajka> ok
16:09:03 <jcajka> From my side I have submitted change proposal for go1.14 https://fedoraproject.org/wiki/Changes/golang1.14 and just finished running first scratch rebuild with beta1 there seems to be usual ~10% FTBFS rate with exception that it seems to be significantly more packages with broken deps, i.e. build root can't be assembled
16:09:50 <jcajka> but this is more of a first impression haven't checked yet all of the ~100 FTBFS packages
16:10:49 <jcajka> otherwise no obvious compiler/stdlib issues on GC side yet
16:11:17 <QuLogic> ~100 doesn't seem too bad
16:11:26 <QuLogic> unfortunate, but alright, I guess
16:12:19 <Eighth_Doctor> I guess this is the first round where we use new Go packaging macros
16:12:27 <Eighth_Doctor> so everything is going to be a bit different
16:13:17 <jcajka> yeah motly thing as usual, some that I have checked are issue on side of the packages(no change with change of the compiler), kind of also broken deps, but packages might no longer be compatible, i.e. missing declarations or on other hand re-declarations, etc.
16:16:28 <jcajka> my only gripe is that currently there are no information in src RPM that golang compiler(and which) is used, only way being to parse the spec files for constructs that depend on it, but I don't have time for creating tool for that so I re-build everything that is using new macros in addition to package that declare that they use golang
16:17:04 <jcajka> BTW re-build including creating the srpms takes ~48h in "mock --chain"
16:19:10 <jcajka> that is all from my side for this year so far
16:22:17 <QuLogic> guess that's all for now then
16:22:20 <QuLogic> sounds good
16:22:32 <Eighth_Doctor> I haven't done anything yet :)
16:22:40 <Eighth_Doctor> so I have nothing to add here
16:24:32 <jcajka> :)
16:25:21 <jcajka> I guess then it is all for today. I will end the meeting 1730h if there are no other topics.
16:26:58 <nim> No other topic from me, than,ks for the meeting
16:27:32 <QuLogic> all I've done is bump a few (non-binary) things & fix ftbfs on htmltest, still waiting on review request to fix tinygo
16:27:50 <QuLogic> nothing to discuss in meeting there though
16:28:40 <nim> jcajka, it’d b fairly easy to add a Provides that matches the compiler a package has been built with
16:30:01 <nim> (I’d rather all the buildroot content list was saved in the srpm but the RFE was closed because "people are supposed to query koji for this info"
16:30:59 <nim> jcajka, however just adding a provides to trace the compiler used is trivial as long as you give us the command that output whatever you want
16:31:09 <nim> as info
16:31:11 <jcajka> nim: that might be useful, possibly from the packaged binaries, but my case is srpm, they should at least explicitly depend on golang compiler
16:32:36 <jcajka> could you elaborate on 'command that output whatever'
16:33:39 <nim> jcajka, just the cli command that a spec should execute to output the info you need
16:34:15 <jcajka> for dynamic BR or provides??
16:35:13 <nim> the thing that will output "build-with(something)"
16:36:23 <nim> and computes the something
16:36:36 <jcajka> I'm not familiar with that do you have some links to some writing about that?
16:38:18 <nim> just anything that outputs a string that means something to you and can be put inside a built-with() provides namespace
16:38:59 <nim> I think the string needs to be without spaces, but I may be wrong
16:39:20 <jcajka> yeah, I'm interested in all the technical background of the built-with(), I guess RPM feature, right?
16:39:43 <nim> it's just something I made up out of hand
16:39:58 <nim> you can set pretty much any string you want as autoprovides
16:40:13 <nim> as long as you are able to compute the string in the spec
16:40:46 <jcajka> oh.. ok
16:40:48 <nim> the built-with() is just namespacing to avoid collision with other provides
16:41:20 <QuLogic> you are speaking of https://rpm.org/user_doc/dependency_generators.html#generators I think?
16:41:52 <nim> like I said the rpm devs have refused to add a generic mecanism, because they feel you should query koji for buildroot contents
16:42:31 <nim> QuLogic, yes that would just be a dep generator
16:43:01 <nim> it would also be possible to make it a BR *if* our specs used autobrs
16:43:42 <nim> but most of them do not because eclipseo felt better recomputing BRs manually in his spec generator
16:43:53 <jcajka> tbh on this I'm more on their side, really my main usability issue is on the srpm side where the new spec format hides BR(not talking about dynamic BR here)
16:44:09 <jcajka> BR here being the golang compiler
16:46:22 <nim> jcajka, it was not possible to both reduce the number of spec lines and keep all the spec lines yes
16:46:51 <nim> so if your question is about spec files, not srpm, anything with a goipath line inside it will use go
16:47:29 <nim> the goipath + gometa line is the pivot declaration that makes a spec a golang spec
16:48:32 <nim> and the spec itself will never tell you what compiler a srpm has been built with because it does not know
16:48:50 <nim> it will take whatever compiler which is available at built time
16:50:17 <jcajka> nim: I don't care about that in this case, I have koji for that, I just want to get list of the packages that expect golang or gcc-go in their buildroot, if I do querry srpm repo
16:50:54 <jcajka> do you have tool that will find all the packages with this constructs?
16:53:29 <nim> jcajka, any srpm that requires go-rpm-macros is likely to be what you want
16:54:35 <nim> any go srpm that does not require  go-rpm-macros is something people handcrafted and I can’t help you with those
16:55:27 <jcajka> ok, that is what I do, thanks for confirming that
16:56:19 <nim> you won't get more info about the compiler koji populated the buildroot with using autobrs or autodeps, I think
16:56:34 <nim> (ie generators as pointed by QuLogic )
16:57:08 <jcajka> you can record it in the specfile explicitly, anyway we are getting on top of the hour any other topics?
16:57:13 <nim> (except with using autobrs or autodeps I meant)
16:58:04 <nim> jcajka, with autobrs it *may* be possible to set a fake br at the srpm level
16:59:05 <nim> but since eclipseo chose not to use the autobt logic in go-rpm-macros, most of our specs do not call autobrs
16:59:22 <nim> I'll keep it in mind when I try to revisit modules
17:00:25 <jcajka> ack
17:00:31 <jcajka> thanks
17:01:07 <jcajka> will end meeting in 5s
17:02:05 <jcajka> #endmeeting