ola: new package
PATCH 1/1 ola: new package
--- 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
package/Config.in +1 -0
@@ -277,6 +277,7 @@ source "package/minicom/Config.in" source "package/nanocom/Config.in" source "package/neard/Config.in" source "package/ofono/Config.in" +source "package/ola/Config.in" source "package/on2-8170-modules/Config.in" source "package/open2300/Config.in" source "package/openocd/Config.in"
package/ola/Config.in new file +143 -0
143 lines not on this page · raw message
package/ola/ola.mk new file +155 -0
155 lines not on this page · raw message
Signature · 1 line
1.8.3.4
PATCH 1/1 ola: new package
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.
package/ola/Config.in line 8
Quoted 8 lines · Dave Skok
package/ola/Config.in new file +8
-0+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
package/ola/Config.in line 17
Quoted 9 lines
package/ola/Config.in new file +9
-0+ 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.
Quoted 8 lines
package/ola/ola.mk new file +5
-0@@ -0,0 +1,155 @@ +################################################################################ +# +# ola +# +################################################################################
package/ola/ola.mk line 15
Quoted 10 lines
package/ola/ola.mk new file +10
-0+ +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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
A message that is not in the archive (sent off-list or not yet received): CALy4uEXhixrLNKzrRVsdYqCeNer6XPB_kXKwJepH8Pnh9+M+mA@mail.gmail.com
PATCH 1/1 ola: new package
Dear David Skok,
Please always keep the Buildroot mailing list Cc'ed when continuing discussions that started on the list.
Quoted 3 lines · David Skok
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.
Quoted 11 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 ola: new package
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
Quoted 51 lines · Thomas Petazzoni
Dear David Skok,
Please always keep the Buildroot mailing list Cc'ed when continuing discussions that started on the list.
Quoted 3 lines · David Skok
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.
Quoted 11 lines
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