All of lore.kernel.org
 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 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.