[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Thomas Petazzoni]

Hello,

Build statistics for 2019-05-14
===============================

      branch |  OK | NOK | TIM | TOT |
   2019.02.x |  32 |   1 |   1 |  34 |
      master | 246 |  15 |   3 | 264 |

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

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

                chocolate-doom | 3 
  vdr-plugin-vnsiserver-v1.8.0 | 3 
          wpebackend-fdo-1.0.1 | 3 
                suricata-4.1.3 | 2 
           host-mfgtools-v0.02 | 1 
                   mimic-1.1.0 | 1 
                mono-5.20.1.27 | 1 
             openjdk-jdk-12+33 | 1 
                qt5base-5.12.2 | 1 
              qt5enginio-1.6.3 | 1 
              wpewebkit-2.22.5 | 1 


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

microblazeel |                 chocolate-doom | TIM | http://autobuild.buildroot.net/results/9b0700268318eb273d1f354fc3daefabd256102f |     
microblazeel |                 chocolate-doom | TIM | http://autobuild.buildroot.net/results/e570839576be8963dc6bd36342e2f857da3c6146 |     
microblazeel |                 chocolate-doom | TIM | http://autobuild.buildroot.net/results/5d537f9458641a3c512a4e665c0d29b55943e895 |     
         arm |            host-mfgtools-v0.02 | NOK | http://autobuild.buildroot.net/results/469f6da7a80b44fadf30b72ea5be4a080cbeb1d0 |     
     powerpc |                    mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/62bc12ea756a25155c5dec29a22c862223453f01 |     
         arm |                 mono-5.20.1.27 | NOK | http://autobuild.buildroot.net/results/dbd64c89815d393a4e28b312d74fd80ee6de92da |     
         arm |              openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/2bb330e431c50e0133b2073b997f3d682cebe94c |     
      x86_64 |                 qt5base-5.12.2 | NOK | http://autobuild.buildroot.net/results/d4d99a49303e5149365d7e7564d8b021fca1754d |     
      xtensa |               qt5enginio-1.6.3 | NOK | http://autobuild.buildroot.net/results/f0e5c2246cda27b918b50a7c55bc7c8dcd3f33df |     
        i586 |                 suricata-4.1.3 | NOK | http://autobuild.buildroot.net/results/16c0ed79f4eb2516461afa34d160b9bde14f0a19 |     
        m68k |                 suricata-4.1.3 | NOK | http://autobuild.buildroot.net/results/1c7729e774b6564750f7ec9f8665a275dcbfeacf |     
       nios2 |   vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/079202947c71de3c108d89db06d629dff7b0f49e |     
     sparc64 |   vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/fa63ccd99ad84f5051eefee1a3d595ec7ad57796 |     
       nios2 |   vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/7de28ffa6ee05ce6fa98cfb56952d03e38cafaf0 |     
     aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/39ccf985b3121342589167fe8bc0f88735318c28 |     
     aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/fa8341c0b11c5ef30a4692927e90f64de5bf4e11 |     
     aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/790c239fee8a59682927cb87ea9c1908a83d3c84 |     
         arm |               wpewebkit-2.22.5 | NOK | http://autobuild.buildroot.net/results/645be27edc31037a9b1bb7ce0dc85440949b0846 |     

Results for branch '2019.02.x'
==============================

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

                   mutt-1.11.2 | 1 
                       netsurf | 1 


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

         arm |                    mutt-1.11.2 | NOK | http://autobuild.buildroot.net/results/bbdabc088f839195e336baa1dfb765844aa325d2 |     
         arc |                        netsurf | TIM | http://autobuild.buildroot.net/results/eb8ebdd069973e37c5e32beaf84a5e7dc3c08bca |     


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Adrian Perez de Castro]

Hello,

On Wed, 15 May 2019 06:00:34 -0000, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

>      aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/39ccf985b3121342589167fe8bc0f88735318c28 |     
>      aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/fa8341c0b11c5ef30a4692927e90f64de5bf4e11 |     
>      aarch64 |           wpebackend-fdo-1.0.1 | NOK | http://autobuild.buildroot.net/results/790c239fee8a59682927cb87ea9c1908a83d3c84 |     

The wpebackend-fdo build failure would go away by applying Giulio's patch:

  https://patchwork.ozlabs.org/patch/1085508/

>          arm |               wpewebkit-2.22.5 | NOK | http://autobuild.buildroot.net/results/645be27edc31037a9b1bb7ce0dc85440949b0846 |     


This build failure of of the wpewebkit package is kind of odd: it looks like
with assertions enabled (as in: doing a debug build) uses some variables which
do not exist, and I wonder why we haven't seen this before?when working on
WebKit we routinely do debug builds ?\_(?)_/? 

I think it is more worth it to push the update to WPE WebKit 2.24.x forward,
and this build failure would just go away.

Regards,
?Adri?n
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190515/22d82b26/attachment.asc>

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Thomas Petazzoni]

Hello Adrian,

On Wed, 15 May 2019 22:17:03 +0300
Adrian Perez de Castro <aperez@igalia.com> wrote:

> >          arm |               wpewebkit-2.22.5 | NOK | http://autobuild.buildroot.net/results/645be27edc31037a9b1bb7ce0dc85440949b0846 |       
> 
> 
> This build failure of of the wpewebkit package is kind of odd: it looks like
> with assertions enabled (as in: doing a debug build) uses some variables which
> do not exist, and I wonder why we haven't seen this before?when working on
> WebKit we routinely do debug builds ?\_(?)_/? 

This build has BR2_ENABLE_DEBUG=y, and when BR2_ENABLE_DEBUG=y, the
CMake package infrastructure passes -DCMAKE_BUILD_TYPE=Debug. I assume
that's under this condition that assertions become enabled.

> I think it is more worth it to push the update to WPE WebKit 2.24.x forward,
> and this build failure would just go away.

Except that the build issue you're seeing is in master, and we're past
-rc1 (even -rc2 now), and therefore we generally don't take version
bumps in master, as we're too close to the release. Especially a
version bump on a complex package like wpewebkit, and for which the
version bump requires bumping the versions of a number of other
packages as well.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Adrian Perez de Castro]

On Thu, 16 May 2019 08:33:53 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello Adrian,
> 
> On Wed, 15 May 2019 22:17:03 +0300
> Adrian Perez de Castro <aperez@igalia.com> wrote:
> 
> > >          arm |               wpewebkit-2.22.5 | NOK | http://autobuild.buildroot.net/results/645be27edc31037a9b1bb7ce0dc85440949b0846 |       
> > 
> > 
> > This build failure of of the wpewebkit package is kind of odd: it looks like
> > with assertions enabled (as in: doing a debug build) uses some variables which
> > do not exist, and I wonder why we haven't seen this before?when working on
> > WebKit we routinely do debug builds ?\_(?)_/? 
> 
> This build has BR2_ENABLE_DEBUG=y, and when BR2_ENABLE_DEBUG=y, the
> CMake package infrastructure passes -DCMAKE_BUILD_TYPE=Debug. I assume
> that's under this condition that assertions become enabled.

On a related note: for debug builds done by packagers we usually recommend
building with ?-DCMAKE_BUILD_TYPE=RelWithDebInfo? because using the ?Debug?
produces excruciatingly slow WebKit binaries. To give you an idea: loading
some simple static HTML page over the network can take a couple of minutes.
Typically full ?Debug? builds are only ever used by WebKit developers.

> > I think it is more worth it to push the update to WPE WebKit 2.24.x forward,
> > and this build failure would just go away.
> 
> Except that the build issue you're seeing is in master, and we're past
> -rc1 (even -rc2 now), and therefore we generally don't take version
> bumps in master, as we're too close to the release. Especially a
> version bump on a complex package like wpewebkit, and for which the
> version bump requires bumping the versions of a number of other
> packages as well.

Good point, I was forgetting about the upcoming release. Let's fix this.
Do you think it would be enough to make Buildroot use ?RelWithDebInfo? for
debug builds? I see that other packages (like flare-engine, for example) do
that already.

Cheers,
?Adri?n
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190516/054655ff/attachment.asc>

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Thomas Petazzoni]

Hello,

+Samuel Martin in the discussion.

On Thu, 16 May 2019 11:52:48 +0300
Adrian Perez de Castro <aperez@igalia.com> wrote:

> > This build has BR2_ENABLE_DEBUG=y, and when BR2_ENABLE_DEBUG=y, the
> > CMake package infrastructure passes -DCMAKE_BUILD_TYPE=Debug. I assume
> > that's under this condition that assertions become enabled.  
> 
> On a related note: for debug builds done by packagers we usually recommend
> building with ?-DCMAKE_BUILD_TYPE=RelWithDebInfo? because using the ?Debug?
> produces excruciatingly slow WebKit binaries. To give you an idea: loading
> some simple static HTML page over the network can take a couple of minutes.
> Typically full ?Debug? builds are only ever used by WebKit developers.

I know there was so back and forth between Debug and RelWithDebInfo,
see the commit log of commit 104bb29e0490bfb487e2e665448dd3ca07fcc2b5:

commit 104bb29e0490bfb487e2e665448dd3ca07fcc2b5
Author: Samuel Martin <s.martin49@gmail.com>
Date:   Sun Oct 16 13:12:37 2016 +0200

    Revert "package/cmake: with BR2_ENABLE_DEBUG use RelWithDebInfo"
    
    This reverts commit 4b0120183404913f7f7788ef4f0f6b51498ef363.
    
    Before reverting this patch, CMake packages are built with the following
    options:
      * if BR2_ENABLE_DEBUG is set:
        The CMake build type is set to RelWithDebInfo, which means:
        - Optimization level is forced to: -O2;
        - no log nor assert due to -DNDEBUG;
        - BR2_DEBUG_{1..3} effect is unchanged;
      * otherwise:
        The CMake build type is set to Release, which means:
        - Optimization level is forced to: -O3;
        - no log nor assert due to -DNDEBUG (as expected).
      In any case, the optimization WRT the binary size is always ignored
      and forced.
    
    Reverting to the previous situation, so Buildroot now chooses between
    the 'Debug' and 'Release' config types, which are semantically closer
    to what Buildroot does everywhere else:
      * if BR2_ENABLE_DEBUG is set:
        The CMake build type is set to Debug, which means:
        - only -g option is passed by CMake;
        - optimization is not forced, nor debug level, so they are kept
          as-is;
      * otherwise:
        The CMake build type is set to Release, so no change in this case:
        - Optimization level is forced to: -O3;
        - no log nor assert due to -DNDEBUG (as expected);
        - size optimization is ignored.
    
    Follow-up patches will fix the CMake flag variables that are appended by
    CMake.
    
    Cc: Charles Hardin <ckhardin@exablox.com>
    Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
    Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
    Signed-off-by: Samuel Martin <s.martin49@gmail.com>
    Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

So apparently, the issue with RelWithDebInfo is that it forces the
optimization level.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Build results for 2019-05-14

[Arnout Vandecappelle]

On 16/05/2019 11:06, Thomas Petazzoni wrote:
> Hello,
> 
> +Samuel Martin in the discussion.
> 
> On Thu, 16 May 2019 11:52:48 +0300
> Adrian Perez de Castro <aperez@igalia.com> wrote:
> 
>>> This build has BR2_ENABLE_DEBUG=y, and when BR2_ENABLE_DEBUG=y, the
>>> CMake package infrastructure passes -DCMAKE_BUILD_TYPE=Debug. I assume
>>> that's under this condition that assertions become enabled.  
>>
>> On a related note: for debug builds done by packagers we usually recommend
>> building with ?-DCMAKE_BUILD_TYPE=RelWithDebInfo? because using the ?Debug?
>> produces excruciatingly slow WebKit binaries. To give you an idea: loading
>> some simple static HTML page over the network can take a couple of minutes.
>> Typically full ?Debug? builds are only ever used by WebKit developers.
> 
> I know there was so back and forth between Debug and RelWithDebInfo,
> see the commit log of commit 104bb29e0490bfb487e2e665448dd3ca07fcc2b5:
[snip]
>     Reverting to the previous situation, so Buildroot now chooses between
>     the 'Debug' and 'Release' config types, which are semantically closer
>     to what Buildroot does everywhere else:
>       * if BR2_ENABLE_DEBUG is set:
>         The CMake build type is set to Debug, which means:
>         - only -g option is passed by CMake;
>         - optimization is not forced, nor debug level, so they are kept
>           as-is;
>       * otherwise:
>         The CMake build type is set to Release, so no change in this case:
>         - Optimization level is forced to: -O3;
>         - no log nor assert due to -DNDEBUG (as expected);
>         - size optimization is ignored.
>     
>     Follow-up patches will fix the CMake flag variables that are appended by
>     CMake.
>     
>     Cc: Charles Hardin <ckhardin@exablox.com>
>     Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>     Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
>     Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>     Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>     Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> So apparently, the issue with RelWithDebInfo is that it forces the
> optimization level.

 CMAKE_BUILD_TYPE basically does two things.

1. In addition to CMAKE_C_FLAGS, CMAKE_C_FLAGS_<buildtype> is used (and the same
for a bunch of other variables). The defaults of these variables set various
debug and optimisation flags. Note that packages tend to add things both to
CMAKE_C_FLAGS and CMAKE_C_FLAGS_RELEASE/DEBUG/...

2. Package's CMakeLists.txt use it to do various things, e.g. build additional
stuff in debug mode, or enable Werror, or .... Impossible to say in general what
they will come up with.

 I think we should do the same as we did with autotools a while ago: we remove
the --enable-debug and instead always build in "release" mode, but we force
debug flags through CFLAGS. That's also how it's documented in the
BR2_ENABLE_DEBUG help text.

 So, I think we should set CMAKE_BUILD_TYPE to Release - or even leave it empty,
since that's the default. And then we only need to set CMAKE_C_FLAGS_RELEASE.


 By the way, while investigating this, I discovered that we set -DNDEBUG for
CMake release, but we don't do that for other build systems. Sounds like a
mistake...

 Regards,
 Arnout