[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] package/ola: fix build against google.protobuf

[Yann E. MORIN]

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

[Buildroot] [PATCH] package/ola: fix build against google.protobuf

[Peter Korsgaard]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Arnout Vandecappelle]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-01-08

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'