Patchwork [1/2] site/arm-common: alignment values for guin32, guin64 and unsigned long

login
mail settings
Submitter Martin Jansa
Date May 2, 2012, 1:59 p.m.
Message ID <eec6dc7f29ff7e5297e2827196cc81ffd9a76831.1335967122.git.Martin.Jansa@gmail.com>
Download mbox | patch
Permalink /patch/26819/
State Accepted
Commit 6a9d7ba0d50dec99ae4ad9ee2c4e4b2b3bba6692
Headers show

Comments

Martin Jansa - May 2, 2012, 1:59 p.m.
From: Tomas Frydrych <tomas@sleepfive.com>

These are required to build recent versions of glib-2.0

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/site/arm-common |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Martin Jansa - May 2, 2012, 2:09 p.m.
On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
> From: Tomas Frydrych <tomas@sleepfive.com>
> 
> These are required to build recent versions of glib-2.0

similar patch is needed also for other site files, just noticed it while
building for qemux86-64

> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/site/arm-common |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/site/arm-common b/meta/site/arm-common
> index c3ffe08..cad8027 100644
> --- a/meta/site/arm-common
> +++ b/meta/site/arm-common
> @@ -76,6 +76,9 @@ glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
>  glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
>  glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
>  glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
> +ac_cv_alignof_guint32=4
> +ac_cv_alignof_guint64=8
> +ac_cv_alignof_unsigned_long=4
>  
>  #gstreamer
>  as_cv_unaligned_access=${as_cv_unaligned_access=no}
> -- 
> 1.7.8.6
>
Khem Raj - May 2, 2012, 9:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/02/2012 07:09 AM, Martin Jansa wrote:
> On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
>> From: Tomas Frydrych <tomas@sleepfive.com>
>> 
>> These are required to build recent versions of glib-2.0
> 
> similar patch is needed also for other site files, just noticed it
> while building for qemux86-64

would you also include rest of architectures too please ?

> 
>> 
>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- 
>> meta/site/arm-common |    3 +++ 1 files changed, 3 insertions(+),
>> 0 deletions(-)
>> 
>> diff --git a/meta/site/arm-common b/meta/site/arm-common index
>> c3ffe08..cad8027 100644 --- a/meta/site/arm-common +++
>> b/meta/site/arm-common @@ -76,6 +76,9 @@
>> glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4} 
>> glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4} 
>> glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4} 
>> glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
>>
>> 
+ac_cv_alignof_guint32=4
>> +ac_cv_alignof_guint64=8 +ac_cv_alignof_unsigned_long=4
>> 
>> #gstreamer as_cv_unaligned_access=${as_cv_unaligned_access=no} --
>>  1.7.8.6
>> 
> 
> 
> 
> _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+hol8ACgkQuwUzVZGdMxQEkgCfZY5mVAR5RxST2olpH41m6V+d
iQwAnRBaSrzbM/RGWmb8cZJjXwMAg6KJ
=tUvc
-----END PGP SIGNATURE-----
Martin Jansa - May 3, 2012, 5:38 a.m.
On Wed, May 02, 2012 at 02:08:47PM -0700, Khem Raj wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/02/2012 07:09 AM, Martin Jansa wrote:
> > On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
> >> From: Tomas Frydrych <tomas@sleepfive.com>
> >> 
> >> These are required to build recent versions of glib-2.0
> > 
> > similar patch is needed also for other site files, just noticed it
> > while building for qemux86-64
> 
> would you also include rest of architectures too please ?

I did for x86 and x86-64, for the rest I don't know the right values or
care enough to find them somewhere.

Cheers,

> 
> > 
> >> 
> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- 
> >> meta/site/arm-common |    3 +++ 1 files changed, 3 insertions(+),
> >> 0 deletions(-)
> >> 
> >> diff --git a/meta/site/arm-common b/meta/site/arm-common index
> >> c3ffe08..cad8027 100644 --- a/meta/site/arm-common +++
> >> b/meta/site/arm-common @@ -76,6 +76,9 @@
> >> glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4} 
> >> glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4} 
> >> glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4} 
> >> glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
> >>
> >> 
> +ac_cv_alignof_guint32=4
> >> +ac_cv_alignof_guint64=8 +ac_cv_alignof_unsigned_long=4
> >> 
> >> #gstreamer as_cv_unaligned_access=${as_cv_unaligned_access=no} --
> >>  1.7.8.6
> >> 
> > 
> > 
> > 
> > _______________________________________________ Openembedded-core
> > mailing list Openembedded-core@lists.openembedded.org 
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk+hol8ACgkQuwUzVZGdMxQEkgCfZY5mVAR5RxST2olpH41m6V+d
> iQwAnRBaSrzbM/RGWmb8cZJjXwMAg6KJ
> =tUvc
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - May 3, 2012, 5:44 a.m.
On Wed, May 2, 2012 at 10:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, May 02, 2012 at 02:08:47PM -0700, Khem Raj wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/02/2012 07:09 AM, Martin Jansa wrote:
>> > On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
>> >> From: Tomas Frydrych <tomas@sleepfive.com>
>> >>
>> >> These are required to build recent versions of glib-2.0
>> >
>> > similar patch is needed also for other site files, just noticed it
>> > while building for qemux86-64
>>
>> would you also include rest of architectures too please ?
>
> I did for x86 and x86-64, for the rest I don't know the right values or
> care enough to find them somewhere.

will this upgrade break glib for architectures that have wrong values
for these vars ?
if answer is yes then I think we should do that before applying this
upgrade otherwise
it will be a regression

>
> Cheers,
>
>>
>> >
>> >>
>> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> ---
>> >> meta/site/arm-common |    3 +++ 1 files changed, 3 insertions(+),
>> >> 0 deletions(-)
>> >>
>> >> diff --git a/meta/site/arm-common b/meta/site/arm-common index
>> >> c3ffe08..cad8027 100644 --- a/meta/site/arm-common +++
>> >> b/meta/site/arm-common @@ -76,6 +76,9 @@
>> >> glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
>> >> glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
>> >> glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
>> >> glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
>> >>
>> >>
>> +ac_cv_alignof_guint32=4
>> >> +ac_cv_alignof_guint64=8 +ac_cv_alignof_unsigned_long=4
>> >>
>> >> #gstreamer as_cv_unaligned_access=${as_cv_unaligned_access=no} --
>> >>  1.7.8.6
>> >>
>> >
>> >
>> >
>> > _______________________________________________ Openembedded-core
>> > mailing list Openembedded-core@lists.openembedded.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk+hol8ACgkQuwUzVZGdMxQEkgCfZY5mVAR5RxST2olpH41m6V+d
>> iQwAnRBaSrzbM/RGWmb8cZJjXwMAg6KJ
>> =tUvc
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - May 3, 2012, 5:46 a.m.
On Wed, May 02, 2012 at 10:44:05PM -0700, Khem Raj wrote:
> On Wed, May 2, 2012 at 10:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Wed, May 02, 2012 at 02:08:47PM -0700, Khem Raj wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 05/02/2012 07:09 AM, Martin Jansa wrote:
> >> > On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
> >> >> From: Tomas Frydrych <tomas@sleepfive.com>
> >> >>
> >> >> These are required to build recent versions of glib-2.0
> >> >
> >> > similar patch is needed also for other site files, just noticed it
> >> > while building for qemux86-64
> >>
> >> would you also include rest of architectures too please ?
> >
> > I did for x86 and x86-64, for the rest I don't know the right values or
> > care enough to find them somewhere.
> 
> will this upgrade break glib for architectures that have wrong values
> for these vars ?
> if answer is yes then I think we should do that before applying this
> upgrade otherwise
> it will be a regression

glib-2.32.1 will build there fine, but glib-2.32.2 will fail during
do_configure, so yes someone should add those.

Cheers,

> 
> >
> > Cheers,
> >
> >>
> >> >
> >> >>
> >> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> ---
> >> >> meta/site/arm-common |    3 +++ 1 files changed, 3 insertions(+),
> >> >> 0 deletions(-)
> >> >>
> >> >> diff --git a/meta/site/arm-common b/meta/site/arm-common index
> >> >> c3ffe08..cad8027 100644 --- a/meta/site/arm-common +++
> >> >> b/meta/site/arm-common @@ -76,6 +76,9 @@
> >> >> glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
> >> >> glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
> >> >> glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
> >> >> glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
> >> >>
> >> >>
> >> +ac_cv_alignof_guint32=4
> >> >> +ac_cv_alignof_guint64=8 +ac_cv_alignof_unsigned_long=4
> >> >>
> >> >> #gstreamer as_cv_unaligned_access=${as_cv_unaligned_access=no} --
> >> >>  1.7.8.6
> >> >>
> >> >
> >> >
> >> >
> >> > _______________________________________________ Openembedded-core
> >> > mailing list Openembedded-core@lists.openembedded.org
> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.11 (GNU/Linux)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>
> >> iEYEARECAAYFAk+hol8ACgkQuwUzVZGdMxQEkgCfZY5mVAR5RxST2olpH41m6V+d
> >> iQwAnRBaSrzbM/RGWmb8cZJjXwMAg6KJ
> >> =tUvc
> >> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - May 3, 2012, 8:55 a.m.
On Thu, 2012-05-03 at 07:46 +0200, Martin Jansa wrote:
> On Wed, May 02, 2012 at 10:44:05PM -0700, Khem Raj wrote:
> > On Wed, May 2, 2012 at 10:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > On Wed, May 02, 2012 at 02:08:47PM -0700, Khem Raj wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> On 05/02/2012 07:09 AM, Martin Jansa wrote:
> > >> > On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
> > >> >> From: Tomas Frydrych <tomas@sleepfive.com>
> > >> >>
> > >> >> These are required to build recent versions of glib-2.0
> > >> >
> > >> > similar patch is needed also for other site files, just noticed it
> > >> > while building for qemux86-64
> > >>
> > >> would you also include rest of architectures too please ?
> > >
> > > I did for x86 and x86-64, for the rest I don't know the right values or
> > > care enough to find them somewhere.
> > 
> > will this upgrade break glib for architectures that have wrong values
> > for these vars ?
> > if answer is yes then I think we should do that before applying this
> > upgrade otherwise
> > it will be a regression
> 
> glib-2.32.1 will build there fine, but glib-2.32.2 will fail during
> do_configure, so yes someone should add those.

Lets be really clear about this, glib 2.32.1 will build fine but crash
at runtime due to divide by zero errors.

I'm not taking any glib patches until we have this working on the core
architectures we support.

Please can people not send upgrades which knowingly break things. I'm
fine having a fairly aggressive set of updates but anything with serious
breakage like this will get reverted and cause me to consider patches
from those person long and hard with a lot of testing before merging in
future.

Cheers,

Richard
Martin Jansa - May 3, 2012, 9:29 a.m.
On Thu, May 03, 2012 at 09:55:44AM +0100, Richard Purdie wrote:
> On Thu, 2012-05-03 at 07:46 +0200, Martin Jansa wrote:
> > On Wed, May 02, 2012 at 10:44:05PM -0700, Khem Raj wrote:
> > > On Wed, May 2, 2012 at 10:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > > On Wed, May 02, 2012 at 02:08:47PM -0700, Khem Raj wrote:
> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > > >> Hash: SHA1
> > > >>
> > > >> On 05/02/2012 07:09 AM, Martin Jansa wrote:
> > > >> > On Wed, May 02, 2012 at 03:59:45PM +0200, Martin Jansa wrote:
> > > >> >> From: Tomas Frydrych <tomas@sleepfive.com>
> > > >> >>
> > > >> >> These are required to build recent versions of glib-2.0
> > > >> >
> > > >> > similar patch is needed also for other site files, just noticed it
> > > >> > while building for qemux86-64
> > > >>
> > > >> would you also include rest of architectures too please ?
> > > >
> > > > I did for x86 and x86-64, for the rest I don't know the right values or
> > > > care enough to find them somewhere.
> > > 
> > > will this upgrade break glib for architectures that have wrong values
> > > for these vars ?
> > > if answer is yes then I think we should do that before applying this
> > > upgrade otherwise
> > > it will be a regression
> > 
> > glib-2.32.1 will build there fine, but glib-2.32.2 will fail during
> > do_configure, so yes someone should add those.
> 
> Lets be really clear about this, glib 2.32.1 will build fine but crash
> at runtime due to divide by zero errors.

FWIW: I've seen it on one device and only in midori (in same batch of
upgrades with bring newer midori and newer gcc, so at the time I was
sending glib-2.32.1 I didn't know midori fails and it was working for me
in other apps).

That's why I sent follow-up patch to upgrade to 2.32.2 which will not
build on architectures without this so it will never go to runtime and
people which are building for e.g. mips will notice that soon enough.
 
> I'm not taking any glib patches until we have this working on the core
> architectures we support.

True, hopefully now the maintainers or even owners of those
architectures will do their job and add those site config values.
 
> Please can people not send upgrades which knowingly break things. I'm
> fine having a fairly aggressive set of updates but anything with serious
> breakage like this will get reverted and cause me to consider patches
> from those person long and hard with a lot of testing before merging in
> future.

And I'm pretty sad from contributing something in my free time and then
being asked over and over again to fix stuff I've never used/built
before. So this patchset is probably last one from me to oe-core/meta-oe
and now I'll care only about stuff in meta-smartphone and for other
layers just fill bug reports/feature requests to keep paid developers
busy and enjoy my free time in other ways..

Cheers,
Richard Purdie - May 3, 2012, 1:29 p.m.
On Thu, 2012-05-03 at 11:29 +0200, Martin Jansa wrote:
> FWIW: I've seen it on one device and only in midori (in same batch of
> upgrades with bring newer midori and newer gcc, so at the time I was
> sending glib-2.32.1 I didn't know midori fails and it was working for me
> in other apps).
> 
> That's why I sent follow-up patch to upgrade to 2.32.2 which will not
> build on architectures without this so it will never go to runtime and
> people which are building for e.g. mips will notice that soon enough.

2.32.2 is certainly a better option at this point.

> > I'm not taking any glib patches until we have this working on the core
> > architectures we support.
> 
> True, hopefully now the maintainers or even owners of those
> architectures will do their job and add those site config values.

The patch cannot go in until this has happened so yes, I hope so to.
 
> > Please can people not send upgrades which knowingly break things. I'm
> > fine having a fairly aggressive set of updates but anything with serious
> > breakage like this will get reverted and cause me to consider patches
> > from those person long and hard with a lot of testing before merging in
> > future.
> 
> And I'm pretty sad from contributing something in my free time and then
> being asked over and over again to fix stuff I've never used/built
> before. So this patchset is probably last one from me to oe-core/meta-oe
> and now I'll care only about stuff in meta-smartphone and for other
> layers just fill bug reports/feature requests to keep paid developers
> busy and enjoy my free time in other ways..

This is not what I'm saying. I'm asking that if people know that a patch
is going to break two out of four architectures we support, they mention
this clearly in the patch/pull request so we can deal with it. That is
taking some responsibility for the overall integrity of the project.
This was only partially known in the 2.32.1 timeframe but was clearly
known for 2.32.2. Evening an indication of what testing was done would
help me.

You are not being asked to fix it, however it will have to get fixed
before such a change can be applied to OE-Core (there is a difference
between those two things). I am going to find someone to figure out the
values for the other architectures and then this can go in.

The number of times I take something, people knew there was an issue but
didn't mention it, things break and then I personally end up having to
fix up the problem is getting beyond the point I can cope with. I'm
asking for people's help here...

Cheers,

Richard
Richard Purdie - May 3, 2012, 1:46 p.m.
I should also note that there is a wider problem here I'm complaining
about. The glib issue is actually less of a concern.

People keep sending patches without sensible descriptions in the commit
message. I think I've made some comments on list to Saul about this to
pick on someone in particular. The last set of patches from Khem
contains one which removed pretty much the whole qemu patch set from the
git version with no explanation in the commit message.

No, its not going in and I find it a a bit of an insult that I'm being
expected to read the diffs, notice these changes and spent time replying
to the patch with a nicely worded rejection email. I might just start
replying "no".

So what I'm asking is that people think about the changes they submit
and try and help me, not use patch submission as a sounding board and
not to hope I don't spot something.

To scale this project we need to develop trust relationships with people
taking ownership of areas of the codebase. I consider Mark Hatle to
"own" most things rpm for example. To scale we need to do more of this
but trust is important. If some people don't want to do this and just
contribute things when they can which interest them, that is fine but we
are going to reach a point where we have to take longer to test and take
such changes.

Cheers,

Richard
Khem Raj - May 3, 2012, 2:07 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/03/2012 06:46 AM, Richard Purdie wrote:
> I should also note that there is a wider problem here I'm
> complaining about. The glib issue is actually less of a concern.
> 
> People keep sending patches without sensible descriptions in the
> commit message. I think I've made some comments on list to Saul
> about this to pick on someone in particular. The last set of
> patches from Khem contains one which removed pretty much the whole
> qemu patch set from the git version with no explanation in the
> commit message.

OK provide that feedback to the patch. I will improve on it. Are you
talking about below commit.  I did mention patches are not forward ported

qemu-git: Move to tip of git

There are a lot of armv7 and sh4 fixes that its worth moving to latest
version. The patch forward porting can happen later.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

> 
> No, its not going in and I find it a a bit of an insult that I'm
> being expected to read the diffs, notice these changes and spent
> time replying to the patch with a nicely worded rejection email. I
> might just start replying "no".
> 
> So what I'm asking is that people think about the changes they
> submit and try and help me, not use patch submission as a sounding
> board and not to hope I don't spot something.
> 
> To scale this project we need to develop trust relationships with
> people taking ownership of areas of the codebase. I consider Mark
> Hatle to "own" most things rpm for example. To scale we need to do
> more of this but trust is important. If some people don't want to
> do this and just contribute things when they can which interest
> them, that is fine but we are going to reach a point where we have
> to take longer to test and take such changes.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ikS0ACgkQuwUzVZGdMxSK0wCdHTtEilAecZpvXkbd0Mak2LPw
NgIAn36cIeZ2fHbC85OFKXPrEkOsbU0q
=uyc9
-----END PGP SIGNATURE-----
Martin Jansa - May 3, 2012, 2:41 p.m.
On Thu, May 03, 2012 at 02:46:48PM +0100, Richard Purdie wrote:
> I should also note that there is a wider problem here I'm complaining
> about. The glib issue is actually less of a concern.
> 
> People keep sending patches without sensible descriptions in the commit
> message. I think I've made some comments on list to Saul about this to
> pick on someone in particular. The last set of patches from Khem
> contains one which removed pretty much the whole qemu patch set from the
> git version with no explanation in the commit message.
> 
> No, its not going in and I find it a a bit of an insult that I'm being
> expected to read the diffs, notice these changes and spent time replying
> to the patch with a nicely worded rejection email. I might just start
> replying "no".

True I should be more precise in saying what was tested, in cover letter
I've said:
Tested on my images and fixed failing recipe, mostly it's about
including header files like:
glib-2.0/glib/gthread.h:28:2: error: #error "Only <glib.h> can be
included directly."

And by my images I mean SHR image which cover much more then just
oe-core (mostly meta-oe and meta-smartphone layers). So I had to fix
9 recipes in meta-oe layer and 3 more in meta-smartphone while testing
rebuild from scratch with gcc-4.7 which needed another 3 recipes fixed
in meta-oe, firefox in meta-mozilla and 2 more recipes in
meta-smartphone. So yes I was quite busy whole weekend just because I
wanted to provide good gcc-4.7 coverage with more layers than just
oe-core. Whole glib upgrade was just one of steps in order to be able to
upgrade failing webkit-efl... And it wasn't my decision to make gcc-4.7
default version.

And when talking with Saul on IRC I've
said that I'm not building world (because my desktop is too slow, so
your autobuilder can find broken recipes sooner then my machine even
gets to building them).

So that's why I felt a bit insulted too when it's my fault that I wasn't
testing all this also on e.g. mips.

And FWIW as soon as I've discovered there is problem with other archs
I've replied to this patch (saying that other archs need similar patch)
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021774.html
and submited site changes for x86/x86-64 where I was able to test it
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021779.html

So if that's not enough to report there is known problem with such patch
I cannot do more and I'll rather go out for a walk in such nice weather.

Cheers,
 
> So what I'm asking is that people think about the changes they submit
> and try and help me, not use patch submission as a sounding board and
> not to hope I don't spot something.
> 
> To scale this project we need to develop trust relationships with people
> taking ownership of areas of the codebase. I consider Mark Hatle to
> "own" most things rpm for example. To scale we need to do more of this
> but trust is important. If some people don't want to do this and just
> contribute things when they can which interest them, that is fine but we
> are going to reach a point where we have to take longer to test and take
> such changes.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - May 3, 2012, 2:50 p.m.
On Thu, May 3, 2012 at 7:41 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>
>
> So that's why I felt a bit insulted too when it's my fault that I wasn't
> testing all this also on e.g. mips.
>
> And FWIW as soon as I've discovered there is problem with other archs
> I've replied to this patch (saying that other archs need similar patch)
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021774.html
> and submited site changes for x86/x86-64 where I was able to test it
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021779.html
>
> So if that's not enough to report there is known problem with such patch
> I cannot do more and I'll rather go out for a walk in such nice weather.

Yes thats a good. Thing.  I think this kind of work might need coordination
where you stage it and others can chime in with respective machine details
I will try to test your patch on arm,mips,ppc and add appropriate
bits. Its better to
discuss the downsides early on.

Patch

diff --git a/meta/site/arm-common b/meta/site/arm-common
index c3ffe08..cad8027 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -76,6 +76,9 @@  glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
 glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
 glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
 glib_cv_sys_use_pid_niceness_surrogate=${glib_cv_sys_use_pid_niceness_surrogate=yes}
+ac_cv_alignof_guint32=4
+ac_cv_alignof_guint64=8
+ac_cv_alignof_unsigned_long=4
 
 #gstreamer
 as_cv_unaligned_access=${as_cv_unaligned_access=no}