16:05:49 <abadger1999> #startmeeting fpc
16:05:49 <zodbot> Meeting started Thu Jul 24 16:05:49 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:53 <abadger1999> #meetingname fpc
16:05:53 <zodbot> The meeting name has been set to 'fpc'
16:05:59 <abadger1999> #topic Roll Call
16:06:04 <abadger1999> Who's here?
16:06:27 * Rathann present
16:06:29 <abadger1999> #chair geppetto Rathann
16:06:29 <zodbot> Current chairs: Rathann abadger1999 geppetto
16:07:28 * RemiFedora here
16:08:01 <RemiFedora> sorry for last week meeting, I was here (in #fedora-devel), just miss the meeting :(
16:08:18 <abadger1999> #chair RemiFedora
16:08:18 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto
16:08:40 <abadger1999> tibbs|w, SmootherFrOgZ: You guys here?
16:09:11 <tibbs|w> Yeah, I'm around.
16:09:27 <abadger1999> #chair tibbs|w
16:09:27 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs|w
16:09:41 <abadger1999> Let's start with an easy one:
16:10:05 <abadger1999> #topic #341 How to replace "docker" package with an entirely different package of the same name?
16:10:12 <abadger1999> https://fedorahosted.org/fpc/ticket/341
16:10:55 <abadger1999> mattdm is just asking for guidance on how to effect this transition.
16:11:04 <abadger1999> https://fedorahosted.org/fpc/ticket/341#comment:15
16:12:03 <abadger1999> I think if anyone has a better idea than https://fedorahosted.org/fpc/ticket/341#comment:16 just speak up.
16:12:23 <abadger1999> Otherwise I'll CC dgilmore to the ticket and he can figure out if that's actually the best method.
16:12:59 <abadger1999> I don't think anything that gets proposed would contravene guidelines so we don't need to take votes or anything.
16:13:02 <Rathann> that seems to be a good solution
16:13:13 <abadger1999> Maybe that one was too easy ;-)
16:13:20 <abadger1999> #topic #382     Go Packaging Guidelines Draft
16:13:24 <abadger1999> https://fedorahosted.org/fpc/ticket/382
16:13:40 <abadger1999> Sees that vbatts|work is here this week :-)
16:13:45 <abadger1999> And also updated the ticket.
16:18:34 <abadger1999> vbatts|work: So one thing I noticed from your comments... moving to a bundled model would be worse in the typical Fedora hierarchy of "bad things to do with your dependencies" than statically linking.
16:20:08 <abadger1999> *tap*tap* is this thing on? ;-)
16:20:35 <geppetto> yeh
16:20:43 <geppetto> just reading
16:21:10 <geppetto> the Go Language Architectures  needs to change to conditionally define go_arches, and then just always use the secodn form IMO
16:21:49 <geppetto> I also don't like the generic macro import_path …
16:24:08 <geppetto> No exclusiveArch on the binary example … is that intentional?
16:25:04 <geppetto> vbatts|work: ping?
16:26:28 * abadger1999 starts creating a list in the ticket since vbatts|work seems to be busy elsewhere
16:26:33 <Rathann> is there a bug open for missing build ID note on golang binaries?
16:31:11 <Rathann> hm why is BuildArch: noarch set only for F19+?
16:31:50 <RemiFedora> noarch package don't have -debuginfo...
16:31:54 <Rathann> I mean what's the point of the %if considering only F19+ are currently supported
16:32:21 <Rathann> is that ExclusiveArch: for EPEL only?
16:34:02 <RemiFedora> epel seems to have same version than f19
16:34:21 <abadger1999> geppetto: Your import_path comment -- you would like %go_import_path ?
16:34:38 <geppetto> sure, that's fine
16:34:58 <geppetto> anything that couldn't be a python or something else
16:35:54 <abadger1999> <nod>
16:36:27 <Rathann> I wonder if Go upstream has shared library support in their roadmap
16:36:30 <vbatts|work> here now
16:36:31 <vbatts|work> sorry
16:37:06 <vbatts|work> abadger1999: i'm here now. blame dwalsh for distracting me :-)
16:37:48 <abadger1999> Cool.
16:37:54 <vbatts|work> so bundling sucks, yes. but does address the atrophy of letting leaves go with out upstream updates, due to rpm version conflicts to satisfy all the leaves
16:38:14 <vbatts|work> Rathann: there is no firm word on a golang *.so
16:38:36 <vbatts|work> Rathann: it basically goes against their model
16:39:07 <vbatts|work> geppetto: what kind of conditionals are you thinking of for %{go_arches} ?
16:39:26 * vbatts|work looks for other questions in backlog
16:39:38 <abadger1999> vbatts|work: I can paste them one at a time if you want.
16:39:43 <vbatts|work> RemiFedora: debuginfo, that is a tricky one.
16:39:58 <geppetto> vbatts|work: look at how site_path is setup for python packages
16:40:22 <abadger1999> %{?!go_arches: %global go_arches %{ix86} x86_64 %{arm}} and then always use ExclusiveArch:  %{go_arches}
16:40:25 <vbatts|work> RemiFedora: you can objcopy the debug symbols out of golang binaries, but the rpm macro looks for the .note.gnu.build id note, whihc the go complier does not include
16:40:33 <geppetto> vbatts|work: What abadger1999 said :)
16:40:34 <vbatts|work> there for that debuginfo macro fails
16:41:01 <vbatts|work> abadger1999, geppetto: noted
16:41:01 <RemiFedora> vbatts|work, yes I miss the library is noarch, app is arched...
16:42:11 <vbatts|work> abadger1999: perhaps %go_import_path is more explicit
16:43:47 <vbatts|work> what next?
16:44:57 <vbatts|work> RemiFedora: i'll look to clarify on the binary and library section about setting arch correctly
16:45:04 <abadger1999> * Why are we using a conditional in the library spec file template for setting noarch?
16:45:19 * vbatts|work looks
16:45:25 <Rathann> vbatts|work: for the build-ID thing, can you provide an alternative rpm macro that works with what go compiler produces? would that still work with gdb?
16:47:20 <vbatts|work> Rathann: perhaps? i would welcome pointers on jump starting that, since it would be a little learning curve on figuring out what all is presently done, and needs to be done. my bandwidth is not in surplus presently :-\
16:49:31 <vbatts|work> Rathann: i don't have completely solid response, on that. I think at first, when we were going to ship the go compiler's *.a archives, the post macros were forcing an Arch judgement, which was unwarranted since those archives are only relevant to the go compiler itself
16:49:53 <vbatts|work> (the linux go compiler can produce windows, darwin, bsd or linux binaries)
16:50:15 <vbatts|work> err ^ response was fro abadger1999
16:50:43 <Rathann> vbatts|work: actually it was my question ;)
16:51:04 <vbatts|work> about the conditional for a noarch library? cool
16:51:36 <Rathann> but %if 0%{fedora} >= 19 is now always true on Fedora
16:51:46 <Rathann> so what's the point?
16:51:56 <Rathann> of keeping it, I mean
16:52:08 <Rathann> is EPEL different here?
16:52:35 <vbatts|work> epel6 was different
16:52:41 <vbatts|work> epel probably not
16:52:45 <vbatts|work> err epel7
16:55:08 <vbatts|work> on bundling, the worst i see about it, is the ability to track the bundled versions of libraries with a given project. such that a CVE would be rough to follow.
16:55:45 <vbatts|work> were it easy to track, no biggies. update the source of the affected, and rebuild.
16:56:14 <abadger1999> vbatts|work: It's worse than that.
16:56:23 <abadger1999> once bundling starts versions diverge.
16:56:28 <abadger1999> Then when you get that CVE,
16:56:34 <vbatts|work> by the inverse, source libraries are neatly separated out into their own packages, and an update to the source library still means a rebuild of the leaves.
16:56:59 <abadger1999> you might have an extremely rough time because you either have to backport the fix to the older version or port the code to the newer version.
16:57:09 <vbatts|work> but like you mentioned, testing the functionality could become detached from upstream, and more the burden of the packagers themselves
16:57:56 <vbatts|work> abadger1999: fair. i guess i'm taking the optimal case of an active upstream that is keeping their bundled source up-to-date
16:58:45 <abadger1999> vbatts|work: If the bundled source is up to date, then we don't have any problem with separate packages :-)  (other than Fedora has to keep the library packages up to date as well)
16:58:57 <vbatts|work> agreed
17:00:12 <vbatts|work> i'm not pushing bundling. just trying to look at it from angles
17:01:46 <abadger1999> So I think where FPC was before is that we're seeing that we have static linking here and we're okay with that but we're leaning towards wanting a system that means rebuilds to packages need to occur when dependencies are updated.
17:03:06 <abadger1999> Rather than a system where packages have been statically linked and when the dependencies are updated, old packages can continue to simply be linked against the old versions of the libraries.
17:03:27 <abadger1999> I'm not remembering how we thought implementation of those would go.
17:03:59 <vbatts|work> i would like to know, since the language is statically compiled, what tooling is there (or need to be) for determining leaves that need to be rebuilt, when a libraries' source have an errata
17:04:40 <Rathann> hm, there seems to have been a discussion around shared library support last year: https://groups.google.com/forum/#!topic/golang-nuts/zmjXkGrEx6Q
17:04:59 <RemiFedora> abadger1999, this couldperhaps be managed by a fake package, each library providing a sub-package (-libs, but empty for now, or with the license), and each app requiring foo-libs = %version
17:05:00 <abadger1999> vbatts|work: We could do it by making people add Requires: golang = $version  (and $release?).
17:05:26 <RemiFedora> as I think the app have to provide the license of each used library...
17:05:27 <abadger1999> IIRC from the discussion that's what ocaml does except that they have a script that does it automatically.
17:05:48 <abadger1999> (and uses hash values that get put into virtual provides and into the requires instead of package versions).
17:05:53 <vbatts|work> abadger1999: of the compiler itself, but also of any non-stdlib libraries too?
17:06:00 <abadger1999> vbatts|work: yeah.
17:06:42 <vbatts|work> explicit marking of version, then when an increased version library is introduced, how does that flag that a binary needs a rebuild?
17:08:07 <abadger1999> vbatts|work: On the user side: if you have foo-app-1.0-1  and bar-lib-1.1-1 installed and Fedora packagers update to bar-lib-1.2-1 without rebuilding foo-app then yum upgrade will tell you it can't install the new package.
17:08:39 <abadger1999> vbatts|work: on the packager side, you'd probably run repoquery --whatrequires bar-lib
17:08:59 <RemiFedora> and you will receive the "broken dep" mail
17:09:03 <abadger1999> vbatts|work: and that tell you foo-app.  So you'd rebuild foo-app at the same time as bar-lib.
17:09:24 <abadger1999> right.  reactive (broken deps mail) vs proactive (running repoquery)
17:11:49 <vbatts|work> interesting
17:12:38 <abadger1999> I don't think we were set in stone about this aspect but I do think we thought that was the precedent in other similar situations so we'd need to be convinced that this case should follow a different model.
17:12:58 <Rathann> https://codereview.appspot.com/9738047/ <- shared library support for Go
17:13:03 <Rathann> under review
17:13:32 <geppetto> Rathann: will that break shared libary ABI everytime someone updates anything?
17:14:03 <Rathann> no idea
17:14:17 <Rathann> I have zero knowledge about Go, I'm just searching around
17:14:39 <vbatts|work> Rathann: nice!
17:15:58 <Rathann> I'd prefer to wait until that or something similar is upstream, but I don't see anything that would be a major block in current Go Guidelines proposal
17:16:30 <Rathann> as long as you're aware of static linking consequences
17:16:43 <Rathann> and as long as all dependencies are properly tracked
17:17:11 <abadger1999> vbatts|work: Different go topic: regarding %go_arches... the note says that go_arches is defined in golang >= 1.2.1... Is that present everywhere?  I'm seeing it in f20 at least.
17:20:18 <abadger1999> vbatts|work: If so, we can just get rid of the non-%go_arches instructions
17:20:26 <vbatts|work> abadger1999: should be at this point (f19, epel6 included)
17:20:40 <vbatts|work> abadger1999: i'll check on that
17:21:33 <vbatts|work> Rathann: it may be go1.4 or later for that SO type thing to land. So, worth tracking but we'll still need a plan for the statically linked approach too
17:22:07 <Rathann> indeed
17:22:14 <vbatts|work> quick bio break, sorry
17:22:55 <abadger1999> I've updated teh draft for go_import_path
17:23:54 <Rathann> https://code.google.com/p/go/issues/detail?id=256 <- bugreport for missing shared lib support, it does link to the codereview ticket I linked above
17:25:14 <Rathann> abadger1999: http://rpms.famillecollet.com/rpmphp/zoom.php?rpm=golang it seems it's everywhere now
17:25:29 <Rathann> so the %if can be dropped in favour of go_arches
17:26:13 <vbatts|work> back
17:27:14 <vbatts|work> well f19, 18 and 17 don't have those macros tho
17:28:17 <abadger1999> vbatts|work: okay -- f19 doesn't have it even though it has golang-1.2.2-9 ?
17:28:46 <vbatts|work> ah, i looked at the row for 'base'
17:28:50 <vbatts|work> not 'updates'
17:28:57 <vbatts|work> sorry
17:29:01 <abadger1999> ah oka.
17:29:03 <abadger1999> Cool.
17:29:16 <vbatts|work> first time to see this zoom page
17:29:34 * abadger1999 will update the go_arches in a moment
17:29:55 <abadger1999> Is this the proper change to the library template?
17:29:58 <abadger1999> %if 0%{?fedora} || 0%{?rhel} >= 7
17:29:59 <abadger1999> BuildArch:      noarch
17:30:01 <abadger1999> %endif
17:30:02 <abadger1999> ExclusiveArch:  %{go_arches}
17:30:24 <abadger1999> Or maybe ExclusiveArch:  %{go_arches} noarch
17:30:40 <vbatts|work> hmm
17:30:50 <vbatts|work> what the effects of the later be?
17:30:52 <abadger1999> From the text of the Libraries and Arch section, that seems like what's meant but I'm not sure.
17:31:37 <abadger1999> I was going to fix the conditional but noticed that the template also didn't seem to do what the Libraries and Arch section recommended.
17:32:08 <vbatts|work> :-\
17:32:58 <vbatts|work> ah yeah
17:33:07 <vbatts|work> the lib and arch section needs updates
17:33:14 <vbatts|work> the template is most current
17:34:25 <vbatts|work> abadger1999: are you editing the draft presently?
17:34:40 <abadger1999> vbatts|work: yep,  let me get out of that.
17:34:56 <vbatts|work> your fine. just didn't want to conflict
17:35:01 <vbatts|work> *you're
17:35:37 <abadger1999> Okay. I've just finished (changing all ExclusiveArch to use go_arches)
17:36:01 <abadger1999> Go ahead and update the lib and arch section.
17:36:44 <vbatts|work> Rathann: is %%__spec_install_post what includes the script for doing the debug info collection for %debug_package?
17:38:27 <Rathann> yes, it calls /usr/lib/rpm/find-debuginfo.sh
17:38:46 <abadger1999> vbatts|work: oh -- another question about go_arches --- is that provided by redhat-rpm-config or by golang?
17:39:28 <vbatts|work> Rathann: hrm, i don't see that script in `rpm --eval "%__spec_install_post"` on my f20 machine
17:39:38 <abadger1999> we'll need to get it into redhat-rpm-config if it's not there due to the macro being needed at SRPM buildtime.
17:40:22 <vbatts|work> abadger1999: presently golang, though redhat-rpm-config may make sense. What all pulls in redhat-rpm-config?
17:40:24 <Rathann> vbatts|work: do you have redhat-rpm-config installed?
17:40:25 <geppetto> vbatts|work: go_arches / exclusiveArch still isn't used in the binary example … is that intended?
17:40:58 <geppetto> vbatts|work: Also, why the change from commit to rev in the binary example?
17:41:15 <abadger1999> vbatts|work: The important thing is that koji pulls redhat-rpm-config into its buildroot.
17:41:44 <vbatts|work> geppetto: the arch for binaries should be there, i'll make a note to add that
17:41:58 <abadger1999> vbatts|work: if it doesn't get pulled into the buildroot, then the spec file won't parse properly when koji tries to build an srpm from the spec file in git.
17:42:57 <vbatts|work> geppetto: rev is more for hg and commit for git repos
17:43:02 <vbatts|work> shortrev*
17:43:54 <vbatts|work> abadger1999: right. that kind of "expected base" was what i was unsure of
17:44:09 <abadger1999> <nod>
17:44:13 <vbatts|work> like whether groupinstall "development tools" would land it
17:45:05 <abadger1999> I can't remember if koji implements it via a special package that simply depends on the packages for the buildroot or as a certain comps group.
17:45:15 <vbatts|work> Rathann: yes i have redhat-rpm-config installed, but that script is not expanded in the %__spec_install_post macro
17:45:27 <vbatts|work> abadger1999: k
17:45:41 <Rathann> vbatts|work: it does here ;)
17:45:51 <vbatts|work> abadger1999: so, to move /etc/rpm/macros.golang to redhat-rpm-config, what does that involve?
17:46:24 <vbatts|work> and likely has a workflow for changes to the macros, and a longer release cycle
17:46:36 <vbatts|work> perhaps we shouldn't do that until golang related macros dust settles?
17:47:54 <abadger1999> vbatts|work: I guess open a bugzilla -- and ping dgilmore if no one seems to look at that bugzilla.  Also note: We'd only need go_arches I think, not the rest of the go macros.
17:48:01 <Rathann> hm which package holds /etc/rpm/macros.golang?
17:48:19 <Rathann> $ sudo yum install /etc/rpm/macros.golang
17:48:19 <Rathann> Loaded plugins: changelog, langpacks
17:48:19 <Rathann> No package /etc/rpm/macros.golang available.
17:48:19 <Rathann> Error: Nothing to do
17:48:36 <Rathann> that's on f20
17:48:43 <vbatts|work> Rathann: ah that is the el6 path
17:48:53 <vbatts|work> f20 macros dir is somewhere in /usr
17:49:16 <Rathann> /usr/lib/rpm/macros.d/macros.golang
17:49:18 <Rathann> found it :)
17:49:30 <vbatts|work> :-)
17:50:13 <vbatts|work> abadger1999: well, if i am to work on getting an alternate debuginfo strip process done, that will be a golang specific macro
17:50:32 * Rathann found a bug in golang package, apparently
17:51:40 <abadger1999> vbatts|work: <nod>  Talk to dgilmore -- Off the top of my head, I don't remember what the differentiating factors are for macros that must be present when the srpm is created vs only needed when the package is built.
17:52:04 <abadger1999> only macros that must be present when the srpm is created need to be in redhat-rpm-config.
17:52:56 <vbatts|work> abadger1999: so then the golang rpm itself would carry a macros, but for more specific diddling around?
17:53:49 <abadger1999> vbatts|work: correct.  usually the compiler or interpreter package contains most of the macros and redhat-rpm-config contains just the ones that have to be present in the buildroot (for srpm creation time).
17:53:50 <vbatts|work> in addition to redhat-rpm-config having a macros just for the srpm creation
17:53:59 <vbatts|work> abadger1999: ah
17:54:11 <vbatts|work> makes more sense
17:58:50 <abadger1999> Alright -- did we get all of the issues talked about?
17:59:33 * abadger1999 sees one more from earlier
17:59:36 <abadger1999> * http://fedoraproject.org/wiki/PackagingDrafts/Go#Debuginfo_and_Stripping_Binaries
17:59:37 <abadger1999> * Is there a bugzilla open for missing build id?  We should link to that so we can remove this portion when the bug is fixed.
18:01:10 <abadger1999> vbatts|work: ^
18:01:42 <abadger1999> Alright, let's move on.
18:02:24 <abadger1999> #topic #419     ruby193 in SCL
18:02:27 <vbatts|work> i can open a bz for creating a macro to do the objcopy of debug, but the go compiler does not include the .note.gnu.build-id comment and i can't see that they would
18:02:49 * Rathann goes to check who reviewed the golang as it has some FPG violations inside
18:03:14 <abadger1999> vbatts|work: okay,  I think it's fine just to have the bugzilla to link to.
18:03:20 <vbatts|work> Rathann: FPG violations?
18:03:39 <abadger1999> places where it does things contrary to the packaging guideliens
18:04:09 <vbatts|work> oh
18:04:20 <abadger1999> So for ruby193 scl... the submitter closed the ticket and withdrew the scl Fedora 21 Change
18:04:26 <abadger1999> So no longer a big issue.
18:04:32 <abadger1999> we can close that.
18:05:04 <geppetto> Ok, can you #action it?
18:05:22 <geppetto> Or #info … so I'll see it when doing next weeks schedule
18:05:27 <abadger1999> We'll probably end up dealing with any outstanding issues in the main scl ticket anyhow.
18:05:32 * geppetto nods
18:05:46 <abadger1999> #action toshio will close the Ruby1.9.3 scl approval ticket
18:07:27 <abadger1999> #topic Open Floor
18:07:36 <abadger1999> Anyone have anything else?
18:08:21 <abadger1999> I would encourage people to keep thinking about the question of chairmanship.
18:08:42 <abadger1999> We could do something like fesco does
18:08:55 <abadger1999> where the chair rotates between members.
18:09:06 <geppetto> I could live with that
18:09:38 <abadger1999> So each week, one person would be responsible for running the meeting, writing up the ticket outcomes, adding the approved drafts to the guidelines, etc.
18:10:01 <abadger1999> Cool.  Let that percolate in your brains and we can decide if that's what we want to do net meeting.
18:10:07 * abadger1999 will end in 60s
18:11:10 <abadger1999> #endmeeting