Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: gtk+-native-2.20.0-r8.0 fails in do_configure.
Date: Thu, 08 Apr 2010 11:54:37 +0200	[thread overview]
Message-ID: <hpk94t$lgd$2@dough.gmane.org> (raw)
In-Reply-To: <20100408112243.f558a240.ospite@studenti.unina.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08-04-10 11:22, Antonio Ospite wrote:
> On Tue, 6 Apr 2010 11:58:37 +0200
> Antonio Ospite <ospite@studenti.unina.it> wrote:
> 
>> On Sat, 3 Apr 2010 20:17:09 +0200
>> Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
>>
>>> Dnia sobota, 3 kwietnia 2010 o 17:17:24 Antonio Ospite napisał(a):
>>>> when building gtk+-native-2.20.0-r8.0 (actually bitbaking
>>>> fso-console-image DISTRO=minimal MACHINE=a780) I get this message:
>>>>
>>>>  Requested 'glib-2.0 >= 2.23.6' but version of GLib is 2.22.1
>>>>
>>>> See also http://tinderbox.openembedded.org/packages/540390/
>>>>
>>>> I can workaround that locally but I would like to learn what the best
>>>> way to solve such issues would be. I don't see any
>>>> preferred-minimal-versions.inc
>>>
>>> Recent glib-2.0 recipes has BBCLASSEXTEND = "native" set but we also have 
>>> glib-2.0-native recipes... I think that native ones should be dropped.
>>>
>>
>> So what is happening to me now it that glib-2.0-native_2.22.1.bb gets
>> selected and the more recent ones with BBCLASSEXTEND = "native" are
>> discarded, right?
>>
> 
> Ok, I confirm this was actually the case, the old way to do native
> recipes seems to have precedence on the new one, this is with bitbake
> 1.8.18, don't know if that is dependent on bitbake version tho.
> 
> Removing all glib-2.0-native packages makes gtk+-native-2.20.0-r8.0
> build ok.
> 
>> If the -native recipes are going to be dropped should the
>> BBCLASSEXTEND mechanism moved to some glib*.inc file?
>>
> 
> Should I just send a patch which blindly removes native
> recipes for older versions, or try to port the BBCLASSEXTEND mechanism
> to them? I don't know if I am fully comfortable with such changes in OE,
> but I can always send a tentative patch.

Porting them has a slight preference over deleting them. The -native
recipes shouldn't be needed for things like maemo-compat, hence the
'slight' :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLvafcMkyGM64RGpERAroAAKCW7+h5AKr8VHhjoowsODwbKdX/+wCglfaW
vf+ofTWZVrCCpZzw6mNyL/8=
=BaGg
-----END PGP SIGNATURE-----




  reply	other threads:[~2010-04-08  9:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-03 15:17 gtk+-native-2.20.0-r8.0 fails in do_configure Antonio Ospite
2010-04-03 18:17 ` Marcin Juszkiewicz
2010-04-06  9:58   ` Antonio Ospite
2010-04-08  9:22     ` Antonio Ospite
2010-04-08  9:54       ` Koen Kooi [this message]
2010-04-08 14:21         ` Antonio Ospite
2010-04-08 21:20           ` [PATCH] glib-2.0: remove old glib-2.0-native recipes Antonio Ospite
2010-04-08 21:33             ` Mike Westerhof
2010-04-08 22:50               ` Tom Rini
2010-04-09  7:51             ` Koen Kooi
2010-04-09 10:32               ` Michael 'Mickey' Lauer
2010-04-09 19:21               ` Antonio Ospite
2010-04-08 14:11   ` gtk+-native-2.20.0-r8.0 fails in do_configure Antonio Ospite
2010-04-08 14:15     ` Koen Kooi
2010-04-08 14:25       ` Antonio Ospite
2010-04-08 15:55         ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='hpk94t$lgd$2@dough.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox