luarocks / luarocks Goto Github PK

Executing the Luarocks command should give final feedback line to the prompt in all cases.
This is an example of what happens currently:
C:>luarocks list

Installed rocks:
----------------

luafilesystem
   1.5.0-1 (installed) - C:\Lua\5.1\rocks

luasocket
   2.0.2-3 (installed) - C:\Lua\5.1\rocks

luazip
   1.2.3-2 (installed) - C:\Lua\5.1\rocks

md5
   1.1.2-1 (installed) - C:\Lua\5.1\rocks


C:\>luarocks install md5
Installing http://luarocks.org/repositories/rocks/md5-1.1.2-1.win32-x86.rock...
Updating manifest for C:\Lua\5.1\rocks

C:\>

So what happened in this case?? Did it replace the existing rock? no?

Maybe rename the luarocks.rep module to something more descriptive like luarocks.repo or luarocks.repository. It's not obvious what rep is on first glance (e.g. similar to string.rep?).

(and no sane control over which version is actually used by require)

It is my strong opinion that copy_directories should result in files being copied to the rock directory verbatim.

LR 2.0.4.1 (can't test with 2.0.5 right now, sorry)

This rockspec: https://raw.github.com/geoffleyland/luatrace/56835aa75df3cc89e909dc231a527b6f42dcf009/rockspec/luatrace-scm-1.rockspec

Instead of /usr/local/bin/luatrace.profile, /usr/local/bin/luatrace/luatrace.profile is installed.

Is this intentional?

I propose a new option for the luarocks command.
purge purge all installed rocks
should be pretty self-explainable.

Some rocks have their "main" module in a directory with a file named init.lua such as lxsh. Somewhere between luarocks 2.0.1 as installed on my ubuntu system and 2.0.7.1, the behavior of processing a file like this changed: https://github.com/xolox/lua-lxsh/blob/ee16ce4903616030a26c15c4f8ce2222434f0ade/etc/template.rockspec

I think this can be fixed in the rockspec, but am unsure if that would actually break compatibility with older versions. There may need to be a special case for when modules specify something like ['lxsh.init'] = 'src/init.lua' to interpret what they really mean.

Here's a bug I opened in lxsh related to this issue: xolox/lua-lxsh#2

All works with LR 2.0.4-rc*

Ubuntu 10.10 x86 (fresh install)
LR 2.0.4

I must be missing something, but it is too late at night (or early in
the morning), and I can't realize what. This used to work on other
machines:

$ sudo apt-get install uuid-dev

$ sudo luarocks install luuid
Installing http://luarocks.org/repositories/rocks/luuid-20100303-1.src.rock...
Archive:  /tmp/luarocks_luarocks-rock-luuid-20100303-1-3259/luuid-20100303-1.src.rock
 inflating: luuid-20100303-1.rockspec
 extracting: luuid.tar.gz

Error: Could not find expected file libuuid.so for LIBUUID -- you may
have to install LIBUUID in your system and/or set the LIBUUID_DIR
variable

$ locate libuuid.so
/lib/libuuid.so.1
/lib/libuuid.so.1.3.0
/usr/lib/libuuid.so

$ file /usr/lib/libuuid.so
/usr/lib/libuuid.so: symbolic link to `/lib/libuuid.so.1.3.0'

$ file /lib/libuuid.so.1.3.0
/lib/libuuid.so.1.3.0: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), dynamically linked, stripped

$ unzip luuid-20100303-1.linux-x86.rock
$ cd lib

$ ldd uuid.so
       linux-gate.so.1 =>  (0x00c90000)
       libuuid.so.1 => /lib/libuuid.so.1 (0x00509000)
       libc.so.6 => /lib/libc.so.6 (0x00aac000)
       /lib/ld-linux.so.2 (0x008d8000)

$ sudo luarocks make foobar-scm-1.rockspec 
Updating manifest for /usr/local/lib/luarocks/rocks

Error: LuaRocks 2.0.5 bug (please report at [email protected]).
/usr/share/lua/5.1//luarocks/build.lua:237: attempt to index field 'description' (a nil value)
stack traceback:
    /usr/share/lua/5.1//luarocks/build.lua:237: in function 
    (tail call): ?
    (tail call): ?
    [C]: in function 'xpcall'
    /usr/share/lua/5.1//luarocks/command_line.lua:143: in function 'run_command'
    /usr/bin/luarocks:23: in main chunk
    [C]: ?

On a rockspec without description table, obviously. Should be a validation error instead.

On a side note, luarocks pack on that rockspec file works (but probably should fail).

Luarocks (in cfg.lua) assumes that for every prefix to search libraries for (/, /usr, /usr/local etc) there is single set of suffixes to use to locate binaries, headers and libraries.

This does not hold in various environments. E.g.

• There might be differences in use of /lib, /lib32 and /lib64 for different prefixes, even on the same system. SuSE and Solaris come to mind. Also /opt/$software stuff is unlikely to use lib64 even on machines where /usr/lib64 is populated
• Recently-landed Debian/Ubuntu multiarch uses /lib/$arch-triplet while keeping /include

The proposed solution is to make external_deps_dirs optionally more sophisticated, and to allow table of the following kind, as well as plain old prefix string:
external_deps_dirs = {
'/',
{
prefix = '/usr',
bin = 'bin',
include = 'include',
lib = 'lib/x86_64-linux-gnu'
},
'/usr/local'
}

That is, if there is a table instead of string in external_deps_dirs, bin/include/lib are taken from it, not from external_deps_subdirs.

everything is alright when using cmd.exe on win32 platform,
but I have a need to use luarocks in msysgit environment,
and the fs.find() with msys' find command produced undesired
behaviour, causing rock deployment while using msys impossible.

I changed following lines of luarocks.fs.win32.tools:
248:
-- Windows find is a bit different
if file:sub(1,2)=="." then file=file:sub(3) end
if file ~= "." then
...

to
248:
-- Windows find is a bit different
if file:sub(1,2)=="." then file=file:sub(3) end
if file:sub(1,2)=="./" then file=file:sub(3) end --the added line
if file ~= "." then
...

Got some strange bug while making rockspec:

user@ubuntu:~/projects/pk-hb/server/lib/pk-tools$ sudo luarocks make rockspec/pk-tools.pk-ensure-nginx-site-enabled-scm-1.rockspec 

Error: LuaRocks 2.0.7 bug (please report at [email protected]).
/usr/local/share/lua/5.1//luarocks/fs/lua.lua:582: bad argument #2 to 'chmod' (bad mode)
stack traceback:
    [C]: in function 'chmod'
    /usr/local/share/lua/5.1//luarocks/fs/lua.lua:582: in function 'chmod'
    /usr/local/share/lua/5.1//luarocks/fs/lua.lua:258: in function </usr/local/share/lua/5.1//luarocks/fs/lua.lua:238>
    (tail call): ?
    /usr/local/share/lua/5.1//luarocks/rep.lua:176: in function 'move_fn'
    /usr/local/share/lua/5.1//luarocks/rep.lua:234: in function 'action'
    /usr/local/share/lua/5.1//luarocks/rep.lua:47: in function </usr/local/share/lua/5.1//luarocks/rep.lua:40>
    (tail call): ?
    (tail call): ?
    /usr/local/share/lua/5.1//luarocks/rep.lua:247: in function 'deploy_files'
    /usr/local/share/lua/5.1//luarocks/build.lua:229: in function </usr/local/share/lua/5.1//luarocks/build.lua:108>
    (tail call): ?
    (tail call): ?
    [C]: in function 'xpcall'
    /usr/local/share/lua/5.1//luarocks/command_line.lua:151: in function 'run_command'
    /usr/local/bin/luarocks:23: in main chunk
    [C]: ?

According to this mailing list post:
http://lua-users.org/lists/lua-l/2011-09/msg00267.html

Lua 5.2, Metalua and the current LuaJIT2 beta 8 (git HEAD ver.) are being stricter about escaping sequences. This prevented luarocks.fs.win32 module from functioning:

luarocks.fs.win32 Line 18:
if arg:match("^[.a-zA-Z]?:?[/]") then

and

luarocks.fs.win32 Line 36:
if pathname:match("^[.a-zA-Z]?:?[/]") then

the matching patterns mentioned above should be:
"^[.a-zA-Z]?:?[/]"

Don't know if luarocks for other platforms got this issue though.

EDITED
Uh, apparently github's editor has some trouble displaying the escaping character (backslash).
Anyway, there was only one backslash in the bracket part of the matching pattern. There should be two consecutive backslashes, if I'm not mistaken.

Got error:

$ git clone https://github.com/lua-nucleo/lua-nucleo.git
$ cd lua-nucleo
$ luarocks make ./rockspec/lua-nucleo-scm-1.rockspec --pack-binary-rock

Error: Your user does not have write permissions in /usr/local/ 
-- you may want to run as a privileged user or use your local tree with --local.

while I thought that "luarocks make --pack-binary-rock" doesn't actually need to get anything from /usr/local.

LR 2.0.5.

Rockspec:

package = "foobar"
version = "scm-1"
source = {
   url = "" -- Installable with `luarocks make` only
}
description = { }
build = {
   type = "none",
   copy_directories = {
      "files"
   }
}

(Note the copy_directories.)

Directory layout:

$ ls -lR
.:
total 16
drwxr-xr-x 2 agladysh agladysh 4096 2011-09-17 18:31 files
-rw-r--r-- 1 agladysh agladysh  194 2011-09-17 18:36 foobar-scm-1.rockspec

./files:
total 4
-rw-r--r-- 1 agladysh agladysh 16 2011-09-17 18:31 foo.txt

When I use pack on rockspec file:

$ luarocks pack foobar-scm-1.rockspec 
    zip warning: name not matched: 
  adding: foobar-scm-1.rockspec (deflated 25%)
Packed: /home/agladysh/tmp/lrpackbug/foobar-scm-1.src.rock

(Note the warning from zip — it probably must be treated as error by LR.)

The created rockfile contains only unusable (due to url="") rockspec file:

$ zipinfo foobar-scm-1.src.rock
Archive:  foobar-scm-1.src.rock
Zip file size: 324 bytes, number of entries: 1
-rw-r--r--  3.0 unx      176 tx defN 11-Sep-17 18:35 foobar-scm-1.rockspec
1 file, 176 bytes uncompressed, 132 bytes compressed:  25.0%

If I build .all.rock with make + pack, all is OK:

$ sudo luarocks make foobar-scm-1.rockspec 
Updating manifest for /usr/local/lib/luarocks/rocks

foobar scm-1 is now built and installed in /usr/local/ 

$ luarocks pack foobar
  adding: files/ (stored 0%)
  adding: files/foo.txt (stored 0%)
  adding: rock_manifest (deflated 13%)
  adding: foobar-scm-1.rockspec (deflated 27%)
Packed: /home/agladysh/tmp/lrpackbug/foobar-scm-1.all.rock

$ zipinfo foobar-scm-1.all.rock
Archive:  foobar-scm-1.all.rock
Zip file size: 927 bytes, number of entries: 4
drwxrwxr-x  3.0 unx        0 bx stor 11-Sep-17 18:55 files/
-rw-r--r--  3.0 unx       16 tx stor 11-Sep-17 18:55 files/foo.txt
-rw-r--r--  3.0 unx      149 tx defN 11-Sep-17 18:55 rock_manifest
-rw-r--r--  3.0 unx      194 tx defN 11-Sep-17 18:55 foobar-scm-1.rockspec
4 files, 359 bytes uncompressed, 287 bytes compressed:  20.1%

More than once we had seen corrupted manifest files if we pressed ctrl+c in the middle of rock installation. This is a recurring problem in our case, as our build scripts run LR quite intensively, and people tend to press CTRL+C to stop them if something is wrong. I will collect and provide more detailed diagnostics if necessary.

To fix that, LR should generate all its files in a temporary directory, then atomically move them atop the existing ones.

For some reason, even if I specify the tag variable in my rockspec, Luarocks never checks out that tag.

However, if I put the tag name in source.branch instead, it works. I'm guessing that this is some kind of issue with the "rockspec.source.tag or rockspec.source.branch" returning branch even though it's not set.

The reason it works if I put the tag in the branch variable is because git uses the same command for checking out a tag and a branch, but this really should be fixed.

luarocks.fs.unix.tools.current_dir() optimizes determination of the current directory by examining the PWD environment variable.

However, this variable is a shell-ism and is only correct if luarocks is invoked directly from a shell. If it is instead invoked from within a program which calls the system chdir() function directly (and doesn't update PWD ) luarocks will think that the current directory is the one set by the last shell invoked, and all sorts of fun action-at-a-distance and hard-to-debug hilarity ensues.

luarocks shouldn't be using PWD.

Thanks!

Diab

E.g:
$ luarocks install --local ../luafilesystem-1.5.0-1.src.rock
...
$ ldd ~/.luarocks/lib/lua/5.1/lfs.so
undefined symbol: lua_getfield (./lfs.so)
undefined symbol: lua_isstring (./lfs.so)
undefined symbol: lua_setmetatable (./lfs.so)
undefined symbol: lua_pushstring (./lfs.so)
undefined symbol: lua_pushfstring (./lfs.so)
undefined symbol: lua_createtable (./lfs.so)
undefined symbol: lua_pushnumber (./lfs.so)
undefined symbol: luaL_checkudata (./lfs.so)
undefined symbol: lua_settable (./lfs.so)
undefined symbol: luaL_checklstring (./lfs.so)
undefined symbol: lua_touserdata (./lfs.so)
undefined symbol: luaL_newmetatable (./lfs.so)
undefined symbol: luaL_optnumber (./lfs.so)
undefined symbol: lua_newuserdata (./lfs.so)
undefined symbol: lua_pushboolean (./lfs.so)
undefined symbol: lua_type (./lfs.so)
undefined symbol: lua_setfield (./lfs.so)
undefined symbol: luaL_register (./lfs.so)
undefined symbol: lua_gettop (./lfs.so)
undefined symbol: luaL_argerror (./lfs.so)
undefined symbol: lua_tolstring (./lfs.so)
undefined symbol: lua_rawset (./lfs.so)
undefined symbol: lua_pushcclosure (./lfs.so)
undefined symbol: lua_pushlstring (./lfs.so)
undefined symbol: luaL_error (./lfs.so)
undefined symbol: luaL_optinteger (./lfs.so)
undefined symbol: lua_pushnil (./lfs.so)
linux-gate.so.1 => (0xb78c6000)
libc.so.6 => /lib/libc.so.6 (0xb7743000)
/lib/ld-linux.so.2 (0xb78c7000)

You could avoid this by adding "-llua" to the gcc -shared command.

For the reference: http://wiki.mandriva.com/en/Underlinking

I need to be able to put "x-something" fields anywhere in the tree.

C:\Temp>luarocks install luafilesystem
C:\Temp>luarocks install luasocket
...

C:\Temp>luarocks remove luafilesystem

C:\>luarocks remove luafilesystem
Checking stability of dependencies on the absence of
luafilesystem 1.5.0-2...

Removing luafilesystem 1.5.0-2...

Error: Failed deleting C:\LuaRocks/lib/lua/5.1/lfs.dll

Once LuaFileSystem is installed, there's no way to remove it. A similar thing occurs with LuaSocket. It can be removed, but it needs two calls to "luarocks remove luasocket". The first one will remove all lua files but fails to remove the shared libraries. The second call will succesfully uninstall it.

It seems to me that, since lfs and luasocket are available, LR had succesfully required them so the shared libraries are in use. They can't be removed with LR while itself is using them.

Maybe the --force flag could also mean that LR won't use neither LuaFileSystem nor LuaSocket while attempting to remove a rock?

Something like --pack-binary-rock for "luarocks make"

One of our recurring problems that takes a lot of time is that something gets messed up in our local repo and LR starts to download the sources for the rockspec instead of installing from the binary (or source) rock in the local repo. Usually we forget to put binary rock for one of platforms.

This leads to all kinds of nasty and hard to diagnose from the first glance problems with our deployment process.

Is it possible to add something like --no-download CLI option (or whatever name you see fit), which would disable any and all downloads for any reason except from repo specified in --only-from? Once LR decides it wants to download something and sees that this option is on, it should fail with message similar to "Want to download for , but --no-download forbids it. Bailing out."

We've just got this stacktrace from LuaRocks 2.0.6:

/usr/bin/luajit2: /usr/share/lua/5.1/luarocks/path.lua:242: assertion failed!
stack traceback:
        [C]: in function 'assert'
        /usr/share/lua/5.1/luarocks/path.lua:242: in function 'path_to_module'
        /usr/share/lua/5.1/luarocks/loader.lua:142: in function 'filter_module_name'
        /usr/share/lua/5.1/luarocks/loader.lua:119: in function 'pick_module'
        /usr/share/lua/5.1/luarocks/loader.lua:177: in function 
        [C]: in function 'require'
<...>

While it is most likely our fault, I would like to see a better diagnostics here.

Hi. I found that some of my rocks fails to install because its .rock file is corrupt. This is happening, for instance, with a rock I have that contains a large .so (about 4mb).

ignacio@ignacio-VirtualBox:~/devel/sources$ unzip -t lua_cassandra-git-1.linux-x86.rock
Archive:  lua_cassandra-git-1.linux-x86.rock
    testing: rock_manifest            OK
    testing: lua_cassandra-git-1.rockspec   OK
    testing: lib/lua_cassandra.so     bad CRC 1f0cb24a  (should be a65c8220)
    testing: doc/keyspace-agent.1.ronn   OK
    testing: doc/column-family-contacts.1.ronn   OK
    testing: doc/keyspace-interactions.1.ronn   OK
    testing: doc/keyspace-repository.1.ronn   OK
    testing: doc/keyspace-contacts.1.ronn   OK
    testing: doc/column-family-users.1.ronn   OK
    testing: doc/column-family-files.1.ronn   OK
At least one error was detected in lua_cassandra-git-1.linux-x86.rock.

That only happens because I have lzlib installed. If I remove it, then the rock above packs and installs just fine.

I looked into tools/zlib.lua and found out that if I change:

local size_buf = 65535

to

local size_buf = 65535 * 500

then it packs correctly. But that's quite an ugly hack :D

Anyway, I looked for a proper fix, and I found that lzlib has a non documented method called compressobj, that returns an object that lets you pass chunks of data to be compressed. So I changed zipwriter_write_file_in_zip to use it, and it packs fine now.

The thing is, that method is not present in lzlib-0.4 (work3) that was released last year.
I could send a pull request with my fix, but it will break if lzlib-0.4 gets released (or you managed to install anything other than lzlib-0.3).
I also could polish my fix a bit, and contemplate both cases (lzlib 0.3 and 0.4)

Let me know what you think.

Regards!

Using luaJIT, the following error occurs on a load of luarocks:

error loading module 'luarocks.fs.win32' from file 'c:\build\LuaRocks\2.0\lua\luarocks\fs\win32.lua':
        c:\build\LuaRocks\2.0\lua\luarocks\fs\win32.lua:19: invalid escape sequence near '"^['

The regex in question is:

   -- Quote DIR for Windows
    if arg:match("^[\.a-zA-Z]?:?[\\/]")  then
        return '"' .. arg:gsub("/", "\\"):gsub('"', '\\"') .. '"'
    end

But ought to read, methinks:

   -- Quote DIR for Windows
    if arg:match("^[%.a-zA-Z]?:?[\\/]")  then
        return '"' .. arg:gsub("/", "\\"):gsub('"', '\\"') .. '"'
    end

since LR is to be run with sudo, and root does not see my keys

Related to #36.

It was discussed several in LuaRocks list some time ago, that it would be great if LR would have a way to auto-test the rocks in the repo, and upload the results to be published as a "support matrix" for all supported platforms.

See here, for example: http://web.archiveorange.com/archive/v/ofZVLFA5pLAwcmoQtDfq (there may be more interesting discussion somewhere in the list, can't remember them all)

(Have a fix in Steve's repo)

luarocks make --pack-binary-rock creates architecture-dependant stones while it seems to be not really necessary.

For example such rocspec:

package = "example-rock"
version = "1.0.0-1"
source = {
   url = "" -- Use `luarocks make`
}
description = {
 ...
}
supported_platforms = {
   "unix"
}
dependencies = {
}
build = {
   type = "none",
   install = {
      bin = {
         "bin/example-script"
      }
   }
}

use only shell script example-script which is not compilied by any means, though it is made in
example-rock-1.0.0-1.linux-x86_64.rock.

LuaRocks should be able to run auto-tests, bundled with the rock

(have a fix in Steve's repo)

Example with private info censored out:

$ ls -la /usr/local/bin/example-rock-file
-------r-x 1 root root  1376 2012-02-07 04:07 /usr/local/bin/example-rock-file

$ sudo strace -ff luarocks make ./rockspec/example-rock-scm-1.rockspec |& grep /usr/local/bin/example-rock-file
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|05, st_size=729, ...}) = 0
unlink("/usr/local/bin/example-rock-file") = 0
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
open("/usr/local/bin/example-rock-file", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|0644, st_size=729, ...}) = 0
chmod("/usr/local/bin/example-rock-file", 05) = 0

Note the last line.

Please tell me if you need exact files to reproduce (works for any rock for me).

Rockspec is looking something like this:

package = "example-rock"
version = "scm-1"
source = {
   url = "" -- Can be built with luarocks make only
}
description = {
   summary = "example-rock",
   homepage = "http://example.com",
   license = "MIT",
   maintainer = "Alexander Gladysh "
}
supported_platforms = {
   "unix"
}
dependencies = {
  "lua >= 5.1",
}
build = {
  type = "none",
  install = {
    bin = {
      "bin/example-rock-file"
    }
  }
}

This prevents LuaRocks from installing cleanly in 64-bit systems that use lib64/ (and this will have to be changed anyway when LR gets support for Lua 5.2).

Related info: http://article.gmane.org/gmane.comp.lang.lua.luarocks/2415/

I'd like for this feature to be added, since some bugs might be present in older versions of Luarocks and some functionality that the rockspec requires may not be present.

As subject says

If we need to make dozens of rocks using --pack-binary-rock luarocks packs every dependency for each rock.
Can we use rocks already installed in system to make rocks with --pack-binary-rock

(Apologies for not doing my homework)

Is it possible to use local Git repo as a source?

I.e. source.url = "/path/to/repo/.git"

AFAIR — not, as LR would think that this is a simple directory.

Since introducing new fields in rockspec is impossible, can LR figure out that if path is ending with .git, it should use Git?

LR 2.0.5 on Windows 7 64.

After installing LR 2.0.5 with defaults (just run install.bat), it fails to find the config.lua file if current directory is _c:_.

C:\>lua5.1 -lluarocks.require
Site-local luarocks/config.lua file not found. Incomplete installation?
lua5.1: C:\LuaRocks\2.0\lua\luarocks\cfg.lua:218: attempt to concatenate field 'LUAROCKS_PREFIX' (a nil value)
stack traceback:
        C:\LuaRocks\2.0\lua\luarocks\cfg.lua:218: in main chunk
        [C]: in function 'require'
        C:\LuaRocks\2.0\lua\luarocks\path.lua:8: in main chunk
        [C]: in function 'require'
        C:\LuaRocks\2.0\lua\luarocks\loader.lua:8: in main chunk
        [C]: in function 'require'
        C:\LuaRocks\2.0\lua\luarocks\require.lua:4: in main chunk
        [C]: ?
        [C]: ?

However, it works fine everywhere else:

C:\Users>lua5.1 -lluarocks.require
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio

I get a crash in Curl when trying to use the latest luarocks-2.0.7.1 and other weird errors when trying to install.

Might I suggest upgrading the coreutils using this source: http://gnuwin32.sourceforge.net/packages/coreutils.htm since it seems newer than UnxUtils? There's also a build of wget there: http://gnuwin32.sourceforge.net/packages/wget.htm

curl can be cross-compiled easily from linux using mingw-cross-env: http://mingw-cross-env.nongnu.org/ which produces statically-linked binaries.

I've tried switching to gnuwin32 wget and coreutils - I replaced everything except find (wasn't included in coreutils) and mkdir (it seemed to break mkdir -p). My branch does install and work cleaner than the 2.0.7.1 zip file.

(Have a fix in Steve's repo.)