17:06:28 <abadger1999> #startmeeting fpc
17:06:28 <zodbot> Meeting started Wed Jan 23 17:06:28 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:06:43 <tibbs> I'm mostly around.
17:06:53 * abadger1999 is a little hesitant to talk about some of these big things with spot out but we'll see what happens.
17:07:03 <abadger1999> #topic Roll Call
17:07:31 * geppetto is here
17:08:11 <abadger1999> racor, Rathann, rdieter, Smoother1rOgZ, limburgher, spot: FPC meeting time, ya'll here?
17:08:18 <limburgher> More or less.
17:08:22 <rdieter> eep, ok
17:09:01 <abadger1999> Well, that's five.
17:09:49 <abadger1999> First off, is there anything anyone would like to deal with today that's easy?
17:09:59 <racor> half  present
17:10:06 <Rathann> here
17:10:10 <abadger1999> There's two that are hard but that will block features so I want to be sure we get to those.
17:11:36 * abadger1999 starts us off then
17:12:00 <abadger1999> #topic NodeJS Guidelines
17:12:12 <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts:Node.js
17:13:00 <abadger1999> This came up last week at FESCo for the Nodejs feature.  I reviewed it with sgallagh at fudcon... it seemed pretty reasonable.
17:13:10 <tibbs> I hadn't seen this before.
17:13:21 <abadger1999> yeah, I just noticed that it didn't get an fpc ticket.
17:13:54 <rdieter> seems ok offhand
17:13:56 <abadger1999> If we want to read this now, the only other thing I think we need to get to is the proposed ruby guidelines and the question of mostly-compatible interpreters.
17:14:37 <limburgher> I see nothing grievously errant.
17:14:37 <rdieter> though, https://fedoraproject.org/wiki/PackagingDrafts:Node.js#Correcting_Dependencies  seems... odd.  patching package.json could yield safer results, no?
17:15:06 <rdieter> meh, not a blocker though
17:15:22 <geppetto> __nodejs macro value seems … weird.
17:15:41 <geppetto> Oh, that's the binary not a dir.
17:15:52 <geppetto> Nevermind
17:15:56 <tibbs> Why would you need that at all?
17:15:56 <limburgher> Right, in case it has to change later.
17:16:05 <limburgher> It conflicted with node. :)
17:16:17 <abadger1999> rdieter: ah I see -- patch the file with %patch.  Then submit the patch upstream.  I think I agree.
17:16:20 <limburgher> Probably a non-issue, but I see the logic.
17:16:28 <tibbs> We already discourage use of those macros.
17:16:50 <tibbs> Unless there's a good reason, of course; I'm just not sure what that reason might be.
17:17:35 * abadger1999 had changed the %{_bindir}/nodejs-symlink-deps and %{_bindir}/nodejs-fixdep location to %_bindir earlier but after some further conversation we think it belongs in its original spot, in /usr/lib/rpm/
17:17:43 <abadger1999> I'll change that back now.
17:18:26 <rdieter> if those are rpm-only tools, that makes sense
17:19:38 <abadger1999> yeah -- tc hollingsworth told me via email that they only work from within a spec file.
17:20:18 <abadger1999> Okay, so the only thing we think is that nodejs-fixdep should jsut be turned into a request to patch and submit the patch upstream?
17:20:43 <rdieter> abadger1999: or at least mention that as an (prefered?) option
17:20:49 <limburgher> Right, I think so.
17:21:21 <Rathann> also, shouldn't this go into nodejs-devel?
17:21:29 <rdieter> Rathann: yes
17:21:30 <tibbs> What's actually behind that fixdep macro?
17:21:51 <tibbs> I mean, "fix everything automatically" sounds kind of magical.
17:22:05 <rdieter> https://fedoraproject.org/wiki/PackagingDrafts:Node.js#BuildRequires  should cover that
17:22:07 <tibbs> I know approximately nothing about nodejs, so.
17:22:40 * abadger1999 checks out hte nodejs pacakge to see
17:23:26 <tibbs> No nodejs-devel appears to be in my repository, so...
17:23:35 <abadger1999> http://pkgs.fedoraproject.org/cgit/nodejs.git/tree/nodejs-fixdep
17:23:48 <abadger1999> For the symlin script: http://pkgs.fedoraproject.org/cgit/nodejs.git/tree/nodejs-symlink-deps
17:25:10 <racor> I do not comprehend the multilib exception rationale. If everything inside is single-arched, everything is arched, hence everything can go into %{libdir} (*sitelib, *sitearch)
17:27:40 * rdieter is ready to vote on nodejs proposal
17:28:13 <abadger1999> racor: Not sure I understand you... Most things will be noarch.  A few packages (none submitted yet, so I don't know what they look like) will have arch-specific extensions.
17:28:59 <tibbs> I guess the question there is how does any kind of multilib exemption have bearing on whether the package puts non-arch-specific stuff under %libdir.
17:29:20 <abadger1999> tibbs: It's %{_prefix}/lib
17:29:24 <Rathann> rdieter: as-is gets -1 from me, the draft needs some fixes mentioned here
17:29:35 <abadger1999> So it would need an exemption like java
17:29:55 <abadger1999> Rathann: The fixdep thing?  I can fix that now.
17:29:56 <tibbs> Well, OK.  But the note doesn't say that.
17:30:06 <rdieter> Rathann: <shrug> ok, I consider those just bug fixes, not worth blocking the guideline
17:30:22 <tibbs> It says that because no multilib, the two directories are the same, which doesn't really make sense to me.
17:31:10 <Rathann> also moving rpm macros and helpers into -devel package
17:33:00 <tibbs> Someone just removed the request for an example spec from the end.
17:33:09 <tibbs> Still needs one, though.
17:33:27 <Rathann> agreed
17:34:16 <racor> abadger1999: They are demanding an exception because the whole package set as they build it is non-multilibed.
17:34:45 <racor> => If they treat everything as non-noarch, they don't need an exception.
17:36:20 <abadger1999> tibbs: ah -- that was me -- it was a request to see an srpm so we'd know what node-gyp would look like but the author added all the sections on node-gyp and left the note in.
17:37:13 <abadger1999> racor: correct.  But that's not something we need to decide -- we made a rule that they could get an exemption from fesco to be non-multilib and then it would be okay for them to do this.
17:37:32 <abadger1999> fixdep has been changed.  You can refresh to see the change.
17:39:32 <tibbs> Hmm, I don't know about that.
17:39:43 <abadger1999> tibbs: refresh and see if the sitelib vs sitearch note is better now.
17:40:14 <tibbs> I mean, I don't see a problem telling upstream that their dependencies need to be fixed somehow and still using the fixdep macro until they apply the change.
17:40:23 <abadger1999> k
17:40:35 <tibbs> It's not really necessary to communicate that to upstream in the form of a patch.
17:41:05 <tibbs> But, either way; the point is that most of the times the macro is needed, upstream actually has something to fix.
17:42:22 <abadger1999> tibbs, rdieter: How about now?
17:42:23 <tibbs> Also, on the topic of that multilib note, is there actually a reason pure javascript stuff isn't in /usr/share?
17:42:35 <Rathann> hm, I don't like it that binary addons are linked statically by node: http://nodejs.org/api/addons.html
17:42:53 <tibbs> I assume it's just because they don't have two search paths.
17:43:04 <rdieter> abadger1999: worksforme
17:43:32 <abadger1999> tibbs: As far as I know, it's the same as other languages -- they don't have a way to split the arch'd from the non-arched and upstream installs to /usr/lib/ by default instead of to %{_libdir}
17:43:57 <tibbs> abadger1999: I figured as much, just needed the knowledge.
17:44:14 <tibbs> Rathann: I got the impression that had been dealt with in Fedora somehow.
17:44:19 <tibbs> Not sure where I got that impression, though.
17:44:40 <tibbs> The draft talks about shared v8 and such.
17:45:10 <Rathann> the nodejs package is not patched in any way
17:45:10 <tibbs> Also, something's missing here:
17:45:20 <tibbs> The Fedora version of node-gyp will handle the fact that shared versions of libuv, v8, and http_parser without modification to the module,
17:45:56 <abadger1999> Rathann: sgallagh worked with upstream when resolving a bunch of this stuff... it might be that the upstream doc is lagging the implementation
17:46:00 <tibbs> There's a verb missed out.
17:46:21 <abadger1999> Rathann: or that might be different than the unbundling work he did and it's still an issue.
17:46:33 <abadger1999> Alright -- shall we vote or make a list of things to ask?
17:46:47 * abadger1999 could vote +1 but is fine with making a list.
17:47:05 <racor> abadger1999: I disagree. It's our job to teach them "best practices". That said "exceptions" are band-aids to bugs. If they can be avoided, we must point them out.
17:47:36 <rdieter> abadger1999: vote, resort to list if it fails
17:47:44 <abadger1999> Okay.
17:48:42 <abadger1999> Proposal: Approve the current version of the Guidelines, ask for clarification (does not need vote) of the "[...]shared versions of libuv,[...]" line before we write it up.
17:48:44 <abadger1999> +1
17:48:45 <rdieter> +1 nodejs proposed guidelines
17:48:50 <limburgher> +1
17:48:54 <geppetto> +1
17:49:03 <Rathann> -1 from me, it still says: "The nodejs package includes an automatic Requires and Provides generator that automatically adds versioned dependencies based on the information provided in a module's package.json file." and the static linking of binary addons is an issue, too
17:49:11 <racor> -1, the proposal is defective
17:50:05 <rdieter> Rathann: would fixing that to nodejs-devel sway your vote?
17:50:08 <tibbs> Ugh, even f18 doesn't have nodejs in the repos.
17:50:45 <abadger1999> tibbs: Yeah, I think deps aren't at the needed versions until f19 (although they may just be waiting on updates)
17:50:53 <rdieter> tibbs: i *think* it needed newer v8
17:51:03 <Rathann> rdieter: no, the static linking is my main issue, also we don't have any example srpm or spec
17:51:06 <tibbs> I just brought up a VM so I could look, and it was the wrong OS.
17:52:48 <tibbs> So I think fundamentally this draft is OK, but there's still stuff that needs fixing.
17:53:11 <tibbs> And that big question about static stuff, which I hope wouldn't have made it past the package review.
17:53:15 <abadger1999> k.  /me works on list
17:53:45 <abadger1999> Rathann: note: the static linking just needs to be clarified as to which it is right?  We aren't mandating that they must fix upstream in some way?
17:53:55 <abadger1999> (since we allow other things to be static linked.)
17:54:44 <abadger1999> Okay => List of questions: https://fedoraproject.org/wiki/PackagingDrafts:Node.js#Questions
17:54:56 <abadger1999> If you have other questions feel free to ask them.
17:55:13 <abadger1999> I'm going to change topics so we can at least start to discuss the other big issue.
17:55:38 <abadger1999> #topic Ruby Guidelines update: https://fedorahosted.org/fpc/ticket/242
17:56:10 <tibbs> BTW, /usr/bin/node is dynamically linked in the current rawhide package.
17:56:24 <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts/Ruby
17:56:31 <tibbs> At least against libuv, libv8, libssl, libhttp_parser and such.
17:56:39 <abadger1999> https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=320351&oldid=320350
17:57:02 <abadger1999> There's not many lines changed but there's a big policy question to be resolved:
17:57:26 <abadger1999> How to deal with interpreters that are almost compatible with each other.
17:57:26 <rdieter> not entirely happy with the ruby(abi) -> ruby(release) change, requires all packages to adapt, but I also understand the rationale for it.
17:57:50 <abadger1999> That question influences whether several of the changes are acceptable:
17:58:06 <abadger1999> " Alternate Ruby interpreters (currently JRuby) also <code>Provide: ruby(release)</code>. This implies, that pure RubyGems packages (these are shared among interpreters) '''must not''' have <code>Requires: ruby</code> or <code>Requires: jruby</code> to have their dependencies satisfied by any of these interpreters"
17:58:23 <abadger1999> "* If the package is pure Ruby, it '''must not''' <code>Requires: ruby</code> or <code>Requires: jruby</code> (but be aware of implementation specific methods, such as <code>fork</code>)."
17:59:22 <abadger1999> The first question is: are we okay with interpreters that are compatible for most code sharing the files for their modules.
17:59:37 <abadger1999> If we're okay with that, then we need to ask whether the proposed implementation is fine.
17:59:38 <geppetto> I think so … why would we be against that?
17:59:39 <tibbs> Seems better than the alternative, I'd think.
18:00:02 <rdieter> probably good enough, for now, given how little we know about it yet.
18:00:29 * abadger1999 is also okay with the idea of sharing
18:01:11 <abadger1999> limburgher, Rathann, racor: is the basic premise okay with you too?
18:02:05 <limburgher> I think so.
18:02:28 <abadger1999> geppetto: I suppose an argument could be made that it's hard to test that situation (ie: that the code in this particular package runs on both interpreters)
18:03:40 <abadger1999> Maybe for implementation we could say that code needs to run its unittests under both ruby and jruby?
18:03:45 <geppetto> abadger1999: seems better than having two packages and testing it twice that way.
18:03:52 <abadger1999> yeah
18:04:01 <tibbs> RIght, you have to test it N times anyway.
18:04:29 <abadger1999> Okay, well that's five who are okay with the basic idea so we can potentially approve an implementation as well.
18:04:31 <tibbs> Python has shown us that having separate packages generated from the same spec gets pretty messy.
18:05:01 <tibbs> I mean, I guess we could ask what the alternative looks like, but that seems an awful amount of work just to prove a point.
18:05:08 <abadger1999> tibbs: heh.  yeah -- but python2/python3 is different than this.... python2 + pypy would be similar (and add another layer of complexity to the current packages)
18:05:21 <limburgher> abadger1999: <nods>
18:06:21 <abadger1999> Could we come up with questions about the current ruby proposal so the authors can address those this week?
18:06:41 <racor> abadger1999: sorry, I don't feel able to vote or comment, The discussion referenced in trac is too long and comes with too many implications, which would me to have more time to think about it.
18:06:51 <Rathann> sorry, had to take a call
18:07:21 <abadger1999> I'd like to see the rubypick (script to allow users and packagers to choose which version of ruby interpreter an application to use) stuff have a recipe in the guidelines.
18:07:24 <tibbs> My fear is that my dumb questions are all in that trac ticket somewhere.
18:07:31 <Rathann> abadger1999: I'm more or less okay with the basic premise
18:07:49 <abadger1999> I'm not sure about hte Provides and Requires... I want to be sure that we're protecting end-users.
18:07:50 <tibbs> Changing rubygems to gems, changing gem_extdir to gem_extdir_mri and such, just seems like busy work for packagers.
18:08:05 <tibbs> But then, the same folks proposing these changes maintain essentially all of the packages.
18:08:24 <abadger1999> Maybe what it needs is to have a section on when it's appropriate to Require: the real ruby or real jruby packages rather than the virtual provide.
18:08:55 <tibbs> I guess that comes down to "when the module uses something that's not compatible between interpreters".
18:09:00 <tibbs> But maybe they have a better list.
18:09:35 <abadger1999> Yeah.  But it's not written into the Guideline Proposal that way
18:09:44 <tibbs> That statement is quite confusing, actually.
18:10:05 <abadger1999> (ie: " If the package is pure Ruby, it '''must not''' <code>Requires: ruby" rather than having a clause about incompatibility)
18:10:06 <tibbs> "must not" require a specific interpreter.  But be aware of something.
18:10:28 <tibbs> And it doesn't tell you why you should be aware of it, or what you should do in that case.
18:11:04 <abadger1999> okay.  that's two questions to ask.
18:11:09 <abadger1999> Anyone have anything else?
18:12:38 <tibbs> To me this doesn't really look that invasive.
18:13:10 <tibbs> I do suspect that regardless of what gets in this guideline, weird compatibility problems are going to crop up and someone who isn't us is going to have to deal with them.
18:13:17 <Rathann> why do we need %{gem_extdir_mri} ?
18:13:45 <tibbs> It's just a rename, I guess, to match upstream terminology.
18:13:57 <abadger1999> Rathann: I think that there's going to be different extdirs for the various ruby interpreters.
18:14:17 <abadger1999> So C-ruby will use gem-extdir_mri and jruby might use gem_extdir_jruby
18:14:25 <abadger1999> We can ask if that's the case.
18:14:31 <Rathann> oh, so it's interpreter-specific?
18:14:58 <tibbs> Hmm, so only pure ruby modules can be shared.
18:14:59 <Rathann> all other dirs for gem packages seem to be interpreter-agnostic
18:15:04 <tibbs> Which kind of makes sense.
18:16:14 <abadger1999> tibbs: correct.
18:16:26 <abadger1999> at least, that's been my understanding of what they've written
18:16:39 * rdieter needs to lunch soon, sounding like this will or will not get voted on today?
18:16:48 * rdieter guesses no
18:17:04 <tibbs> I think the main question was whether we were fundamentally opposed to the sharing issue.
18:17:43 <abadger1999> Will not get voted.
18:18:03 <abadger1999> Just try to add questions and comments to the draft if you think of any.
18:18:11 * abadger1999 will write up the ones we've mentioned here.
18:18:28 <tibbs> I guess they'll submit guidelines for packaging non-MRI extensions later.
18:18:40 <tibbs> Not that I know what MRI means in this context, but....
18:18:56 * abadger1999 will ask what mri means as well.
18:19:12 <abadger1999> Okay.  Seems like that's all we're going to get to this week.
18:19:13 <tibbs> Matz's Ruby Interpreter
18:19:27 <abadger1999> k
18:19:35 <abadger1999> Thanks for coming everyone!
18:19:40 <abadger1999> #endmeeting