[Buildroot] [PATCH 0/4] swupdate: allow configuring with LuaJIT

[Buildroot] [PATCH 0/4] swupdate: allow configuring with LuaJIT

[Jordan Yelloz]

This allows people to build swupdate against LuaJIT for custom Lua upgrade
manifest parsers or pre/post-install hook scripts.

Also, information was added about the limitations of building against Lua 5.1
(which is currently allowed in buildroot) or LuaJIT.

Jordan Yelloz (4):
  swupdate: allowed luajit to enable HAVE_LUA
  swupdate: updated lua check for libconfig
  swupdate: improved help text for Lua support
  swupdate: added a warning for LuaJIT/Lua 5.1

 package/swupdate/Config.in   | 15 +++++++++++++--
 package/swupdate/swupdate.mk |  3 +++
 2 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.9.2

[Buildroot] [PATCH 1/4] swupdate: allowed luajit to enable HAVE_LUA

[Jordan Yelloz]

Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
---
 package/swupdate/swupdate.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/swupdate/swupdate.mk b/package/swupdate/swupdate.mk
index 313a54febd87..7a0fcaea5741 100644
--- a/package/swupdate/swupdate.mk
+++ b/package/swupdate/swupdate.mk
@@ -42,6 +42,9 @@ endif
 ifeq ($(BR2_PACKAGE_LUA),y)
 SWUPDATE_DEPENDENCIES += lua host-pkgconf
 SWUPDATE_MAKE_ENV += HAVE_LUA=y
+else ifeq ($(BR2_PACKAGE_LUAJIT),y)
+SWUPDATE_DEPENDENCIES += luajit host-pkgconf
+SWUPDATE_MAKE_ENV += HAVE_LUA=y
 else
 SWUPDATE_MAKE_ENV += HAVE_LUA=n
 endif
-- 
2.9.2

[Buildroot] [PATCH 2/4] swupdate: updated lua check for libconfig

[Jordan Yelloz]

Most probably this was missed in commit
65b2ae49feb310d3272a47c44cf3b406646b25c1 which removed pinning to Lua
5.2.

Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
---
 package/swupdate/Config.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
index 5f5e1e77b9d1..d7217af1c47f 100644
--- a/package/swupdate/Config.in
+++ b/package/swupdate/Config.in
@@ -3,7 +3,8 @@ config BR2_PACKAGE_SWUPDATE
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on BR2_USE_MMU # fork()
 	# swupdate requires a parser and uses libconfig as default
-	select BR2_PACKAGE_LIBCONFIG if !BR2_PACKAGE_JSON_C && !BR2_PACKAGE_LUA_5_2
+	select BR2_PACKAGE_LIBCONFIG if !BR2_PACKAGE_JSON_C && \
+		!BR2_PACKAGE_HAS_LUAINTERPRETER
 	help
 	  swupdate provides a reliable way to update the software on an
 	  embedded system.
-- 
2.9.2

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Jordan Yelloz]

It now explains limitations of building against Lua < 5.2 interpreters
and how to link to LuaJIT library.

Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
---
 package/swupdate/Config.in | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
index d7217af1c47f..85dde4eb0bc5 100644
--- a/package/swupdate/Config.in
+++ b/package/swupdate/Config.in
@@ -19,7 +19,11 @@ config BR2_PACKAGE_SWUPDATE
 	  use your own modified configuration, you have to select the
 	  necessary packages manually:
 
-	  * Select BR2_PACKAGE_LUA if you want to have Lua support.
+	  * Select BR2_PACKAGE_LUA or BR2_PACKAGE_LUAJIT if you want to have Lua
+	    support.
+	    CONFIG_HANDLER_IN_LUA is not supported in LuaJIT or Lua 5.1.
+	    swupdate must be manually configured with CONFIG_LUAVERSION="jit-5.1"
+	    to link against luajit.
 	  * Select BR2_LIBCURL if you want to use the download feature.
 	  * Select BR2_PACKAGE_OPENSSL is you want to add encryption support.
 	  * Select BR2_PACKAGE_MTD if you want to use swupdate with UBI
-- 
2.9.2

[Buildroot] [PATCH 4/4] swupdate: added a warning for LuaJIT/Lua 5.1

[Jordan Yelloz]

Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
---
 package/swupdate/Config.in | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
index 85dde4eb0bc5..046903de87f5 100644
--- a/package/swupdate/Config.in
+++ b/package/swupdate/Config.in
@@ -55,6 +55,12 @@ config BR2_PACKAGE_SWUPDATE_INSTALL_WEBSITE
 	  This is necessary if you want to run swupdate with the embedded
 	  webserver and do not provide an own website to be installed to
 	  /var/www/swupdate.
+
+if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
+comment "swupdate cannot use CONFIG_HANDLER_IN_LUA with Lua API < 5.2."
+comment "Lua parsers and pre/post-install hooks should still work.    "
+endif
+
 endif
 
 comment "swupdate needs a toolchain w/ threads"
-- 
2.9.2

[Buildroot] [PATCH 1/4] swupdate: allowed luajit to enable HAVE_LUA

[Thomas Petazzoni]

Hello,

On Sun, 24 Jul 2016 16:27:36 -0700, Jordan Yelloz wrote:

> diff --git a/package/swupdate/swupdate.mk b/package/swupdate/swupdate.mk
> index 313a54febd87..7a0fcaea5741 100644
> --- a/package/swupdate/swupdate.mk
> +++ b/package/swupdate/swupdate.mk
> @@ -42,6 +42,9 @@ endif
>  ifeq ($(BR2_PACKAGE_LUA),y)
>  SWUPDATE_DEPENDENCIES += lua host-pkgconf
>  SWUPDATE_MAKE_ENV += HAVE_LUA=y
> +else ifeq ($(BR2_PACKAGE_LUAJIT),y)
> +SWUPDATE_DEPENDENCIES += luajit host-pkgconf
> +SWUPDATE_MAKE_ENV += HAVE_LUA=y

If both luajit and classic lua are supported, then could you instead
use:

ifeq ($(BR2_PACKAGE_HAS_LUAINTERPRETER),y)
SWUPDATE_DEPENDENCIES += luainterpreter host-pkgconf
SWUPDATE_MAKE_ENV += HAVE_LUA=y

luainterpreter is a virtual package that automatically depends either
on lua or luajit, depending on which of the two is enabled in the
configuration.

Could you test this solution, and send an updated version of your patch?

Thanks a lot!

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

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Thomas Petazzoni]

Hello,

On Sun, 24 Jul 2016 16:27:38 -0700, Jordan Yelloz wrote:

> -	  * Select BR2_PACKAGE_LUA if you want to have Lua support.
> +	  * Select BR2_PACKAGE_LUA or BR2_PACKAGE_LUAJIT if you want to have Lua
> +	    support.
> +	    CONFIG_HANDLER_IN_LUA is not supported in LuaJIT or Lua 5.1.
> +	    swupdate must be manually configured with CONFIG_LUAVERSION="jit-5.1"
> +	    to link against luajit.

What does this last sentence means?

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

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Jordan Yelloz]

On 07/25/2016 12:32 AM, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 24 Jul 2016 16:27:38 -0700, Jordan Yelloz wrote:
> 
>> -	  * Select BR2_PACKAGE_LUA if you want to have Lua support.
>> +	  * Select BR2_PACKAGE_LUA or BR2_PACKAGE_LUAJIT if you want to have Lua
>> +	    support.
>> +	    CONFIG_HANDLER_IN_LUA is not supported in LuaJIT or Lua 5.1.
>> +	    swupdate must be manually configured with CONFIG_LUAVERSION="jit-5.1"
>> +	    to link against luajit.
> 
> What does this last sentence means?
> 
> Thomas
> 

Regarding CONFIG_LUAVERSION, this is trying to explain how to
successfully configure swupdate to build against LuaJIT. If you just
choose LuaJIT, it will not be successful automatically due to some minor
limitations in the swupdate build system.

swupdate has some build rules that are not that good (it uses
pkg-config for some parts of the build but uses a secondary list of
library names to actually link the final executable against) and when
adding the Lua library to the list of libraries to link, it relies on
concatenating "lua" with $(CONFIG_LUAVERSION).

Basically, the only way to get swupdate to link against libluajit-5.1.so
is to ensure CONFIG_LUAVERSION="jit-5.1" is in your swupdate KConfig
file. To me, the easiest/safest way of handling that is to expect the
user to configure swupdate manually with that value.

--
Jordan

[Buildroot] [PATCH 1/4] swupdate: allowed luajit to enable HAVE_LUA

[Jordan Yelloz]

On 07/25/2016 12:31 AM, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 24 Jul 2016 16:27:36 -0700, Jordan Yelloz wrote:
> 
>> diff --git a/package/swupdate/swupdate.mk b/package/swupdate/swupdate.mk
>> index 313a54febd87..7a0fcaea5741 100644
>> --- a/package/swupdate/swupdate.mk
>> +++ b/package/swupdate/swupdate.mk
>> @@ -42,6 +42,9 @@ endif
>>  ifeq ($(BR2_PACKAGE_LUA),y)
>>  SWUPDATE_DEPENDENCIES += lua host-pkgconf
>>  SWUPDATE_MAKE_ENV += HAVE_LUA=y
>> +else ifeq ($(BR2_PACKAGE_LUAJIT),y)
>> +SWUPDATE_DEPENDENCIES += luajit host-pkgconf
>> +SWUPDATE_MAKE_ENV += HAVE_LUA=y
> 
> If both luajit and classic lua are supported, then could you instead
> use:
> 
> ifeq ($(BR2_PACKAGE_HAS_LUAINTERPRETER),y)
> SWUPDATE_DEPENDENCIES += luainterpreter host-pkgconf
> SWUPDATE_MAKE_ENV += HAVE_LUA=y
> 
> luainterpreter is a virtual package that automatically depends either
> on lua or luajit, depending on which of the two is enabled in the
> configuration.
> 
> Could you test this solution, and send an updated version of your patch?
> 
> Thanks a lot!
> 
> Thomas
> 

Hi,

I've updated my patch to reflect your changes and it still works. I'll
resubmit the patch series if you're okay with my explanation for patch 3/4.

--
Jordan

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Jörg Krause]

On Mo, 2016-07-25 at 09:36 -0700, Jordan Yelloz wrote:

On 07/25/2016 12:32 AM, Thomas Petazzoni wrote:


Hello,

On Sun, 24 Jul 2016 16:27:38 -0700, Jordan Yelloz wrote:



-	??* Select BR2_PACKAGE_LUA if you want to have Lua
support.
+	??* Select BR2_PACKAGE_LUA or BR2_PACKAGE_LUAJIT if you
want to have Lua
+	????support.
+	????CONFIG_HANDLER_IN_LUA is not supported in LuaJIT or
Lua 5.1.
+	????swupdate must be manually configured with
CONFIG_LUAVERSION="jit-5.1"
+	????to link against luajit.


What does this last sentence means?

Thomas



Regarding CONFIG_LUAVERSION, this is trying to explain how to
successfully configure swupdate to build against LuaJIT. If you just
choose LuaJIT, it will not be successful automatically due to some
minor
limitations in the swupdate build system.

swupdate has some build rules that are not that good (it uses
pkg-config for some parts of the build but uses a secondary list of
library names to actually link the final executable against) and when
adding the Lua library to the list of libraries to link, it relies on
concatenating "lua" with $(CONFIG_LUAVERSION).

Basically, the only way to get swupdate to link against libluajit-
5.1.so
is to ensure CONFIG_LUAVERSION="jit-5.1" is in your swupdate KConfig
file. To me, the easiest/safest way of handling that is to expect the
user to configure swupdate manually with that value.


I like the idea of using swupdate with LuaJIT!

How about setting LUAVERSION if LuaJIT is selected? Like adding this somewhere:

$(call KCONFIG_SET_OPT,CONFIG_LUAVERSION,"jit-5.1")

Best regards
J?rg Krause

[Buildroot] [PATCH 2/4] swupdate: updated lua check for libconfig

[Jörg Krause]

On So, 2016-07-24 at 16:27 -0700, Jordan Yelloz wrote:
> Most probably this was missed in commit
> 65b2ae49feb310d3272a47c44cf3b406646b25c1 which removed pinning to Lua
> 5.2.
> 
> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> ---
> ?package/swupdate/Config.in | 3 ++-
> ?1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
> index 5f5e1e77b9d1..d7217af1c47f 100644
> --- a/package/swupdate/Config.in
> +++ b/package/swupdate/Config.in
> @@ -3,7 +3,8 @@ config BR2_PACKAGE_SWUPDATE
> ?	depends on BR2_TOOLCHAIN_HAS_THREADS
> ?	depends on BR2_USE_MMU # fork()
> ?	# swupdate requires a parser and uses libconfig as default
> -	select BR2_PACKAGE_LIBCONFIG if !BR2_PACKAGE_JSON_C &&
> !BR2_PACKAGE_LUA_5_2
> +	select BR2_PACKAGE_LIBCONFIG if !BR2_PACKAGE_JSON_C && \
> +		!BR2_PACKAGE_HAS_LUAINTERPRETER


Good catch, thank you!

J?rg

[Buildroot] [PATCH 4/4] swupdate: added a warning for LuaJIT/Lua 5.1

[Jörg Krause]

On So, 2016-07-24 at 16:27 -0700, Jordan Yelloz wrote:
> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> ---
> ?package/swupdate/Config.in | 6 ++++++
> ?1 file changed, 6 insertions(+)
> 
> diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
> index 85dde4eb0bc5..046903de87f5 100644
> --- a/package/swupdate/Config.in
> +++ b/package/swupdate/Config.in
> @@ -55,6 +55,12 @@ config BR2_PACKAGE_SWUPDATE_INSTALL_WEBSITE
> ?	??This is necessary if you want to run swupdate with the
> embedded
> ?	??webserver and do not provide an own website to be
> installed to
> ?	??/var/www/swupdate.
> +
> +if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
> +comment "swupdate cannot use CONFIG_HANDLER_IN_LUA with Lua API <
> 5.2."
> +comment "Lua parsers and pre/post-install hooks should still
> work.????"
> +endif
> +

I would prefer to put this as a note in the help text.

Do you know where this restriction comes from? Why does the Lua
handlers does not work? Did you tell upstream about the issue? AFAIK
swupate should work with Lua 5.1 - 5.3, but I did not checked.

Best regards
J?rg Krause

[Buildroot] [PATCH 4/4] swupdate: added a warning for LuaJIT/Lua 5.1

[Jordan Yelloz]

On 07/29/2016 09:20 AM, J?rg Krause wrote:
> On So, 2016-07-24 at 16:27 -0700, Jordan Yelloz wrote:
>> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
>> ---
>>  package/swupdate/Config.in | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/package/swupdate/Config.in b/package/swupdate/Config.in
>> index 85dde4eb0bc5..046903de87f5 100644
>> --- a/package/swupdate/Config.in
>> +++ b/package/swupdate/Config.in
>> @@ -55,6 +55,12 @@ config BR2_PACKAGE_SWUPDATE_INSTALL_WEBSITE
>>  	  This is necessary if you want to run swupdate with the
>> embedded
>>  	  webserver and do not provide an own website to be
>> installed to
>>  	  /var/www/swupdate.
>> +
>> +if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
>> +comment "swupdate cannot use CONFIG_HANDLER_IN_LUA with Lua API <
>> 5.2."
>> +comment "Lua parsers and pre/post-install hooks should still
>> work.    "
>> +endif
>> +
> 
> I would prefer to put this as a note in the help text.
> 

Ok, I can move it there.

> Do you know where this restriction comes from? Why does the Lua
> handlers does not work? Did you tell upstream about the issue? AFAIK
> swupate should work with Lua 5.1 - 5.3, but I did not checked.

The handlers incompatibility is because of the Lua C API changes from
5.1 to 5.2.
I've done some testing earlier this week and it turns out you can
actually include the compat53 C files
(<https://github.com/keplerproject/lua-compat-5.3/tree/master/c-api>)
into swupdate's core/handler.c if you really want and the lua handlers
feature will build and work successfully with Lua 5.1 and LuaJIT (though
I have done very limited testing).

I started writing a patch for swupdate but I currently have no use for
the handlers in lua and don't have the time to integrate it into
swupdate's build system so it's on hold.

--
Jordan

[Buildroot] [PATCH 4/4] swupdate: added a warning for LuaJIT/Lua 5.1

[Jörg Krause]

On Fr, 2016-07-29 at 09:32 -0700, Jordan Yelloz wrote:
> On 07/29/2016 09:20 AM, J?rg Krause wrote:
> > 
> > On So, 2016-07-24 at 16:27 -0700, Jordan Yelloz wrote:
> > > 
> > > Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> > > ---
> > > ?package/swupdate/Config.in | 6 ++++++
> > > ?1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/package/swupdate/Config.in
> > > b/package/swupdate/Config.in
> > > index 85dde4eb0bc5..046903de87f5 100644
> > > --- a/package/swupdate/Config.in
> > > +++ b/package/swupdate/Config.in
> > > @@ -55,6 +55,12 @@ config BR2_PACKAGE_SWUPDATE_INSTALL_WEBSITE
> > > ?	??This is necessary if you want to run swupdate with the
> > > embedded
> > > ?	??webserver and do not provide an own website to be
> > > installed to
> > > ?	??/var/www/swupdate.
> > > +
> > > +if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
> > > +comment "swupdate cannot use CONFIG_HANDLER_IN_LUA with Lua API
> > > <
> > > 5.2."
> > > +comment "Lua parsers and pre/post-install hooks should still
> > > work.????"
> > > +endif
> > > +
> > 
> > I would prefer to put this as a note in the help text.
> > 
> 
> Ok, I can move it there.
> 
> > 
> > Do you know where this restriction comes from? Why does the Lua
> > handlers does not work? Did you tell upstream about the issue?
> > AFAIK
> > swupate should work with Lua 5.1 - 5.3, but I did not checked.
> 
> The handlers incompatibility is because of the Lua C API changes from
> 5.1 to 5.2.
> I've done some testing earlier this week and it turns out you can
> actually include the compat53 C files
> (<https://github.com/keplerproject/lua-compat-5.3/tree/master/c-api>)
> into swupdate's core/handler.c if you really want and the lua
> handlers
> feature will build and work successfully with Lua 5.1 and LuaJIT
> (though
> I have done very limited testing).
> 
> I started writing a patch for swupdate but I currently have no use
> for
> the handlers in lua and don't have the time to integrate it into
> swupdate's build system so it's on hold.

Maybe you could report it on the swupdates mailing list. Maybe Stefano
Babic can help you with the patch.

J?rg

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Jordan Yelloz]

On 07/29/2016 09:14 AM, J?rg Krause wrote:
> On Mo, 2016-07-25 at 09:36 -0700, Jordan Yelloz wrote:
> 
> On 07/25/2016 12:32 AM, Thomas Petazzoni wrote:
> 
> 
> Hello,
> 
> On Sun, 24 Jul 2016 16:27:38 -0700, Jordan Yelloz wrote:
> 
> 
> 
> -	  * Select BR2_PACKAGE_LUA if you want to have Lua
> support.
> +	  * Select BR2_PACKAGE_LUA or BR2_PACKAGE_LUAJIT if you
> want to have Lua
> +	    support.
> +	    CONFIG_HANDLER_IN_LUA is not supported in LuaJIT or
> Lua 5.1.
> +	    swupdate must be manually configured with
> CONFIG_LUAVERSION="jit-5.1"
> +	    to link against luajit.
> 
> 
> What does this last sentence means?
> 
> Thomas
> 
> 
> 
> Regarding CONFIG_LUAVERSION, this is trying to explain how to
> successfully configure swupdate to build against LuaJIT. If you just
> choose LuaJIT, it will not be successful automatically due to some
> minor
> limitations in the swupdate build system.
> 
> swupdate has some build rules that are not that good (it uses
> pkg-config for some parts of the build but uses a secondary list of
> library names to actually link the final executable against) and when
> adding the Lua library to the list of libraries to link, it relies on
> concatenating "lua" with $(CONFIG_LUAVERSION).
> 
> Basically, the only way to get swupdate to link against libluajit-
> 5.1.so
> is to ensure CONFIG_LUAVERSION="jit-5.1" is in your swupdate KConfig
> file. To me, the easiest/safest way of handling that is to expect the
> user to configure swupdate manually with that value.
> 
> 
> I like the idea of using swupdate with LuaJIT!
> 
> How about setting LUAVERSION if LuaJIT is selected? Like adding this somewhere:
> 
> $(call KCONFIG_SET_OPT,CONFIG_LUAVERSION,"jit-5.1")
> 

Hi,

I do prefer this approach. I have made some changes to my patch to
conditionally add KCONFIG_SET_OPT. However, in order to get it working
we will also need to set CONFIG_LUA=y since CONFIG_LUAVERSION depends on
CONFIG_LUA=y.
If everybody approves of automatically enabling some
Lua support in swupdate when lua is enabled in buildroot, we can do
that. And if we do that, we might as well do the same when PUC Lua is
enabled in buildroot.
Otherwise, we will soon have to add some more options to the swupdate
buildroot kconfig and there might be some confusing overlap between the
kconfig of buildroot and that of swupdate.
Something to consider when adding complexity to this is that the current
swupdate defconfig distributed with buildroot has very few features
enabled (no MTD, no shell scripts, no u-boot environment patching). I
would imagine that anyone who uses swupdate with buildroot for anything
serious would keep their own custom defconfig for their project. If
that's the case then it might be best to continue to do as little as
possible and just get out of the way of the user and leave it to them to
properly configure Lua support in swupdate.

--
Jordan

[Buildroot] [PATCH 1/4] swupdate: allowed luajit to enable HAVE_LUA

[Thomas Petazzoni]

Hello,

On Sun, 24 Jul 2016 16:27:36 -0700, Jordan Yelloz wrote:
> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> ---
>  package/swupdate/swupdate.mk | 3 +++
>  1 file changed, 3 insertions(+)

I've applied, after updating it to use the luainterpreter virtual
package instead. I've also expanded the commit log to explain what's
going on. See
https://git.buildroot.org/buildroot/commit/?id=515ced20087407189bc5523a2bf7c19b239cb78d.

Best regards,

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

[Buildroot] [PATCH 2/4] swupdate: updated lua check for libconfig

[Thomas Petazzoni]

Hello,

On Sun, 24 Jul 2016 16:27:37 -0700, Jordan Yelloz wrote:
> Most probably this was missed in commit
> 65b2ae49feb310d3272a47c44cf3b406646b25c1 which removed pinning to Lua
> 5.2.
> 
> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> ---
>  package/swupdate/Config.in | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied to master, thanks.

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

[Buildroot] [PATCH 3/4] swupdate: improved help text for Lua support

[Thomas Petazzoni]

Hello,

On Sun, 24 Jul 2016 16:27:38 -0700, Jordan Yelloz wrote:
> It now explains limitations of building against Lua < 5.2 interpreters
> and how to link to LuaJIT library.
> 
> Signed-off-by: Jordan Yelloz <jordan@yelloz.me>
> ---
>  package/swupdate/Config.in | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

In the end, I decided to apply your patch, with just a little bit of
rewording.

Following the discussion we had back in July, do not hesitate to send
another patch series that uses KCONFIG_SET_OPT to automatically set the
appropriate options in swupdate configuration. But this should be done
not only for Lua, but also for other features.

Best regards,

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

[Buildroot] [PATCH 4/4] swupdate: added a warning for LuaJIT/Lua 5.1

[Thomas Petazzoni]

Hello,

On Fri, 29 Jul 2016 18:20:34 +0200, J?rg Krause wrote:

> > +if BR2_PACKAGE_LUA_5_1 || BR2_PACKAGE_LUAJIT
> > +comment "swupdate cannot use CONFIG_HANDLER_IN_LUA with Lua API <
> > 5.2."
> > +comment "Lua parsers and pre/post-install hooks should still
> > work.????"
> > +endif
> > +  
> 
> I would prefer to put this as a note in the help text.

Agreed. And it's actually in the help text now, thanks to PATCH 3/4 of
this series. See
https://git.buildroot.org/buildroot/commit/?id=02549bd9182f9d333dc47682d51c277786001467.

So I'll mark this PATCH 4/4 as Rejected.

Thanks,

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