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-----
next prev parent 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