* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08
@ 2014-01-09 7:30 Thomas Petazzoni
2014-01-09 19:14 ` Yann E. MORIN
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2014-01-09 7:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-01-08
===============================
success : 84
failures : 50
timeouts : 3
TOTAL : 137
Classification of failures by reason
====================================
aiccu-20070115 | 6
pixman-0.30.0 | 3
unknown | 3
alsa-utils-1.0.26 | 3
sysprof-1.1.8 | 2
cairo-1.12.10 | 2
ola-0.8.32 | 2
icu-51.2 | 2
rt-tests-0.83 | 2
thrift-0.9.1 | 2
dmraid-1.0.0.rc15 | 2
cryptsetup-1.6.3 | 2
systemd-44 | 1
qt5connectivity-5.2.0 | 1
toolchain-external-undefined | 1
bcusdk-0.0.5 | 1
crda-1.1.3 | 1
dhcpcd-6.1.0 | 1
libsigsegv-2.10 | 1
libpcap-1.5.1 | 1
php-5.5.7 | 1
ntp-4.2.6p5 | 1
wvstreams-4.6.1 | 1
imagemagick-6.8.8-1 | 1
weston-1.3.0 | 1
sdl-1.2.15 | 1
netsnmp-5.7.2 | 1
libv4l-0.8.9 | 1
host-elf2flt-20130904 | 1
poppler-0.24.4 | 1
libnfc-llcp-1103 | 1
zmqpp-30d72d95f2cfdf9c5cedf... | 1
tvheadend-c7d0335eb10d02b78... | 1
directfb-1.6.3 | 1
Detail of failures
===================
avr32 | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/d99f945ada3215b8580321dc789657c7d0697fc6/
avr32 | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/0df56efacbf66789840df6e08eb864d62fddbbf3/
x86_64 | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/8ac89656c786c04700b8fc8354aef47963f086e7/
powerpc | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/eb8854b5d8b5dfd6c8caa242dde71698c0dc263a/
powerpc | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/24fa6e0c317d6a13a9fd9348e2effcc2cb340a8b/
sh4a | aiccu-20070115 | NOK | http://autobuild.buildroot.net/results/e43edb6b30ddb00fb1ad585a5e0d59898ac368e1/
bfin | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/1d1cda7bcaf21af496fa21b0d87920d5dfa5254c/
bfin | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/518e50524c5eba495300d45c1558c9fc83b4da20/
bfin | alsa-utils-1.0.26 | NOK | http://autobuild.buildroot.net/results/2ab02782bc3fa1b3a2cf6ce086557cfd88fde410/
i686 | bcusdk-0.0.5 | NOK | http://autobuild.buildroot.net/results/ac46bec04dcf966284d279172d038dbed0595d15/
arm | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/b4ec231fff142827c3faada32d6d0d83c56ea1c9/
arm | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/45931ea228ae64ae4cd2fe7cab97ee36c45d47cf/
nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/277ecbaa3467f4bcfa7f69cc166500f4a782a21b/
sh4a | cryptsetup-1.6.3 | NOK | http://autobuild.buildroot.net/results/7649217bfce93bed71d56752922ee963700dc5a9/
powerpc | cryptsetup-1.6.3 | NOK | http://autobuild.buildroot.net/results/2be7ee750d4424976cb783e3a497f1b6bead8c98/
bfin | dhcpcd-6.1.0 | NOK | http://autobuild.buildroot.net/results/add75f89740a0d0a3b7082e5863fa83e547cddd5/
x86_64 | directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/5d714b0eb1d9c18ae8dbb855f7457020449ef83d/
arc | dmraid-1.0.0.rc15 | NOK | http://autobuild.buildroot.net/results/37a66954953311147eaf4d7fa87ff6406472c497/
arc | dmraid-1.0.0.rc15 | NOK | http://autobuild.buildroot.net/results/a6a48cc783dadf94c36c40cfe65edf7689a7f264/
arm | host-elf2flt-20130904 | NOK | http://autobuild.buildroot.net/results/fc6ca7d657c88afbe98a2de8d25738ccfef209b8/
bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/e4075fe0acf6ed6d706a9978d14f6f59eaeb0805/
bfin | icu-51.2 | NOK | http://autobuild.buildroot.net/results/1dac8bfb5d985b2c5ed6f90c3037d330e2737c35/
i686 | imagemagick-6.8.8-1 | NOK | http://autobuild.buildroot.net/results/b7caa662db07f811b28837ca2c5003be19bf3c00/
i686 | libnfc-llcp-1103 | NOK | http://autobuild.buildroot.net/results/b69577c10cd6c2ed207b1f181750e1ed144a907a/
powerpc | libpcap-1.5.1 | NOK | http://autobuild.buildroot.net/results/932ef0d4af220286d6b818dce26a64a3e27191ae/
microblaze | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/799ac378713d82f9632a2aa925223e21157b1042/
aarch64 | libv4l-0.8.9 | NOK | http://autobuild.buildroot.net/results/88688d689d31ae89dcc829755eda93ef59d800ab/
xtensa | netsnmp-5.7.2 | NOK | http://autobuild.buildroot.net/results/054f9af1c72103dd81fb1339fa88c5fee410b33e/
powerpc | ntp-4.2.6p5 | NOK | http://autobuild.buildroot.net/results/3f78dad1914781906eae7defca074c7ff731097d/
arm | ola-0.8.32 | NOK | http://autobuild.buildroot.net/results/40a5dde3b553e98c05a7f52d1c1ff7a230686c8b/
x86_64 | ola-0.8.32 | NOK | http://autobuild.buildroot.net/results/eb94659357e0dc68efd45aaa9e9fa03ee286f533/
arm | php-5.5.7 | NOK | http://autobuild.buildroot.net/results/fe928bccf65b5950fae904d922d00d630382f28d/
microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/d678f48125bbe59e89b627d247834c594845390b/
microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/a4b0ce0621701df55c146609388c3e529ea3411e/
microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/093646df3351c703014cc504a6f157bbde82af6c/
arm | poppler-0.24.4 | NOK | http://autobuild.buildroot.net/results/301643161cf4a7f7f9fbdc56c48c1e84db60ee5b/
arm | qt5connectivity-5.2.0 | NOK | http://autobuild.buildroot.net/results/262a1f0709748a6ab74c0f0ea64f5d4b7cbd945a/
mipsel | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/38dd62b618841b0e139be66ed2a2fe5261052ff9/
xtensa | rt-tests-0.83 | NOK | http://autobuild.buildroot.net/results/8aaa4b56a53241b7342fede568fbc72a7656cc38/
x86_64 | sdl-1.2.15 | NOK | http://autobuild.buildroot.net/results/70cfd649cfe96248a6bf35cb8f6f589982a36fd4/
powerpc | sysprof-1.1.8 | NOK | http://autobuild.buildroot.net/results/2c1a38f118162d16e332324424610b011eca14c9/
powerpc | sysprof-1.1.8 | NOK | http://autobuild.buildroot.net/results/e9d35fe6e63a90c047933062c5297a42f8c72a91/
i686 | systemd-44 | NOK | http://autobuild.buildroot.net/results/b68702f233c435c9bb3c4e0213c0f79eb36291d3/
x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/ebce3ee060f9b12519a48cc9610001a24f0add22/
avr32 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/4088ded448e1abae5e425072e8c769b19d558ecb/
mips64el | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a4136986568d291f8b55d41eeb5970394a35972f/
arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/827a5b39647fb83f20b449d8cace6a829af03d35/
x86_64 | unknown | TIM | http://autobuild.buildroot.net/results/4c46e1d25cb674e4098841fdf8f01a6edd8c2df9/
i686 | unknown | TIM | http://autobuild.buildroot.net/results/636e512a9a1cd1b479e444a7b45ff21e29ee3375/
powerpc | unknown | TIM | http://autobuild.buildroot.net/results/1f0c0bc6a45441e3ac9b42820d95ef4bb436f5bb/
i686 | weston-1.3.0 | NOK | http://autobuild.buildroot.net/results/b61f802d16a92717cd8ea701eb289cbc9719ba42/
xtensa | wvstreams-4.6.1 | NOK | http://autobuild.buildroot.net/results/db8a896b1f724163e14de03a605be16924b42925/
arm | zmqpp-30d72d95f2cfdf9c5cedf... | NOK | http://autobuild.buildroot.net/results/6198d72088dd72f9506ee65678eca9d3020fd718/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-09 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni @ 2014-01-09 19:14 ` Yann E. MORIN 2014-01-09 19:15 ` [Buildroot] [PATCH] package/ola: fix build against google.protobuf Yann E. MORIN 2014-01-09 23:29 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni 0 siblings, 2 replies; 10+ messages in thread From: Yann E. MORIN @ 2014-01-09 19:14 UTC (permalink / raw) To: buildroot On 2014-01-09 08:30 +0100, Thomas Petazzoni spake thusly: [--SNIP--] > Detail of failures [--SNIP--] > arm | ola-0.8.32 | NOK | http://autobuild.buildroot.net/results/40a5dde3b553e98c05a7f52d1c1ff7a230686c8b/ > x86_64 | ola-0.8.32 | NOK | http://autobuild.buildroot.net/results/eb94659357e0dc68efd45aaa9e9fa03ee286f533/ OK, so I've digged a bit into that ola build failure. What happens is that ola runs the host-python to check if it can 'import' the google.protobuf module. Of course, this fails since google.protobuf is installed in target/ and not in host/ (and we do not explicitly install a host-variant). So, this test is inherently flawed for cross-compilation. There is a very simple trick^Whack we can use to fix this issue, either: - remove the test entirely, since we enforce the dependency from the Config.in an ola.mk, and thus we know google.protobuf will be present - install a host-google-protobuf as well, so our host Python finds it. I've tested the first solution, and it builds fine. Not runtime-tested, since I don't have any OLP hardware. I'll shortly send a patch with this first solution. If any interested in this package could test and report sucess/failure, that be great! TIA! ;-) Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] package/ola: fix build against google.protobuf 2014-01-09 19:14 ` Yann E. MORIN @ 2014-01-09 19:15 ` Yann E. MORIN 2014-01-09 21:05 ` Peter Korsgaard 2014-01-09 23:29 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni 1 sibling, 1 reply; 10+ messages in thread From: Yann E. MORIN @ 2014-01-09 19:15 UTC (permalink / raw) To: buildroot From: "Yann E. MORIN" <yann.morin.1998@free.fr> To test for the google.protobuf presence, ola's ./conifgure runs the host Python. This is doomed to fail, as google.protobuf is installed in target/ and not in host/ Since our dependencies ensures that goole.protobuf is indeed installed before we attempt to configure and build ola, we can just ditch the test altogether. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- .../ola-0002-fix-check-for-google.protobuf.patch | 30 ++++++++++++++++++++++ package/ola/ola.mk | 3 +++ 2 files changed, 33 insertions(+) create mode 100644 package/ola/ola-0002-fix-check-for-google.protobuf.patch diff --git a/package/ola/ola-0002-fix-check-for-google.protobuf.patch b/package/ola/ola-0002-fix-check-for-google.protobuf.patch new file mode 100644 index 0000000..f0bc465 --- /dev/null +++ b/package/ola/ola-0002-fix-check-for-google.protobuf.patch @@ -0,0 +1,30 @@ +configure: do not check for google.protobuf + +The check for google.protobuf is inherently flawed for cross-compilation, +as it uses the host Python to check for target modules. + +In Buildroot, our dependencies ensures that google.protobuf is present +by the time we configure and build ola, so we can just skip the test +altogether. + +We don't need to fake the result of the test: it is used nowhere; the +test is only here to fail or succeed. + +Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> + +diff -durN ola-0.8.32.orig/configure.ac ola-0.8.32/configure.ac +--- ola-0.8.32.orig/configure.ac 2013-09-29 19:46:48.000000000 +0200 ++++ ola-0.8.32/configure.ac 2014-01-09 19:43:55.342044336 +0100 +@@ -530,7 +530,11 @@ + + if test "${enable_python_libs}" = "yes"; then + AM_PATH_PYTHON(2.6) +- AX_PYTHON_MODULE("google.protobuf", "fatal") ++# AX_PYTHON_MODULE is inherently broken for cross-compilation ++# since it executes the host Python to check for target modules. ++# In Buildroot, we do not need to check for google.protobuf, ++# since our dependencies ensure it is available. ++# AX_PYTHON_MODULE("google.protobuf", "fatal") + fi + + # Maybe build the logic sniffer tools diff --git a/package/ola/ola.mk b/package/ola/ola.mk index bc7de24..542aa77 100644 --- a/package/ola/ola.mk +++ b/package/ola/ola.mk @@ -11,6 +11,9 @@ OLA_LICENSE = LGPLv2.1+ (libola, libolacommon, Python bindings), GPLv2+ (libolas OLA_LICENSE_FILES = LICENCE GPL LGPL OLA_INSTALL_STAGING = YES +# We modify configure.ac, so we need to autoreconf +OLA_AUTORECONF = YES + # util-linux provides uuid lib OLA_DEPENDENCIES = protobuf util-linux host-bison host-flex -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] package/ola: fix build against google.protobuf 2014-01-09 19:15 ` [Buildroot] [PATCH] package/ola: fix build against google.protobuf Yann E. MORIN @ 2014-01-09 21:05 ` Peter Korsgaard 0 siblings, 0 replies; 10+ messages in thread From: Peter Korsgaard @ 2014-01-09 21:05 UTC (permalink / raw) To: buildroot >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > From: "Yann E. MORIN" <yann.morin.1998@free.fr> > To test for the google.protobuf presence, ola's ./conifgure runs the > host Python. This is doomed to fail, as google.protobuf is installed > in target/ and not in host/ > Since our dependencies ensures that goole.protobuf is indeed installed s/goole/google/ Committed with that fixed, thanks. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-09 19:14 ` Yann E. MORIN 2014-01-09 19:15 ` [Buildroot] [PATCH] package/ola: fix build against google.protobuf Yann E. MORIN @ 2014-01-09 23:29 ` Thomas Petazzoni 2014-01-11 23:17 ` Yann E. MORIN 1 sibling, 1 reply; 10+ messages in thread From: Thomas Petazzoni @ 2014-01-09 23:29 UTC (permalink / raw) To: buildroot Dear Yann E. MORIN, On Thu, 9 Jan 2014 20:14:27 +0100, Yann E. MORIN wrote: > What happens is that ola runs the host-python to check if it can > 'import' the google.protobuf module. > > Of course, this fails since google.protobuf is installed in target/ and > not in host/ (and we do not explicitly install a host-variant). Correct. But what is odd is that this test was *not* failing before the migration to the Python infrastructure. I've started investigating this, but haven't found the reason why before the Python infra it was building OK, and not after the Python infra. > There is a very simple trick^Whack we can use to fix this issue, either: > - remove the test entirely, since we enforce the dependency from the > Config.in an ola.mk, and thus we know google.protobuf will be > present The problem of this solution is that the patch you've done cannot be upstreamed, and therefore we would have to keep AUTORECONF = YES forever on this package. Maybe we can make the configure.ac test conditional on whether we're cross-compiling and push the patch upstream? Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-09 23:29 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni @ 2014-01-11 23:17 ` Yann E. MORIN 2014-01-14 6:59 ` Arnout Vandecappelle 0 siblings, 1 reply; 10+ messages in thread From: Yann E. MORIN @ 2014-01-11 23:17 UTC (permalink / raw) To: buildroot Thomas, All, On 2014-01-10 07:29 +0800, Thomas Petazzoni spake thusly: > On Thu, 9 Jan 2014 20:14:27 +0100, Yann E. MORIN wrote: > > What happens is that ola runs the host-python to check if it can > > 'import' the google.protobuf module. > > > > Of course, this fails since google.protobuf is installed in target/ and > > not in host/ (and we do not explicitly install a host-variant). > > Correct. But what is odd is that this test was *not* failing before the > migration to the Python infrastructure. I've started investigating > this, but haven't found the reason why before the Python infra it was > building OK, and not after the Python infra. > > > There is a very simple trick^Whack we can use to fix this issue, either: > > - remove the test entirely, since we enforce the dependency from the > > Config.in an ola.mk, and thus we know google.protobuf will be > > present > > The problem of this solution is that the patch you've done cannot be > upstreamed, and therefore we would have to keep AUTORECONF = YES > forever on this package. Maybe we can make the configure.ac test > conditional on whether we're cross-compiling and push the patch > upstream? I understand your conerns, and in fact was not expecting the patch to be applied that fast! ;-] Now, if we add a check, I don;t know how to handle this. After all, a check is here to detect whether a dependency is present or missing. So we ehould expect the following from ./configure: - user did not request the feature: if the dependencies are present, it is enabled; if they are missign it is disabled; - user explicitly required the feature to be disabled: no problem, the feature is disabled and ./configure does not even need to check for the dependencies at all; - user explictly required the feature to be enabled: ./configure has to check if the dependencies are met, and abort if not. Ideally, we should be able to check target dependencies, but this is not possible with Python. So, while cross-compiling we can not check those dependencies, what should we do? - user did not explictly reuired the feature: detect we're cross-compiling, and disable it (or enable it?) - user explixitly required the feature to be enabled: trust the user that the dependencies are met, without checking, at the risk of a mis-behaviour at build time, or worse, at runtime? I really don't know what is best to do. I think I'll do the above and try to get the patch upstreamed. Let's see what hey think about it. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-11 23:17 ` Yann E. MORIN @ 2014-01-14 6:59 ` Arnout Vandecappelle 2014-01-14 20:35 ` Yann E. MORIN 2014-01-26 6:37 ` Thomas Petazzoni 0 siblings, 2 replies; 10+ messages in thread From: Arnout Vandecappelle @ 2014-01-14 6:59 UTC (permalink / raw) To: buildroot On 12/01/14 00:17, Yann E. MORIN wrote: > Thomas, All, > > On 2014-01-10 07:29 +0800, Thomas Petazzoni spake thusly: >> On Thu, 9 Jan 2014 20:14:27 +0100, Yann E. MORIN wrote: >>> What happens is that ola runs the host-python to check if it can >>> 'import' the google.protobuf module. >>> >>> Of course, this fails since google.protobuf is installed in target/ and >>> not in host/ (and we do not explicitly install a host-variant). >> >> Correct. But what is odd is that this test was *not* failing before the >> migration to the Python infrastructure. I've started investigating >> this, but haven't found the reason why before the Python infra it was >> building OK, and not after the Python infra. >> >>> There is a very simple trick^Whack we can use to fix this issue, either: >>> - remove the test entirely, since we enforce the dependency from the >>> Config.in an ola.mk, and thus we know google.protobuf will be >>> present >> >> The problem of this solution is that the patch you've done cannot be >> upstreamed, and therefore we would have to keep AUTORECONF = YES >> forever on this package. Maybe we can make the configure.ac test >> conditional on whether we're cross-compiling and push the patch >> upstream? > > I understand your conerns, and in fact was not expecting the patch to be > applied that fast! ;-] > > Now, if we add a check, I don;t know how to handle this. > > After all, a check is here to detect whether a dependency is present or > missing. So we ehould expect the following from ./configure: > > - user did not request the feature: if the dependencies are present, > it is enabled; if they are missign it is disabled; > > - user explicitly required the feature to be disabled: no problem, > the feature is disabled and ./configure does not even need to check > for the dependencies at all; > > - user explictly required the feature to be enabled: ./configure has > to check if the dependencies are met, and abort if not. > > Ideally, we should be able to check target dependencies, but this is not > possible with Python. So, while cross-compiling we can not check those > dependencies, what should we do? > > - user did not explictly reuired the feature: detect we're > cross-compiling, and disable it (or enable it?) > > - user explixitly required the feature to be enabled: trust the user > that the dependencies are met, without checking, at the risk of a > mis-behaviour at build time, or worse, at runtime? > > I really don't know what is best to do. I think I'll do the above and > try to get the patch upstreamed. Let's see what hey think about it. What should definitely be upstreamable, is to add a cache variable for this option. Then we can set the cache variable from buildroot like we do for so many other things already. 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-14 6:59 ` Arnout Vandecappelle @ 2014-01-14 20:35 ` Yann E. MORIN 2014-01-26 6:37 ` Thomas Petazzoni 1 sibling, 0 replies; 10+ messages in thread From: Yann E. MORIN @ 2014-01-14 20:35 UTC (permalink / raw) To: buildroot Arnout, All, On 2014-01-14 07:59 +0100, Arnout Vandecappelle spake thusly: > On 12/01/14 00:17, Yann E. MORIN wrote: > >On 2014-01-10 07:29 +0800, Thomas Petazzoni spake thusly: [--SNIP--] > >>The problem of this solution is that the patch you've done cannot be > >>upstreamed, and therefore we would have to keep AUTORECONF = YES > >>forever on this package. Maybe we can make the configure.ac test > >>conditional on whether we're cross-compiling and push the patch > >>upstream? [--SNIP--] > >I really don't know what is best to do. I think I'll do the above and > >try to get the patch upstreamed. Let's see what hey think about it. > What should definitely be upstreamable, is to add a cache variable for this > option. Then we can set the cache variable from buildroot like we do for so > many other things already. He, that's indeed a good idea! It turned out to be not so easy, since their configure.ac and helpers are not really nicely coded, but I managed to do something that looks to be working. Patches are on their way to the list, and after reviews, I'll try to upstream them (after rebasing onto their master, which as changed a lot). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-14 6:59 ` Arnout Vandecappelle 2014-01-14 20:35 ` Yann E. MORIN @ 2014-01-26 6:37 ` Thomas Petazzoni 2014-01-26 10:30 ` Yann E. MORIN 1 sibling, 1 reply; 10+ messages in thread From: Thomas Petazzoni @ 2014-01-26 6:37 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Tue, 14 Jan 2014 07:59:23 +0100, Arnout Vandecappelle wrote: > > I really don't know what is best to do. I think I'll do the above and > > try to get the patch upstreamed. Let's see what hey think about it. > > What should definitely be upstreamable, is to add a cache variable for > this option. Then we can set the cache variable from buildroot like we do > for so many other things already. Yes, that is usually the right solution for this type of problem. It allows to tell configure that we know what we're doing :-) Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 2014-01-26 6:37 ` Thomas Petazzoni @ 2014-01-26 10:30 ` Yann E. MORIN 0 siblings, 0 replies; 10+ messages in thread From: Yann E. MORIN @ 2014-01-26 10:30 UTC (permalink / raw) To: buildroot Thomas, All, On 2014-01-26 07:37 +0100, Thomas Petazzoni spake thusly: > On Tue, 14 Jan 2014 07:59:23 +0100, Arnout Vandecappelle wrote: > > > I really don't know what is best to do. I think I'll do the above and > > > try to get the patch upstreamed. Let's see what hey think about it. > > > > What should definitely be upstreamable, is to add a cache variable for > > this option. Then we can set the cache variable from buildroot like we do > > for so many other things already. > > Yes, that is usually the right solution for this type of problem. It > allows to tell configure that we know what we're doing :-) Yes. This has been upstreamed now (albeit slightly differently from the patch we carry in Buildroot). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-01-26 10:30 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-09 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni 2014-01-09 19:14 ` Yann E. MORIN 2014-01-09 19:15 ` [Buildroot] [PATCH] package/ola: fix build against google.protobuf Yann E. MORIN 2014-01-09 21:05 ` Peter Korsgaard 2014-01-09 23:29 ` [Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08 Thomas Petazzoni 2014-01-11 23:17 ` Yann E. MORIN 2014-01-14 6:59 ` Arnout Vandecappelle 2014-01-14 20:35 ` Yann E. MORIN 2014-01-26 6:37 ` Thomas Petazzoni 2014-01-26 10:30 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox