All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
       [not found] <20180408060016.70C472084F@mail.bootlin.com>
@ 2018-04-10  2:50 ` Carlos Santos
  2018-04-10  3:00   ` Carlos Santos
  0 siblings, 1 reply; 12+ messages in thread
From: Carlos Santos @ 2018-04-10  2:50 UTC (permalink / raw)
  To: buildroot

> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Sent: Sunday, April 8, 2018 3:00:16 AM
> Subject: [autobuild.buildroot.net] Your build results for 2018-04-07

> Hello,
> 
> This is the list of Buildroot build failures that occured on
> 2018-04-07, and for which you are a registered architecture developer
> or package developer. Please help us improving the quality of
> Buildroot by investigating those build failures and sending patches to
> fix them. Thanks!
> 
> Results for the 'master' branch
> ===============================
> 
> Build failures related to your packages:
> 
>     powerpc |               tpm2-abrmd-1.3.0 |
>     http://autobuild.buildroot.net/results/b29a2f868438a2210873ea72f491db63175848be
> 
> --
> http://autobuild.buildroot.net

The it's a problem libglib2, not in tpm2-abrmd:

$ echo -e '#include <gio/gio.h>\nint main(){return 0;}' | host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
                 from staging/usr/include/glib-2.0/glib-object.h:23,
                 from staging/usr/include/glib-2.0/gio/gioenums.h:28,
                 from staging/usr/include/glib-2.0/gio/giotypes.h:28,
                 from staging/usr/include/glib-2.0/gio/gio.h:26,
                 from <stdin>:1:
staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
cc1: all warnings being treated as errors

This was after commit 4dcfcd17c09b5684e95943de119b95a34c93ad63, so the
bump to libglig2 v2.56.1 did not solve the problem.

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-10  2:50 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07 Carlos Santos
@ 2018-04-10  3:00   ` Carlos Santos
  2018-04-10 17:09     ` Fabrice Fontaine
  0 siblings, 1 reply; 12+ messages in thread
From: Carlos Santos @ 2018-04-10  3:00 UTC (permalink / raw)
  To: buildroot

> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: "buildroot" <buildroot@buildroot.org>
> Cc: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> Sent: Monday, April 9, 2018 11:50:27 PM
> Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07

>> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
>> To: "Carlos Santos" <casantos@datacom.ind.br>
>> Sent: Sunday, April 8, 2018 3:00:16 AM
>> Subject: [autobuild.buildroot.net] Your build results for 2018-04-07
> 
>> Hello,
>> 
>> This is the list of Buildroot build failures that occured on
>> 2018-04-07, and for which you are a registered architecture developer
>> or package developer. Please help us improving the quality of
>> Buildroot by investigating those build failures and sending patches to
>> fix them. Thanks!
>> 
>> Results for the 'master' branch
>> ===============================
>> 
>> Build failures related to your packages:
>> 
>>     powerpc |               tpm2-abrmd-1.3.0 |
>>     http://autobuild.buildroot.net/results/b29a2f868438a2210873ea72f491db63175848be
>> 
>> --
>> http://autobuild.buildroot.net
> 
> The it's a problem libglib2, not in tpm2-abrmd:
> 
> $ echo -e '#include <gio/gio.h>\nint main(){return 0;}' |
> host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I
> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror
> -c - -o /tmp/foo.o
> In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>                 from staging/usr/include/glib-2.0/glib-object.h:23,
>                 from staging/usr/include/glib-2.0/gio/gioenums.h:28,
>                 from staging/usr/include/glib-2.0/gio/giotypes.h:28,
>                 from staging/usr/include/glib-2.0/gio/gio.h:26,
>                 from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is
> not used [-Werror=unused-value]
> cc1: all warnings being treated as errors
> 
> This was after commit 4dcfcd17c09b5684e95943de119b95a34c93ad63, so the
> bump to libglig2 v2.56.1 did not solve the problem.

It seems to be relates do this specific tollchain. I can't reproduce it
using the host compiler:

$ gcc --version
gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
$ echo -e '#include <gio/gio.h>\nint main(){return 0;}' | gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o

[no error]

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-10  3:00   ` Carlos Santos
@ 2018-04-10 17:09     ` Fabrice Fontaine
  2018-04-10 18:53       ` Fabrice Fontaine
  0 siblings, 1 reply; 12+ messages in thread
From: Fabrice Fontaine @ 2018-04-10 17:09 UTC (permalink / raw)
  To: buildroot

Dear all,

2018-04-10 5:00 GMT+02:00 Carlos Santos <casantos@datacom.ind.br>:

> > From: "Carlos Santos" <casantos@datacom.ind.br>
> > To: "buildroot" <buildroot@buildroot.org>
> > Cc: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>, "Thomas Petazzoni"
> <thomas.petazzoni@bootlin.com>
> > Sent: Monday, April 9, 2018 11:50:27 PM
> > Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results
> for 2018-04-07
>
> >> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> >> To: "Carlos Santos" <casantos@datacom.ind.br>
> >> Sent: Sunday, April 8, 2018 3:00:16 AM
> >> Subject: [autobuild.buildroot.net] Your build results for 2018-04-07
> >
> >> Hello,
> >>
> >> This is the list of Buildroot build failures that occured on
> >> 2018-04-07, and for which you are a registered architecture developer
> >> or package developer. Please help us improving the quality of
> >> Buildroot by investigating those build failures and sending patches to
> >> fix them. Thanks!
> >>
> >> Results for the 'master' branch
> >> ===============================
> >>
> >> Build failures related to your packages:
> >>
> >>     powerpc |               tpm2-abrmd-1.3.0 |
> >>     http://autobuild.buildroot.net/results/b29a2f868438a2210873
> ea72f491db63175848be
> >>
> >> --
> >> http://autobuild.buildroot.net
> >
> > The it's a problem libglib2, not in tpm2-abrmd:
> >
> > $ echo -e '#include <gio/gio.h>\nint main(){return 0;}' |
> > host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I
> > staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
> -Werror
> > -c - -o /tmp/foo.o
> > In file included from staging/usr/include/glib-2.0/g
> object/gbinding.h:29:0,
> >                 from staging/usr/include/glib-2.0/glib-object.h:23,
> >                 from staging/usr/include/glib-2.0/gio/gioenums.h:28,
> >                 from staging/usr/include/glib-2.0/gio/giotypes.h:28,
> >                 from staging/usr/include/glib-2.0/gio/gio.h:26,
> >                 from <stdin>:1:
> > staging/usr/include/glib-2.0/gobject/gobject.h: In function
> 'g_set_object':
> > staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value
> computed is
> > not used [-Werror=unused-value]
> > cc1: all warnings being treated as errors
> >
> > This was after commit 4dcfcd17c09b5684e95943de119b95a34c93ad63, so the
> > bump to libglig2 v2.56.1 did not solve the problem.
>
> It seems to be relates do this specific tollchain. I can't reproduce it
> using the host compiler:
>
> $ gcc --version
> gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
> $ echo -e '#include <gio/gio.h>\nint main(){return 0;}' | gcc -x c -I
> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
> -Werror -c - -o /tmp/foo.o
>
> [no error]
>
> Indeed, this is an issue with libglib2 on powerpc.
It seems it doesn't like the following statement:
g_object_ref (new_object);

because the return value of g_object_ref is "not used".

I can make a patch to return a void value:
(void) g_object_ref (new_object);

But if I fix this one, there is a lot more errors:

src/access-broker.c: In function 'access_broker_set_property':
src/access-broker.c:71:9: error: value computed is not used
[-Werror=unused-value]
src/command-source.c: In function 'command_source_set_property':
src/command-source.c:149:9: error: value computed is not used
[-Werror=unused-value]
src/command-source.c: In function 'command_source_on_new_connection':
src/command-source.c:277:5: error: value computed is not used
[-Werror=unused-value]
src/command-source.c: In function 'command_source_new':
src/command-source.c:429:5: error: value computed is not used
[-Werror=unused-value]
cc1: all warnings being treated as errors

Each time, it's a call to g_object_ref.

So, I search a bit and it seems that the issue is link to this definition
from gobject.h:

#if defined(__GNUC__) && !defined(__cplusplus) && GLIB_VERSION_MAX_ALLOWED
>= GLIB_VERSION_2_56
/* Make reference APIs type safe with macros */
#define g_object_ref(Obj)      ((__typeof__(Obj)) (g_object_ref) (Obj))
#define g_object_ref_sink(Obj) ((__typeof__(Obj)) (g_object_ref_sink) (Obj))
#endif

These lines have been added by commit https://github.com/GNOM
E/glib/commit/3fae39a5d742afe73741f5fd7aa24e3ae8182f06.
I don't understand why it's not working on powerpc so I will just send a
patch for libglib2 to put back old behavior if __powerpc__ is defined.


> --
> Carlos Santos (Casantos) - DATACOM, P&D
> ?The greatest triumph that modern PR can offer is the transcendent
> success of having your words and actions judged by your reputation,
> rather than the other way about.? ? Christopher Hitchens
>
Best Regards,

Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180410/bf4221eb/attachment.html>

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-10 17:09     ` Fabrice Fontaine
@ 2018-04-10 18:53       ` Fabrice Fontaine
  2018-04-11 12:39         ` Carlos Santos
  0 siblings, 1 reply; 12+ messages in thread
From: Fabrice Fontaine @ 2018-04-10 18:53 UTC (permalink / raw)
  To: buildroot

Dear all,

2018-04-10 19:09 GMT+02:00 Fabrice Fontaine <fontaine.fabrice@gmail.com>:

> Dear all,
>
> 2018-04-10 5:00 GMT+02:00 Carlos Santos <casantos@datacom.ind.br>:
>
>> > From: "Carlos Santos" <casantos@datacom.ind.br>
>> > To: "buildroot" <buildroot@buildroot.org>
>> > Cc: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>, "Thomas
>> Petazzoni" <thomas.petazzoni@bootlin.com>
>> > Sent: Monday, April 9, 2018 11:50:27 PM
>> > Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results
>> for 2018-04-07
>>
>> >> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
>> >> To: "Carlos Santos" <casantos@datacom.ind.br>
>> >> Sent: Sunday, April 8, 2018 3:00:16 AM
>> >> Subject: [autobuild.buildroot.net] Your build results for 2018-04-07
>> >
>> >> Hello,
>> >>
>> >> This is the list of Buildroot build failures that occured on
>> >> 2018-04-07, and for which you are a registered architecture developer
>> >> or package developer. Please help us improving the quality of
>> >> Buildroot by investigating those build failures and sending patches to
>> >> fix them. Thanks!
>> >>
>> >> Results for the 'master' branch
>> >> ===============================
>> >>
>> >> Build failures related to your packages:
>> >>
>> >>     powerpc |               tpm2-abrmd-1.3.0 |
>> >>     http://autobuild.buildroot.net/results/b29a2f868438a2210873
>> ea72f491db63175848be
>> >>
>> >> --
>> >> http://autobuild.buildroot.net
>> >
>> > The it's a problem libglib2, not in tpm2-abrmd:
>> >
>> > $ echo -e '#include <gio/gio.h>\nint main(){return 0;}' |
>> > host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I
>> > staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
>> -Werror
>> > -c - -o /tmp/foo.o
>> > In file included from staging/usr/include/glib-2.0/g
>> object/gbinding.h:29:0,
>> >                 from staging/usr/include/glib-2.0/glib-object.h:23,
>> >                 from staging/usr/include/glib-2.0/gio/gioenums.h:28,
>> >                 from staging/usr/include/glib-2.0/gio/giotypes.h:28,
>> >                 from staging/usr/include/glib-2.0/gio/gio.h:26,
>> >                 from <stdin>:1:
>> > staging/usr/include/glib-2.0/gobject/gobject.h: In function
>> 'g_set_object':
>> > staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value
>> computed is
>> > not used [-Werror=unused-value]
>> > cc1: all warnings being treated as errors
>> >
>> > This was after commit 4dcfcd17c09b5684e95943de119b95a34c93ad63, so the
>> > bump to libglig2 v2.56.1 did not solve the problem.
>>
>> It seems to be relates do this specific tollchain. I can't reproduce it
>> using the host compiler:
>>
>> $ gcc --version
>> gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>> $ echo -e '#include <gio/gio.h>\nint main(){return 0;}' | gcc -x c -I
>> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
>> -Werror -c - -o /tmp/foo.o
>>
>> [no error]
>>
>> Indeed, this is an issue with libglib2 on powerpc.
> It seems it doesn't like the following statement:
> g_object_ref (new_object);
>
> because the return value of g_object_ref is "not used".
>
> I can make a patch to return a void value:
> (void) g_object_ref (new_object);
>
> But if I fix this one, there is a lot more errors:
>
> src/access-broker.c: In function 'access_broker_set_property':
> src/access-broker.c:71:9: error: value computed is not used
> [-Werror=unused-value]
> src/command-source.c: In function 'command_source_set_property':
> src/command-source.c:149:9: error: value computed is not used
> [-Werror=unused-value]
> src/command-source.c: In function 'command_source_on_new_connection':
> src/command-source.c:277:5: error: value computed is not used
> [-Werror=unused-value]
> src/command-source.c: In function 'command_source_new':
> src/command-source.c:429:5: error: value computed is not used
> [-Werror=unused-value]
> cc1: all warnings being treated as errors
>
> Each time, it's a call to g_object_ref.
>
> So, I search a bit and it seems that the issue is link to this definition
> from gobject.h:
>
> #if defined(__GNUC__) && !defined(__cplusplus) && GLIB_VERSION_MAX_ALLOWED
> >= GLIB_VERSION_2_56
> /* Make reference APIs type safe with macros */
> #define g_object_ref(Obj)      ((__typeof__(Obj)) (g_object_ref) (Obj))
> #define g_object_ref_sink(Obj) ((__typeof__(Obj)) (g_object_ref_sink)
> (Obj))
> #endif
>
> These lines have been added by commit https://github.com/GNOM
> E/glib/commit/3fae39a5d742afe73741f5fd7aa24e3ae8182f06.
> I don't understand why it's not working on powerpc so I will just send a
> patch for libglib2 to put back old behavior if __powerpc__ is defined.
>
Disabling this feature on powerpc is not a good solution for the glib
developers: https://bugzilla.gnome.org/show_bug.cgi?id=795138.
So except if someone knows why this define doesn't work on powerpc, perhaps
we could remove -Werror from tpm2-abrmd package and hope that other glib
packages will not break on powerpc ...

>
>
>> --
>> Carlos Santos (Casantos) - DATACOM, P&D
>> ?The greatest triumph that modern PR can offer is the transcendent
>> success of having your words and actions judged by your reputation,
>> rather than the other way about.? ? Christopher Hitchens
>>
> Best Regards,
>
> Fabrice
>
Best Regards,

Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180410/8581bbf7/attachment.html>

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-10 18:53       ` Fabrice Fontaine
@ 2018-04-11 12:39         ` Carlos Santos
  2018-04-11 13:19           ` Thomas Petazzoni
  0 siblings, 1 reply; 12+ messages in thread
From: Carlos Santos @ 2018-04-11 12:39 UTC (permalink / raw)
  To: buildroot

> From: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: "buildroot" <buildroot@buildroot.org>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> Sent: Tuesday, April 10, 2018 3:53:44 PM
> Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07

[...]

>> Indeed, this is an issue with libglib2 on powerpc.
>> It seems it doesn't like the following statement:
>> g_object_ref (new_object);

>> because the return value of g_object_ref is "not used".

>> I can make a patch to return a void value:
>> (void) g_object_ref (new_object);

>> But if I fix this one, there is a lot more errors:

>> src/access-broker.c: In function 'access_broker_set_property':
>> src/access-broker.c:71:9: error: value computed is not used
>> [-Werror=unused-value]
>> src/command-source.c: In function 'command_source_set_property':
>> src/command-source.c:149:9: error: value computed is not used
>> [-Werror=unused-value]
>> src/command-source.c: In function 'command_source_on_new_connection':
>> src/command-source.c:277:5: error: value computed is not used
>> [-Werror=unused-value]
>> src/command-source.c: In function 'command_source_new':
>> src/command-source.c:429:5: error: value computed is not used
>> [-Werror=unused-value]
>> cc1: all warnings being treated as errors

>> Each time, it's a call to g_object_ref.

>> So, I search a bit and it seems that the issue is link to this definition from
>> gobject.h:

>> #if defined(__GNUC__) && !defined(__cplusplus) && GLIB_VERSION_MAX_ALLOWED >=
>> GLIB_VERSION_2_56
>> /* Make reference APIs type safe with macros */
>> #define g_object_ref(Obj) ((__typeof__(Obj)) (g_object_ref) (Obj))
>> #define g_object_ref_sink(Obj) ((__typeof__(Obj)) (g_object_ref_sink) (Obj))
>> #endif

>> These lines have been added by commit [
>> https://github.com/GNOME/glib/commit/3fae39a5d742afe73741f5fd7aa24e3ae8182f06 |
>> https://github.com/GNOME/glib/commit/3fae39a5d742afe73741f5fd7aa24e3ae8182f06 ]
>> .
>> I don't understand why it's not working on powerpc so I will just send a patch
>> for libglib2 to put back old behavior if __powerpc__ is defined.

> Disabling this feature on powerpc is not a good solution for the glib
> developers: [ https://bugzilla.gnome.org/show_bug.cgi?id=795138 |
> https://bugzilla.gnome.org/show_bug.cgi?id=795138 ] .
> So except if someone knows why this define doesn't work on powerpc, perhaps we
> could remove -Werror from tpm2-abrmd package and hope that other glib packages
> will not break on powerpc ...

I investigated it a little bit more and it seems to be restricted to
the rather old GCC used in that build.

$ host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc --version
powerpc-ctng_e500v2-linux-gnuspe-gcc (crosstool-NG hg+-c65fcf8a34b7) 4.7.3
$ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
                 from staging/usr/include/glib-2.0/glib-object.h:23,
                 from <stdin>:1:
staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
cc1: all warnings being treated as errors

Using newer GCC versions:

$ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG 1.20.0) 4.8.2
$ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
[success]

$ host/bin/powerpc-buildroot-linux-uclibc-gcc --version
powerpc-buildroot-linux-uclibc-gcc.br_real (Buildroot 2016.08-git-01162-g94c7298) 4.9.3
echo -e '#include <glib-object.h>\n' | host/bin/powerpc-buildroot-linux-uclibc-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
[success]

$ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG bf52f9a) 5.3.0
$ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
[success]

$ host/bin/powerpc-linux-gcc --version
powerpc-linux-gcc.br_real (Buildroot 2017.08-git-01078-g95b1dae) 6.3.0
echo -e '#include <glib-object.h>\n' | host/bin/powerpc-linux-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
[success]

So I think we should make libglib2 depend on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 if
the target architecture is PowerPC. Do you agree?

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-11 12:39         ` Carlos Santos
@ 2018-04-11 13:19           ` Thomas Petazzoni
  2018-04-12  2:40             ` Carlos Santos
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2018-04-11 13:19 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 11 Apr 2018 09:39:24 -0300 (BRT), Carlos Santos wrote:

> I investigated it a little bit more and it seems to be restricted to
> the rather old GCC used in that build.
> 
> $ host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc --version
> powerpc-ctng_e500v2-linux-gnuspe-gcc (crosstool-NG hg+-c65fcf8a34b7) 4.7.3
> $ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>                  from staging/usr/include/glib-2.0/glib-object.h:23,
>                  from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors
> 
> Using newer GCC versions:
> 
> $ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
> powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG 1.20.0) 4.8.2
> $ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> [success]
> 
> $ host/bin/powerpc-buildroot-linux-uclibc-gcc --version
> powerpc-buildroot-linux-uclibc-gcc.br_real (Buildroot 2016.08-git-01162-g94c7298) 4.9.3
> echo -e '#include <glib-object.h>\n' | host/bin/powerpc-buildroot-linux-uclibc-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> [success]
> 
> $ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
> powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG bf52f9a) 5.3.0
> $ echo -e '#include <glib-object.h>\n' | host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> [success]
> 
> $ host/bin/powerpc-linux-gcc --version
> powerpc-linux-gcc.br_real (Buildroot 2017.08-git-01078-g95b1dae) 6.3.0
> echo -e '#include <glib-object.h>\n' | host/bin/powerpc-linux-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> [success]
> 
> So I think we should make libglib2 depend on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 if
> the target architecture is PowerPC. Do you agree?

Is this problem really PowerPC specific ? Did you try other gcc 4.7
toolchains for other architectures ?

Also, adding new dependencies on libglib2 is an absolute nightmare: you
have to propagate those new dependencies to gazillions of packages (all
reverse dependencies of libglib2) :-/

Best regards,

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

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-11 13:19           ` Thomas Petazzoni
@ 2018-04-12  2:40             ` Carlos Santos
  2018-04-12  7:06               ` Thomas Petazzoni
  0 siblings, 1 reply; 12+ messages in thread
From: Carlos Santos @ 2018-04-12  2:40 UTC (permalink / raw)
  To: buildroot

> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>, "buildroot" <buildroot@buildroot.org>
> Sent: Wednesday, April 11, 2018 10:19:10 AM
> Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07

> Hello,
> 
> On Wed, 11 Apr 2018 09:39:24 -0300 (BRT), Carlos Santos wrote:
> 
>> I investigated it a little bit more and it seems to be restricted to
>> the rather old GCC used in that build.
>> 
>> $ host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc --version
>> powerpc-ctng_e500v2-linux-gnuspe-gcc (crosstool-NG hg+-c65fcf8a34b7) 4.7.3
>> $ echo -e '#include <glib-object.h>\n' |
>> host/bin/powerpc-ctng_e500v2-linux-gnuspe-gcc -x c -I
>> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror
>> -c - -o /tmp/foo.o
>> In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>>                  from staging/usr/include/glib-2.0/glib-object.h:23,
>>                  from <stdin>:1:
>> staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
>> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is
>> not used [-Werror=unused-value]
>> cc1: all warnings being treated as errors
>> 
>> Using newer GCC versions:
>> 
>> $ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
>> powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG 1.20.0) 4.8.2
>> $ echo -e '#include <glib-object.h>\n' |
>> host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0
>> -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
>> [success]
>> 
>> $ host/bin/powerpc-buildroot-linux-uclibc-gcc --version
>> powerpc-buildroot-linux-uclibc-gcc.br_real (Buildroot
>> 2016.08-git-01162-g94c7298) 4.9.3
>> echo -e '#include <glib-object.h>\n' |
>> host/bin/powerpc-buildroot-linux-uclibc-gcc -x c -I
>> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror
>> -c - -o /tmp/foo.o
>> [success]
>> 
>> $ host/bin/powerpc-e500v2-linux-gnuspe-gcc --version
>> powerpc-e500v2-linux-gnuspe-gcc (crosstool-NG bf52f9a) 5.3.0
>> $ echo -e '#include <glib-object.h>\n' |
>> host/bin/powerpc-e500v2-linux-gnuspe-gcc -x c -I staging/usr/include/glib-2.0
>> -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
>> [success]
>> 
>> $ host/bin/powerpc-linux-gcc --version
>> powerpc-linux-gcc.br_real (Buildroot 2017.08-git-01078-g95b1dae) 6.3.0
>> echo -e '#include <glib-object.h>\n' | host/bin/powerpc-linux-gcc -x c -I
>> staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror
>> -c - -o /tmp/foo.o
>> [success]
>> 
>> So I think we should make libglib2 depend on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 if
>> the target architecture is PowerPC. Do you agree?
> 
> Is this problem really PowerPC specific ? Did you try other gcc 4.7
> toolchains for other architectures ?

I will try to find a museum from which I can get such toolchains.

> Also, adding new dependencies on libglib2 is an absolute nightmare: you
> have to propagate those new dependencies to gazillions of packages (all
> reverse dependencies of libglib2) :-/

Indeed it is. :-(

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-12  2:40             ` Carlos Santos
@ 2018-04-12  7:06               ` Thomas Petazzoni
  2018-04-12 14:27                 ` Carlos Santos
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2018-04-12  7:06 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 11 Apr 2018 23:40:37 -0300 (BRT), Carlos Santos wrote:

> > Is this problem really PowerPC specific ? Did you try other gcc 4.7
> > toolchains for other architectures ?  
> 
> I will try to find a museum from which I can get such toolchains.

Old Sourcery toolchains can typically be used for that, and
http://sources.buildroot.net/ is a good museum to find them. For
example:

http://sources.buildroot.net/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
http://sources.buildroot.net/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
http://sources.buildroot.net/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
http://sources.buildroot.net/arm-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
etc.

> > Also, adding new dependencies on libglib2 is an absolute nightmare: you
> > have to propagate those new dependencies to gazillions of packages (all
> > reverse dependencies of libglib2) :-/  
> 
> Indeed it is. :-(

Hence we should try to avoid this if possible :-)

Best regards,

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

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-12  7:06               ` Thomas Petazzoni
@ 2018-04-12 14:27                 ` Carlos Santos
  2018-04-12 14:37                   ` Thomas Petazzoni
  0 siblings, 1 reply; 12+ messages in thread
From: Carlos Santos @ 2018-04-12 14:27 UTC (permalink / raw)
  To: buildroot

> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: "Fabrice Fontaine" <fontaine.fabrice@gmail.com>, "buildroot" <buildroot@buildroot.org>
> Sent: Thursday, April 12, 2018 4:06:41 AM
> Subject: Re: [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07

> Hello,
> 
> On Wed, 11 Apr 2018 23:40:37 -0300 (BRT), Carlos Santos wrote:
> 
>> > Is this problem really PowerPC specific ? Did you try other gcc 4.7
>> > toolchains for other architectures ?
>> 
>> I will try to find a museum from which I can get such toolchains.
> 
> Old Sourcery toolchains can typically be used for that, and
> http://sources.buildroot.net/ is a good museum to find them. For
> example:
> 
> http://sources.buildroot.net/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
> http://sources.buildroot.net/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
> http://sources.buildroot.net/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
> http://sources.buildroot.net/arm-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
> etc.

I generated toolchains with ct-NG 1.20 for i686 and ARM. Here are
the results:

$ i686-nptl-linux-gnu-gcc --version
i686-nptl-linux-gnu-gcc (crosstool-NG 1.20.0) 4.7.4
$ echo '#include <glib-object.h>' | i686-nptl-linux-gnu-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
                 from staging/usr/include/glib-2.0/glib-object.h:23,
                 from <stdin>:1:
staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
cc1: all warnings being treated as errors

$ arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (crosstool-NG 1.20.0) 4.7.4
$ echo '#include <glib-object.h>' | arm-unknown-linux-gnueabi-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
                 from staging/usr/include/glib-2.0/glib-object.h:23,
                 from <stdin>:1:
staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
cc1: all warnings being treated as errors

> 
>> > Also, adding new dependencies on libglib2 is an absolute nightmare: you
>> > have to propagate those new dependencies to gazillions of packages (all
>> > reverse dependencies of libglib2) :-/
>> 
>> Indeed it is. :-(
> 
> Hence we should try to avoid this if possible :-)

I will change in the tpm2-abrmd recipe but will try to restrict it to
GCC 4.7.x and below.

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-12 14:27                 ` Carlos Santos
@ 2018-04-12 14:37                   ` Thomas Petazzoni
  0 siblings, 0 replies; 12+ messages in thread
From: Thomas Petazzoni @ 2018-04-12 14:37 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu, 12 Apr 2018 11:27:19 -0300 (BRT), Carlos Santos wrote:

> I generated toolchains with ct-NG 1.20 for i686 and ARM. Here are
> the results:
> 
> $ i686-nptl-linux-gnu-gcc --version
> i686-nptl-linux-gnu-gcc (crosstool-NG 1.20.0) 4.7.4
> $ echo '#include <glib-object.h>' | i686-nptl-linux-gnu-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>                  from staging/usr/include/glib-2.0/glib-object.h:23,
>                  from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors
> 
> $ arm-unknown-linux-gnueabi-gcc --version
> arm-unknown-linux-gnueabi-gcc (crosstool-NG 1.20.0) 4.7.4
> $ echo '#include <glib-object.h>' | arm-unknown-linux-gnueabi-gcc -x c -I staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall -Werror -c - -o /tmp/foo.o
> In file included from staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
>                  from staging/usr/include/glib-2.0/glib-object.h:23,
>                  from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function 'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors

So the problem is indeed not PowerPC specific :) Thanks for taking the
time to generate those toolchains BTW!

Perhaps this will encourage the glib developers to accept a solution
upstream ?

> I will change in the tpm2-abrmd recipe but will try to restrict it to
> GCC 4.7.x and below.

What about a solution in glib itself ? Make those definitions
conditional on the gcc version, i.e only if gcc >= 4.8 is used ?

Best regards,

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

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
  2018-04-08 15:09 ` André Hentschel
@ 2018-04-08 15:48   ` Yann E. MORIN
  0 siblings, 0 replies; 12+ messages in thread
From: Yann E. MORIN @ 2018-04-08 15:48 UTC (permalink / raw)
  To: buildroot

Andr?, All,

On 2018-04-08 17:09 +0200, Andr? Hentschel spake thusly:
> Am 08.04.2018 um 08:00 schrieb Thomas Petazzoni:
> > Hello,
> > 
> > This is the list of Buildroot build failures that occured on
> > 2018-04-07, and for which you are a registered architecture developer
> > or package developer. Please help us improving the quality of
> > Buildroot by investigating those build failures and sending patches to
> > fix them. Thanks!
> > 
> > Results for the 'master' branch
> > ===============================
> > 
> > Build failures related to your packages:
> > 
> >          arc |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/35f9f7a4adc6c2cad741079e4afdf1408c94703b
> >          arc |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/258a0d3e7d40ed2d558127d9d201a8d21c219f0d
> >  powerpc64le |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/3197c847eb12aebc3509a7e11741530df57d2f14
> >         i686 |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/70c9a898a5ef148acc92fb505a8d2608b8ac485a
> > 
> 
> Hi,
> 
> I already have another mail with one failure of this kind.
> It all comes down to a broken setup it seems to me:
> 
> > ^[[3m>>> azure-iot-sdk-c 2018-03-16 Downloading^[[23m
> > Initialized empty Git repository in /home/peko/autobuild/instance-0/dl/azure-iot-sdk-c/git/.git/
> > Unknown option: -C
> > usage: git [--version] [--help] [-c name=value]
> >            [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
> >            [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
> >            [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
> >            <command> [<args>]

OK, so old git versions do not have the -C option. This is a fall-out of
the big download changes we've made last week-end to supoprt git caching.

Thanks for the investigations, I'll fix the issue.

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

* [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07
       [not found] <20180408060016.A832E207F1@mail.bootlin.com>
@ 2018-04-08 15:09 ` André Hentschel
  2018-04-08 15:48   ` Yann E. MORIN
  0 siblings, 1 reply; 12+ messages in thread
From: André Hentschel @ 2018-04-08 15:09 UTC (permalink / raw)
  To: buildroot

Am 08.04.2018 um 08:00 schrieb Thomas Petazzoni:
> Hello,
> 
> This is the list of Buildroot build failures that occured on
> 2018-04-07, and for which you are a registered architecture developer
> or package developer. Please help us improving the quality of
> Buildroot by investigating those build failures and sending patches to
> fix them. Thanks!
> 
> Results for the 'master' branch
> ===============================
> 
> Build failures related to your packages:
> 
>          arc |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/35f9f7a4adc6c2cad741079e4afdf1408c94703b
>          arc |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/258a0d3e7d40ed2d558127d9d201a8d21c219f0d
>  powerpc64le |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/3197c847eb12aebc3509a7e11741530df57d2f14
>         i686 |     azure-iot-sdk-c-2018-03-16 | http://autobuild.buildroot.net/results/70c9a898a5ef148acc92fb505a8d2608b8ac485a
> 

Hi,

I already have another mail with one failure of this kind.
It all comes down to a broken setup it seems to me:

> ^[[3m>>> azure-iot-sdk-c 2018-03-16 Downloading^[[23m
> Initialized empty Git repository in /home/peko/autobuild/instance-0/dl/azure-iot-sdk-c/git/.git/
> Unknown option: -C
> usage: git [--version] [--help] [-c name=value]
>            [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
>            [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
>            [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
>            <command> [<args>]

...

> ^[[3m>>> azure-iot-sdk-c 2018-03-16 Downloading^[[23m
> fatal: No such remote 'origin'

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

end of thread, other threads:[~2018-04-12 14:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20180408060016.70C472084F@mail.bootlin.com>
2018-04-10  2:50 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2018-04-07 Carlos Santos
2018-04-10  3:00   ` Carlos Santos
2018-04-10 17:09     ` Fabrice Fontaine
2018-04-10 18:53       ` Fabrice Fontaine
2018-04-11 12:39         ` Carlos Santos
2018-04-11 13:19           ` Thomas Petazzoni
2018-04-12  2:40             ` Carlos Santos
2018-04-12  7:06               ` Thomas Petazzoni
2018-04-12 14:27                 ` Carlos Santos
2018-04-12 14:37                   ` Thomas Petazzoni
     [not found] <20180408060016.A832E207F1@mail.bootlin.com>
2018-04-08 15:09 ` André Hentschel
2018-04-08 15:48   ` Yann E. MORIN

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.