diff mbox

[14/25] lua-bit32: new package

Message ID 20170223170047.24417-15-arnout@mind.be
State Accepted
Headers show

Commit Message

Arnout Vandecappelle Feb. 23, 2017, 5 p.m. UTC 
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

Comments

Thomas Petazzoni March 2, 2017, 9:54 p.m. UTC | #1 
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
Arnout Vandecappelle March 2, 2017, 10:24 p.m. UTC | #2 
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
>
Thomas Petazzoni March 17, 2017, 4:14 p.m. UTC | #3 
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
Arnout Vandecappelle March 17, 2017, 10:17 p.m. UTC | #4 
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
>
Thomas Petazzoni March 18, 2017, 10:42 a.m. UTC | #5 
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
Arnout Vandecappelle March 18, 2017, 1:17 p.m. UTC | #6 
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
Thomas Petazzoni March 18, 2017, 1:49 p.m. UTC | #7 
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
Arnout Vandecappelle March 18, 2017, 2:03 p.m. UTC | #8 
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
>
diff mbox

Patch

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))