All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
@ 2014-02-08  7:30 Thomas Petazzoni
  2014-02-08 12:49 ` Yann E. MORIN
  0 siblings, 1 reply; 13+ messages in thread
From: Thomas Petazzoni @ 2014-02-08  7:30 UTC (permalink / raw)
  To: buildroot

Build statistics for 2014-02-07
===============================

        success : 99 
       failures : 33 
       timeouts : 0  
          TOTAL : 132

Classification of failures by reason
====================================

                     vlc-2.1.2 | 6 
         dvb-apps-be76da69f250 | 2 
                libnftnl-1.0.0 | 2 
         qt5connectivity-5.2.0 | 1 
                   open2300-12 | 1 
                      qt-4.8.5 | 1 
                    systemd-44 | 1 
                 cairo-1.12.10 | 1 
           imagemagick-6.8.8-4 | 1 
             util-linux-2.23.2 | 1 
               w_scan-20130331 | 1 
                 libxml2-2.9.1 | 1 
                oprofile-0.9.8 | 1 
                       joe-3.7 | 1 
                coreutils-8.21 | 1 
                elfutils-0.155 | 1 
                 qt5base-5.2.0 | 1 
                 webkit-1.11.5 | 1 
        ltp-testsuite-20130904 | 1 
                       kmod-16 | 1 
                    mpd-0.18.7 | 1 
                      icu-51.2 | 1 
                  thrift-0.9.1 | 1 
              gst1-libav-1.2.2 | 1 
                rtorrent-0.9.3 | 1 
                  samba-3.6.22 | 1 

Detail of failures
===================

      bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/3f004a970796cfc22bc2256767e4c5dcb87da78b/
    xtensa |                 coreutils-8.21 | NOK | http://autobuild.buildroot.net/results/566dc533f7afe7279d8ee53663d2e9c5a3952a96/
       arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
       arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
      bfin |                 elfutils-0.155 | NOK | http://autobuild.buildroot.net/results/5b5eec3fba50ee8ce4d5908a9ee368e4e72d87a1/
    x86_64 |               gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/5fa8193a716c8f05bdb99f5446709b1ca906496a/
     avr32 |                       icu-51.2 | NOK | http://autobuild.buildroot.net/results/b741e1ce412bec7f7e14ab1dd6385b9e55140c6d/
      i686 |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/5c118d29d0f1ab73b24721be64fbb82f0c3a3b8b/
      bfin |                        joe-3.7 | NOK | http://autobuild.buildroot.net/results/f920c85244afffe38497459753bf005946001d0d/
    xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/9d88ec290a96a5862ba03a9b7d8c9b9a8c2558f4/
   powerpc |                 libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/b401337fdbcd73dd944067bfe05d1370d455acd3/
   powerpc |                 libnftnl-1.0.0 | NOK | http://autobuild.buildroot.net/results/1ece4286d70f2ae033c1dda9d481050d16cce695/
       arc |                  libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/7158a2a19da6bfa950125a951a39061ccaa73101/
       arm |         ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/19a77a8c2537a92e386d5f1d1c10ad914fe02236/
   powerpc |                     mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/33c1367f7c299ef00cb880386b1416490bf8e1c5/
  mips64el |                    open2300-12 | NOK | http://autobuild.buildroot.net/results/d60b908aca08179fc495c42d51cc1625f51f394b/
       arc |                 oprofile-0.9.8 | NOK | http://autobuild.buildroot.net/results/514f484496750317a5b2f371767a09730c8cf721/
      i686 |                       qt-4.8.5 | NOK | http://autobuild.buildroot.net/results/550b1542367eacfb11fb1c32ef496d2a30d391c6/
      i686 |                  qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/91f273dd11280f0d74f7892e66a47114b395eddb/
      i686 |          qt5connectivity-5.2.0 | NOK | http://autobuild.buildroot.net/results/7fe5eeb89190c790f8e6783aa1a21e47907a111b/
       arc |                 rtorrent-0.9.3 | NOK | http://autobuild.buildroot.net/results/a37dd7663a19897421c9cee99679710a4b56b3fc/
     nios2 |                   samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/0e86eb19365fbe4f6e341638d0c13fb1ad15c707/
      i686 |                     systemd-44 | NOK | http://autobuild.buildroot.net/results/490d9730ddffca4f105fb6cf73ac4ad28e6e1eb1/
    x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/a972190f8715b87f38023170b3e907c99e5104fe/
   powerpc |              util-linux-2.23.2 | NOK | http://autobuild.buildroot.net/results/3a734dc7271c080ef9d5ad88faa1d031db6afdab/
       arm |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/19f1450ed5453aa666bc7aae2e965ad81e5f845d/
  mips64el |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/5e42d1139bbbed2421193d8acc52df9442c43730/
       arm |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/344af6e756a5f2c1ee515a355ae5b288401c4c71/
      mips |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/41615b8c9b09654a3f7b750cd784118c1e4795c0/
      sh4a |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/f8bed9a42f1853db8aa81161d7be5a7cb67afe8f/
      mips |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/d03753f956db98f7a1f7c5b7a5d534e281827c46/
   powerpc |                  webkit-1.11.5 | NOK | http://autobuild.buildroot.net/results/77966c174bfaecce947fee0de63740cf801ba534/
   powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/


-- 
http://autobuild.buildroot.net

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-08  7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07 Thomas Petazzoni
@ 2014-02-08 12:49 ` Yann E. MORIN
  2014-02-10  8:31   ` Thomas Petazzoni
  0 siblings, 1 reply; 13+ messages in thread
From: Yann E. MORIN @ 2014-02-08 12:49 UTC (permalink / raw)
  To: buildroot

Thomas, All,

On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
> Build statistics for 2014-02-07
>        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
>        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/

Too old toolchain:
  - SYS_TURBO was introduced in linux 3.2
  - SYS_DVBC_ANNEX_A in linux 3.2
  - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3

>    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/

Too old toolchain, as usual.

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] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-08 12:49 ` Yann E. MORIN
@ 2014-02-10  8:31   ` Thomas Petazzoni
  2014-02-10 10:27     ` Thomas De Schampheleire
  2014-02-10 17:31     ` Yann E. MORIN
  0 siblings, 2 replies; 13+ messages in thread
From: Thomas Petazzoni @ 2014-02-10  8:31 UTC (permalink / raw)
  To: buildroot

Dear Yann E. MORIN,

On Sat, 8 Feb 2014 13:49:07 +0100, Yann E. MORIN wrote:

> On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
> > Build statistics for 2014-02-07
> >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
> >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
> 
> Too old toolchain:
>   - SYS_TURBO was introduced in linux 3.2
>   - SYS_DVBC_ANNEX_A in linux 3.2
>   - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3

The too old toolchain in question is Linaro 2013.11, i.e a fairly
recent Linaro toolchain. I believe kernel 3.2/3.3 are not that old for
embedded products, and we should support toolchains that have such old
kernel headers.

> >    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/
> 
> Too old toolchain, as usual.

This one I agree is old. The question is: how do I exclude this package
from being built. Should we introduce hidden Config.in bools for kernel
header versions, so that the packages that need at least the kernel
headers from kernel X.Y are not visible if you have a too old
toolchain? Those bools would be set by linux-headers/Config.in for the
internal backend, automatically set for the well-known external
toolchains, and a custom choice for special external toolchains.

Thoughts?

Best regards,

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10  8:31   ` Thomas Petazzoni
@ 2014-02-10 10:27     ` Thomas De Schampheleire
  2014-02-10 17:39       ` Arnout Vandecappelle
  2014-02-10 17:31     ` Yann E. MORIN
  1 sibling, 1 reply; 13+ messages in thread
From: Thomas De Schampheleire @ 2014-02-10 10:27 UTC (permalink / raw)
  To: buildroot

On Mon, Feb 10, 2014 at 9:31 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Yann E. MORIN,
>
> On Sat, 8 Feb 2014 13:49:07 +0100, Yann E. MORIN wrote:
>
>> On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
>> > Build statistics for 2014-02-07
>> >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
>> >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
>>
>> Too old toolchain:
>>   - SYS_TURBO was introduced in linux 3.2
>>   - SYS_DVBC_ANNEX_A in linux 3.2
>>   - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3
>
> The too old toolchain in question is Linaro 2013.11, i.e a fairly
> recent Linaro toolchain. I believe kernel 3.2/3.3 are not that old for
> embedded products, and we should support toolchains that have such old
> kernel headers.
>
>> >    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/
>>
>> Too old toolchain, as usual.
>
> This one I agree is old. The question is: how do I exclude this package
> from being built. Should we introduce hidden Config.in bools for kernel
> header versions, so that the packages that need at least the kernel
> headers from kernel X.Y are not visible if you have a too old
> toolchain? Those bools would be set by linux-headers/Config.in for the
> internal backend, automatically set for the well-known external
> toolchains, and a custom choice for special external toolchains.

I think we should indeed implement a mechanism to restrict packages
based on kernel headers.
There have been many packages that require recent kernel headers, and
it is not feasible to fix all these packages individually. Forcing the
user to update their kernel headers or toolchain is not unreasonable,
and otherwise they are always welcome to propose a patch for a
particular package, or discuss the matter upstream.

The solution you propose seems a good idea to me and not too complex.

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10  8:31   ` Thomas Petazzoni
  2014-02-10 10:27     ` Thomas De Schampheleire
@ 2014-02-10 17:31     ` Yann E. MORIN
  2014-02-10 17:44       ` Thomas De Schampheleire
  2014-02-10 17:44       ` Thomas Petazzoni
  1 sibling, 2 replies; 13+ messages in thread
From: Yann E. MORIN @ 2014-02-10 17:31 UTC (permalink / raw)
  To: buildroot

Thomas, All,

On 2014-02-10 09:31 +0100, Thomas Petazzoni spake thusly:
> On Sat, 8 Feb 2014 13:49:07 +0100, Yann E. MORIN wrote:
> 
> > On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
> > > Build statistics for 2014-02-07
> > >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
> > >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
> > 
> > Too old toolchain:
> >   - SYS_TURBO was introduced in linux 3.2
> >   - SYS_DVBC_ANNEX_A in linux 3.2
> >   - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3
> 
> The too old toolchain in question is Linaro 2013.11, i.e a fairly
> recent Linaro toolchain. I believe kernel 3.2/3.3 are not that old for
> embedded products, and we should support toolchains that have such old
> kernel headers.

Sorry, I should have said: kernel-headers too old.

That toolchain is using headers from Linux 3.1.1, which are too old to
have the required defines (since they appeared in 3.3).

So, same issue, just a different phrasing.

> > >    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/
> > 
> > Too old toolchain, as usual.
> 
> This one I agree is old. The question is: how do I exclude this package
> from being built. Should we introduce hidden Config.in bools for kernel
> header versions, so that the packages that need at least the kernel
> headers from kernel X.Y are not visible if you have a too old
> toolchain? Those bools would be set by linux-headers/Config.in for the
> internal backend, automatically set for the well-known external
> toolchains, and a custom choice for special external toolchains.
> 
> Thoughts?

Something like:

    config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
        bool

    config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
        select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1

    config BR2_PACKAGE_DVB_APPS
        depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1

And so on for all the headers version of interest?

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] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 10:27     ` Thomas De Schampheleire
@ 2014-02-10 17:39       ` Arnout Vandecappelle
  2014-02-10 20:07         ` Thomas Petazzoni
  0 siblings, 1 reply; 13+ messages in thread
From: Arnout Vandecappelle @ 2014-02-10 17:39 UTC (permalink / raw)
  To: buildroot

On 02/10/14 11:27, Thomas De Schampheleire wrote:
> On Mon, Feb 10, 2014 at 9:31 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Yann E. MORIN,
>>
>> On Sat, 8 Feb 2014 13:49:07 +0100, Yann E. MORIN wrote:
>>
>>> On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
>>>> Build statistics for 2014-02-07
>>>>        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
>>>>        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
>>>
>>> Too old toolchain:
>>>   - SYS_TURBO was introduced in linux 3.2
>>>   - SYS_DVBC_ANNEX_A in linux 3.2
>>>   - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3
>>
>> The too old toolchain in question is Linaro 2013.11, i.e a fairly
>> recent Linaro toolchain. I believe kernel 3.2/3.3 are not that old for
>> embedded products, and we should support toolchains that have such old
>> kernel headers.
>>
>>>>    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/
>>>
>>> Too old toolchain, as usual.
>>
>> This one I agree is old. The question is: how do I exclude this package
>> from being built. Should we introduce hidden Config.in bools for kernel
>> header versions, so that the packages that need at least the kernel
>> headers from kernel X.Y are not visible if you have a too old
>> toolchain? Those bools would be set by linux-headers/Config.in for the
>> internal backend, automatically set for the well-known external
>> toolchains, and a custom choice for special external toolchains.
> 
> I think we should indeed implement a mechanism to restrict packages
> based on kernel headers.
> There have been many packages that require recent kernel headers, and
> it is not feasible to fix all these packages individually. Forcing the
> user to update their kernel headers or toolchain is not unreasonable,
> and otherwise they are always welcome to propose a patch for a
> particular package, or discuss the matter upstream.
> 
> The solution you propose seems a good idea to me and not too complex.

 I had also thought about this option already. However, I expect the "not
too complex" is not entirely true: you probably want symbols from
something like 2.6.36 up to 3.13... Hm, that's just 20 symbols, maybe not
so bad after all. However, for custom external toolchains and for custom
kernel headers, all of these have to be made visible as well, so that
adds another 20 symbols...

 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] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:31     ` Yann E. MORIN
@ 2014-02-10 17:44       ` Thomas De Schampheleire
  2014-02-10 17:51         ` Thomas Petazzoni
  2014-02-10 17:51         ` Yann E. MORIN
  2014-02-10 17:44       ` Thomas Petazzoni
  1 sibling, 2 replies; 13+ messages in thread
From: Thomas De Schampheleire @ 2014-02-10 17:44 UTC (permalink / raw)
  To: buildroot

On Mon, Feb 10, 2014 at 6:31 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2014-02-10 09:31 +0100, Thomas Petazzoni spake thusly:
>> On Sat, 8 Feb 2014 13:49:07 +0100, Yann E. MORIN wrote:
>>
>> > On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
>> > > Build statistics for 2014-02-07
>> > >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/310e355f2f601801e4500b9d3e714d3883e7aa32/
>> > >        arm |          dvb-apps-be76da69f250 | NOK | http://autobuild.buildroot.net/results/90e1a2e3e428e6c3fe5b51668ab92c139f176260/
>> >
>> > Too old toolchain:
>> >   - SYS_TURBO was introduced in linux 3.2
>> >   - SYS_DVBC_ANNEX_A in linux 3.2
>> >   - SYS_DVBC_ANNEX_C and DTV_ENUM_DELSYS in linux 3.3
>>
>> The too old toolchain in question is Linaro 2013.11, i.e a fairly
>> recent Linaro toolchain. I believe kernel 3.2/3.3 are not that old for
>> embedded products, and we should support toolchains that have such old
>> kernel headers.
>
> Sorry, I should have said: kernel-headers too old.
>
> That toolchain is using headers from Linux 3.1.1, which are too old to
> have the required defines (since they appeared in 3.3).
>
> So, same issue, just a different phrasing.
>
>> > >    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/549564293607c959fa09e12510bb2aaa79f4f479/
>> >
>> > Too old toolchain, as usual.
>>
>> This one I agree is old. The question is: how do I exclude this package
>> from being built. Should we introduce hidden Config.in bools for kernel
>> header versions, so that the packages that need at least the kernel
>> headers from kernel X.Y are not visible if you have a too old
>> toolchain? Those bools would be set by linux-headers/Config.in for the
>> internal backend, automatically set for the well-known external
>> toolchains, and a custom choice for special external toolchains.
>>
>> Thoughts?
>
> Something like:
>
>     config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
>         bool
>
>     config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
>         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
>
>     config BR2_PACKAGE_DVB_APPS
>         depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
>
> And so on for all the headers version of interest?

So suppose we need to be able to check on 2_6_3, 3_0 and 3_1, the
linaro symbol would become:
     config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_3
         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1

right?

And when adding a check on a previously unchecked version, all the
toolchains need to be updated.

It's a pity that there is no comparison operator in kconfig, this
would make this more easy...

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:31     ` Yann E. MORIN
  2014-02-10 17:44       ` Thomas De Schampheleire
@ 2014-02-10 17:44       ` Thomas Petazzoni
  1 sibling, 0 replies; 13+ messages in thread
From: Thomas Petazzoni @ 2014-02-10 17:44 UTC (permalink / raw)
  To: buildroot

Dear Yann E. MORIN,

On Mon, 10 Feb 2014 18:31:37 +0100, Yann E. MORIN wrote:

> Something like:
> 
>     config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
>         bool
> 
>     config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
>         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> 
>     config BR2_PACKAGE_DVB_APPS
>         depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> 
> And so on for all the headers version of interest?

Yes, exactly.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:44       ` Thomas De Schampheleire
@ 2014-02-10 17:51         ` Thomas Petazzoni
  2014-02-10 17:55           ` Yann E. MORIN
  2014-02-10 17:51         ` Yann E. MORIN
  1 sibling, 1 reply; 13+ messages in thread
From: Thomas Petazzoni @ 2014-02-10 17:51 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Mon, 10 Feb 2014 18:44:21 +0100, Thomas De Schampheleire wrote:

> So suppose we need to be able to check on 2_6_3, 3_0 and 3_1, the
> linaro symbol would become:
>      config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_3
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> 
> right?

No. BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1 would already
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0, which selects 2.6.39 and so
on.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:44       ` Thomas De Schampheleire
  2014-02-10 17:51         ` Thomas Petazzoni
@ 2014-02-10 17:51         ` Yann E. MORIN
  1 sibling, 0 replies; 13+ messages in thread
From: Yann E. MORIN @ 2014-02-10 17:51 UTC (permalink / raw)
  To: buildroot

Thomas?, All,

On 2014-02-10 18:44 +0100, Thomas De Schampheleire spake thusly:
> On Mon, Feb 10, 2014 at 6:31 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >> > On 2014-02-08 08:30 +0100, Thomas Petazzoni spake thusly:
[--SNIP--]
> >> This one I agree is old. The question is: how do I exclude this package
> >> from being built. Should we introduce hidden Config.in bools for kernel
> >> header versions, so that the packages that need at least the kernel
> >> headers from kernel X.Y are not visible if you have a too old
> >> toolchain? Those bools would be set by linux-headers/Config.in for the
> >> internal backend, automatically set for the well-known external
> >> toolchains, and a custom choice for special external toolchains.
> >>
> >> Thoughts?
> >
> > Something like:
> >
> >     config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> >         bool
> >
> >     config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
> >         select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> >
> >     config BR2_PACKAGE_DVB_APPS
> >         depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> >
> > And so on for all the headers version of interest?
> 
> So suppose we need to be able to check on 2_6_3, 3_0 and 3_1, the
> linaro symbol would become:
>      config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_3
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
>          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> 
> right?

I was thinking of something a bit more complete (just an example, not
actual values):

    config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
        bool

    config BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
        bool
        select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0

    config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
        bool "Linaro 2013.11"
        select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1

    config BR2_PACKAGE_DVB_APPS
        bool "dvb-apps"
        depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0

That way, the _AT_LEAST_3_0 would be selected automatically since the
toolchain would select _AT_LEAST_3_1

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] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:51         ` Thomas Petazzoni
@ 2014-02-10 17:55           ` Yann E. MORIN
  0 siblings, 0 replies; 13+ messages in thread
From: Yann E. MORIN @ 2014-02-10 17:55 UTC (permalink / raw)
  To: buildroot

Thomas?, All,

On 2014-02-10 18:51 +0100, Thomas Petazzoni spake thusly:
> On Mon, 10 Feb 2014 18:44:21 +0100, Thomas De Schampheleire wrote:
> 
> > So suppose we need to be able to check on 2_6_3, 3_0 and 3_1, the
> > linaro symbol would become:
> >      config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11
> >          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_3
> >          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
> >          select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
> > 
> > right?
> 
> No. BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1 would already
> select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0, which selects 2.6.39 and so
> on.

Exactly. And we would only have the headers version we're interested in,
not every single one of them (I guess).

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] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 17:39       ` Arnout Vandecappelle
@ 2014-02-10 20:07         ` Thomas Petazzoni
  2014-02-11  7:18           ` Arnout Vandecappelle
  0 siblings, 1 reply; 13+ messages in thread
From: Thomas Petazzoni @ 2014-02-10 20:07 UTC (permalink / raw)
  To: buildroot

Dear Arnout Vandecappelle,

On Mon, 10 Feb 2014 18:39:48 +0100, Arnout Vandecappelle wrote:

> >> This one I agree is old. The question is: how do I exclude this package
> >> from being built. Should we introduce hidden Config.in bools for kernel
> >> header versions, so that the packages that need at least the kernel
> >> headers from kernel X.Y are not visible if you have a too old
> >> toolchain? Those bools would be set by linux-headers/Config.in for the
> >> internal backend, automatically set for the well-known external
> >> toolchains, and a custom choice for special external toolchains.
> > 
> > I think we should indeed implement a mechanism to restrict packages
> > based on kernel headers.
> > There have been many packages that require recent kernel headers, and
> > it is not feasible to fix all these packages individually. Forcing the
> > user to update their kernel headers or toolchain is not unreasonable,
> > and otherwise they are always welcome to propose a patch for a
> > particular package, or discuss the matter upstream.
> > 
> > The solution you propose seems a good idea to me and not too complex.
> 
>  I had also thought about this option already. However, I expect the "not
> too complex" is not entirely true: you probably want symbols from
> something like 2.6.36 up to 3.13... Hm, that's just 20 symbols, maybe not
> so bad after all. However, for custom external toolchains and for custom
> kernel headers, all of these have to be made visible as well, so that
> adds another 20 symbols...

True, but I don't really see another solution that solves the problem
at hand...

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
  2014-02-10 20:07         ` Thomas Petazzoni
@ 2014-02-11  7:18           ` Arnout Vandecappelle
  0 siblings, 0 replies; 13+ messages in thread
From: Arnout Vandecappelle @ 2014-02-11  7:18 UTC (permalink / raw)
  To: buildroot

On 02/10/14 21:07, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Mon, 10 Feb 2014 18:39:48 +0100, Arnout Vandecappelle wrote:
> 
>>>> This one I agree is old. The question is: how do I exclude this package
>>>> from being built. Should we introduce hidden Config.in bools for kernel
>>>> header versions, so that the packages that need at least the kernel
>>>> headers from kernel X.Y are not visible if you have a too old
>>>> toolchain? Those bools would be set by linux-headers/Config.in for the
>>>> internal backend, automatically set for the well-known external
>>>> toolchains, and a custom choice for special external toolchains.
>>>
>>> I think we should indeed implement a mechanism to restrict packages
>>> based on kernel headers.
>>> There have been many packages that require recent kernel headers, and
>>> it is not feasible to fix all these packages individually. Forcing the
>>> user to update their kernel headers or toolchain is not unreasonable,
>>> and otherwise they are always welcome to propose a patch for a
>>> particular package, or discuss the matter upstream.
>>>
>>> The solution you propose seems a good idea to me and not too complex.
>>
>>  I had also thought about this option already. However, I expect the "not
>> too complex" is not entirely true: you probably want symbols from
>> something like 2.6.36 up to 3.13... Hm, that's just 20 symbols, maybe not
>> so bad after all. However, for custom external toolchains and for custom
>> kernel headers, all of these have to be made visible as well, so that
>> adds another 20 symbols...
> 
> True, but I don't really see another solution that solves the problem
> at hand...

 Neither do I.

 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] 13+ messages in thread

end of thread, other threads:[~2014-02-11  7:18 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-08  7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07 Thomas Petazzoni
2014-02-08 12:49 ` Yann E. MORIN
2014-02-10  8:31   ` Thomas Petazzoni
2014-02-10 10:27     ` Thomas De Schampheleire
2014-02-10 17:39       ` Arnout Vandecappelle
2014-02-10 20:07         ` Thomas Petazzoni
2014-02-11  7:18           ` Arnout Vandecappelle
2014-02-10 17:31     ` Yann E. MORIN
2014-02-10 17:44       ` Thomas De Schampheleire
2014-02-10 17:51         ` Thomas Petazzoni
2014-02-10 17:55           ` Yann E. MORIN
2014-02-10 17:51         ` Yann E. MORIN
2014-02-10 17:44       ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.