Thanks! I did as you told in ~/.luarocks/config.lua , it worked.
My luarocks version is 2.0.10, I used homebrew to install luarocks.
2013/5/8 <luarocks-developers-requ...@lists.sourceforge.net>
> Send Luarocks-developers mailing list submissions to
> luarocks-developers@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/luarocks-developers
> or, via email, send a message with subject or body 'help' to
> luarocks-developers-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> luarocks-developers-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Luarocks-developers digest..."
>
>
> Today's Topics:
>
> 1. Re: can not install lsqlite3 on OS X 10.8 (Doug Currie)
> 2. Re: Hostile rockspec takeover (Philipp Janda)
> 3. Re: Hostile rockspec takeover (Hisham)
> 4. Re: Hostile rockspec takeover (Hisham)
> 5. Re: Hostile rockspec takeover (Hisham)
> 6. Re: [ANN] lua-path 0.1.0 (Hisham)
> 7. Re: [ANN] lua-websockets 2.0 (Hisham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 May 2013 12:13:17 -0400
> From: Doug Currie <doug.cur...@gmail.com>
> Subject: Re: [Luarocks-developers] can not install lsqlite3 on OS X
> 10.8
> To: luarocks-developers@lists.sourceforge.net
> Message-ID: <8c43c7d6-2cf6-4076-8b2d-16a56493a...@gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
>
> On May 7, 2013, at 10:22 AM, Ao Xu <xat...@gmail.com> wrote:
>
> > I tried to install lsqlite3 on OS X 10.8 , but didn't work. Here are the
> details:
> >
> > ?
> > export MACOSX_DEPLOYMENT_TARGET=10.3; gcc -O2 -fPIC
> -I/usr/local/opt/lua/include -c lsqlite3.c -o lsqlite3.o
> -I/usr/local/include
> > export MACOSX_DEPLOYMENT_TARGET=10.3; gcc -bundle -undefined
> dynamic_lookup -all_load -o lsqlite3.so -L/usr/local/opt/lua/lib lsqlite3.o
> -L/usr/local/lib -Wl,-rpath,/usr/local/lib: -lsqlite3
> > ld: -rpath can only be used when targeting Mac OS X 10.5 or later
>
> What version of luarocks are you using? You can check that, and the status
> os your configuration files by running luarocks without arguments.
>
> Check your local configuration at ~/.luarocks/config.lua
>
> Mine is:
>
> variables = {
> -- CC = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch i686 -arch
> x86_64",
> -- LD = "export MACOSX_DEPLOYMENT_TARGET=10.6; gcc -arch i686 -arch
> x86_64"
> CC = "export MACOSX_DEPLOYMENT_TARGET=10.6; cc -arch i686 -arch x86_64",
> LD = "export MACOSX_DEPLOYMENT_TARGET=10.6; cc -arch i686 -arch x86_64"
> }
>
> and lsqlite3 builds for me.
>
> You are probably fine with just:
>
> variables = {
> CC = "export MACOSX_DEPLOYMENT_TARGET=10.8; cc ",
> LD = "export MACOSX_DEPLOYMENT_TARGET=10.8; cc "
> }
>
> e
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 07 May 2013 18:32:50 +0200
> From: Philipp Janda <siffie...@gmx.net>
> Subject: Re: [Luarocks-developers] Hostile rockspec takeover
> To: luarocks-developers@lists.sourceforge.net
> Message-ID: <kmbabe$rp0$1...@ger.gmane.org>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Am 07.05.2013 18:05 schr?bte Jack Lawson:
> > Or you could just fork the code and upload a new version of the rock and
> > use and promote that,
>
> New name or old name? If new name, you basically get *more* unmaintained
> rocks in the repository (see lposix vs. luaposix). You would also have
> to change/fix/fork all rocks having this one as a dependency ...
>
> > instead of changing someone else's code, and then you
>
> I proposed changing (fixing) someone else's rockspec, not their code ...
>
> > can avoid this whole mess. If the owner isn't updating an older rock, by
> > virtue of entropy (and perhaps statistics on how popular a rock has been
> > the last month) the new one will take over.
>
> Like with luasocket, for example?! Fortunately, luasocket specifies
> correct Lua dependencies ...
>
> Philipp
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 7 May 2013 15:48:57 -0300
> From: Hisham <h...@hisham.hm>
> Subject: Re: [Luarocks-developers] Hostile rockspec takeover
> To: luarocks-developers@lists.sourceforge.net
> Message-ID:
> <CAJpkDYdNZaTzhsai9r2Di=ay3rx0oU8Zb328M3_ufg=
> f_ky...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 6 May 2013 20:02, Philipp Janda <siffie...@gmx.net> wrote:
> > Am 07.05.2013 00:31 schr?bte Jack Lawson:
> >> Allowing any arbitrary person to update another person's rockspec sounds
> >> very dangerous to me; I could imagine a developer of a popular library
> >> going afk, and someone else uploading a "lua version change" rockspec
> that
> >
> > That would be *a year* of AFK by now ...
> > And Lua version changes don't happen that often.
> >
> >> also points the tar at a malicious source directory, for example.
> >> Far-fetched, perhaps, but I'd lean more towards requiring more security
> and
> >> away from letting anyone update rockspecs.
> >>
> >> If a package says >= Lua 5.1, and 5.3 breaks it, and nobody can get
> ahold
> >> of the developer - make a new rock, rather than editing the old one.
> Make
> >> it clear that it has a new maintainer. This reeks of security issues.
> >
> > I think a new rock cannot fix the dependency issues of older rocks: If
> > the new rock forbids Lua 5.3, luarocks would simply pick the old one
> > which still (incorrectly) declares compatibility, wouldn't it?
>
> In the current version of LuaRocks, it wouldn't. It always tries the
> latest rock only, even if an older rock would satisfy the
> dependencies. This has pros and cons, though. I've been thinking about
> generating separate manifests for Lua 5.1 and 5.2 and let LuaRocks use
> the correct one, so that Lua 5.1 users still have easy access to older
> versions of rocks as new versions that are Lua 5.2 only replace them,
> but I'm not sure if this is worth the effort.
>
> -- Hisham
> http://hisham.hm/
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 7 May 2013 15:51:34 -0300
> From: Hisham <h...@hisham.hm>
> Subject: Re: [Luarocks-developers] Hostile rockspec takeover
> To: luarocks-developers@lists.sourceforge.net
> Message-ID:
> <
> cajpkdyezzciy1tmlngzs2ctgctr51wyngcnzrid+zx6duk1...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 7 May 2013 02:47, Thijs Schreijer <th...@thijsschreijer.nl> wrote:
> >> >
> >> > Are there that many rocks that fail when switching to 5.2 that this
> is a
> >> > major issue?
> >>
> >> Most C bindings break. Lua-only modules should be ok, unless they use
> >> setfenv.
> >>
> >
> > That's a bit of over simplification:
> > - Lots of code still having the 'module' statement (LuaRocks, coxpcall,
> > copas, to new very commonly used ones). Easy to fix as it is a compile
> > time error if I'm not mistaken
>
> 'module' is deprecated but it is still present in Lua 5.2. I run
> LuaRocks in Lua 5.2 all the time (it does have a runtime check for
> setfenv and any other Lua-5.1-specific code). If 'module' really goes
> away in Lua 5.3, I may follow Petite Abeille's approach and ship my
> own version along.
>
> -- Hisham
> http://hisham.hm/
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 7 May 2013 16:12:40 -0300
> From: Hisham <h...@hisham.hm>
> Subject: Re: [Luarocks-developers] Hostile rockspec takeover
> To: luarocks-developers@lists.sourceforge.net
> Message-ID:
> <
> cajpkdyemy2scrjnyyz-sujal_0cufqtyxlb2fpq1tjz7gg0...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 7 May 2013 13:32, Philipp Janda <siffie...@gmx.net> wrote:
> > Am 07.05.2013 18:05 schr?bte Jack Lawson:
> >> Or you could just fork the code and upload a new version of the rock and
> >> use and promote that,
> >
> > New name or old name? If new name, you basically get *more* unmaintained
> > rocks in the repository (see lposix vs. luaposix). You would also have
> > to change/fix/fork all rocks having this one as a dependency ...
> >
> >> instead of changing someone else's code, and then you
> >
> > I proposed changing (fixing) someone else's rockspec, not their code ...
> >
> >> can avoid this whole mess. If the owner isn't updating an older rock, by
> >> virtue of entropy (and perhaps statistics on how popular a rock has been
> >> the last month) the new one will take over.
> >
> > Like with luasocket, for example?! Fortunately, luasocket specifies
> > correct Lua dependencies ...
>
> [Ouch, it's hard to pick a particular message to reply to in a long
> thread when using GMail.]
>
> This is a great discussion, many good points were raised.
>
> As it was mentioned above, being the upstream maintainer and
> submitting a rockspec are not necessarily the same thing, so i don't
> think we should think in terms of "hostile takeover".
>
> I always thought that anyone is welcome to submit a rockspec of any
> project, whether they wrote it or not (you never see Roberto
> submitting rockspecs for lpeg, do you? :) ).
>
> On security: it's usually not a concern because the source.url tends
> to point to evidently upstream URLs. It's especially not a concern in
> the case of a rockspec revision fixing dependencies, since those don't
> even change the source.url. It's even less a concern when the only
> change is in the "lua" dependency. It's plain to see there's no
> malicious possibilities in that (the worst this could do is to
> temporarily break a rockspec).
>
> On scaling: I'd really like to see the main rockspec eventually going
> to MoonRocks or similiar. I reported some issues in MoonRocks to Leaf
> Corcoran but haven't heard back from him, so I took it to mean that he
> doesn't have the time to focus on MoonRocks lately, which made me
> assume that it is not ready for taking over as the main rocks
> repository. But I'm not closed to the idea. Then there's an issue
> about accounts and abandoned rocks, but to a good extent I think this
> could be handled by a group of mods on a case-by-case basis without
> too much red tape.
>
> On forbidding rocks with "lua >= 5.1": I've been seeing less of those,
> since I fixed the documentation to recommend "lua ~> 5.1" and
> users/devs are more aware of the issue. I think things will eventually
> get sorted out, without having to ban any rocks.
>
> We all want the repository to have the best possible quality, but I
> think we should strive to get things towards a more open/wiki-like
> approach, and not the other way around.
>
> So, in short, feel free to send new revisions of rockspecs which you
> know are broken on Lua 5.2 fixing the 'dependencies' table and I'll
> upload them!
>
> -- Hisham
> http://hisham.hm/
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 7 May 2013 16:16:15 -0300
> From: Hisham <h...@hisham.hm>
> Subject: Re: [Luarocks-developers] [ANN] lua-path 0.1.0
> To: luarocks-developers@lists.sourceforge.net
> Message-ID:
> <CAJpkDYeEGaN81k796b6pmACsKN2E++T0=
> 1nfyi2vxqn2v1a...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 7 May 2013 06:10, Alexey Melnichuk <mi...@newmail.ru> wrote:
> > Rockspec for lua-path version 0.1.0 attached.
>
> Uploaded, thanks!
>
> (Your rockspecs are not appearing as attachments, though. They appear
> embedded in the email text. Attachments are a bit more convenient to
> me, so if you could start sending them as such, it would be great.
> Thanks!)
>
> -- Hisham
> http://hisham.hm/
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 7 May 2013 16:23:51 -0300
> From: Hisham <h...@hisham.hm>
> Subject: Re: [Luarocks-developers] [ANN] lua-websockets 2.0
> To: luarocks-developers@lists.sourceforge.net
> Message-ID:
> <
> cajpkdydrvhxbjylrhqduzm5u5xauuedq7anvde_ti9fqrju...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 7 May 2013 08:57, Gerhard Lipp <gel...@gmail.com> wrote:
> > Hi!
> >
> > There is a new release of lua-websocket. Main features are:
>
> Uploaded, thanks!
>
> -- Hisham
> http://hisham.hm/
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>
> ------------------------------
>
> _______________________________________________
> Luarocks-developers mailing list
> Luarocks-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/luarocks-developers
>
>
> End of Luarocks-developers Digest, Vol 24, Issue 10
> ***************************************************
>
--
-------------------------------------------------------
我：XA
豆瓣：douban.com/people/xatest
twitter：twitter.com/xatest
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
