[Buildroot] [autobuild.buildroot.net] Build results for 2018-02-25

[Buildroot] [autobuild.buildroot.net] Build results for 2018-02-25

[Thomas Petazzoni]

Hello,

Build statistics for 2018-02-25
===============================

      branch |  OK | NOK | TIM | TOT |
      master | 147 |  32 |   0 | 179 |
   2017.11.x |  25 |   1 |   0 |  26 |
        next |  40 |  19 |   0 |  59 |

Results for branch 'master'
===========================

Classification of failures by reason
------------------------------------

                     php-7.2.2 | 7 
                  boost-1.66.0 | 6 
             bluez5_utils-5.48 | 4 
                 hiawatha-10.6 | 2 
              host-erlang-20.0 | 2 
                    sdl2-2.0.7 | 2 
               binutils-2.29.1 | 1 
          host-rust-bin-1.23.0 | 1 
                 mesa3d-17.3.5 | 1 
                 mplayer-1.3.0 | 1 
                    mpv-0.27.0 | 1 
                      qt-4.8.7 | 1 
                   systemd-237 | 1 
    trace-cmd-trace-cmd-v2.6.1 | 1 
uclibc-ng-test-c6d62cbc6050... | 1 


Detail of failures
------------------

     powerpc |                binutils-2.29.1 | NOK | http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6 | ORPH
        mips |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/f84ea17ee70bef3583a8e320fbfd63653d03b661 |     
    mips64el |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/b5b5a7fc4d191bd7bcdc6a753a6ec5969bdd98d1 |     
     aarch64 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/5828c2face461d4f3e1e5a1ce198a13bc1e2b07f |     
       nios2 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/2f8a661ff15ea797d1c03b7bc82cfd47159c9ef2 |     
microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/edd0809b0920fb99384f731b748c29eef3f26bd4 |     
     powerpc |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/51f5ff6fdea5e466b231eb304f2906781417867a |     
microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/d082bf84191974c664805fc28288dc88c3dcf28a |     
        m68k |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/2514e27740f9f12a7a2766c7f8f08c0d3a2b6885 |     
        bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/61c963cd3f1a9480b03731424995f9a972c9d090 |     
        bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/6e8ebe92e028236fc0b4e341e045dfead38d7f23 |     
         arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/49d3157248f9e73ea5bdee63569ccd7a5e0eb07f |     
         arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/701a22aa4f594be09926ba5f5c599988ad832e16 |     
     powerpc |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/45edf95c0c44c9d553879e0cbb771098d7c63aa1 |     
         arm |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/a36d00407a371d70b4551a9717ebd6ff852c8bca |     
         arm |           host-rust-bin-1.23.0 | NOK | http://autobuild.buildroot.net/results/03396b02b7932f08c0a89eb482a65e80c3cd021b |     
     aarch64 |                  mesa3d-17.3.5 | NOK | http://autobuild.buildroot.net/results/a4d7c2720dbe7f6dd7111c507711dc23cc25b6cc |     
        i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/ec4e7e975c2e8f978a771a1702933d0612e95a9c |     
     aarch64 |                     mpv-0.27.0 | NOK | http://autobuild.buildroot.net/results/2ce2d9be9e0699114e3bc3c0434ba05f64741f89 |     
      xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/4a3cc5780c229a9d5d86543e68cd0819c8cabbd1 | ORPH
      xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/bcf5e27a1e9f9eea2d1688445146df3c50a8919e | ORPH
         arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/c363c6fdaecb5d9a9ebb6b8a0930c93df48ce42a | ORPH
      xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/3d933b4e9f7de29776e64229e87b7d57c5381212 | ORPH
         arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/d7a6ced35e42945795ac2adcdf581c4b368bd6a4 | ORPH
     powerpc |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/73108d7ff2ba10ec522c5a551bba54db357f95a8 | ORPH
microblazeel |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/e0c434001b5a2a30299af491a6be65f289e157f1 | ORPH
     powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/b0ff91d12a569ae9f6a78b1c62c75fb64e207be3 | ORPH
         arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/1fe27c28772ae3ba0ba6d33fa23f597db2707d1c |     
         arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/46b7c072a64c34ceb6e4be191bddc2bbfd26b3a6 |     
         arm |                    systemd-237 | NOK | http://autobuild.buildroot.net/results/c2985c0471cfb8e396991bce125222d15474d0d0 |     
       sparc |     trace-cmd-trace-cmd-v2.6.1 | NOK | http://autobuild.buildroot.net/results/d3538deb2e993e53d34286403b9ded3138eb4eb9 |     
        i586 | uclibc-ng-test-c6d62cbc6050... | NOK | http://autobuild.buildroot.net/results/e57e3bd425f43471283f10824d54b62b9116e260 |     

Results for branch '2017.11.x'
==============================

Classification of failures by reason
------------------------------------

            host-libxml2-2.9.5 | 1 


Detail of failures
------------------

      xtensa |             host-libxml2-2.9.5 | NOK | http://autobuild.buildroot.net/results/7326eb0a682628b99736c326400601513d4c7a51 | ORPH

Results for branch 'next'
=========================

Classification of failures by reason
------------------------------------

                  autofs-5.1.4 | 2 
                    htop-2.1.0 | 2 
         libcpprestsdk-v2.10.1 | 2 
                    liblo-0.29 | 2 
               asterisk-14.7.5 | 1 
                  boost-1.66.0 | 1 
                  host-go-1.10 | 1 
              keepalived-1.4.1 | 1 
               lightning-2.1.0 | 1 
                    make-4.2.1 | 1 
                     php-7.2.2 | 1 
                    sdl2-2.0.7 | 1 
                   trinity-1.8 | 1 
tvheadend-e06ffd87beff16103... | 1 
                  udftools-2.0 | 1 


Detail of failures
------------------

         arm |                asterisk-14.7.5 | NOK | http://autobuild.buildroot.net/results/1dd75446a298b486127dd4469f6d3783afe0767b |     
         arm |                   autofs-5.1.4 | NOK | http://autobuild.buildroot.net/results/10b5c5b13971214d0439b715f1a46c78a5249309 |     
        i586 |                   autofs-5.1.4 | NOK | http://autobuild.buildroot.net/results/b3276b2cbd1e1c260f8df4c3945f51ddc09d492f |     
microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/119d2993d0146c07463585757add95e83ecb2fe9 |     
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/41d50743ee6154b7c18519dd4c8aff4493b850d2 | ORPH
    mips64el |                     htop-2.1.0 | NOK | http://autobuild.buildroot.net/results/65c5a8395e6c788ec85fab7630b38e0e57312303 | ORPH
     powerpc |                     htop-2.1.0 | NOK | http://autobuild.buildroot.net/results/3946f07c9bbd340d16767ea6d5506ec89972d4e9 | ORPH
         arm |               keepalived-1.4.1 | NOK | http://autobuild.buildroot.net/results/e1bba3ce0b3b8bedb42ec0ac740b404a806d41b1 |     
        i586 |          libcpprestsdk-v2.10.1 | NOK | http://autobuild.buildroot.net/results/f24a85d7e2dae302f7fcc1dced6625bd5a5f5384 |     
      xtensa |          libcpprestsdk-v2.10.1 | NOK | http://autobuild.buildroot.net/results/9507c5631c6717cf89eee2f6573ea95fbd5398db |     
       sparc |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/98bfc9dd2800557bc3de507352646452ed26bc44 | ORPH
        m68k |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/d6e63eab14914a086858dce7a0a918f57160e303 | ORPH
         arm |                lightning-2.1.0 | NOK | http://autobuild.buildroot.net/results/6d887941564585c7e87279c65dc91267bb63ec11 |     
         arm |                     make-4.2.1 | NOK | http://autobuild.buildroot.net/results/6d15295f1436641865c4e67f9a8017e3b8c7ca17 | ORPH
         arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/fb1e49d0294157a52f50c57e04bdaa054cb07288 | ORPH
         arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/ecda641e9b0751660e2918cadeab021e7feae60e |     
         arm |                    trinity-1.8 | NOK | http://autobuild.buildroot.net/results/326a7e828a7ef0e19fcbbd4937970e22cd1fce03 |     
microblazeel | tvheadend-e06ffd87beff16103... | NOK | http://autobuild.buildroot.net/results/5008618185dcd70ab164f709d0299f828c2bf5f8 |     
        m68k |                   udftools-2.0 | NOK | http://autobuild.buildroot.net/results/419af93b874f1418e64e6a9058439350ac655ed3 |     


-- 
http://autobuild.buildroot.net

[Buildroot] Analysis of build results for 2018-02-25

[Thomas Petazzoni]

Hello,

We're almost at the end of the month, and therefore almost at the
final 2018.02, which will be a LTS. I believe it is a good opportunity
to make a final effort to resolve the remaining build failures. See
below for an analysis.

Romain, Johan, Frank, Eric, Mahyar, Bernd, Guillermo, Pierre, Waldemar,
there are questions for you below. Thanks!

On Mon, 26 Feb 2018 08:00:10 +0100 (CET), Thomas Petazzoni wrote:

>      powerpc |                binutils-2.29.1 | NOK | http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6 | ORPH

read.c: In function 's_app_line':
read.c:2001:1: internal compiler error: Segmentation fault
 s_app_line (int appline)

Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
someone retry with a newer gcc, and see if it is fixed ?

Also, is someone interested in adopting this package ? Romain, you have
done a fair bit of toolchain stuff lately, maybe you're interested in
adopting binutils ?

>         mips |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/f84ea17ee70bef3583a8e320fbfd63653d03b661 |     
>     mips64el |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/b5b5a7fc4d191bd7bcdc6a753a6ec5969bdd98d1 |     
>      aarch64 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/5828c2face461d4f3e1e5a1ce198a13bc1e2b07f |     
>        nios2 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/2f8a661ff15ea797d1c03b7bc82cfd47159c9ef2 |     

Readline is now needed. We have a patch to add readline as a
dependency (https://patchwork.ozlabs.org/patch/860386/), but Baruch
(and me) asked to ask upstream about it, because it looked like a
possibly unintentional change. Since nobody investigated further, I
propose that we apply Bernd's patch adding the readline dependency. If
someone is unhappy with it, we can always revert when the problem is
fixed.

> microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/edd0809b0920fb99384f731b748c29eef3f26bd4 |     
>      powerpc |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/51f5ff6fdea5e466b231eb304f2906781417867a |     
> microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/d082bf84191974c664805fc28288dc88c3dcf28a |     
>         m68k |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/2514e27740f9f12a7a2766c7f8f08c0d3a2b6885 |     
>         bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/61c963cd3f1a9480b03731424995f9a972c9d090 |     
>         bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/6e8ebe92e028236fc0b4e341e045dfead38d7f23 |    

All these are fixed by
https://git.buildroot.org/buildroot/commit/?id=a93a7afb817e09012b28b44d99d0af3d38001fff.
 
>          arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/49d3157248f9e73ea5bdee63569ccd7a5e0eb07f |     
>          arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/701a22aa4f594be09926ba5f5c599988ad832e16 |     

Fixed by
https://git.buildroot.org/buildroot/commit/?id=7bb17b10af531749192e067efd67a117f2bc8053

>      powerpc |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/45edf95c0c44c9d553879e0cbb771098d7c63aa1 |     
>          arm |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/a36d00407a371d70b4551a9717ebd6ff852c8bca |     

I propose that we make erlang depend on x86/x86_64 as host
architecture. Johan, Frank, are you OK ?

>          arm |           host-rust-bin-1.23.0 | NOK | http://autobuild.buildroot.net/results/03396b02b7932f08c0a89eb482a65e80c3cd021b |     

404 not found while downloding
https://static.rust-lang.org/dist/rust-std-1.23.0-armv7-unknown-linux-gnueabi.tar.xz.
Eric could you have a look ?

>      aarch64 |                  mesa3d-17.3.5 | NOK | http://autobuild.buildroot.net/results/a4d7c2720dbe7f6dd7111c507711dc23cc25b6cc |     

glsl/glsl_parser_extras.cpp: In function 'bool do_common_optimization(exec_list*, bool, bool, const gl_shader_compiler_options*, bool)':
glsl/glsl_parser_extras.cpp:2178:1: internal compiler error: Segmentation fault

Meh, a compiler failure. Bernd, could you test with various gcc
versions, and see if the problem has been fixed ?

>         i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/ec4e7e975c2e8f978a771a1702933d0612e95a9c |     

I guess this is fixed by the old patches submitted by Bernd, which are
still in patchwork. I'm still not super happy about these patches,
though (as I already expressed as a reply to those patches).

>      aarch64 |                     mpv-0.27.0 | NOK | http://autobuild.buildroot.net/results/2ce2d9be9e0699114e3bc3c0434ba05f64741f89 |     

/home/buildroot/autobuild/run/instance-0/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/eglplatform.h:125:10: fatal error: X11/Xlib.h: No such file or directory
 #include <X11/Xlib.h>

Mahyar, since you added the mpv package, could you have a look ? Or
someone else ?

>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/4a3cc5780c229a9d5d86543e68cd0819c8cabbd1 | ORPH
>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/bcf5e27a1e9f9eea2d1688445146df3c50a8919e | ORPH
>          arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/c363c6fdaecb5d9a9ebb6b8a0930c93df48ce42a | ORPH
>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/3d933b4e9f7de29776e64229e87b7d57c5381212 | ORPH
>          arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/d7a6ced35e42945795ac2adcdf581c4b368bd6a4 | ORPH
>      powerpc |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/73108d7ff2ba10ec522c5a551bba54db357f95a8 | ORPH
> microblazeel |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/e0c434001b5a2a30299af491a6be65f289e157f1 | ORPH

I have looked at all of them, but it seems like the issue is always:

/home/peko/autobuild/instance-2/output/build/php-7.2.2/ext/sockets/sockets.c:800:37: error: 'AI_IDN' undeclared (first use in this function)
  REGISTER_LONG_CONSTANT("AI_IDN",   AI_IDN,    CONST_CS | CONST_PERSISTENT);

AI_IDN is not available on uClibc (and apparently not in musl either).
So the simple fix is to add some dependencies on
BR2_PACKAGE_PHP_EXT_SOCKETS. The better fix is to introduce an autoconf
check, like is already done for AI_ALL. This is probably easy to do.

>      powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/b0ff91d12a569ae9f6a78b1c62c75fb64e207be3 | ORPH

tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:18074

Someone to test this with newer gcc versions ?

>          arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/1fe27c28772ae3ba0ba6d33fa23f597db2707d1c |     
>          arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/46b7c072a64c34ceb6e4be191bddc2bbfd26b3a6 |     


/accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-4/output/build/sdl2-2.0.7/src/video/raspberry/SDL_rpivideo.c: In function 'RPI_Create':
/accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-4/output/build/sdl2-2.0.7/src/video/raspberry/SDL_rpivideo.c:126:39: error: 'RPI_GLES_DefaultProfileConfig' undeclared (first use in this function)
     device->GL_DefaultProfileConfig = RPI_GLES_DefaultProfileConfig;
                                       ^
SDL2 / RPi support broken.

Guillermo, you enabled RPi support in SDL2, could you look at those
build issues ?

>          arm |                    systemd-237 | NOK | http://autobuild.buildroot.net/results/c2985c0471cfb8e396991bce125222d15474d0d0 |     

The infamous locale issue. Unless someone comes up with a better
solution than https://patchwork.ozlabs.org/patch/876880/, I think I'm
going to go ahead and apply this fix.

>        sparc |     trace-cmd-trace-cmd-v2.6.1 | NOK | http://autobuild.buildroot.net/results/d3538deb2e993e53d34286403b9ded3138eb4eb9 |     

ctracecmd_wrap.o -o ctracecmd.so
ctracecmd_wrap.o: In function `SWIG_Python_ErrorType':
ctracecmd_wrap.c:(.text+0xa0): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_RuntimeError'
ctracecmd_wrap.c:(.text+0xc0): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_MemoryError'
ctracecmd_wrap.c:(.text+0xd4): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_IOError'
ctracecmd_wrap.c:(.text+0xdc): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_IndexError'
ctracecmd_wrap.c:(.text+0xe4): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_TypeError'

Pierre, you added support for trace-cmd in Buildroot, could you have a look ?

>         i586 | uclibc-ng-test-c6d62cbc6050... | NOK | http://autobuild.buildroot.net/results/e57e3bd425f43471283f10824d54b62b9116e260 |     

tst-syscall6.c: In function 'main':
tst-syscall6.c:32:48: error: 'RWF_DSYNC' undeclared (first use in this function)

This is when building against musl. Waldemar ? :-)

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Johan Oudinet]

Hi Thomas, All,

On Mon, Feb 26, 2018 at 11:33 AM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> We're almost at the end of the month, and therefore almost at the
> final 2018.02, which will be a LTS. I believe it is a good opportunity
> to make a final effort to resolve the remaining build failures. See
> below for an analysis.
>
> Romain, Johan, Frank, Eric, Mahyar, Bernd, Guillermo, Pierre, Waldemar,
> there are questions for you below. Thanks!
>
> On Mon, 26 Feb 2018 08:00:10 +0100 (CET), Thomas Petazzoni wrote:
>
>>      powerpc |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/45edf95c0c44c9d553879e0cbb771098d7c63aa1 |
>>          arm |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/a36d00407a371d70b4551a9717ebd6ff852c8bca |
>
> I propose that we make erlang depend on x86/x86_64 as host
> architecture. Johan, Frank, are you OK ?

Yes, I agree with making host-erlang depends on x86/x86_64
architectures. I never compile it from another architecture anyway. I
looked at existing patches to such errors, but find nothing that make
Erlang successfully compiled from a powerpc or an arm host.
What is the exact option to add to Config.in to achieve this?
Do you want me to submit a patch or you do it?

Best,
-- 
Johan

[Buildroot] Analysis of build results for 2018-02-25

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 11:51:41 +0100, Johan Oudinet wrote:

> > I propose that we make erlang depend on x86/x86_64 as host
> > architecture. Johan, Frank, are you OK ?  
> 
> Yes, I agree with making host-erlang depends on x86/x86_64
> architectures. I never compile it from another architecture anyway. I
> looked at existing patches to such errors, but find nothing that make
> Erlang successfully compiled from a powerpc or an arm host.
> What is the exact option to add to Config.in to achieve this?
> Do you want me to submit a patch or you do it?

Since there is nothing that selects BR2_PACKAGE_ERLANG, it's pretty
easy as there only one place to modify.

I think I would keep it simple and in package/erlang/Config.in, do:

config BR2_PACKAGE_HOST_ERLANG_ARCH_SUPPORTS
	bool
	default y if BR2_HOSTARCH = "x86_64"
	default y if BR2_HOSTARCH = "x86"

config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
	bool
	... keep existing code ...
	# erlang needs host-erlang
	depends on BR2_PACKAGE_HOST_ERLANG_ARCH_SUPPORTS

And be done with it :)

If you could submit a patch doing this, it'd be nice. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > We're almost at the end of the month, and therefore almost at the
 > final 2018.02, which will be a LTS. I believe it is a good opportunity
 > to make a final effort to resolve the remaining build failures. See
 > below for an analysis.

Thanks for the overview.

 >> powerpc | binutils-2.29.1 | NOK |
 >> http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6
 >> | ORPH

 > read.c: In function 's_app_line':
 > read.c:2001:1: internal compiler error: Segmentation fault
 >  s_app_line (int appline)

 > Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
 > someone retry with a newer gcc, and see if it is fixed ?

Notice that this happened on gcc67, so on the Ryzen CPU (and nowhere
else), so I'm afraid the Ryzen crashes are _STILL_ not fixed. I'll stop
the autobuilder again.


 > Readline is now needed. We have a patch to add readline as a
 > dependency (https://patchwork.ozlabs.org/patch/860386/), but Baruch
 > (and me) asked to ask upstream about it, because it looked like a
 > possibly unintentional change. Since nobody investigated further, I
 > propose that we apply Bernd's patch adding the readline dependency. If
 > someone is unhappy with it, we can always revert when the problem is
 > fixed.

Yes, I guess this is the best solution for 2018.02.


 >> aarch64 | mesa3d-17.3.5 | NOK |
 >> http://autobuild.buildroot.net/results/a4d7c2720dbe7f6dd7111c507711dc23cc25b6cc
 >> |

 > glsl/glsl_parser_extras.cpp: In function 'bool
 > do_common_optimization(exec_list*, bool, bool, const
 > gl_shader_compiler_options*, bool)':
 > glsl/glsl_parser_extras.cpp:2178:1: internal compiler error: Segmentation fault

 > Meh, a compiler failure. Bernd, could you test with various gcc
 > versions, and see if the problem has been fixed ?

Once more on gcc67 (and no other autobuilders), please ignore.


 >> i686 | mplayer-1.3.0 | NOK |
 >> http://autobuild.buildroot.net/results/ec4e7e975c2e8f978a771a1702933d0612e95a9c
 >> |

 > I guess this is fixed by the old patches submitted by Bernd, which are
 > still in patchwork. I'm still not super happy about these patches,
 > though (as I already expressed as a reply to those patches).

Agreed, but what are the alternatives? Make the package unavailable for
x86 or drop it completely, as it is afaik dead upstream.


 >> powerpc | qt-4.8.7 | NOK |
 >> http://autobuild.buildroot.net/results/b0ff91d12a569ae9f6a78b1c62c75fb64e207be3
 >> | ORPH

 > tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
 > validate_condition_mode, at config/rs6000/rs6000.c:18074

 > Someone to test this with newer gcc versions ?

Or deprecate qt4?


 >> arm | systemd-237 | NOK |
 >> http://autobuild.buildroot.net/results/c2985c0471cfb8e396991bce125222d15474d0d0
 >> |

 > The infamous locale issue. Unless someone comes up with a better
 > solution than https://patchwork.ozlabs.org/patch/876880/, I think I'm
 > going to go ahead and apply this fix.

Agreed, considering how close we are getting to 2018.02.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2018-02-25

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 13:48:03 +0100, Peter Korsgaard wrote:

>  > Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
>  > someone retry with a newer gcc, and see if it is fixed ?  
> 
> Notice that this happened on gcc67, so on the Ryzen CPU (and nowhere
> else), so I'm afraid the Ryzen crashes are _STILL_ not fixed. I'll stop
> the autobuilder again.

Ah, ok. Good to know.

>  > Readline is now needed. We have a patch to add readline as a
>  > dependency (https://patchwork.ozlabs.org/patch/860386/), but Baruch
>  > (and me) asked to ask upstream about it, because it looked like a
>  > possibly unintentional change. Since nobody investigated further, I
>  > propose that we apply Bernd's patch adding the readline dependency. If
>  > someone is unhappy with it, we can always revert when the problem is
>  > fixed.  
> 
> Yes, I guess this is the best solution for 2018.02.

ACK, I'll apply tonight if nobody does so in the mean time.

>  > Meh, a compiler failure. Bernd, could you test with various gcc
>  > versions, and see if the problem has been fixed ?  
> 
> Once more on gcc67 (and no other autobuilders), please ignore.

ACK.

>  >> i686 | mplayer-1.3.0 | NOK |
>  >> http://autobuild.buildroot.net/results/ec4e7e975c2e8f978a771a1702933d0612e95a9c
>  >> |  
> 
>  > I guess this is fixed by the old patches submitted by Bernd, which are
>  > still in patchwork. I'm still not super happy about these patches,
>  > though (as I already expressed as a reply to those patches).  
> 
> Agreed, but what are the alternatives? Make the package unavailable for
> x86 or drop it completely, as it is afaik dead upstream.

mplayer upstream is dead ? If that is the case, then indeed we should
just take those patches as-is.

>  >> powerpc | qt-4.8.7 | NOK |
>  >> http://autobuild.buildroot.net/results/b0ff91d12a569ae9f6a78b1c62c75fb64e207be3
>  >> | ORPH  
> 
>  > tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
>  > validate_condition_mode, at config/rs6000/rs6000.c:18074  
> 
>  > Someone to test this with newer gcc versions ?  
> 
> Or deprecate qt4?

Just because it's broken on powerpc?

So, I remembered I did some testing, and apparently the result of my
testing is that gcc 6.x has the issue, but gcc 7.x compiles Qt4
correctly. I believe my idea was then to bisect which commit *fixed*
the problem, but you can imagine that within gcc, it's going to take a
while.

But bottom line is: problem doesn't exist with gcc 7.x anymore.

>  >> arm | systemd-237 | NOK |
>  >> http://autobuild.buildroot.net/results/c2985c0471cfb8e396991bce125222d15474d0d0
>  >> |  
> 
>  > The infamous locale issue. Unless someone comes up with a better
>  > solution than https://patchwork.ozlabs.org/patch/876880/, I think I'm
>  > going to go ahead and apply this fix.  
> 
> Agreed, considering how close we are getting to 2018.02.

We also have the issue that systemd is currently broken anyway (see the
report from J?r?my Rosen, the attempt to fix it from Jan and Romain). I
don't think we can release until this problem is resolved.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Frank Hunleth]

Hi Johan and Thomas,

On Mon, Feb 26, 2018 at 5:51 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> Hi Thomas, All,
>
> On Mon, Feb 26, 2018 at 11:33 AM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> Hello,
>>
>> We're almost at the end of the month, and therefore almost at the
>> final 2018.02, which will be a LTS. I believe it is a good opportunity
>> to make a final effort to resolve the remaining build failures. See
>> below for an analysis.
>>
>> Romain, Johan, Frank, Eric, Mahyar, Bernd, Guillermo, Pierre, Waldemar,
>> there are questions for you below. Thanks!
>>
>> On Mon, 26 Feb 2018 08:00:10 +0100 (CET), Thomas Petazzoni wrote:
>>
>>>      powerpc |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/45edf95c0c44c9d553879e0cbb771098d7c63aa1 |
>>>          arm |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/a36d00407a371d70b4551a9717ebd6ff852c8bca |
>>
>> I propose that we make erlang depend on x86/x86_64 as host
>> architecture. Johan, Frank, are you OK ?
>
> Yes, I agree with making host-erlang depends on x86/x86_64
> architectures. I never compile it from another architecture anyway. I
> looked at existing patches to such errors, but find nothing that make
> Erlang successfully compiled from a powerpc or an arm host.

I agree with this solution as well. I'm not aware of anyone using
host-erlang on anything but x86_64.

-Frank


> What is the exact option to add to Config.in to achieve this?
> Do you want me to submit a patch or you do it?
>
> Best,
> --
> Johan

[Buildroot] Analysis of build results for 2018-02-25

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> > I guess this is fixed by the old patches submitted by Bernd, which are
 >> > still in patchwork. I'm still not super happy about these patches,
 >> > though (as I already expressed as a reply to those patches).  
 >> 
 >> Agreed, but what are the alternatives? Make the package unavailable for
 >> x86 or drop it completely, as it is afaik dead upstream.

 > mplayer upstream is dead ? If that is the case, then indeed we should
 > just take those patches as-is.

I haven't followed development in details, but the latest mplayer
release is more than 2 years old and several forks exists (E.G. mpv).


 >> > tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
 >> > validate_condition_mode, at config/rs6000/rs6000.c:18074  
 >> 
 >> > Someone to test this with newer gcc versions ?  
 >> 
 >> Or deprecate qt4?

 > Just because it's broken on powerpc?

Well, mainly because it is no longer maintained upstream. Even Debian is
removing Qt4:

https://wiki.debian.org/Qt4Removal

 >> Agreed, considering how close we are getting to 2018.02.

 > We also have the issue that systemd is currently broken anyway (see the
 > report from J?r?my Rosen, the attempt to fix it from Jan and Romain). I
 > don't think we can release until this problem is resolved.

Agreed!

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2018-02-25

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 15:06:20 +0100, Peter Korsgaard wrote:

>  > mplayer upstream is dead ? If that is the case, then indeed we should
>  > just take those patches as-is.  
> 
> I haven't followed development in details, but the latest mplayer
> release is more than 2 years old and several forks exists (E.G. mpv).

But isn't mplayer one of those projects that says that releases are
useless, and people should always use the latest trunk/master/tip
because it's obviously "the best".

>  >> > tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
>  >> > validate_condition_mode, at config/rs6000/rs6000.c:18074    
>  >>   
>  >> > Someone to test this with newer gcc versions ?    
>  >> 
>  >> Or deprecate qt4?  
> 
>  > Just because it's broken on powerpc?  
> 
> Well, mainly because it is no longer maintained upstream. Even Debian is
> removing Qt4:
> 
> https://wiki.debian.org/Qt4Removal

True, but we are not going to remove it for 2018.02, right ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Mahyar Koshkouei]

Hi all,

With regards to the mpv issue, the compile error occurs because the
"odroid-mali" package sets the cflags "-DMESA_EGL_NO_X11_HEADERS"
which mpv seems to ignore. A linking error then occurs in mpv when
forcing the cflag.

Therefore I propose to disable mali support in mpv using
"--disable-mali-fbdev" until someone who has interest in mpv support
on the odroid comes and fixes this.
Additionally, I have updated mpv to the latest minor release 0.27.2 to
fix CVE-2018-6360 security issue.

I will post the patches shortly.

Kind Regards,
Mahyar

On 26 February 2018 at 10:33, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> We're almost at the end of the month, and therefore almost at the
> final 2018.02, which will be a LTS. I believe it is a good opportunity
> to make a final effort to resolve the remaining build failures. See
> below for an analysis.
>
> Romain, Johan, Frank, Eric, Mahyar, Bernd, Guillermo, Pierre, Waldemar,
> there are questions for you below. Thanks!
>
> On Mon, 26 Feb 2018 08:00:10 +0100 (CET), Thomas Petazzoni wrote:
>
>>      powerpc |                binutils-2.29.1 | NOK | http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6 | ORPH
>
> read.c: In function 's_app_line':
> read.c:2001:1: internal compiler error: Segmentation fault
>  s_app_line (int appline)
>
> Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
> someone retry with a newer gcc, and see if it is fixed ?
>
> Also, is someone interested in adopting this package ? Romain, you have
> done a fair bit of toolchain stuff lately, maybe you're interested in
> adopting binutils ?
>
>>         mips |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/f84ea17ee70bef3583a8e320fbfd63653d03b661 |
>>     mips64el |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/b5b5a7fc4d191bd7bcdc6a753a6ec5969bdd98d1 |
>>      aarch64 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/5828c2face461d4f3e1e5a1ce198a13bc1e2b07f |
>>        nios2 |              bluez5_utils-5.48 | NOK | http://autobuild.buildroot.net/results/2f8a661ff15ea797d1c03b7bc82cfd47159c9ef2 |
>
> Readline is now needed. We have a patch to add readline as a
> dependency (https://patchwork.ozlabs.org/patch/860386/), but Baruch
> (and me) asked to ask upstream about it, because it looked like a
> possibly unintentional change. Since nobody investigated further, I
> propose that we apply Bernd's patch adding the readline dependency. If
> someone is unhappy with it, we can always revert when the problem is
> fixed.
>
>> microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/edd0809b0920fb99384f731b748c29eef3f26bd4 |
>>      powerpc |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/51f5ff6fdea5e466b231eb304f2906781417867a |
>> microblazeel |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/d082bf84191974c664805fc28288dc88c3dcf28a |
>>         m68k |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/2514e27740f9f12a7a2766c7f8f08c0d3a2b6885 |
>>         bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/61c963cd3f1a9480b03731424995f9a972c9d090 |
>>         bfin |                   boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/6e8ebe92e028236fc0b4e341e045dfead38d7f23 |
>
> All these are fixed by
> https://git.buildroot.org/buildroot/commit/?id=a93a7afb817e09012b28b44d99d0af3d38001fff.
>
>>          arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/49d3157248f9e73ea5bdee63569ccd7a5e0eb07f |
>>          arc |                  hiawatha-10.6 | NOK | http://autobuild.buildroot.net/results/701a22aa4f594be09926ba5f5c599988ad832e16 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=7bb17b10af531749192e067efd67a117f2bc8053
>
>>      powerpc |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/45edf95c0c44c9d553879e0cbb771098d7c63aa1 |
>>          arm |               host-erlang-20.0 | NOK | http://autobuild.buildroot.net/results/a36d00407a371d70b4551a9717ebd6ff852c8bca |
>
> I propose that we make erlang depend on x86/x86_64 as host
> architecture. Johan, Frank, are you OK ?
>
>>          arm |           host-rust-bin-1.23.0 | NOK | http://autobuild.buildroot.net/results/03396b02b7932f08c0a89eb482a65e80c3cd021b |
>
> 404 not found while downloding
> https://static.rust-lang.org/dist/rust-std-1.23.0-armv7-unknown-linux-gnueabi.tar.xz.
> Eric could you have a look ?
>
>>      aarch64 |                  mesa3d-17.3.5 | NOK | http://autobuild.buildroot.net/results/a4d7c2720dbe7f6dd7111c507711dc23cc25b6cc |
>
> glsl/glsl_parser_extras.cpp: In function 'bool do_common_optimization(exec_list*, bool, bool, const gl_shader_compiler_options*, bool)':
> glsl/glsl_parser_extras.cpp:2178:1: internal compiler error: Segmentation fault
>
> Meh, a compiler failure. Bernd, could you test with various gcc
> versions, and see if the problem has been fixed ?
>
>>         i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/ec4e7e975c2e8f978a771a1702933d0612e95a9c |
>
> I guess this is fixed by the old patches submitted by Bernd, which are
> still in patchwork. I'm still not super happy about these patches,
> though (as I already expressed as a reply to those patches).
>
>>      aarch64 |                     mpv-0.27.0 | NOK | http://autobuild.buildroot.net/results/2ce2d9be9e0699114e3bc3c0434ba05f64741f89 |
>
> /home/buildroot/autobuild/run/instance-0/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/eglplatform.h:125:10: fatal error: X11/Xlib.h: No such file or directory
>  #include <X11/Xlib.h>
>
> Mahyar, since you added the mpv package, could you have a look ? Or
> someone else ?
>
>>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/4a3cc5780c229a9d5d86543e68cd0819c8cabbd1 | ORPH
>>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/bcf5e27a1e9f9eea2d1688445146df3c50a8919e | ORPH
>>          arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/c363c6fdaecb5d9a9ebb6b8a0930c93df48ce42a | ORPH
>>       xtensa |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/3d933b4e9f7de29776e64229e87b7d57c5381212 | ORPH
>>          arm |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/d7a6ced35e42945795ac2adcdf581c4b368bd6a4 | ORPH
>>      powerpc |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/73108d7ff2ba10ec522c5a551bba54db357f95a8 | ORPH
>> microblazeel |                      php-7.2.2 | NOK | http://autobuild.buildroot.net/results/e0c434001b5a2a30299af491a6be65f289e157f1 | ORPH
>
> I have looked at all of them, but it seems like the issue is always:
>
> /home/peko/autobuild/instance-2/output/build/php-7.2.2/ext/sockets/sockets.c:800:37: error: 'AI_IDN' undeclared (first use in this function)
>   REGISTER_LONG_CONSTANT("AI_IDN",   AI_IDN,    CONST_CS | CONST_PERSISTENT);
>
> AI_IDN is not available on uClibc (and apparently not in musl either).
> So the simple fix is to add some dependencies on
> BR2_PACKAGE_PHP_EXT_SOCKETS. The better fix is to introduce an autoconf
> check, like is already done for AI_ALL. This is probably easy to do.
>
>>      powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/b0ff91d12a569ae9f6a78b1c62c75fb64e207be3 | ORPH
>
> tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:18074
>
> Someone to test this with newer gcc versions ?
>
>>          arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/1fe27c28772ae3ba0ba6d33fa23f597db2707d1c |
>>          arm |                     sdl2-2.0.7 | NOK | http://autobuild.buildroot.net/results/46b7c072a64c34ceb6e4be191bddc2bbfd26b3a6 |
>
>
> /accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-4/output/build/sdl2-2.0.7/src/video/raspberry/SDL_rpivideo.c: In function 'RPI_Create':
> /accts/mlweber1/rclinux/rc-buildroot-test/scripts/instance-4/output/build/sdl2-2.0.7/src/video/raspberry/SDL_rpivideo.c:126:39: error: 'RPI_GLES_DefaultProfileConfig' undeclared (first use in this function)
>      device->GL_DefaultProfileConfig = RPI_GLES_DefaultProfileConfig;
>                                        ^
> SDL2 / RPi support broken.
>
> Guillermo, you enabled RPi support in SDL2, could you look at those
> build issues ?
>
>>          arm |                    systemd-237 | NOK | http://autobuild.buildroot.net/results/c2985c0471cfb8e396991bce125222d15474d0d0 |
>
> The infamous locale issue. Unless someone comes up with a better
> solution than https://patchwork.ozlabs.org/patch/876880/, I think I'm
> going to go ahead and apply this fix.
>
>>        sparc |     trace-cmd-trace-cmd-v2.6.1 | NOK | http://autobuild.buildroot.net/results/d3538deb2e993e53d34286403b9ded3138eb4eb9 |
>
> ctracecmd_wrap.o -o ctracecmd.so
> ctracecmd_wrap.o: In function `SWIG_Python_ErrorType':
> ctracecmd_wrap.c:(.text+0xa0): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_RuntimeError'
> ctracecmd_wrap.c:(.text+0xc0): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_MemoryError'
> ctracecmd_wrap.c:(.text+0xd4): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_IOError'
> ctracecmd_wrap.c:(.text+0xdc): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_IndexError'
> ctracecmd_wrap.c:(.text+0xe4): relocation truncated to fit: R_SPARC_GOT13 against undefined symbol `PyExc_TypeError'
>
> Pierre, you added support for trace-cmd in Buildroot, could you have a look ?
>
>>         i586 | uclibc-ng-test-c6d62cbc6050... | NOK | http://autobuild.buildroot.net/results/e57e3bd425f43471283f10824d54b62b9116e260 |
>
> tst-syscall6.c: In function 'main':
> tst-syscall6.c:32:48: error: 'RWF_DSYNC' undeclared (first use in this function)
>
> This is when building against musl. Waldemar ? :-)
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Thomas Petazzoni]

Hello,

On Mon, 26 Feb 2018 15:30:42 +0000, Mahyar Koshkouei wrote:

> With regards to the mpv issue, the compile error occurs because the
> "odroid-mali" package sets the cflags "-DMESA_EGL_NO_X11_HEADERS"
> which mpv seems to ignore. A linking error then occurs in mpv when
> forcing the cflag.
> 
> Therefore I propose to disable mali support in mpv using
> "--disable-mali-fbdev" until someone who has interest in mpv support
> on the odroid comes and fixes this.

That's fine with me.

> Additionally, I have updated mpv to the latest minor release 0.27.2 to
> fix CVE-2018-6360 security issue.

OK, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[Buildroot] Analysis of build results for 2018-02-25

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > On Mon, 26 Feb 2018 15:06:20 +0100, Peter Korsgaard wrote:

 >> > mplayer upstream is dead ? If that is the case, then indeed we should
 >> > just take those patches as-is.  
 >> 
 >> I haven't followed development in details, but the latest mplayer
 >> release is more than 2 years old and several forks exists (E.G. mpv).

 > But isn't mplayer one of those projects that says that releases are
 > useless, and people should always use the latest trunk/master/tip
 > because it's obviously "the best".

Maybe. I do see some recent changes in subversion, but mainly small
things (tweaks to the handwritten configure script).

 >> >> Or deprecate qt4?  
 >> 
 >> > Just because it's broken on powerpc?  
 >> 
 >> Well, mainly because it is no longer maintained upstream. Even Debian is
 >> removing Qt4:
 >> 
 >> https://wiki.debian.org/Qt4Removal

 > True, but we are not going to remove it for 2018.02, right ?

It is indeed getting quite late for 2018.02, but given that:

- It isn't supported upstream
- The package is orphaned in Buildroot
- Other distributions (like Debian) no longer supports it

Makes me think that we won't be able to do a good job supporting it
throughout the 2018.02 support cycle.

We don't have a good way of handling deprecations, so I'm not sure what
the best option is:

- Do nothing
- Change prompt to "Qt (obsolete)"
- Remove package

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2018-02-25

[Peter Seiderer]

Hello Peter,

On Mon, 26 Feb 2018 13:48:03 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:

> 
>  >> powerpc | binutils-2.29.1 | NOK |
>  >> http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6
>  >> | ORPH  
> 
>  > read.c: In function 's_app_line':
>  > read.c:2001:1: internal compiler error: Segmentation fault
>  >  s_app_line (int appline)  
> 
>  > Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
>  > someone retry with a newer gcc, and see if it is fixed ?  
> 
> Notice that this happened on gcc67, so on the Ryzen CPU (and nowhere
> else), so I'm afraid the Ryzen crashes are _STILL_ not fixed. I'll stop
> the autobuilder again.

Is it a Ryzen CPU manufactured prior to week 25/2017? It is possible to
get an exchange CPU via RMA by AMD Customer Care, see [1] (worked for me
and the new delivered CPU runs stable (and after disabling PowerSaveStates
leading to machine-check exception)...

Regards,
Peter

[1] https://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1

[Buildroot] Analysis of build results for 2018-02-25

[Peter Korsgaard]

>>>>> "Peter" == Peter Seiderer <ps.report@gmx.net> writes:

 > Hello Peter,
 > On Mon, 26 Feb 2018 13:48:03 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:

 >> 
 >> >> powerpc | binutils-2.29.1 | NOK |
 >> >> http://autobuild.buildroot.net/results/22839bca79e16fc0d76ebc0f3e5ec4a6d23e99f6
 >> >> | ORPH  
 >> 
 >> > read.c: In function 's_app_line':
 >> > read.c:2001:1: internal compiler error: Segmentation fault
 >> >  s_app_line (int appline)  
 >> 
 >> > Compiler error. It's on PowerPC, with a toolchain from 2017.11. Could
 >> > someone retry with a newer gcc, and see if it is fixed ?  
 >> 
 >> Notice that this happened on gcc67, so on the Ryzen CPU (and nowhere
 >> else), so I'm afraid the Ryzen crashes are _STILL_ not fixed. I'll stop
 >> the autobuilder again.

 > Is it a Ryzen CPU manufactured prior to week 25/2017? It is possible to
 > get an exchange CPU via RMA by AMD Customer Care, see [1] (worked for me
 > and the new delivered CPU runs stable (and after disabling PowerSaveStates
 > leading to machine-check exception)...

Thanks, but this should already be an exchanged CPU with an updated
BIOS:

https://lists.tetaneutral.net/pipermail/cfarm-users/2018-February/000252.html

:/
-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2018-02-25

[Arnout Vandecappelle]

On 26-02-18 20:01, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> 
>  > Hello,
>  > On Mon, 26 Feb 2018 15:06:20 +0100, Peter Korsgaard wrote:
> 
>  >> > mplayer upstream is dead ? If that is the case, then indeed we should
>  >> > just take those patches as-is.  
>  >> 
>  >> I haven't followed development in details, but the latest mplayer
>  >> release is more than 2 years old and several forks exists (E.G. mpv).
> 
>  > But isn't mplayer one of those projects that says that releases are
>  > useless, and people should always use the latest trunk/master/tip
>  > because it's obviously "the best".
> 
> Maybe. I do see some recent changes in subversion, but mainly small
> things (tweaks to the handwritten configure script).
> 
>  >> >> Or deprecate qt4?  
>  >> 
>  >> > Just because it's broken on powerpc?  
>  >> 
>  >> Well, mainly because it is no longer maintained upstream. Even Debian is
>  >> removing Qt4:
>  >> 
>  >> https://wiki.debian.org/Qt4Removal
> 
>  > True, but we are not going to remove it for 2018.02, right ?
> 
> It is indeed getting quite late for 2018.02, but given that:
> 
> - It isn't supported upstream
> - The package is orphaned in Buildroot
> - Other distributions (like Debian) no longer supports it
> 
> Makes me think that we won't be able to do a good job supporting it
> throughout the 2018.02 support cycle.

 Well, for most packages, the "support" is limited to "it's still there and it
still doesn't fail in autobuilders". Which will not happen because we don't use
any new toolchains or anything during the LTS support cycle.

> 
> We don't have a good way of handling deprecations, so I'm not sure what
> the best option is:
> 
> - Do nothing
> - Change prompt to "Qt (obsolete)"

 I like this one. It costs us nothing, it makes it clear that you can't expect
support updates on this package, and it's an advance warning that it may be removed.

> - Remove package

 Eventually, yes, with legacy handling. I would remove it only when it breaks.


 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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2018-02-25

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> Makes me think that we won't be able to do a good job supporting it
 >> throughout the 2018.02 support cycle.

 >  Well, for most packages, the "support" is limited to "it's still there and it
 > still doesn't fail in autobuilders".

I was hoping for a bit more than that, E.G. has no known security
issues.


 > Which will not happen because we don't use any new toolchains or
 > anything during the LTS support cycle.

Unless there is a security issue in one of the libraries it uses (like
openssl) and we need to bump the version to fix that issue.


 >> We don't have a good way of handling deprecations, so I'm not sure what
 >> the best option is:
 >> 
 >> - Do nothing
 >> - Change prompt to "Qt (obsolete)"

 >  I like this one. It costs us nothing, it makes it clear that you can't expect
 > support updates on this package, and it's an advance warning that it may be removed.

Ok, I'll send a patch.


 >> - Remove package

 >  Eventually, yes, with legacy handling. I would remove it only when it breaks.

Ok.


-- 
Bye, Peter Korsgaard