anybody know a Ubuntu universe maintainer to one-line patch luarocks?

[Jay Carlson <nop@...>]

On Tue, Mar 13, 2012 at 7:43 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 9:29 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> I'll go so far as to say that if a package consisting of more than
>> a single Lua file does not install by `luarocks install pkgname`,
>> I'm usually too lazy to install it.
>
> Which is why Hisham needs our support, he's running key infrastructure.
>
> I'll make μL available as a rock, as well, so people can use it as a
> lightweight dependency.

(thread hijack)

Anybody know an Ubuntu universe maintainer? The luarocks "all
architecture" package hardcodes LUAROCKS_UNAME_M as "i686", which
means CFLAGS won't get -fPIC on x86_64. Simply removing the
LUAROCKS_UNAME_M line from the distributed
/usr/share/lua/5.1/luarocks/config.lua will fix it.

This is important as it breaks all of lhf's packages; I found it when
trying to build the rock of lpack. Although he can cheat by omitting
-fpic for DSOs on i386, he can't on other architectures. The rockspecs
for his packages fix this for him--if they know they're on a non-i386
architecture.[1] IMO the rockspecs should include -fpic on i386 as
well.

I posted a bogus patch in
https://bugs.launchpad.net/ubuntu/+source/luarocks/+bug/923161 ; it's
bogus because it does not patch luarocks.orig, it's something which
needs to be applied during the luarocks.deb build process after
config.lua has been installed into the target root.

I just filed the Debian bug for this. It seems a little unfair, since
the results are more benign on Debian: their "all" build machine
hardcodes LUAROCKS_UNAME_M as x86_64 which will get -fPIC. It's a
stupid way to do it since I'm trying to get it fixed in Debian just so
it would be picked up in Ubuntu, since the consequences are more
drastic on Ubuntu.

Jay

[1]: I've given up on Lua upstream doing the right thing with DSOs
(hey, it mostly works on i386) which is why I don't complain about it.
As a side note, please do not write -fPIC until you get a "fails to
build" bug report on some architecture (probably sparc). -fPIC can be
drastically less efficient than -fpic and is not necessary unless your
shared object uses a *lot* of global symbols.