[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[Arnout Vandecappelle]

 This is a collection of fixes and improvements for the Lua and LuaRocks
infrastructure.

 It was triggered by luaposix, which fails to load at runtime with luajit
and lua 5.1 (cfr. [1]). As is typically the case, this one fix lead to a
whole lot of other changes.

 The first patches can be applied independently of each other. They are
small issues that I noticed while implementing the PKG_NAME_UPSTREAM
feature. See the individual commit messages for details.

 We decided that new Lua packages should have a name starting with lua
(I guess both lua, like luaposix, and lua-, like lua-iconv, are OK).
Patch 13 documents that in package/Config.in.

 A new package lua-bit32 is added in patch 14. This package is used to
fix luaposix in patch 15. Subsequent patches generalize the hacks that
are needed for lua-bit32 because of the added lua- prefix. Patch 16
reworks the extraction so it doesn't rely on specific naming of the
subdirectory in which luarocks extracts stuff. Patch 18 introduces
a _NAME_UPSTREAM variable so that the automatically derived variable
names from the luarocks infra are correct when the Buildroot name is
different. Patch 20 extends that concept to the typical situation that
the Lua name has camel case, while the Buildroot name (as well as the
LuaRocks name) is lower case.

 Patch 25 is again independent of the rest. It removes documentation from
the target that is installed there by some Lua (not LuaRocks) packages.
For example, luaposix does that.

 Patches 18 to 24 are somewhat controversial because they introduce
"magic automation" just to save a few lines in the package .mk file. The
amount of savings from those isn't impressive either, they have a
diffstat of 13 insertions(+), 17 deletions(-) (discounting the
documentation change). Still, I believe it makes creation of LuaRocks
packages a bit easier so I included them.

 I did a runtime test after all patches applied by doing a
require "foo"
for each luarocks package with a Lua 5.1 interpreter. I am also using the
fixed luaposix on an actual customer device.

 Obviously, this entire series is for next.

 Regards,
 Arnout

[1] https://lists.osuosl.org/pipermail/buildroot/2017-February/184511.html

----------------------------------------------------------------
The following changes since commit c75f0a4d69db655bb523fbab30e0f4656bc5fb71:

  configs/liteboard: Bump to kernel 4.10 (2017-02-21 16:11:05 +0100)

are available in the git repository at:

  https://gitlab.com/arnout/buildroot lua

for you to fetch changes up to a5dfafeb82c2a91f51908110beafe7389015ca75:

  lua: remove documentation from target (2017-02-23 16:48:06 +0100)

----------------------------------------------------------------
Arnout Vandecappelle (25):
      lutok: move to Lua libraries menu
      cosmo: remove broken package
      luarocks-package: use $(HOST_PKG_VERSION) instead of $(PKG_VERSION)
      manual: luarocks: improve tutorial example
      lpty: remove LPTY_VERSION_UPSTREAM
      lua-periphery: remove LUA_PERIPHERY_VERSION_UPSTREAM
      luasec: remove LUASEC_VERSION_UPSTREAM
      ljlinenoise: remove default definition of PKG_SUBDIR
      lua-csnappy: remove default definition of PKG_SUBDIR
      lua-iconv: remove default definition of PKG_SUBDIR
      luacrypto: remove default definition of PKG_SUBDIR
      lunit: remove default definition of PKG_SUBDIR
      package/Config.in: explain that lua package names should start with lua
      lua-bit32: new package
      luaposix: fix runtime by selecting "bit32" instead of "bitop"
      luarocks-package: rework extraction
      lua-bit32: remove custom extract commands
      luarocks-package: introduce PKG_NAME_UPSTREAM
      lua-bit32: use PKG_NAME_UPSTREAM
      luarocks-package: lowercase the upstream name for LuaRocks
      lua-coat: use PKG_NAME_UPSTREAM
      lua-cjson: use LUA_CJSON_SUBDIR
      lua-testmore: use PKG_NAME_UPSTREAM
      luabitop: use PKG_NAME_UPSTREAM
      lua: remove documentation from target

 docs/manual/adding-packages-luarocks.txt           | 55 +++++++++++++---------
 package/Config.in                                  |  6 ++-
 package/cosmo/Config.in                            | 10 ----
 package/cosmo/cosmo.hash                           |  2 -
 package/ljlinenoise/ljlinenoise.mk                 |  4 +-
 package/lpty/lpty.mk                               |  3 +-
 package/lua-bit32/Config.in                        |  9 ++++
 package/lua-bit32/lua-bit32.hash                   |  2 +
 package/{cosmo/cosmo.mk => lua-bit32/lua-bit32.mk} |  9 ++--
 package/lua-cjson/lua-cjson.mk                     |  5 +-
 package/lua-coat/lua-coat.mk                       |  5 +-
 package/lua-csnappy/lua-csnappy.mk                 |  4 +-
 package/lua-iconv/lua-iconv.mk                     |  4 +-
 package/lua-periphery/lua-periphery.mk             |  3 +-
 package/lua-testmore/lua-testmore.mk               |  5 +-
 package/luabitop/luabitop.mk                       |  5 +-
 package/luacrypto/luacrypto.mk                     |  4 +-
 package/luainterpreter/luainterpreter.mk           | 11 +++++
 package/luaposix/Config.in                         |  6 ++-
 package/luasec/luasec.mk                           |  3 +-
 package/lunit/lunit.mk                             |  4 +-
 package/lutok/Config.in                            |  1 -
 package/pkg-luarocks.mk                            | 14 ++++--
 23 files changed, 94 insertions(+), 80 deletions(-)
 delete mode 100644 package/cosmo/Config.in
 delete mode 100644 package/cosmo/cosmo.hash
 create mode 100644 package/lua-bit32/Config.in
 create mode 100644 package/lua-bit32/lua-bit32.hash
 rename package/{cosmo/cosmo.mk => lua-bit32/lua-bit32.mk} (51%)

[Buildroot] [PATCH 01/25] lutok: move to Lua libraries menu

[Arnout Vandecappelle]

Since this package really is a Lua extension, it fits under the Lua
libraries menu.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
The original patch had lutok before the Lua libraries menu, which is
also not appropriate. Thomas moved it to after the menu while
committing. It's not clear to me why Thomas didn't move it inside the
menu instead.
---
 package/Config.in       | 2 +-
 package/lutok/Config.in | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/Config.in b/package/Config.in
index e6dbe5822e..69e068b6d4 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -557,6 +557,7 @@ menu "Lua libraries/modules"
 	source "package/luasocket/Config.in"
 	source "package/luasql-sqlite3/Config.in"
 	source "package/lunit/Config.in"
+	source "package/lutok/Config.in"
 	source "package/luv/Config.in"
 	source "package/luvi/Config.in"
 	source "package/lzlib/Config.in"
@@ -567,7 +568,6 @@ menu "Lua libraries/modules"
 	source "package/xavante/Config.in"
 endmenu
 endif
-	source "package/lutok/Config.in"
 	source "package/micropython/Config.in"
 	source "package/micropython-lib/Config.in"
 	source "package/moarvm/Config.in"
diff --git a/package/lutok/Config.in b/package/lutok/Config.in
index d6c87cf586..ab9c32b6d5 100644
--- a/package/lutok/Config.in
+++ b/package/lutok/Config.in
@@ -1,7 +1,6 @@
 config BR2_PACKAGE_LUTOK
 	bool "lutok"
 	depends on BR2_INSTALL_LIBSTDCPP
-	depends on BR2_PACKAGE_HAS_LUAINTERPRETER
 	depends on !BR2_PACKAGE_LUAJIT
 	help
 	  Lutok is a lightweight C++ API library for Lua.
-- 
2.11.0

[Buildroot] [PATCH 01/25] lutok: move to Lua libraries menu

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:23 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Since this package really is a Lua extension, it fits under the Lua
> libraries menu.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Applied to master, thanks.

> The original patch had lutok before the Lua libraries menu, which is
> also not appropriate. Thomas moved it to after the menu while
> committing. It's not clear to me why Thomas didn't move it inside the
> menu instead.

Not sure why I did that. I even explicitly wrote in the commit log that
I did this change on purpose. Really, I don't see why. I applied the
patch at 21:41, so not even too late. Dunno.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 02/25] cosmo: remove broken package

[Arnout Vandecappelle]

The cosmo package has been marked as broken for two and a half years
now, and nobody cared. Get rid of it.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/Config.in        |  1 -
 package/cosmo/Config.in  | 10 ----------
 package/cosmo/cosmo.hash |  2 --
 package/cosmo/cosmo.mk   | 10 ----------
 4 files changed, 23 deletions(-)
 delete mode 100644 package/cosmo/Config.in
 delete mode 100644 package/cosmo/cosmo.hash
 delete mode 100644 package/cosmo/cosmo.mk

diff --git a/package/Config.in b/package/Config.in
index 69e068b6d4..cf9c401af0 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -524,7 +524,6 @@ menu "Lua libraries/modules"
 	source "package/argparse/Config.in"
 	source "package/cgilua/Config.in"
 	source "package/copas/Config.in"
-	source "package/cosmo/Config.in"
 	source "package/coxpcall/Config.in"
 	source "package/dado/Config.in"
 	source "package/easydbus/Config.in"
diff --git a/package/cosmo/Config.in b/package/cosmo/Config.in
deleted file mode 100644
index 869a1072ed..0000000000
--- a/package/cosmo/Config.in
+++ /dev/null
@@ -1,10 +0,0 @@
-config BR2_PACKAGE_COSMO
-	bool "cosmo"
-	# run-time dependency
-	select BR2_PACKAGE_LPEG
-	# upstream site does not provide a valid archive
-	depends on BROKEN
-	help
-	  Cosmo is a "safe templates" engine for Lua.
-
-	  http://mascarenhas.github.io/cosmo/
diff --git a/package/cosmo/cosmo.hash b/package/cosmo/cosmo.hash
deleted file mode 100644
index ff88576469..0000000000
--- a/package/cosmo/cosmo.hash
+++ /dev/null
@@ -1,2 +0,0 @@
-# locally computed
-sha256  4e81c1bba7ab3b4633c8d6dadfc8332c59c818829436435b4d5a2ec76adfbb87  cosmo-14.03.04-1.src.rock
diff --git a/package/cosmo/cosmo.mk b/package/cosmo/cosmo.mk
deleted file mode 100644
index 0ab5324569..0000000000
--- a/package/cosmo/cosmo.mk
+++ /dev/null
@@ -1,10 +0,0 @@
-################################################################################
-#
-# cosmo
-#
-################################################################################
-
-COSMO_VERSION = 14.03.04-1
-COSMO_LICENSE = MIT
-
-$(eval $(luarocks-package))
-- 
2.11.0

[Buildroot] [PATCH 02/25] cosmo: remove broken package

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:24 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> The cosmo package has been marked as broken for two and a half years
> now, and nobody cared. Get rid of it.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/Config.in        |  1 -
>  package/cosmo/Config.in  | 10 ----------
>  package/cosmo/cosmo.hash |  2 --
>  package/cosmo/cosmo.mk   | 10 ----------
>  4 files changed, 23 deletions(-)
>  delete mode 100644 package/cosmo/Config.in
>  delete mode 100644 package/cosmo/cosmo.hash
>  delete mode 100644 package/cosmo/cosmo.mk

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 03/25] luarocks-package: use $(HOST_PKG_VERSION) instead of $(PKG_VERSION)

[Arnout Vandecappelle]

The inner-luarocks-package macro was using $(3)_VERSION as the package
version, i.e. the version of the target package, even when it's the
host package. We should instead use $(2)_VERSION, i.e. the host package
version, like is done in inner-generic-package.

Since luarocks-package doesn't even support a host version, it doens't
make a whole lot of difference, but let's keep things consistent.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/pkg-luarocks.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/pkg-luarocks.mk b/package/pkg-luarocks.mk
index da5c912c81..aa83e74a0e 100644
--- a/package/pkg-luarocks.mk
+++ b/package/pkg-luarocks.mk
@@ -34,9 +34,9 @@
 define inner-luarocks-package
 
 $(2)_BUILD_OPTS		?=
-$(2)_SUBDIR		?= $(1)-$$(shell echo "$$($(3)_VERSION)" | sed -e "s/-[0-9]$$$$//")
-$(2)_ROCKSPEC		?= $(1)-$$($(3)_VERSION).rockspec
-$(2)_SOURCE		?= $(1)-$$($(3)_VERSION).src.rock
+$(2)_SUBDIR		?= $(1)-$$(shell echo "$$($(2)_VERSION)" | sed -e "s/-[0-9]$$$$//")
+$(2)_ROCKSPEC		?= $(1)-$$($(2)_VERSION).rockspec
+$(2)_SOURCE		?= $(1)-$$($(2)_VERSION).src.rock
 $(2)_SITE		?= $$(call qstrip,$$(BR2_LUAROCKS_MIRROR))
 
 # Since we do not support host-luarocks-package, we know this is
-- 
2.11.0

[Buildroot] [PATCH 03/25] luarocks-package: use $(HOST_PKG_VERSION) instead of $(PKG_VERSION)

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:25 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> The inner-luarocks-package macro was using $(3)_VERSION as the package
> version, i.e. the version of the target package, even when it's the
> host package. We should instead use $(2)_VERSION, i.e. the host package
> version, like is done in inner-generic-package.
> 
> Since luarocks-package doesn't even support a host version, it doens't
> make a whole lot of difference, but let's keep things consistent.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/pkg-luarocks.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 04/25] manual: luarocks: improve tutorial example

[Arnout Vandecappelle]

The license file in a luarocks package is always inside the subdir, so the
example should reflect this.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 docs/manual/adding-packages-luarocks.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/manual/adding-packages-luarocks.txt b/docs/manual/adding-packages-luarocks.txt
index c914238f0b..712c29e9a4 100644
--- a/docs/manual/adding-packages-luarocks.txt
+++ b/docs/manual/adding-packages-luarocks.txt
@@ -23,7 +23,7 @@ with an example :
 10: LUAFOO_BUILD_OPTS += FOO_INCDIR=$(STAGING_DIR)/usr/include
 11: LUAFOO_BUILD_OPTS += FOO_LIBDIR=$(STAGING_DIR)/usr/lib
 12: LUAFOO_LICENSE = luaFoo license
-13: LUAFOO_LICENSE_FILES = COPYING
+13: LUAFOO_LICENSE_FILES = $(LUAFOO_SUBDIR)/COPYING
 14:
 15: $(eval $(luarocks-package))
 ------------------------
-- 
2.11.0

[Buildroot] [PATCH 04/25] manual: luarocks: improve tutorial example

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:26 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> The license file in a luarocks package is always inside the subdir, so the
> example should reflect this.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  docs/manual/adding-packages-luarocks.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 05/25] lpty: remove LPTY_VERSION_UPSTREAM

[Arnout Vandecappelle]

It is not used for anything.

Note that the SUBDIR is NOT the usual lpty-$(LPTY_VERSION_UPSTREAM);
it *does* have the rockspec version in its name.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lpty/lpty.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/lpty/lpty.mk b/package/lpty/lpty.mk
index 963ab61103..5a691256c1 100644
--- a/package/lpty/lpty.mk
+++ b/package/lpty/lpty.mk
@@ -4,8 +4,7 @@
 #
 ################################################################################
 
-LPTY_VERSION_UPSTREAM = 1.0.1
-LPTY_VERSION = $(LPTY_VERSION_UPSTREAM)-1
+LPTY_VERSION = 1.0.1-1
 LPTY_SUBDIR = lpty-$(LPTY_VERSION)
 LPTY_LICENSE = MIT
 LPTY_LICENSE_FILES = $(LPTY_SUBDIR)/doc/LICENSE
-- 
2.11.0

[Buildroot] [PATCH 05/25] lpty: remove LPTY_VERSION_UPSTREAM

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:27 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> It is not used for anything.
> 
> Note that the SUBDIR is NOT the usual lpty-$(LPTY_VERSION_UPSTREAM);
> it *does* have the rockspec version in its name.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/lpty/lpty.mk | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 06/25] lua-periphery: remove LUA_PERIPHERY_VERSION_UPSTREAM

[Arnout Vandecappelle]

It is not used for anything.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-periphery/lua-periphery.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/lua-periphery/lua-periphery.mk b/package/lua-periphery/lua-periphery.mk
index 48eba39289..2c04eede86 100644
--- a/package/lua-periphery/lua-periphery.mk
+++ b/package/lua-periphery/lua-periphery.mk
@@ -4,8 +4,7 @@
 #
 ################################################################################
 
-LUA_PERIPHERY_VERSION_UPSTREAM = 1.0.6
-LUA_PERIPHERY_VERSION = $(LUA_PERIPHERY_VERSION_UPSTREAM)-1
+LUA_PERIPHERY_VERSION = 1.0.6-1
 LUA_PERIPHERY_SUBDIR = lua-periphery
 LUA_PERIPHERY_LICENSE = MIT
 LUA_PERIPHERY_LICENSE_FILES = $(LUA_PERIPHERY_SUBDIR)/LICENSE
-- 
2.11.0

[Buildroot] [PATCH 06/25] lua-periphery: remove LUA_PERIPHERY_VERSION_UPSTREAM

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:28 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> It is not used for anything.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/lua-periphery/lua-periphery.mk | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 07/25] luasec: remove LUASEC_VERSION_UPSTREAM

[Arnout Vandecappelle]

It is not used for anything.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/luasec/luasec.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/luasec/luasec.mk b/package/luasec/luasec.mk
index fd1f1cdbb7..b059e1c6ee 100644
--- a/package/luasec/luasec.mk
+++ b/package/luasec/luasec.mk
@@ -4,8 +4,7 @@
 #
 ################################################################################
 
-LUASEC_VERSION_UPSTREAM = 0.5
-LUASEC_VERSION = $(LUASEC_VERSION_UPSTREAM)-2
+LUASEC_VERSION = 0.5-2
 LUASEC_SUBDIR = luasec
 LUASEC_LICENSE = MIT
 LUASEC_LICENSE_FILES = $(LUASEC_SUBDIR)/LICENSE
-- 
2.11.0

[Buildroot] [PATCH 07/25] luasec: remove LUASEC_VERSION_UPSTREAM

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:29 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> It is not used for anything.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/luasec/luasec.mk | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 08/25] ljlinenoise: remove default definition of PKG_SUBDIR

[Arnout Vandecappelle]

The luarocks infra already provides the correct default value for
PKG_SUBDIR, so it doesn't have to be defined in the .mk file.

Therefore, _VERSION_UPSTREAM doesn't need to be defined either.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/ljlinenoise/ljlinenoise.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/package/ljlinenoise/ljlinenoise.mk b/package/ljlinenoise/ljlinenoise.mk
index aca635885a..edcbdc95df 100644
--- a/package/ljlinenoise/ljlinenoise.mk
+++ b/package/ljlinenoise/ljlinenoise.mk
@@ -4,9 +4,7 @@
 #
 ################################################################################
 
-LJLINENOISE_VERSION_UPSTREAM = 0.1.2
-LJLINENOISE_VERSION = $(LJLINENOISE_VERSION_UPSTREAM)-1
-LJLINENOISE_SUBDIR = ljlinenoise-$(LJLINENOISE_VERSION_UPSTREAM)
+LJLINENOISE_VERSION = 0.1.2-1
 LJLINENOISE_LICENSE = MIT
 LJLINENOISE_LICENSE_FILES = $(LJLINENOISE_SUBDIR)/COPYRIGHT
 
-- 
2.11.0

[Buildroot] [PATCH 08/25] ljlinenoise: remove default definition of PKG_SUBDIR

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:30 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> The luarocks infra already provides the correct default value for
> PKG_SUBDIR, so it doesn't have to be defined in the .mk file.
> 
> Therefore, _VERSION_UPSTREAM doesn't need to be defined either.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/ljlinenoise/ljlinenoise.mk | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Patches 08/25 to 12/25 included applied to master. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 09/25] lua-csnappy: remove default definition of PKG_SUBDIR

[Arnout Vandecappelle]

The luarocks infra already provides the correct default value for
PKG_SUBDIR, so it doesn't have to be defined in the .mk file.

Therefore, _VERSION_UPSTREAM doesn't need to be defined either.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-csnappy/lua-csnappy.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/package/lua-csnappy/lua-csnappy.mk b/package/lua-csnappy/lua-csnappy.mk
index 073925917d..1867b60e7a 100644
--- a/package/lua-csnappy/lua-csnappy.mk
+++ b/package/lua-csnappy/lua-csnappy.mk
@@ -4,9 +4,7 @@
 #
 ################################################################################
 
-LUA_CSNAPPY_VERSION_UPSTREAM = 0.1.4
-LUA_CSNAPPY_VERSION = $(LUA_CSNAPPY_VERSION_UPSTREAM)-1
-LUA_CSNAPPY_SUBDIR = lua-csnappy-$(LUA_CSNAPPY_VERSION_UPSTREAM)
+LUA_CSNAPPY_VERSION = 0.1.4-1
 LUA_CSNAPPY_LICENSE = BSD-3c
 LUA_CSNAPPY_LICENSE_FILES = $(LUA_CSNAPPY_SUBDIR)/COPYRIGHT
 
-- 
2.11.0

[Buildroot] [PATCH 10/25] lua-iconv: remove default definition of PKG_SUBDIR

[Arnout Vandecappelle]

The luarocks infra already provides the correct default value for
PKG_SUBDIR, so it doesn't have to be defined in the .mk file.

Therefore, _VERSION_UPSTREAM doesn't need to be defined either.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-iconv/lua-iconv.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/package/lua-iconv/lua-iconv.mk b/package/lua-iconv/lua-iconv.mk
index f0afa2b85e..dd7533af59 100644
--- a/package/lua-iconv/lua-iconv.mk
+++ b/package/lua-iconv/lua-iconv.mk
@@ -4,9 +4,7 @@
 #
 ################################################################################
 
-LUA_ICONV_VERSION_UPSTREAM = 7
-LUA_ICONV_VERSION = $(LUA_ICONV_VERSION_UPSTREAM)-1
-LUA_ICONV_SUBDIR  = lua-iconv-$(LUA_ICONV_VERSION_UPSTREAM)
+LUA_ICONV_VERSION = 7-1
 LUA_ICONV_DEPENDENCIES = $(if $(BR2_PACKAGE_LIBICONV),libiconv)
 LUA_ICONV_LICENSE = MIT
 LUA_ICONV_LICENSE_FILES = $(LUA_ICONV_SUBDIR)/COPYING
-- 
2.11.0

[Buildroot] [PATCH 11/25] luacrypto: remove default definition of PKG_SUBDIR

[Arnout Vandecappelle]

The luarocks infra already provides the correct default value for
PKG_SUBDIR, so it doesn't have to be defined in the .mk file.

Therefore, _VERSION_UPSTREAM doesn't need to be defined either.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/luacrypto/luacrypto.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/package/luacrypto/luacrypto.mk b/package/luacrypto/luacrypto.mk
index b0e972c629..b6dbb9999f 100644
--- a/package/luacrypto/luacrypto.mk
+++ b/package/luacrypto/luacrypto.mk
@@ -4,9 +4,7 @@
 #
 ################################################################################
 
-LUACRYPTO_VERSION_UPSTREAM = 0.3.2
-LUACRYPTO_VERSION = $(LUACRYPTO_VERSION_UPSTREAM)-1
-LUACRYPTO_SUBDIR = luacrypto-$(LUACRYPTO_VERSION_UPSTREAM)
+LUACRYPTO_VERSION = 0.3.2-1
 LUACRYPTO_LICENSE = MIT
 LUACRYPTO_LICENSE_FILES = $(LUACRYPTO_SUBDIR)/COPYING
 LUACRYPTO_DEPENDENCIES = openssl
-- 
2.11.0

[Buildroot] [PATCH 12/25] lunit: remove default definition of PKG_SUBDIR

[Arnout Vandecappelle]

The luarocks infra already provides the correct default value for
PKG_SUBDIR, so it doesn't have to be defined in the .mk file.

Therefore, _VERSION_UPSTREAM doesn't need to be defined either.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lunit/lunit.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/package/lunit/lunit.mk b/package/lunit/lunit.mk
index 3c557f8748..34e22db757 100644
--- a/package/lunit/lunit.mk
+++ b/package/lunit/lunit.mk
@@ -4,9 +4,7 @@
 #
 ################################################################################
 
-LUNIT_VERSION_UPSTREAM = 0.5
-LUNIT_VERSION = $(LUNIT_VERSION_UPSTREAM)-2
-LUNIT_SUBDIR = lunit-$(LUNIT_VERSION_UPSTREAM)
+LUNIT_VERSION = 0.5-2
 LUNIT_LICENSE = MIT
 LUNIT_LICENSE_FILES = $(LUNIT_SUBDIR)/LICENSE
 
-- 
2.11.0

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Arnout Vandecappelle]

We have decided that lua packages should have a name that starts with
lua (like is the case for python and perl). However, we're not going to
rename all the existing lua packages that don't start with lua. This
makes it unclear for people adding packages how they should name the
package, so add a comment to package/Config.in to explain it.

It's rather terse but it gets the message across.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/Config.in b/package/Config.in
index cf9c401af0..efcde1fdd2 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -521,6 +521,8 @@ endif
 if BR2_PACKAGE_HAS_LUAINTERPRETER && !BR2_STATIC_LIBS
 # lua modules are dynamically loaded, so not available on static builds
 menu "Lua libraries/modules"
+# When adding lua packages, make sure the name start with "lua".
+# Many packages currently don't, but that's historical accident.
 	source "package/argparse/Config.in"
 	source "package/cgilua/Config.in"
 	source "package/copas/Config.in"
-- 
2.11.0

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:35 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> We have decided that lua packages should have a name that starts with
> lua (like is the case for python and perl). However, we're not going to
> rename all the existing lua packages that don't start with lua. This
> makes it unclear for people adding packages how they should name the
> package, so add a comment to package/Config.in to explain it.

Should we require "lua" as a prefix or "lua-" ? For Perl and Python, we
use "perl-" and "python-" respectively.

We currently have 10 packages that start with "lua-", and 12 that start
with just "lua".

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Arnout Vandecappelle]

On 02-03-17 22:50, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 23 Feb 2017 18:00:35 +0100, Arnout Vandecappelle
> (Essensium/Mind) wrote:
>> We have decided that lua packages should have a name that starts with
>> lua (like is the case for python and perl). However, we're not going to
>> rename all the existing lua packages that don't start with lua. This
>> makes it unclear for people adding packages how they should name the
>> package, so add a comment to package/Config.in to explain it.
> 
> Should we require "lua" as a prefix or "lua-" ? For Perl and Python, we
> use "perl-" and "python-" respectively.
> 
> We currently have 10 packages that start with "lua-", and 12 that start
> with just "lua".

 The problem is that we want to use upstream names. The upstream name of
luaposix is luaposix. We certainly don't want to change that into lua-posix, and
making it lua-luaposix would be weird as well. Note that Debian does call it
lua-posix. So to use the lua-posix package, you have to do 'require "luaposix"',
which makes little sense IMHO.

 For me, the important thing is that I can see in the package directory which
packages are lua-related. I'm not really bothered with seeing a mix of lua-foo
and luabar.

 Perl is different because module names (almost?) never start with Perl. Python
is different because package names sometimes are like pyfoo, but never
python-foo, and we have indeed chosen to make it python-pyfoo.

 If people think it would be better for consistency to have lua-luafoo, I can
live with that (just 3 letters more). But do keep in mind that we have already
forsaken consistency because of the historical discrepancy.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Thomas Petazzoni]

Hello,

On Thu, 2 Mar 2017 23:19:50 +0100, Arnout Vandecappelle wrote:

>  The problem is that we want to use upstream names. The upstream name of
> luaposix is luaposix. We certainly don't want to change that into lua-posix, and
> making it lua-luaposix would be weird as well. Note that Debian does call it
> lua-posix. So to use the lua-posix package, you have to do 'require "luaposix"',
> which makes little sense IMHO.
> 
>  For me, the important thing is that I can see in the package directory which
> packages are lua-related. I'm not really bothered with seeing a mix of lua-foo
> and luabar.
> 
>  Perl is different because module names (almost?) never start with Perl. Python
> is different because package names sometimes are like pyfoo, but never
> python-foo, and we have indeed chosen to make it python-pyfoo.
> 
>  If people think it would be better for consistency to have lua-luafoo, I can
> live with that (just 3 letters more). But do keep in mind that we have already
> forsaken consistency because of the historical discrepancy.

Fair enough, but then I'd like that the rule be:

 * If the upstream package name is luafoo, then it should be luafoo in
   Buildroot.

 * If the upstream package name is foo, then it should be lua-foo in
   Buildroot.

Does that sound OK?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Arnout Vandecappelle]

On 02-03-17 23:22, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 2 Mar 2017 23:19:50 +0100, Arnout Vandecappelle wrote:
> 
>>  The problem is that we want to use upstream names. The upstream name of
>> luaposix is luaposix. We certainly don't want to change that into lua-posix, and
>> making it lua-luaposix would be weird as well. Note that Debian does call it
>> lua-posix. So to use the lua-posix package, you have to do 'require "luaposix"',
>> which makes little sense IMHO.
>>
>>  For me, the important thing is that I can see in the package directory which
>> packages are lua-related. I'm not really bothered with seeing a mix of lua-foo
>> and luabar.
>>
>>  Perl is different because module names (almost?) never start with Perl. Python
>> is different because package names sometimes are like pyfoo, but never
>> python-foo, and we have indeed chosen to make it python-pyfoo.
>>
>>  If people think it would be better for consistency to have lua-luafoo, I can
>> live with that (just 3 letters more). But do keep in mind that we have already
>> forsaken consistency because of the historical discrepancy.
> 
> Fair enough, but then I'd like that the rule be:
> 
>  * If the upstream package name is luafoo, then it should be luafoo in
>    Buildroot.
> 
>  * If the upstream package name is foo, then it should be lua-foo in
>    Buildroot.
> 
> Does that sound OK?

 That's exactly what I meant. Should I update the Config.in?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 13/25] package/Config.in: explain that lua package names should start with lua

[Thomas Petazzoni]

Hello,

On Thu, 2 Mar 2017 23:26:16 +0100, Arnout Vandecappelle wrote:

> > Fair enough, but then I'd like that the rule be:
> > 
> >  * If the upstream package name is luafoo, then it should be luafoo in
> >    Buildroot.
> > 
> >  * If the upstream package name is foo, then it should be lua-foo in
> >    Buildroot.
> > 
> > Does that sound OK?  
> 
>  That's exactly what I meant. Should I update the Config.in?

Yes, would be nice. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Arnout Vandecappelle]

This package is needed to make luaposix work.

The upstream name is just "bit32", but the luarocks infra doesn't
support an upstream name different from the Buildroot name. We therefore
have to explicitly set all variables and we need custom extract
commands.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/Config.in                |  1 +
 package/lua-bit32/Config.in      |  9 +++++++++
 package/lua-bit32/lua-bit32.hash |  2 ++
 package/lua-bit32/lua-bit32.mk   | 20 ++++++++++++++++++++
 4 files changed, 32 insertions(+)
 create mode 100644 package/lua-bit32/Config.in
 create mode 100644 package/lua-bit32/lua-bit32.hash
 create mode 100644 package/lua-bit32/lua-bit32.mk

diff --git a/package/Config.in b/package/Config.in
index efcde1fdd2..ca24bb20f9 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -536,6 +536,7 @@ menu "Lua libraries/modules"
 	source "package/lpty/Config.in"
 	source "package/lrandom/Config.in"
 	source "package/lsqlite3/Config.in"
+	source "package/lua-bit32/Config.in"
 	source "package/lua-cjson/Config.in"
 	source "package/lua-coat/Config.in"
 	source "package/lua-coatpersistent/Config.in"
diff --git a/package/lua-bit32/Config.in b/package/lua-bit32/Config.in
new file mode 100644
index 0000000000..6acecf0552
--- /dev/null
+++ b/package/lua-bit32/Config.in
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_LUA_BIT32
+	bool "lua-bit32"
+	depends on BR2_PACKAGE_HAS_LUAINTERPRETER
+	help
+	  bit32 is the native Lua 5.2 bit manipulation library, in the
+	  version from Lua 5.3; it is compatible with Lua 5.1, 5.2 and
+	  5.3.
+
+	  http://www.lua.org/manual/5.2/manual.html#6.7
diff --git a/package/lua-bit32/lua-bit32.hash b/package/lua-bit32/lua-bit32.hash
new file mode 100644
index 0000000000..21dbd05318
--- /dev/null
+++ b/package/lua-bit32/lua-bit32.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256  fe7bc70d1e48183d95ccfb6741e70a676283075173122cb161303d77059b27a6  bit32-5.3.0-1.src.rock
diff --git a/package/lua-bit32/lua-bit32.mk b/package/lua-bit32/lua-bit32.mk
new file mode 100644
index 0000000000..8304d6eaec
--- /dev/null
+++ b/package/lua-bit32/lua-bit32.mk
@@ -0,0 +1,20 @@
+################################################################################
+#
+# lua-bit32
+#
+################################################################################
+
+LUA_BIT32_VERSION = 5.3.0-1
+LUA_BIT32_SUBDIR = lua-compat-5.2
+LUA_BIT32_ROCKSPEC = bit32-$(LUA_BIT32_VERSION).rockspec
+LUA_BIT32_SOURCE = bit32-$(LUA_BIT32_VERSION).src.rock
+LUA_BIT32_LICENSE = MIT
+LUA_BIT32_LICENSE_FILES = $(LUA_BIT32_SUBDIR)/LICENSE
+
+define LUA_BIT32_EXTRACT_CMDS
+        cd $(LUA_BIT32_DIR) && \
+                $(LUAROCKS_RUN_ENV) $(LUAROCKS_RUN_CMD) unpack --force $(DL_DIR)/$(LUA_BIT32_SOURCE) && \
+		mv bit32-$(LUA_BIT32_VERSION)/* .
+endef
+
+$(eval $(luarocks-package))
-- 
2.11.0

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:36 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> This package is needed to make luaposix work.
> 
> The upstream name is just "bit32", but the luarocks infra doesn't
> support an upstream name different from the Buildroot name. We therefore
> have to explicitly set all variables and we need custom extract
> commands.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/Config.in                |  1 +
>  package/lua-bit32/Config.in      |  9 +++++++++
>  package/lua-bit32/lua-bit32.hash |  2 ++
>  package/lua-bit32/lua-bit32.mk   | 20 ++++++++++++++++++++

You forgot to add yourself to the DEVELOPERS file, so I did this
addition.

> +config BR2_PACKAGE_LUA_BIT32
> +	bool "lua-bit32"
> +	depends on BR2_PACKAGE_HAS_LUAINTERPRETER

This "depends on" is not needed, since lua-bit32/Config.in is anyway
only included if BR2_PACKAGE_HAS_LUAINTERPRETER=y.

I've fixed up those two issues and applied to master. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Arnout Vandecappelle]

On 02-03-17 22:54, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 23 Feb 2017 18:00:36 +0100, Arnout Vandecappelle
> (Essensium/Mind) wrote:
>> This package is needed to make luaposix work.
>>
>> The upstream name is just "bit32", but the luarocks infra doesn't
>> support an upstream name different from the Buildroot name. We therefore
>> have to explicitly set all variables and we need custom extract
>> commands.
>>
>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>> ---
>>  package/Config.in                |  1 +
>>  package/lua-bit32/Config.in      |  9 +++++++++
>>  package/lua-bit32/lua-bit32.hash |  2 ++
>>  package/lua-bit32/lua-bit32.mk   | 20 ++++++++++++++++++++
> 
> You forgot to add yourself to the DEVELOPERS file, so I did this
> addition.

 Well, like most of my packages it's a one-shot rather than something I actively
use, so I tend not to add myself to the DEVELOPERS file. If you do that, you
could instead just add me for all orphaned packages. Hm, would that be a useful
feature? A last-resort developer?


>> +config BR2_PACKAGE_LUA_BIT32
>> +	bool "lua-bit32"
>> +	depends on BR2_PACKAGE_HAS_LUAINTERPRETER
> 
> This "depends on" is not needed, since lua-bit32/Config.in is anyway
> only included if BR2_PACKAGE_HAS_LUAINTERPRETER=y.

 Oops, I just copied it from a BR2_EXTERNAL :-)


 Regards,
 Arnout


> I've fixed up those two issues and applied to master. Thanks!
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Thomas Petazzoni]

Hello,

On Thu, 2 Mar 2017 23:24:31 +0100, Arnout Vandecappelle wrote:

>  Well, like most of my packages it's a one-shot rather than something I actively
> use, so I tend not to add myself to the DEVELOPERS file.

Hum, ok, but then who will take care of fixing this package when/if it
breaks?

> If you do that, you could instead just add me for all orphaned
> packages. Hm, would that be a useful feature? A last-resort developer?

Is this really useful? You're part of the core developers, so I'm sure
you regularly look at the autobuild results e-mail that is sent on the
mailing list.

Or do you really want to implement a feature where build failures for
packages not affected to anyone are sent to you? It's not too difficult
to do.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Arnout Vandecappelle]

On 17-03-17 17:14, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 2 Mar 2017 23:24:31 +0100, Arnout Vandecappelle wrote:
> 
>>  Well, like most of my packages it's a one-shot rather than something I actively
>> use, so I tend not to add myself to the DEVELOPERS file.
> 
> Hum, ok, but then who will take care of fixing this package when/if it
> breaks?
> 
>> If you do that, you could instead just add me for all orphaned
>> packages. Hm, would that be a useful feature? A last-resort developer?
> 
> Is this really useful? You're part of the core developers, so I'm sure
> you regularly look at the autobuild results e-mail that is sent on the
> mailing list.

 I wouldn't say "regularly". I do look occasionally. I would pay a lot more
attention if I got an occasional personal mail.

 That is, of course, assuming that there are no longer daily failures of
orphaned packages. Otherwise it doesn't make a lot of sense.

 Regards,
 Arnout

> 
> Or do you really want to implement a feature where build failures for
> packages not affected to anyone are sent to you? It's not too difficult
> to do.
> 
> Best regards,
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Thomas Petazzoni]

Hello,

On Fri, 17 Mar 2017 23:17:25 +0100, Arnout Vandecappelle wrote:

>  I wouldn't say "regularly". I do look occasionally. I would pay a lot more
> attention if I got an occasional personal mail.

OK. But it probably wouldn't be "occasional". From a quick look, we
have currently ~500 packages not associated to a developer, so about
1/4 of all packages we have.

But currently, we indeed don't notice when there is a build failure on
a package that is orphaned. Having at least you notified on orphaned
packages build failures would raise the attention on this or that
package being orphaned, and then we can see what needs to be done: find
if someone has been active on that package recently and is willing to
adopt it, remove the package if it's too broken and nobody cares, etc.

What do you think?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 14/25] lua-bit32: new package

[Arnout Vandecappelle]

On 18-03-17 11:42, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 17 Mar 2017 23:17:25 +0100, Arnout Vandecappelle wrote:
> 
>>  I wouldn't say "regularly". I do look occasionally. I would pay a lot more
>> attention if I got an occasional personal mail.
> 
> OK. But it probably wouldn't be "occasional". From a quick look, we
> have currently ~500 packages not associated to a developer, so about
> 1/4 of all packages we have.
> 
> But currently, we indeed don't notice when there is a build failure on
> a package that is orphaned. Having at least you notified on orphaned
> packages build failures would raise the attention on this or that
> package being orphaned, and then we can see what needs to be done: find
> if someone has been active on that package recently and is willing to
> adopt it, remove the package if it's too broken and nobody cares, etc.
> 
> What do you think?

 Sounds good! Will you work on the getdeveloper script?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Orphan package notification

[Thomas Petazzoni]

Hello,

On Sat, 18 Mar 2017 14:17:55 +0100, Arnout Vandecappelle wrote:

>  Sounds good! Will you work on the getdeveloper script?

It's implemented and pushed. However, it's not in the getdeveloper
script, but instead in the daily-mail script, which is located in the
buildroot-test Git repository.

The commit log gives the details:

    daily-mail: implement orphan package notification
    
    This commit improves the notification for orphan packages, in two ways:
    
     - When a package is not associated to a developer in the DEVELOPERS
       file, Arnout is the fallback developer, and will receive
       notifications related to this package each day. In order to help
       Arnout distinguish his own packages from the orphan package a new
       column has been added in the report, which says "ORPH" if the package
       is orphaned.
    
     - The daily mail sent to the mailing list with all build failures will
       now also have the "ORPH" column, for orphan packages.
    
    This will all hopefully help us notice which packages are orphan and
    causing build issues, and see what we should do about them.

So the daily mail sent to the mailing list will now look like this:

      x86_64 |                     gdb-7.11.1 | NOK | http://autobuild.buildroot.net/results/ed8726d4cd536b81a4bca4c3d9056ad4ff2658db | ORPH
         arm |                     git-2.12.0 | NOK | http://autobuild.buildroot.net/results/561d8bfd9a98e0fdbae0e4bdf21aeea297fbf876 |     
microblazeel |                nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/240cfb0497b1dd7b5b33b8f64635cca435d49f05 | ORPH
         arm |                qt5webkit-5.8.0 | NOK | http://autobuild.buildroot.net/results/3792695078cf3fe7bac255a42c88d4540b5b275f |     
         arm |                   trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/94b4281bc10856d56a7d4abcf269cb5dd584e34e |     
      xtensa |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/5828f903e4f6f548b1f537467603ce5194c95395 | ORPH
 powerpc64le |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/58422d42f8b5543539526f967d0896e4d5371e7e | ORPH
    mips64el |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/42f7c13890c4f935834c16992a6fe00b9f0e15b9 | ORPH
      xtensa |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/3a13ee820973d3cba436e7c35e1f08e90b344b12 | ORPH

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Orphan package notification

[Arnout Vandecappelle]

On 18-03-17 14:49, Thomas Petazzoni wrote:
> Hello,
> 
> On Sat, 18 Mar 2017 14:17:55 +0100, Arnout Vandecappelle wrote:
> 
>>  Sounds good! Will you work on the getdeveloper script?
> 
> It's implemented and pushed. However, it's not in the getdeveloper
> script, but instead in the daily-mail script, which is located in the
> buildroot-test Git repository.
> 
> The commit log gives the details:
> 
>     daily-mail: implement orphan package notification
>     
>     This commit improves the notification for orphan packages, in two ways:
>     
>      - When a package is not associated to a developer in the DEVELOPERS
>        file, Arnout is the fallback developer, and will receive
>        notifications related to this package each day. In order to help
>        Arnout distinguish his own packages from the orphan package a new
>        column has been added in the report, which says "ORPH" if the package
>        is orphaned.

 Wow, so I'm hardcoded in the Buildroot infra! Cool! :-)

 Regards,
 Arnout

>     
>      - The daily mail sent to the mailing list with all build failures will
>        now also have the "ORPH" column, for orphan packages.
>     
>     This will all hopefully help us notice which packages are orphan and
>     causing build issues, and see what we should do about them.
> 
> So the daily mail sent to the mailing list will now look like this:
> 
>       x86_64 |                     gdb-7.11.1 | NOK | http://autobuild.buildroot.net/results/ed8726d4cd536b81a4bca4c3d9056ad4ff2658db | ORPH
>          arm |                     git-2.12.0 | NOK | http://autobuild.buildroot.net/results/561d8bfd9a98e0fdbae0e4bdf21aeea297fbf876 |     
> microblazeel |                nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/240cfb0497b1dd7b5b33b8f64635cca435d49f05 | ORPH
>          arm |                qt5webkit-5.8.0 | NOK | http://autobuild.buildroot.net/results/3792695078cf3fe7bac255a42c88d4540b5b275f |     
>          arm |                   trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/94b4281bc10856d56a7d4abcf269cb5dd584e34e |     
>       xtensa |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/5828f903e4f6f548b1f537467603ce5194c95395 | ORPH
>  powerpc64le |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/58422d42f8b5543539526f967d0896e4d5371e7e | ORPH
>     mips64el |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/42f7c13890c4f935834c16992a6fe00b9f0e15b9 | ORPH
>       xtensa |            uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/3a13ee820973d3cba436e7c35e1f08e90b344b12 | ORPH
> 
> Best regards,
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 15/25] luaposix: fix runtime by selecting "bit32" instead of "bitop"

[Arnout Vandecappelle]

Since the bump of luaposix to 33.4.0, it doesn't work anymore at
runtime with LuaJIT or Lua 5.1. This can be tested with the following
defconfig:

BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_LUA_5_1=y
BR2_PACKAGE_LUAPOSIX=y

/usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
...

In older luaposix versions, it would try to load the 'bit' instead of
'bit32' module if LUAVER == 5.1. However, this feature was removed in
33.4.0.

So instead of adding a runtime dependency on luabitop, depend on
lua-bit32.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/luaposix/Config.in | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/luaposix/Config.in b/package/luaposix/Config.in
index 9707cdeeff..91abcb9e32 100644
--- a/package/luaposix/Config.in
+++ b/package/luaposix/Config.in
@@ -1,8 +1,10 @@
 config BR2_PACKAGE_LUAPOSIX
 	bool "luaposix"
 	depends on BR2_PACKAGE_HAS_LUAINTERPRETER
-	select BR2_PACKAGE_LUABITOP if BR2_PACKAGE_LUA_5_1
-	# LuaBitOp is already included in LuaJIT
+	# "bit32" is included in Lua 5.2+. luajit has an equivalent
+	# "bit" module, but since it has a different name, luaposix
+	# doesn't find it.
+	select BR2_PACKAGE_LUA_BIT32 if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
 	help
 	  This is a POSIX binding for LuaJIT, Lua 5.1, 5.2 and 5.3;
 	  like most libraries it simply binds to C APIs on the
-- 
2.11.0

[Buildroot] [PATCH 15/25] luaposix: fix runtime by selecting "bit32" instead of "bitop"

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:37 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Since the bump of luaposix to 33.4.0, it doesn't work anymore at
> runtime with LuaJIT or Lua 5.1. This can be tested with the following
> defconfig:
> 
> BR2_x86_64=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_PACKAGE_LUA=y
> BR2_PACKAGE_LUA_5_1=y
> BR2_PACKAGE_LUAPOSIX=y
> 
> /usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
> ...

This smells like an excellent candidate for a runtime test in the test
infrastructure, no? :-)

> In older luaposix versions, it would try to load the 'bit' instead of
> 'bit32' module if LUAVER == 5.1. However, this feature was removed in
> 33.4.0.
> 
> So instead of adding a runtime dependency on luabitop, depend on
> lua-bit32.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Applied, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 15/25] luaposix: fix runtime by selecting "bit32" instead of "bitop"

[Arnout Vandecappelle]

On 02-03-17 22:58, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 23 Feb 2017 18:00:37 +0100, Arnout Vandecappelle
> (Essensium/Mind) wrote:
>> Since the bump of luaposix to 33.4.0, it doesn't work anymore at
>> runtime with LuaJIT or Lua 5.1. This can be tested with the following
>> defconfig:
>>
>> BR2_x86_64=y
>> BR2_TOOLCHAIN_EXTERNAL=y
>> BR2_PACKAGE_LUA=y
>> BR2_PACKAGE_LUA_5_1=y
>> BR2_PACKAGE_LUAPOSIX=y
>>
>> /usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
>> ...
> 
> This smells like an excellent candidate for a runtime test in the test
> infrastructure, no? :-)

 Since the runtime test infra hasn't been committed yet, I didn't do that :-)

 Regards,
 Arnout

> 
>> In older luaposix versions, it would try to load the 'bit' instead of
>> 'bit32' module if LUAVER == 5.1. However, this feature was removed in
>> 33.4.0.
>>
>> So instead of adding a runtime dependency on luabitop, depend on
>> lua-bit32.
>>
>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> 
> Applied, thanks!
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 15/25] luaposix: fix runtime by selecting "bit32" instead of "bitop"

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:37 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Since the bump of luaposix to 33.4.0, it doesn't work anymore at
> runtime with LuaJIT or Lua 5.1. This can be tested with the following
> defconfig:
> 
> BR2_x86_64=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_PACKAGE_LUA=y
> BR2_PACKAGE_LUA_5_1=y
> BR2_PACKAGE_LUAPOSIX=y
> 
> /usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
> ...
> 
> In older luaposix versions, it would try to load the 'bit' instead of
> 'bit32' module if LUAVER == 5.1. However, this feature was removed in
> 33.4.0.
> 
> So instead of adding a runtime dependency on luabitop, depend on
> lua-bit32.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Now that I think more about this, I believe PATCH 14/25 and 15/25
should be merged into the LTS branch, since they fix a runtime issue
with Lua.

I believe even though they show up as patches 14 and 15 in the series,
they don't depend on any of the previous patches.

Peter, what do you think?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 15/25] luaposix: fix runtime by selecting "bit32" instead of "bitop"

[Arnout Vandecappelle]

On 02-03-17 23:28, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 23 Feb 2017 18:00:37 +0100, Arnout Vandecappelle
> (Essensium/Mind) wrote:
>> Since the bump of luaposix to 33.4.0, it doesn't work anymore at
>> runtime with LuaJIT or Lua 5.1. This can be tested with the following
>> defconfig:
>>
>> BR2_x86_64=y
>> BR2_TOOLCHAIN_EXTERNAL=y
>> BR2_PACKAGE_LUA=y
>> BR2_PACKAGE_LUA_5_1=y
>> BR2_PACKAGE_LUAPOSIX=y
>>
>> /usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
>> ...
>>
>> In older luaposix versions, it would try to load the 'bit' instead of
>> 'bit32' module if LUAVER == 5.1. However, this feature was removed in
>> 33.4.0.
>>
>> So instead of adding a runtime dependency on luabitop, depend on
>> lua-bit32.
>>
>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> 
> Now that I think more about this, I believe PATCH 14/25 and 15/25
> should be merged into the LTS branch, since they fix a runtime issue
> with Lua.
> 
> I believe even though they show up as patches 14 and 15 in the series,
> they don't depend on any of the previous patches.

 Indeed, I intentionally created the lua-bit32 package first without all the
niceties in the luarocks-package infra, and then factored the complexity in the
infra, to make it easy to apply only the fix and not the refactoring.

 Actually, for my customer I just applied the lua-bit32 patch (in a
BR2_EXTERNAL) and it is selected manually, so I am sure it works like that.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 16/25] luarocks-package: rework extraction

[Arnout Vandecappelle]

The luarocks package infra extracts the package directly under
$(BUILD_DIR), because the contents are always in a subdirectory name
<pkg>-<version>. However, this only works when the upstream package name
is the same as the Buildroot package name.

Instead, we can rely on the fixed structure of a .src.rock: it always
contains the source subdirectory in a directory called foo, where foo
is the basename of the .src.rock file. Therefore, we can extract into
a subdirectory of $($(PKG)_DIR), then move its contents up two
directory levels.

Note, we can't extract directly into $($(PKG)_DIR) because it's
possible that $($(PKG)_SUBDIR) == <pkg>-<version>. In that case, we
would try to move the directory unto itself and get "Directory not
empty". This is the case e.g. for the lpty package.

Two alternatives were considered but are more complicated:
- instead of using wildcards for the move, we could have used
  <.src.rock basename>/$($(PKG)_SUBDIR);
- instead of extracting with luarocks, we could use unzip to extract
  (the .src.rock is a ZIP file), but then we also have to move the
  .rockspec into the subdir. In addition, sometimes the ZIP file
  contains a tarball instead of the extracted source.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/pkg-luarocks.mk | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/package/pkg-luarocks.mk b/package/pkg-luarocks.mk
index aa83e74a0e..08ea9b801a 100644
--- a/package/pkg-luarocks.mk
+++ b/package/pkg-luarocks.mk
@@ -44,12 +44,15 @@ $(2)_SITE		?= $$(call qstrip,$$(BR2_LUAROCKS_MIRROR))
 $(2)_DEPENDENCIES	+= host-luarocks luainterpreter
 
 #
-# Extract step
+# Extract step. Extract into a temporary dir and move the relevant part to the
+# source dir.
 #
 ifndef $(2)_EXTRACT_CMDS
 define $(2)_EXTRACT_CMDS
-	cd $$($(2)_DIR)/.. && \
+	mkdir -p $$($(2)_DIR)/luarocks-extract
+	cd $$($(2)_DIR)/luarocks-extract && \
 		$$(LUAROCKS_RUN_ENV) $$(LUAROCKS_RUN_CMD) unpack --force $$(DL_DIR)/$$($(2)_SOURCE)
+	mv $$($(2)_DIR)/luarocks-extract/*/* $$($(2)_DIR)
 endef
 endif
 
-- 
2.11.0

[Buildroot] [PATCH 16/25] luarocks-package: rework extraction

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:38 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> The luarocks package infra extracts the package directly under
> $(BUILD_DIR), because the contents are always in a subdirectory name
> <pkg>-<version>. However, this only works when the upstream package name
> is the same as the Buildroot package name.
> 
> Instead, we can rely on the fixed structure of a .src.rock: it always
> contains the source subdirectory in a directory called foo, where foo
> is the basename of the .src.rock file. Therefore, we can extract into
> a subdirectory of $($(PKG)_DIR), then move its contents up two
> directory levels.
> 
> Note, we can't extract directly into $($(PKG)_DIR) because it's
> possible that $($(PKG)_SUBDIR) == <pkg>-<version>. In that case, we
> would try to move the directory unto itself and get "Directory not
> empty". This is the case e.g. for the lpty package.
> 
> Two alternatives were considered but are more complicated:
> - instead of using wildcards for the move, we could have used
>   <.src.rock basename>/$($(PKG)_SUBDIR);
> - instead of extracting with luarocks, we could use unzip to extract
>   (the .src.rock is a ZIP file), but then we also have to move the
>   .rockspec into the subdir. In addition, sometimes the ZIP file
>   contains a tarball instead of the extracted source.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/pkg-luarocks.mk | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 17/25] lua-bit32: remove custom extract commands

[Arnout Vandecappelle]

With the reworked luarocks extraction, they are no longer needed.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-bit32/lua-bit32.mk | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/package/lua-bit32/lua-bit32.mk b/package/lua-bit32/lua-bit32.mk
index 8304d6eaec..f4090c703a 100644
--- a/package/lua-bit32/lua-bit32.mk
+++ b/package/lua-bit32/lua-bit32.mk
@@ -11,10 +11,4 @@ LUA_BIT32_SOURCE = bit32-$(LUA_BIT32_VERSION).src.rock
 LUA_BIT32_LICENSE = MIT
 LUA_BIT32_LICENSE_FILES = $(LUA_BIT32_SUBDIR)/LICENSE
 
-define LUA_BIT32_EXTRACT_CMDS
-        cd $(LUA_BIT32_DIR) && \
-                $(LUAROCKS_RUN_ENV) $(LUAROCKS_RUN_CMD) unpack --force $(DL_DIR)/$(LUA_BIT32_SOURCE) && \
-		mv bit32-$(LUA_BIT32_VERSION)/* .
-endef
-
 $(eval $(luarocks-package))
-- 
2.11.0

[Buildroot] [PATCH 17/25] lua-bit32: remove custom extract commands

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:39 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> With the reworked luarocks extraction, they are no longer needed.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/lua-bit32/lua-bit32.mk | 6 ------
>  1 file changed, 6 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 18/25] luarocks-package: introduce PKG_NAME_UPSTREAM

[Arnout Vandecappelle]

Since we now require Lua package names to start with "lua", it is likely
that the Buildroot name is different from the upstream LuaRocks name.
Add a feature to the luarocks-package infra that makes it easier to
handle this situation: the package can explicitly specify the upstream
name in PKG_NAME_UPSTREAM, and that name will be used in PKG_ROCKSPEC,
PKG_SOURCE and PKG_SUBDIR.

Add an explanation of this feature to the manual. To make the example
relevant, it is changed to lua-foo, where the upstream name is plain
foo. To avoid confusion with the dependency on a native library, that
dependency is renamed to bar.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
The change in the manual should perhaps have been a separate commit, but
this series is already long enough as it is :-)
---
 docs/manual/adding-packages-luarocks.txt | 54 +++++++++++++++++++-------------
 package/pkg-luarocks.mk                  |  7 +++--
 2 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/docs/manual/adding-packages-luarocks.txt b/docs/manual/adding-packages-luarocks.txt
index 712c29e9a4..4965a209ae 100644
--- a/docs/manual/adding-packages-luarocks.txt
+++ b/docs/manual/adding-packages-luarocks.txt
@@ -13,34 +13,40 @@ with an example :
 ------------------------
 01: ################################################################################
 02: #
-03: # luafoo
+03: # lua-foo
 04: #
 05: ################################################################################
 06:
-07: LUAFOO_VERSION = 1.0.2-1
-08: LUAFOO_DEPENDENCIES = foo
-09:
-10: LUAFOO_BUILD_OPTS += FOO_INCDIR=$(STAGING_DIR)/usr/include
-11: LUAFOO_BUILD_OPTS += FOO_LIBDIR=$(STAGING_DIR)/usr/lib
-12: LUAFOO_LICENSE = luaFoo license
-13: LUAFOO_LICENSE_FILES = $(LUAFOO_SUBDIR)/COPYING
-14:
-15: $(eval $(luarocks-package))
+07: LUA_FOO_VERSION = 1.0.2-1
+08: LUA_FOO_NAME_UPSTREAM = foo
+09: LUA_FOO_DEPENDENCIES = bar
+10:
+11: LUA_FOO_BUILD_OPTS += BAR_INCDIR=$(STAGING_DIR)/usr/include
+12: LUA_FOO_BUILD_OPTS += BAR_LIBDIR=$(STAGING_DIR)/usr/lib
+13: LUA_FOO_LICENSE = luaFoo license
+14: LUA_FOO_LICENSE_FILES = $(LUA_FOO_SUBDIR)/COPYING
+15:
+16: $(eval $(luarocks-package))
 ------------------------
 
 On line 7, we declare the version of the package (the same as in the rockspec,
 which is the concatenation of the upstream version and the rockspec revision,
 separated by a hyphen '-').
 
-On line 8, we declare our dependencies against native libraries, so that they
+On line 8, we declare that the package is called "foo" on LuaRocks. In
+Buildroot, we give Lua-related packages a name that starts with "lua", so the
+Buildroot name is different from the upstream name. +LUA_FOO_NAME_UPSTREAM+
+makes the link between the two names.
+
+On line 9, we declare our dependencies against native libraries, so that they
 are built before the build process of our package starts.
 
-On lines 10-11, we tell Buildroot to pass custom options to LuaRocks when it is
+On lines 11-12, we tell Buildroot to pass custom options to LuaRocks when it is
 building the package.
 
-On lines 12-13, we specify the licensing terms for the package.
+On lines 13-14, we specify the licensing terms for the package.
 
-Finally, on line 15, we invoke the +luarocks-package+
+Finally, on line 16, we invoke the +luarocks-package+
 macro that generates all the Makefile rules that actually allows the
 package to be built.
 
@@ -67,24 +73,28 @@ macro.
 
 First, all the package metadata information variables that exist in
 the generic infrastructure also exist in the LuaRocks infrastructure:
-+LUAFOO_VERSION+, +LUAFOO_SOURCE+, +LUAFOO_SITE+,
-+LUAFOO_DEPENDENCIES+, +LUAFOO_LICENSE+, +LUAFOO_LICENSE_FILES+.
++LUA_FOO_VERSION+, +LUA_FOO_SOURCE+, +LUA_FOO_SITE+,
++LUA_FOO_DEPENDENCIES+, +LUA_FOO_LICENSE+, +LUA_FOO_LICENSE_FILES+.
 
 Two of them are populated by the LuaRocks infrastructure (for the
 +download+ step). If your package is not hosted on the LuaRocks mirror
 +$(BR2_LUAROCKS_MIRROR)+, you can override them:
 
-* +LUAFOO_SITE+, which defaults to +$(BR2_LUAROCKS_MIRROR)+
+* +LUA_FOO_SITE+, which defaults to +$(BR2_LUAROCKS_MIRROR)+
 
-* +LUAFOO_SOURCE+, which defaults to +luafoo-$(LUAFOO_VERSION).src.rock+
+* +LUA_FOO_SOURCE+, which defaults to +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).src.rock+
 
 A few additional variables, specific to the LuaRocks infrastructure, are
 also defined. They can be overridden in specific cases.
 
-* +LUAFOO_ROCKSPEC+, which defaults to +luafoo-$(LUAFOO_VERSION).rockspec+
+* +LUA_FOO_NAME_UPSTREAM+, which defaults to +lua-foo+, i.e. the Buildroot
+  package name
+
+* +LUA_FOO_ROCKSPEC+, which defaults to
+  +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).rockspec+
 
-* +LUAFOO_SUBDIR+, which defaults to
-  +luafoo-$(LUAFOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
+* +LUA_FOO_SUBDIR+, which defaults to
+  +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
 
-* +LUAFOO_BUILD_OPTS+ contains additional build options for the
+* +LUA_FOO_BUILD_OPTS+ contains additional build options for the
   +luarocks build+ call.
diff --git a/package/pkg-luarocks.mk b/package/pkg-luarocks.mk
index 08ea9b801a..2689035cdc 100644
--- a/package/pkg-luarocks.mk
+++ b/package/pkg-luarocks.mk
@@ -34,9 +34,10 @@
 define inner-luarocks-package
 
 $(2)_BUILD_OPTS		?=
-$(2)_SUBDIR		?= $(1)-$$(shell echo "$$($(2)_VERSION)" | sed -e "s/-[0-9]$$$$//")
-$(2)_ROCKSPEC		?= $(1)-$$($(2)_VERSION).rockspec
-$(2)_SOURCE		?= $(1)-$$($(2)_VERSION).src.rock
+$(2)_NAME_UPSTREAM	?= $(1)
+$(2)_SUBDIR		?= $$($(2)_NAME_UPSTREAM)-$$(shell echo "$$($(2)_VERSION)" | sed -e "s/-[0-9]$$$$//")
+$(2)_ROCKSPEC		?= $$($(2)_NAME_UPSTREAM)-$$($(2)_VERSION).rockspec
+$(2)_SOURCE		?= $$($(2)_NAME_UPSTREAM)-$$($(2)_VERSION).src.rock
 $(2)_SITE		?= $$(call qstrip,$$(BR2_LUAROCKS_MIRROR))
 
 # Since we do not support host-luarocks-package, we know this is
-- 
2.11.0

[Buildroot] [PATCH 18/25] luarocks-package: introduce PKG_NAME_UPSTREAM

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:40 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Since we now require Lua package names to start with "lua", it is likely
> that the Buildroot name is different from the upstream LuaRocks name.
> Add a feature to the luarocks-package infra that makes it easier to
> handle this situation: the package can explicitly specify the upstream
> name in PKG_NAME_UPSTREAM, and that name will be used in PKG_ROCKSPEC,
> PKG_SOURCE and PKG_SUBDIR.
> 
> Add an explanation of this feature to the manual. To make the example
> relevant, it is changed to lua-foo, where the upstream name is plain
> foo. To avoid confusion with the dependency on a native library, that
> dependency is renamed to bar.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> The change in the manual should perhaps have been a separate commit, but
> this series is already long enough as it is :-)
> ---
>  docs/manual/adding-packages-luarocks.txt | 54 +++++++++++++++++++-------------
>  package/pkg-luarocks.mk                  |  7 +++--
>  2 files changed, 36 insertions(+), 25 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 19/25] lua-bit32: use PKG_NAME_UPSTREAM

[Arnout Vandecappelle]

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-bit32/lua-bit32.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/lua-bit32/lua-bit32.mk b/package/lua-bit32/lua-bit32.mk
index f4090c703a..14851a5138 100644
--- a/package/lua-bit32/lua-bit32.mk
+++ b/package/lua-bit32/lua-bit32.mk
@@ -5,9 +5,8 @@
 ################################################################################
 
 LUA_BIT32_VERSION = 5.3.0-1
+LUA_BIT32_NAME_UPSTREAM = bit32
 LUA_BIT32_SUBDIR = lua-compat-5.2
-LUA_BIT32_ROCKSPEC = bit32-$(LUA_BIT32_VERSION).rockspec
-LUA_BIT32_SOURCE = bit32-$(LUA_BIT32_VERSION).src.rock
 LUA_BIT32_LICENSE = MIT
 LUA_BIT32_LICENSE_FILES = $(LUA_BIT32_SUBDIR)/LICENSE
 
-- 
2.11.0

[Buildroot] [PATCH 19/25] lua-bit32: use PKG_NAME_UPSTREAM

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:41 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  package/lua-bit32/lua-bit32.mk | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 20/25] luarocks-package: lowercase the upstream name for LuaRocks

[Arnout Vandecappelle]

LuaRocks has a policy that the rockspec and rock filenames are lower
case. However, the upstream name may contain uppercase characters.
We have several packages like that in Buildroot. To simplify the
package .mk files, apply the lowercase from within the infra.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 docs/manual/adding-packages-luarocks.txt | 5 +++--
 package/pkg-luarocks.mk                  | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/docs/manual/adding-packages-luarocks.txt b/docs/manual/adding-packages-luarocks.txt
index 4965a209ae..ec3d4e7ccd 100644
--- a/docs/manual/adding-packages-luarocks.txt
+++ b/docs/manual/adding-packages-luarocks.txt
@@ -82,7 +82,8 @@ Two of them are populated by the LuaRocks infrastructure (for the
 
 * +LUA_FOO_SITE+, which defaults to +$(BR2_LUAROCKS_MIRROR)+
 
-* +LUA_FOO_SOURCE+, which defaults to +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).src.rock+
+* +LUA_FOO_SOURCE+, which defaults to
+  +$(lowercase LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).src.rock+
 
 A few additional variables, specific to the LuaRocks infrastructure, are
 also defined. They can be overridden in specific cases.
@@ -91,7 +92,7 @@ also defined. They can be overridden in specific cases.
   package name
 
 * +LUA_FOO_ROCKSPEC+, which defaults to
-  +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).rockspec+
+  +$(lowercase LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).rockspec+
 
 * +LUA_FOO_SUBDIR+, which defaults to
   +$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
diff --git a/package/pkg-luarocks.mk b/package/pkg-luarocks.mk
index 2689035cdc..d762867111 100644
--- a/package/pkg-luarocks.mk
+++ b/package/pkg-luarocks.mk
@@ -36,8 +36,8 @@ define inner-luarocks-package
 $(2)_BUILD_OPTS		?=
 $(2)_NAME_UPSTREAM	?= $(1)
 $(2)_SUBDIR		?= $$($(2)_NAME_UPSTREAM)-$$(shell echo "$$($(2)_VERSION)" | sed -e "s/-[0-9]$$$$//")
-$(2)_ROCKSPEC		?= $$($(2)_NAME_UPSTREAM)-$$($(2)_VERSION).rockspec
-$(2)_SOURCE		?= $$($(2)_NAME_UPSTREAM)-$$($(2)_VERSION).src.rock
+$(2)_ROCKSPEC		?= $$(call LOWERCASE,$$($(2)_NAME_UPSTREAM))-$$($(2)_VERSION).rockspec
+$(2)_SOURCE		?= $$(call LOWERCASE,$$($(2)_NAME_UPSTREAM))-$$($(2)_VERSION).src.rock
 $(2)_SITE		?= $$(call qstrip,$$(BR2_LUAROCKS_MIRROR))
 
 # Since we do not support host-luarocks-package, we know this is
-- 
2.11.0

[Buildroot] [PATCH 21/25] lua-coat: use PKG_NAME_UPSTREAM

[Arnout Vandecappelle]

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-coat/lua-coat.mk | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/package/lua-coat/lua-coat.mk b/package/lua-coat/lua-coat.mk
index 205995ed63..80ca6b1278 100644
--- a/package/lua-coat/lua-coat.mk
+++ b/package/lua-coat/lua-coat.mk
@@ -4,9 +4,8 @@
 #
 ################################################################################
 
-LUA_COAT_VERSION_UPSTREAM = 0.9.1
-LUA_COAT_VERSION = $(LUA_COAT_VERSION_UPSTREAM)-1
-LUA_COAT_SUBDIR = lua-Coat-$(LUA_COAT_VERSION_UPSTREAM)
+LUA_COAT_VERSION = 0.9.1-1
+LUA_COAT_NAME_UPSTREAM = lua-Coat
 LUA_COAT_LICENSE = MIT
 LUA_COAT_LICENSE_FILES = $(LUA_COAT_SUBDIR)/COPYRIGHT
 
-- 
2.11.0

[Buildroot] [PATCH 22/25] lua-cjson: use LUA_CJSON_SUBDIR

[Arnout Vandecappelle]

The infra sets _SUBDIR to the correct value, so we can use it to define
_LICENSE_FILES.

This removes the need for LUA_CJSON_VERSION_UPSTREAM.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-cjson/lua-cjson.mk | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/package/lua-cjson/lua-cjson.mk b/package/lua-cjson/lua-cjson.mk
index 16cb97412a..1823aa50de 100644
--- a/package/lua-cjson/lua-cjson.mk
+++ b/package/lua-cjson/lua-cjson.mk
@@ -4,9 +4,8 @@
 #
 ################################################################################
 
-LUA_CJSON_VERSION_UPSTREAM = 2.1.0
-LUA_CJSON_VERSION = $(LUA_CJSON_VERSION_UPSTREAM)-1
+LUA_CJSON_VERSION = 2.1.0-1
 LUA_CJSON_LICENSE = MIT
-LUA_CJSON_LICENSE_FILES = lua-cjson-$(LUA_CJSON_VERSION_UPSTREAM)/LICENSE
+LUA_CJSON_LICENSE_FILES = $(LUA_CJSON_SUBDIR)/LICENSE
 
 $(eval $(luarocks-package))
-- 
2.11.0

[Buildroot] [PATCH 23/25] lua-testmore: use PKG_NAME_UPSTREAM

[Arnout Vandecappelle]

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/lua-testmore/lua-testmore.mk | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/package/lua-testmore/lua-testmore.mk b/package/lua-testmore/lua-testmore.mk
index 771b97f000..04482e2586 100644
--- a/package/lua-testmore/lua-testmore.mk
+++ b/package/lua-testmore/lua-testmore.mk
@@ -4,9 +4,8 @@
 #
 ################################################################################
 
-LUA_TESTMORE_VERSION_UPSTREAM = 0.3.2
-LUA_TESTMORE_VERSION = $(LUA_TESTMORE_VERSION_UPSTREAM)-1
-LUA_TESTMORE_SUBDIR = lua-TestMore-$(LUA_TESTMORE_VERSION_UPSTREAM)
+LUA_TESTMORE_VERSION = 0.3.2-1
+LUA_TESTMORE_NAME_UPSTREAM = lua-TestMore
 LUA_TESTMORE_LICENSE = MIT
 LUA_TESTMORE_LICENSE_FILES = $(LUA_TESTMORE_SUBDIR)/COPYRIGHT
 
-- 
2.11.0

[Buildroot] [PATCH 24/25] luabitop: use PKG_NAME_UPSTREAM

[Arnout Vandecappelle]

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/luabitop/luabitop.mk | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/package/luabitop/luabitop.mk b/package/luabitop/luabitop.mk
index 5ced99b327..a36a2feaf1 100644
--- a/package/luabitop/luabitop.mk
+++ b/package/luabitop/luabitop.mk
@@ -4,9 +4,8 @@
 #
 ################################################################################
 
-LUABITOP_VERSION_UPSTREAM = 1.0.2
-LUABITOP_VERSION = $(LUABITOP_VERSION_UPSTREAM)-1
-LUABITOP_SUBDIR = LuaBitOp-$(LUABITOP_VERSION_UPSTREAM)
+LUABITOP_VERSION = 1.0.2-1
+LUABITOP_NAME_UPSTREAM = LuaBitOp
 LUABITOP_LICENSE = MIT
 LUABITOP_LICENSE_FILES = $(LUABITOP_SUBDIR)/README
 
-- 
2.11.0

[Buildroot] [PATCH 25/25] lua: remove documentation from target

[Arnout Vandecappelle]

Many packages install documentation under /usr/share/lua/.../doc. Add
a TARGET_FINALIZE_HOOK to remove it.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/luainterpreter/luainterpreter.mk | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/package/luainterpreter/luainterpreter.mk b/package/luainterpreter/luainterpreter.mk
index a6c98ab992..90382fa78f 100644
--- a/package/luainterpreter/luainterpreter.mk
+++ b/package/luainterpreter/luainterpreter.mk
@@ -6,6 +6,17 @@
 
 LUAINTERPRETER_ABIVER = $(call qstrip,$(BR2_PACKAGE_LUAINTERPRETER_ABI_VERSION))
 
+# Lua packages often install documentation, clean that up globally
+# Since luainterpreter is a virtual package, we can't use
+# LUAINTERPRETER_TARGET_FINALIZE_HOOKS
+ifeq ($(BR2_PACKAGE_HAS_LUAINTERPRETER),y)
+define LUAINTERPRETER_REMOVE_DOC
+	rm -rf $(TARGET_DIR)/usr/share/lua/$(LUAINTERPRETER_ABIVER)/doc
+endef
+
+TARGET_FINALIZE_HOOKS += LUAINTERPRETER_REMOVE_DOC
+endif
+
 $(eval $(virtual-package))
 $(eval $(host-virtual-package))
 
-- 
2.11.0

[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[François Perrad]

2017-02-23 18:00 GMT+01:00 Arnout Vandecappelle (Essensium/Mind)
<arnout@mind.be>:
>  This is a collection of fixes and improvements for the Lua and LuaRocks
> infrastructure.
>
>  It was triggered by luaposix, which fails to load at runtime with luajit
> and lua 5.1 (cfr. [1]). As is typically the case, this one fix lead to a
> whole lot of other changes.
>
>  The first patches can be applied independently of each other. They are
> small issues that I noticed while implementing the PKG_NAME_UPSTREAM
> feature. See the individual commit messages for details.
>
>  We decided that new Lua packages should have a name starting with lua
> (I guess both lua, like luaposix, and lua-, like lua-iconv, are OK).
> Patch 13 documents that in package/Config.in.
>
>  A new package lua-bit32 is added in patch 14. This package is used to
> fix luaposix in patch 15. Subsequent patches generalize the hacks that
> are needed for lua-bit32 because of the added lua- prefix. Patch 16
> reworks the extraction so it doesn't rely on specific naming of the
> subdirectory in which luarocks extracts stuff. Patch 18 introduces
> a _NAME_UPSTREAM variable so that the automatically derived variable
> names from the luarocks infra are correct when the Buildroot name is
> different. Patch 20 extends that concept to the typical situation that
> the Lua name has camel case, while the Buildroot name (as well as the
> LuaRocks name) is lower case.
>
>  Patch 25 is again independent of the rest. It removes documentation from
> the target that is installed there by some Lua (not LuaRocks) packages.
> For example, luaposix does that.
>
>  Patches 18 to 24 are somewhat controversial because they introduce
> "magic automation" just to save a few lines in the package .mk file. The
> amount of savings from those isn't impressive either, they have a
> diffstat of 13 insertions(+), 17 deletions(-) (discounting the
> documentation change). Still, I believe it makes creation of LuaRocks
> packages a bit easier so I included them.
>
>  I did a runtime test after all patches applied by doing a
> require "foo"
> for each luarocks package with a Lua 5.1 interpreter. I am also using the
> fixed luaposix on an actual customer device.
>
>  Obviously, this entire series is for next.
>

Great job.

Fran?ois

>  Regards,
>  Arnout
>
> [1] https://lists.osuosl.org/pipermail/buildroot/2017-February/184511.html
>
> ----------------------------------------------------------------
> The following changes since commit c75f0a4d69db655bb523fbab30e0f4656bc5fb71:
>
>   configs/liteboard: Bump to kernel 4.10 (2017-02-21 16:11:05 +0100)
>
> are available in the git repository at:
>
>   https://gitlab.com/arnout/buildroot lua
>
> for you to fetch changes up to a5dfafeb82c2a91f51908110beafe7389015ca75:
>
>   lua: remove documentation from target (2017-02-23 16:48:06 +0100)
>
> ----------------------------------------------------------------
> Arnout Vandecappelle (25):
>       lutok: move to Lua libraries menu
>       cosmo: remove broken package
>       luarocks-package: use $(HOST_PKG_VERSION) instead of $(PKG_VERSION)
>       manual: luarocks: improve tutorial example
>       lpty: remove LPTY_VERSION_UPSTREAM
>       lua-periphery: remove LUA_PERIPHERY_VERSION_UPSTREAM
>       luasec: remove LUASEC_VERSION_UPSTREAM
>       ljlinenoise: remove default definition of PKG_SUBDIR
>       lua-csnappy: remove default definition of PKG_SUBDIR
>       lua-iconv: remove default definition of PKG_SUBDIR
>       luacrypto: remove default definition of PKG_SUBDIR
>       lunit: remove default definition of PKG_SUBDIR
>       package/Config.in: explain that lua package names should start with lua
>       lua-bit32: new package
>       luaposix: fix runtime by selecting "bit32" instead of "bitop"
>       luarocks-package: rework extraction
>       lua-bit32: remove custom extract commands
>       luarocks-package: introduce PKG_NAME_UPSTREAM
>       lua-bit32: use PKG_NAME_UPSTREAM
>       luarocks-package: lowercase the upstream name for LuaRocks
>       lua-coat: use PKG_NAME_UPSTREAM
>       lua-cjson: use LUA_CJSON_SUBDIR
>       lua-testmore: use PKG_NAME_UPSTREAM
>       luabitop: use PKG_NAME_UPSTREAM
>       lua: remove documentation from target
>
>  docs/manual/adding-packages-luarocks.txt           | 55 +++++++++++++---------
>  package/Config.in                                  |  6 ++-
>  package/cosmo/Config.in                            | 10 ----
>  package/cosmo/cosmo.hash                           |  2 -
>  package/ljlinenoise/ljlinenoise.mk                 |  4 +-
>  package/lpty/lpty.mk                               |  3 +-
>  package/lua-bit32/Config.in                        |  9 ++++
>  package/lua-bit32/lua-bit32.hash                   |  2 +
>  package/{cosmo/cosmo.mk => lua-bit32/lua-bit32.mk} |  9 ++--
>  package/lua-cjson/lua-cjson.mk                     |  5 +-
>  package/lua-coat/lua-coat.mk                       |  5 +-
>  package/lua-csnappy/lua-csnappy.mk                 |  4 +-
>  package/lua-iconv/lua-iconv.mk                     |  4 +-
>  package/lua-periphery/lua-periphery.mk             |  3 +-
>  package/lua-testmore/lua-testmore.mk               |  5 +-
>  package/luabitop/luabitop.mk                       |  5 +-
>  package/luacrypto/luacrypto.mk                     |  4 +-
>  package/luainterpreter/luainterpreter.mk           | 11 +++++
>  package/luaposix/Config.in                         |  6 ++-
>  package/luasec/luasec.mk                           |  3 +-
>  package/lunit/lunit.mk                             |  4 +-
>  package/lutok/Config.in                            |  1 -
>  package/pkg-luarocks.mk                            | 14 ++++--
>  23 files changed, 94 insertions(+), 80 deletions(-)
>  delete mode 100644 package/cosmo/Config.in
>  delete mode 100644 package/cosmo/cosmo.hash
>  create mode 100644 package/lua-bit32/Config.in
>  create mode 100644 package/lua-bit32/lua-bit32.hash
>  rename package/{cosmo/cosmo.mk => lua-bit32/lua-bit32.mk} (51%)
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[Arnout Vandecappelle]

On 24-02-17 07:59, Fran?ois Perrad wrote:
> 2017-02-23 18:00 GMT+01:00 Arnout Vandecappelle (Essensium/Mind)
> <arnout@mind.be>:
>>  This is a collection of fixes and improvements for the Lua and LuaRocks
>> infrastructure.
[snip]
> 
> Great job.

 Do you mean to say "Reviewed-by: " ? :-)

 Regards,
 Arnout


[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[François Perrad]

2017-02-24 10:09 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 24-02-17 07:59, Fran?ois Perrad wrote:
>> 2017-02-23 18:00 GMT+01:00 Arnout Vandecappelle (Essensium/Mind)
>> <arnout@mind.be>:
>>>  This is a collection of fixes and improvements for the Lua and LuaRocks
>>> infrastructure.
> [snip]
>>
>> Great job.
>
>  Do you mean to say "Reviewed-by: " ? :-)
>

Well, 25 x "Reviewed-by: ".

Fran?ois

>  Regards,
>  Arnout
>
>
> [snip]
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH for-next 0/25] Lua(Rocks) improvements

[Thomas Petazzoni]

Hello,

On Thu, 23 Feb 2017 18:00:22 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:

>       package/Config.in: explain that lua package names should start with lua

As we discussed, I marked this one as Changes Requested. Don't forget
to send an updated version :-)

>       luarocks-package: lowercase the upstream name for LuaRocks
>       lua-coat: use PKG_NAME_UPSTREAM
>       lua-cjson: use LUA_CJSON_SUBDIR
>       lua-testmore: use PKG_NAME_UPSTREAM
>       luabitop: use PKG_NAME_UPSTREAM
>       lua: remove documentation from target

I've applied all those remaining patches.

Thanks a lot for the nice cleanup!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com