[1/1] ola: new package

Signed-off-by: Dave Skok <blanco.ether@gmail.com>
---
 package/Config.in     |   1 +
 package/ola/Config.in | 143 ++++++++++++++++++++++++++++++++++++++++++++++
 package/ola/ola.mk    | 155 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 299 insertions(+)
 create mode 100644 package/ola/Config.in
 create mode 100644 package/ola/ola.mk

Dear Dave Skok,

Thanks for this patch! It is not sent properly, isn't wrapped, and has
the proper format. So I tried it, but found a few issues.

On Wed,  7 Aug 2013 09:10:32 -0400, Dave Skok wrote:

> +config BR2_PACKAGE_OLA
> +	bool "open lighting architecture"
> +	select BR2_PACKAGE_PROTOBUF
> +	select BR2_PACKAGE_UTIL_LINUX_LIBUUID
> +	select BR2_PACKAGE_UTIL_LINUX
> +	depends on BR2_INSTALL_LIBSTDCPP # protobuf
> +	depends on BR2_LARGEFILE # util-linux
> +	depends on BR2_USE_WCHAR # util-linux

You should also:

	depends on BR2_TOOLCHAIN_HAS_THREADS

> +	help
> +	  Open Lighting Architecture provides applications 
> +	  with a mechanism to send and receive DMX512 & RDM 
> +	  commands using hardware devices and DMX over IP protocols.
> +
> +	  http://www.opendmx.net/index.php/OLA
> +
> +comment "ola requires a toolchain with C++, largefile and wchar support"
> +	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_LARGEFILE || !BR2_USE_WCHAR

and change this to mention the need for thread support. Without thread
support, OLA fails to build as it tries to include <pthread.h>.

Then, the most annoying issue I had was that the very basic
configuration of OLA (just enable OLA and leave all the sub-options to
the default) doesn't build here:

OlaServer.cpp: In member function 'void ola::OlaServer::UpdatePidStore(const ola::rdm::RootPidStore*)':
OlaServer.cpp:467:14: error: request for member 'SetPidStore' in '*((ola::OlaServer*)this)->ola::OlaServer::m_httpd.std::auto_ptr<_Tp>::operator-><int>()', which is of non-class type 'std::auto_ptr<int>::element_type {aka int}'

I'm really bad at C++, but it looks like SetPidStore() is a method that
only exists when the HTTP server of OLA is enabled, or something like that.

> --- /dev/null
> +++ b/package/ola/ola.mk
> @@ -0,0 +1,155 @@
> +################################################################################
> +#
> +# ola
> +#
> +################################################################################
> +
> +OLA_VERSION = 0.8.30
> +OLA_SITE = https://code.google.com/p/open-lighting/
> +OLA_SITE_METHOD = git
> +
> +# autoreconf required for source pulled from git repo
> +# as it does not track configuration
> +OLA_AUTORECONF = YES
> +OLA_LICENSE = LGPLv2.1+
> +OLA_LICENSE_FILES = LICENSE COPYING.LGPLv2.1

These license informations are not correct. They should be:

OLA_LICENSE = LGPLv2.1+ (libola, libolacommon, Python bindings), GPLv2+ (libolaserver, olad, Python examples and tests)
OLA_LICENSE_FILES = LICENCE GPL LGPL

Also, I believe you should add:

OLA_INSTALL_STAGING = YES

because it installs some clients libraries to talk to the 'olad'
daemon, and those libraries can be useful to link other programs.

I could have fixed those myself, but I've stopped due to the build
failure.

Here is the minimal defconfig that I used to exhibit the build problem:

BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2013.05-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_LARGEFILE=y
BR2_TOOLCHAIN_EXTERNAL_INET_IPV6=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_OLA=y

Best regards,

Thomas

Dear David Skok,

Please always keep the Buildroot mailing list Cc'ed when continuing
discussions that started on the list.

On Mon, 12 Aug 2013 08:26:57 -0400, David Skok wrote:

> I've made the changes you point out.  My apologies but I don't know
> what you mean by "patch is not wrapped" and is (is not?) proper
> format.

What I meant is that your latest patch was perfect.

Often, when people send patches with their normal e-mail client, most
e-mail clients tend to "wrap" lines at 80 characters or so: instead of
having very very long lines, you have lines nicely wrapped at a
reasonable length.

However, while this is very useful when exchanging text, it falls apart
when exchanging patches, because the wrapping feature of the e-mail
clients breaks the patches and they can no longer be applied.

By using 'git send-email' (as you did), you make sure that your e-mail
client will not interfere with how the patch is sent, and specifically
that it doesn't get wrapped.

> I use git command line outlined in buildroot manual to send
> it.  I am new to contributing to open source and am doing my best to
> learn compliance for contribution.  Thank you for your patience so
> far.
> 
> Regarding the compile problem.  I have worked with the maintainer
> previously while I was testing package to correct compile issues.  I
> also test result with success.  The external compiler I used at the
> time was linaro 2013.01 which was option in buildroot for ARM A8 then.
>  I will verify error with configuration you report and find a solution
> asap.

I must say I haven't tested with a Linaro toolchain, which is glibc
based, and I only tested with an uClibc based toolchain. However,
seeing the message, I don't really suspect a glibc vs. uClibc
difference.

Best regards,

Thomas

Dear Thomas,

Problem solved.  Details regarding source of problem are too
confounding to explain.  As it happens to be Simon Newton, the source
maintainer was about to release a new version within minutes of me
contacting him and we (he) was able to resolve it prior to the new
release.

Simon asked for and I provided him with details regarding how he can
verify that future development compiles under buildroot as he is aware
of and encourages Open lighting Architecture use in embedded
environments.  Again, thank you for your patience.  I am encouraged to
contribute more in the future where I can.

Dave



On Mon, Aug 12, 2013 at 2:01 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear David Skok,
>
> Please always keep the Buildroot mailing list Cc'ed when continuing
> discussions that started on the list.
>
> On Mon, 12 Aug 2013 08:26:57 -0400, David Skok wrote:
>
>> I've made the changes you point out.  My apologies but I don't know
>> what you mean by "patch is not wrapped" and is (is not?) proper
>> format.
>
> What I meant is that your latest patch was perfect.
>
> Often, when people send patches with their normal e-mail client, most
> e-mail clients tend to "wrap" lines at 80 characters or so: instead of
> having very very long lines, you have lines nicely wrapped at a
> reasonable length.
>
> However, while this is very useful when exchanging text, it falls apart
> when exchanging patches, because the wrapping feature of the e-mail
> clients breaks the patches and they can no longer be applied.
>
> By using 'git send-email' (as you did), you make sure that your e-mail
> client will not interfere with how the patch is sent, and specifically
> that it doesn't get wrapped.
>
>> I use git command line outlined in buildroot manual to send
>> it.  I am new to contributing to open source and am doing my best to
>> learn compliance for contribution.  Thank you for your patience so
>> far.
>>
>> Regarding the compile problem.  I have worked with the maintainer
>> previously while I was testing package to correct compile issues.  I
>> also test result with success.  The external compiler I used at the
>> time was linaro 2013.01 which was option in buildroot for ARM A8 then.
>>  I will verify error with configuration you report and find a solution
>> asap.
>
> I must say I haven't tested with a Linaro toolchain, which is glibc
> based, and I only tested with an uClibc based toolchain. However,
> seeing the message, I don't really suspect a glibc vs. uClibc
> difference.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com