15:59:06 <spot> #startmeeting Fedora Packaging Committee
15:59:06 <zodbot> Meeting started Wed Aug 15 15:59:06 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:09 <spot> #meetingname fpc
15:59:09 <zodbot> The meeting name has been set to 'fpc'
15:59:15 <spot> #topic Roll Call
15:59:27 * geppetto is here
15:59:50 * limburgher here
16:00:08 * Martix is ready for collisions
16:00:44 <Martix> ooh, bad channel, I have mtg somewhere else
16:00:58 <rdieter> yo
16:01:02 <spot> i was wondering what collisions you might have had. :)
16:01:14 <Martix> :-D
16:01:14 * abadger1999 here
16:01:42 <limburgher> I've got the hadrons.
16:01:51 <Martix> limburgher: +1
16:01:54 <spot> i see +5, +6 if racor is here. ;)
16:02:48 <spot> so, lets get started
16:03:14 <spot> #topic %{_libdir} usage in noarch packages - https://fedorahosted.org/fpc/ticket/203
16:03:49 <spot> Proposal: Noarch packages must not use %{_libdir} (or any macro that resolves from %{_libdir}), since that macro has no useful value in noarch build environments.
16:04:02 <spot> this is very much a "doctor, it hurts when i shoot myself in the kneecap." issue.
16:04:24 <spot> The doctor replies: "Stop shooting yourself."
16:04:24 <limburgher> Yeah.  If you need it because it's arch-specific. . .it's not really noarch.  But oh well.
16:04:39 <rdieter> spot: +1
16:04:44 <racor> yes, I'm here
16:04:58 <limburgher> +1
16:05:06 <spot> +1 from me
16:05:07 <geppetto> +1
16:05:08 <rdieter> think of the kneecaps!
16:05:27 <limburgher> You patellists are alike. . .
16:05:30 <geppetto> Didn't someone mention getting rpmbuild to unset _libdir on noarch builds?
16:05:33 <limburgher> ^all
16:05:40 <abadger1999> -1
16:05:53 <abadger1999> (really to the macro that resolves from libdir part)
16:06:06 <abadger1999> There really is no use for libdir itself in a noarch spec file
16:06:12 <spot> abadger1999: can you give a case where that part is ever valid or useful?
16:06:24 <spot> note that i didn't say "macro containing /usr/lib"
16:06:29 <racor> in noarch packages, libdir should be set to /usr/lib, i.e. using %_libdir should not be an issue
16:06:32 <abadger1999> spot: python_sitearch
16:06:41 <abadger1999> the unittest case I mentioned.
16:06:46 <spot> abadger1999: python_sitearch is not resolved from %{_libdir}
16:07:10 <abadger1999> The java people do have a valid use case as well -- but htere are other alternatives for them
16:07:12 <racor> noarch subpackages of arch'ed packages, however would be facing a problem
16:07:22 <abadger1999> spot:  depends on how you define it and there's also no difference
16:07:31 <spot> abadger1999: no, there is a clear difference.
16:07:47 <abadger1999> ie: pythoin pacakge knows where its installed because libdir is used in its build
16:07:49 <spot> macros that derive directly from %{_libdir} are assuming that %{_libdir} is correct
16:07:54 <abadger1999> that value is stored in a Makefile i nthe python package
16:08:11 <abadger1999> Then the python_sitearch pulls that value out via a python stdlib call.
16:08:12 <spot> a stored value is _always_ correct in the buildenv, %{_libdir} is not.
16:08:34 <abadger1999> libdir that was pre-expanded into a macro from another package would be a stored value.
16:08:50 <spot> a noarch build on an x86_64 build env will have a stored value of /usr/lib64, but %{_libdir} is /usr/lib
16:08:53 <abadger1999> If python_sitearch was defined in the pythn package as
16:08:58 <abadger1999> cat << EOF
16:09:00 <spot> macros are not pre-expanded.
16:09:09 <abadger1999> %python_sitearch %{_libdir}
16:09:17 <abadger1999> EOF > macros.python
16:09:25 <spot> [spot@wolverine ~]$ rpm --showrc |grep python_sitearch
16:09:25 <spot> -14: python_sitearch	%(%{__python} -c "from distutils.sysconfig import get_python_lib; import sys; sys.stdout.write(get_python_lib(1))")
16:09:28 <abadger1999> then it would be the same (value and where it comes from)
16:09:30 <spot> thats what rpm evals.
16:09:34 <spot> it is _NOT_ the same.
16:09:57 <spot> it is asking the binary in the buildenv to pull out a stored value
16:09:58 <abadger1999> (that %python_sitearch line should be %python_sitearch %{_libdir}
16:10:04 <spot> but it isn't
16:10:07 <abadger1999> one % in libdir and two in python_sitearch
16:10:10 <spot> and thats why it works
16:10:19 <abadger1999> yes.  In both your case and in mine.
16:10:30 <rdieter> I think we're quibbling a little, the *general* case matches the proposed guideline pretty well imo, of course there may be exceptions (but I'm having a hard time thinking of any non-contrived example, honestly)
16:10:46 <spot> if %python_sitearch was defined like this: %{_libdir}/foo
16:10:50 <spot> it would _not_ be right
16:11:04 <spot> because macros are evaluated at build time
16:11:13 <abadger1999> spot: If it was defined like that *in the macros.python* it would not, you are correct.
16:11:21 <abadger1999> But if it is a HERE document i nthe spec file it would be
16:11:43 <abadger1999> Because rpmbuild will expand the unescaped macros in the spec file.
16:11:56 <spot> a local macro within the spec file that specified %global foo %{_libdir}/foo ?
16:12:43 <abadger1999> cat << EOF \n %python_sitearch %{_libdir} \nEOF > macros.python
16:13:03 * abadger1999 seems my irc client removes a % when I double it.
16:13:13 <abadger1999> % % python_sitearch %{_libdir}/foo
16:13:26 <spot> why would you put escaped macros into the file?
16:13:38 <limburgher> abadger1999:  Slashdot isn't an IRC client.
16:13:40 <abadger1999> into the spec file?
16:14:05 <rdieter> in a noarch pkg?  isn't this exactly the case this guideline is calling out for 'doing it wrong'?
16:14:20 <abadger1999> what you want written out to the macros file is (x86): %python_sitearch /usr/lib/python2.7/site-packages
16:14:38 <abadger1999> (x86_64): %python_sitearch /usr/lib64/python2.7/site-packages
16:14:46 <spot> sure, okay.
16:14:51 <spot> but that is a hardcoded value
16:14:57 <abadger1999> so if I'm remembering all my escaping rules such right
16:15:01 <spot> thats _not_ a macro evaluated from %{_libdir}
16:15:05 <abadger1999> If this is in the spec file you'll get that:
16:15:10 <abadger1999> cat >> EOF
16:15:29 <abadger1999> % %python_sitearch %{_libdir}/python2.7/site-packages
16:15:33 <abadger1999> EOF > macros.python
16:15:50 <spot> umm, yes. because that's in the spec file
16:15:56 <abadger1999> right.
16:15:58 <spot> but you could never do that in a noarch package
16:16:04 <spot> because the answer would not be reliable
16:16:29 <abadger1999> that's all I'm saying about the: (or any macro that resolves from %{_libdir}) part.
16:16:44 <spot> the eval of %{_libdir} would happen at the moment it was cat'd
16:16:50 <abadger1999> that part is overbroad for that reason.
16:16:52 <abadger1999> Yep.
16:16:54 <spot> i disagree.
16:17:00 <spot> you're describing a case that this doesn't cover
16:17:16 <abadger1999> Okay.  Can we clarify the wording?
16:17:17 <spot> that case would never work in a noarch package
16:17:27 <spot> thus: "Noarch packages must not use %{_libdir} (or any macro that resolves from %{_libdir}), since that macro has no useful value in noarch build environments."
16:17:47 <spot> i'm certainly open to clarification.
16:18:33 <abadger1999> So I think what we both mean is (or any macro that has %{_libdir} in its expansion)
16:18:54 <abadger1999> But I don't like that either since it's not going to be obvious to a packager what that means
16:19:17 <spot> how about: "Noarch packages must not use %{_libdir} (or any macro that contains the literal string "%{_libdir}" in its expansion), since the %{_libdir} macro has no useful value in noarch build environments."
16:19:32 <abadger1999> +1
16:19:40 <spot> okay. :)
16:19:43 <spot> +1 to that
16:19:49 <racor> spot: %libdir must have a useful value, otherwise %configure doesn't work
16:19:52 <racor> -1
16:20:00 <rdieter> +1
16:20:20 <spot> racor: %[_libdir} reports /usr/lib on an x86_64 build host building a noarch package. it is not null, but it is not accurate, and thus, not useful.
16:21:31 <spot> racor: if i s/useful/guaranteed accurate/, does that resolve your concern?
16:22:10 <racor> spot: No - I think this proposal does not serve any useful purpose.
16:22:16 <spot> okay. noted.
16:22:29 <limburgher> +1
16:22:50 <spot> I see +1:3, 0:0, -1:1 on the vote count.
16:23:09 <spot> Proposal is: "Noarch packages must not use %{_libdir} (or any macro that contains the literal string "%{_libdir}" in its expansion), since the %{_libdir} macro has no useful value in noarch build environments."
16:23:36 <geppetto> +1
16:23:42 <spot> rdieter?
16:23:46 <rdieter> +1
16:23:49 <spot> sorry, you were +1
16:23:54 <abadger1999> That's 5 (rdieter voted)
16:24:27 <spot> #action Proposal approved: "Noarch packages must not use %{_libdir} (or any macro that contains the literal string "%{_libdir}" in its expansion), since the %{_libdir} macro has no useful value in noarch build environments." (+1:5, 0:0, -1:1)
16:24:35 <spot> my kingdom for the bot to handle voting. :/
16:24:45 <racor> spot: again, this sentence is just wrong. I think I am going to file a request to ban %configure in noarch packages to demonstrate, what's wrong with it.
16:25:25 <spot> racor: i understand that %configure expects a libarch value, thus, the macro should not be NULL
16:25:42 <spot> s/libarch/libdir
16:26:05 <racor> spot: wrong, again. It expects a value being passed to --libdir
16:26:37 <abadger1999> racor: there is a value being passed.  At the moment, that value is always "/usr/lib"
16:26:45 <spot> racor: thats what i said. configure expects a libdir value. by default, the %configure macro uses %{_libdir}.
16:26:45 <abadger1999> no matter what the architecture.
16:27:06 <spot> i think we can safely add that %configure is a valid exception to this rule.
16:27:29 <racor> abadger1999:  /usr/lib for noarch is right
16:27:39 <racor> ... it's a useful value!
16:27:59 <spot> racor: not really. it exists to make the autoconf beast happy.
16:28:20 <geppetto> racor: And when it gets built on x86_64 and is /usr/lib64 ?
16:28:30 <spot> x86_64 isn't looking for files in /usr/lib unless you've got multilib i686 bits present
16:28:39 <racor> spot: I think you are making a lot of avoidable noise about nothing. This discussion an proposal is superflous.
16:28:51 <spot> racor: we have had two fedora packagers in a week bring up this issue
16:28:57 <spot> one of them opened a ticket
16:28:59 <racor> x86_64 is looking in /usr/lib/../lib64 °!
16:29:06 <spot> i think this illustrates the issue.
16:29:31 <spot> Just so no one claims %configure is no longer permitted in noarch packages, lets vote on specifically exempting it.
16:29:37 <spot> +1
16:29:42 <rdieter> +1
16:29:51 <racor> spot: Tell'em noarch packages receive the correct value, no matter what architecture they are being built on.
16:30:17 <spot> racor: that is clearly incorrect. i think we will have to simply disagree on this point.
16:30:25 <abadger1999> +1
16:30:34 <racor> spot: it's a logical consequence of your "the %{_libdir} macro has no useful value in noarch build environments"-  This is untrue.
16:31:06 <spot> geppetto, limburgher, please vote on explicitly excepting %configure here.
16:31:36 <geppetto> uh … not sure. I mean I don't mind people using configure … but they shouldn't be using configure and having it do something with the --libdir result.
16:31:39 <limburgher> +1 sorry distracted
16:32:15 <spot> geppetto: 99% of configure invocations on noarch take in a --libdir value because autoconf requires that there be one
16:32:15 * abadger1999 has seen noarch packages use configure because the upstream knows autoconf... not because it actually makes use of --libdir
16:32:28 <limburgher> Eww.  Really?
16:32:34 * spot nods
16:32:56 <racor> spot: I am talking about "--libdir" (Input to configure scripts), you are talking about rpm's "arch'ed (noarch/x386/x86_64'ed) %_libdir
16:33:06 <geppetto> Maybe something like: "Certain build environments (like autoconf) require setting a libdir value, this is fine as long as the build/install logic does not actually use this for anything."
16:33:09 <spot> and if it doesn't, configure will just ignore
16:33:44 <spot> i just don't want people to say: %configure contains "%{_libdir}", thus you cannot use it in noarch packages.
16:34:10 * abadger1999 fine with geppetto's wording as well
16:34:13 <racor> abadger1999: I have occasionally explicitly been using %configure --libdir=/usr/lib in the early Fedora days. IIRC, because there had been versions of rpm which didn't get it right.
16:36:03 <geppetto> spot: Yeh, I have no problem with that … I just don't want people to do "Oh, I'm ok installing noarch stuff into libdir … I'm using %configure"
16:36:24 <spot> "As an exception to this rule, noarch packages may use %configure (which uses %{_libdir} to set the --libdir value), but packagers should be very careful to ensure that the build/install logic does not actually use this value for anything."
16:36:35 <geppetto> +1
16:36:50 <limburgher> +1
16:36:52 <spot> +1
16:37:03 <abadger1999> +1
16:37:30 <tibbs|w> Sorry, folks, I got pulled out of my office for an emergency.
16:38:24 <spot> We're at +1:4, 0:0, -1:1 on that wording.
16:38:27 <racor> -1, everything has been said. To me this is all is silly
16:38:32 <rdieter> +1
16:38:52 <spot> #action exception wording for %configure approved (+1:5, 0:0, -1:1)
16:39:18 <spot> #topic Bundling exception(s) for Gargoyle - https://fedorahosted.org/fpc/ticket/202
16:40:42 <spot> worth noting that the interpreter in the VI category "Hugo" is not in the Gargoyle Fedora package
16:40:51 <spot> so i'm not sure why they brought it up without highlighting that
16:41:27 <tibbs|w> He was just being thorough.
16:42:14 <tibbs|w> The Hugo stuff has to be pulled for licensing issues so it's of no consequence to Fedora.
16:42:21 <spot> so, the situation here is that these libraries have to enable support for the "Gargoyle Glk" toolkit
16:42:35 <spot> which is roughly analogous to GTK or QT
16:42:51 <tibbs|w> Well, sort of.  There are multiple cases that he outlined.
16:42:55 <spot> so if we were to unbundle the unmodified interpreters, they'd still have to be built again for Glk
16:43:21 <geppetto> tibbs|h: Yeh, but I think we can ignore everything but IV and V …
16:43:24 <tibbs|w> Some of that stuff is really ancient, and I think there's at least a case to be made that the forked versions can be bundled.
16:43:41 <spot> i'm focusing on IV and V first
16:43:51 <spot> because i think a reasonable case exists for I II and III
16:44:29 <tibbs|w> So, case IV is one of those "why isn't the true upstream up to date" issues.
16:45:07 <spot> so, i'm wondering why there can't be an (just picking an example) "Alan3" package that builds two shared libs, "libalan3-gtk.so" and "libalan3-glk.so"
16:45:18 <limburgher> If it's the "true" upstream, *can* it be out of date?
16:45:19 <spot> then, Gargoyle uses libalan3-glk.so
16:45:35 <tibbs|w> Just for discussion, have you built the package?
16:45:40 * spot has not
16:45:48 <tibbs|w> The interpreters appear to live as executables under /usr/libexec.
16:45:49 * limburgher no
16:45:59 <spot> okay, so they're not libraries
16:46:11 <limburgher> And what calls then?
16:46:19 <limburgher> them
16:46:20 <tibbs|w> Ah, I still have it built.
16:46:44 <spot> okay, so Gargoyle Requires: Alan3-glk
16:46:58 <spot> which provides /usr/libexec/Alan3-glk
16:47:01 <tibbs|w> There's a /usr/bin/gargoyle, which is just a symlink to /usr/libexec/gargoyle/gargoyle.
16:47:16 <tibbs|w> That appears to exec the other interpreters which also live in /usr/libexec/gargoyle.
16:47:36 <limburgher> They should really all be in bindir.
16:47:39 <spot> okay, so it provides /usr/libexec/gargoyle/alan3
16:47:45 <spot> not withstanding limburgher's correct comment
16:47:47 <tibbs|w> Yes, precisely.
16:48:03 <spot> what i'm asking is why that can't be in an "Alan3" package.
16:48:23 <limburgher> I'd think it could.
16:48:32 <spot> especially since context implies that these interps can be built for other targets (gtk vs gargoyle)
16:48:35 <tibbs|w> And that's what I do not know.
16:49:05 <tibbs|w> The "can't find what's available at runtime" argument doesn't matter; just make it a package dep and assume it's there.
16:56:20 <limburgher> spot:  Right, we can't just approve "because it's hard".
16:56:37 <tibbs|w> I agree completely.
16:56:44 <spot> i just don't want the packager to get frustrated at a complete kickback
16:56:53 <limburgher> It's not, really.
16:57:12 <limburgher> I, II, and III are essentially a done deal, are they not?
16:57:16 <spot> so i think we ought to approve an exception for the I II III items, and ask that they not package Gargoyle without packaging the IV V interps separately
16:57:21 <rdieter> granting 1-3 should be a gimme, i personally feel this may be obscure enough that there may well never be any tangible benefit to unbundling 4-5.
16:57:40 <spot> rdieter: yeah, i do see that, but we've never defined "obscurity" as a bundling reason.
16:57:46 <abadger1999> yeah
16:57:57 <abadger1999> do these "terps" run standalone?
16:57:57 <spot> today it is obscure. in 5 years, when we're all playing interactive adventure games again...
16:57:58 <rdieter> well, the goal here is that there are real benefits to unbundling
16:58:09 <geppetto> spot: :)
16:58:10 <limburgher> MMOITA . . .
16:58:11 <rdieter> except when there isn't
16:58:12 <spot> abadger1999: i believe they do.
16:58:26 <spot> they're just not in a nice interface
16:58:39 <limburgher> You're in a room.  There are 500 other people here.  There is a door to the south, and a window to the east.
16:58:50 <spot> look at https://sites.google.com/site/scarehome/
16:59:15 <abadger1999> hmm... For 1-3 I'd lean towards okay to bundle, package as a subpackage that can be used standalone/by other GLK frontends.
16:59:29 <spot> the ANSI/ISO interface and the Xglk (gargoyle) interfaces
16:59:30 <tibbs|w> I don't even know if they are any.
16:59:40 <tibbs|w> This whole thing is kind of obscure.
16:59:41 <abadger1999> or maybe I'm not thinking of  that quite right...
16:59:45 <spot> i do not believe any other GLK frontends exist
16:59:51 <limburgher> Yet. :)
16:59:55 <spot> GLK == Gargoyle
17:00:08 <tibbs|w> But, anyway, I'd vote +1 for the first three cases if we vote.
17:00:10 <spot> i think we could revisit that if/when other GLK frontends existed
17:00:12 <abadger1999> Gargoyle includes its own implementation of the Glk specification, called Garglk, and each interpreter is dynamically linked against Garglk.
17:00:21 <tibbs|w> Hmm.
17:00:47 <spot> this might be a chicken and egg problem.
17:01:02 <spot> if Gargoyle Requires: Alan3, but Alan3 BuildRequires: Gargoyle...
17:01:56 <spot> that might be a valid reason for a bundling exception, the difficulty in separating out dependent interpreters.
17:02:29 <abadger1999> The picture I'm getting is /usr/bin/gargoyle has some method (since it's a symlink, I suspect it's just reading all the executables that are in the directory the actual gargoyle executable lives in) of detecting other interpreters.  It is able to invoke them depending on the content it is being asked to run.
17:02:31 <spot> how separate is the "Garglk" bits?
17:02:40 <abadger1999> Each interpreter is linked to a library
17:02:44 <spot> "are", not is. <grammarfail>
17:03:00 <abadger1999> that is provided by the gargoyle package in addition to the /usr/bin/gargoyle binary.
17:03:09 <spot> so there could be a gargoyle-libs (or garglk) package?
17:03:18 <spot> that could break that loop?
17:03:30 <abadger1999> Yeah -- If I'm understanding correctly.
17:03:43 <tibbs|w> OK, the interpreters definitely do link against libgarglk.so.
17:03:46 <spot> gargoyle Requires: Alan3, && Alan3 BuildRequires: gargoyle-libs-devel
17:03:47 <tibbs|w> (Yes, it isn't versioned0.
17:03:55 * spot sighs
17:04:00 <spot> of course it isn't.
17:04:16 * rdieter has a hard-stop nowish, sorry ,consider me in the permissive-camp today and in favor of an exception for Gargoyle, including items 4-5.
17:05:06 <spot> i kindof want to be able to grant a full exception here because of the obscurity, but i worry about the precedent that sets, i think i could argue for chromium. :/
17:05:32 <tibbs|w> Certainly not due to obscurity.
17:05:32 <geppetto> chromium is obscure?
17:05:41 <spot> geppetto: no, but the bundled items might be.
17:05:46 <abadger1999> heh
17:06:11 <tibbs|w> I don't think obscurity wins here either, but I am at least starting to understand why they bundled.
17:06:25 <geppetto> I think I'd want to apply any obscure clause on both parts … so I wouldn't mind just stamping this because wtf not, and both users can be happy.
17:06:31 <tibbs|w> If gargoyle could determine at runtime what interpreters were available, there would be no loop.
17:06:46 <geppetto> But given chromium has 666 users, I'd never let it bundle anything.
17:06:56 * abadger1999 downloads the srpm
17:06:59 <spot> geppetto: you pull that number out of a hat? ;)
17:07:13 <tibbs|w> Regardless of how we decide, there is another question here.
17:07:15 <geppetto> spot: Something like that :)
17:07:21 <abadger1999> I can look at the code but obviously, not in the timespan of this meeting :)
17:07:52 <tibbs|w> This is a content interpreter.  Fedora has a problem with interpreters where the content isn't necessarily free.
17:08:24 <geppetto> spot: Although, to be fair, if chromium had changed something that was "obscure" I think a good argument could be made that the other thing needed to take the patch or be replaced.
17:08:28 * spot sighs
17:08:44 <spot> so each interp needs to be reviewed for content
17:08:53 <geppetto> tibbs|h: I thought it came with some text adventures, no?
17:08:53 <tibbs|w> Personally I intensely dislike that rule.
17:08:55 <spot> gargoyle doesn't ship any content, does it?
17:09:12 <tibbs|w> It ships no content.
17:09:17 * geppetto sighs
17:09:22 <spot> tibbs|w: feel free to have fesco overturn it. the rule was put in place to prevent legal risk from emulators.
17:10:14 <spot> lemme talk to RH Legal again.
17:10:17 <abadger1999> and of course... it uses a different buildtool (jam) that I've no prior experience with.
17:10:21 <spot> it has been a long time since that point came up.
17:10:30 <tibbs|w> Oh, it comes up for me all the time.
17:10:34 <spot> i propose we table this issue until next week.
17:10:40 <abadger1999> +1 table
17:10:45 <spot> and have anyone willing to look into the viability of unbundling
17:10:59 <spot> i'll look at the legal issue.
17:11:03 <tibbs|w> I will communicate back with Carly.
17:11:06 <tibbs|w> Carlo.
17:11:11 <spot> tibbs|w: thanks
17:11:12 <racor> +1 table. I think I want to see at least some  libraries unbundled for "upstream educational purposes" and avoid a precedent
17:11:40 <spot> #action issue tabled until next week, interested fpc members will look into technical specifics on unbundling
17:11:46 <geppetto> +1 table and eat lunch
17:11:48 <spot> i think that brings us to a close
17:11:54 <spot> as it is 12 minutes past the hour
17:11:57 <spot> thanks everyone
17:12:00 <spot> #endmeeting