From: Koen Kooi <koen@dominion.kabel.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: ipkg/opkg offical response
Date: Fri, 28 Mar 2008 10:43:08 +0100 [thread overview]
Message-ID: <fsiejd$340$1@ger.gmane.org> (raw)
In-Reply-To: <1206696033.5029.9.camel@dax.rpnet.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Richard Purdie schreef:
| On Fri, 2008-03-28 at 01:30 +0100, Leon Woestenberg wrote:
|> On Fri, Mar 28, 2008 at 12:09 AM, Tom Rini
<trini@kernel.crashing.org> wrote:
|>> I'll ask the silly qustion. Given that mkimage hasn't changed in I
|>> don't know how long, why are both providing it? Just to save on
sources
|>> downloaded? Did OM really change mkimage?
|>>
|> Good question, thanks for asking!
|>
|> In fact, I have seen some of the kernel recipes seen switching between
|> openmoko's and non-openmoko u-boot-tools, with and without breakage in
|> the past.
|>
|> Could the openmoko guys please describe what grants their version to
exist? :-)
|
| As far as I know, the mkimage tool hasn't changed in a long time so we
| should be able to share one common version.
The only difference is the number of archs it supports, IIRC bfin and
avr32 may require $vendor mkimage since upstream doesn't support those
yet (again, IIRC).
| Using a simpler recipe kind
| of makes sense but I'll let the openmoko people answer.
The openmoko people have very little to do with openmoko-mkimage, they
try to remove it every now and then and I yell at them for that :) I
created that since _all_ existing uboot recipes were either machine
specific or plain broken. So I created a frozen openmoko-mkimage (all
patches are in OE, SRC_URI fixed to certain rev, etc) that is known to
work and doesn't break.
So if the (new) mkimage-native recipe is generic and non-broken, we
should switch to that.
| One way forward might be to DEPEND on virtual/mkimage-native. The
| various uboot providers can then PROVIDE this and it becomes distro
| policy which one is selected?
If someone spends some time to teach mkimage about avr32 (might already
be upstream) there shouldn't be a need for virtual/mkimage-native IMO.
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFH7L2sMkyGM64RGpERAptVAJ9UPo2nH5k61Wgq7SZcz0cENJ3lFQCeNZLa
EqAOJ0uyuvpWqadGjYRTCaI=
=AkT1
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-03-28 9:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-27 17:17 ipkg/opkg offical response Richard Purdie
2008-03-27 19:25 ` Koen Kooi
2008-03-27 22:57 ` Jeremy Lainé
2008-03-27 23:09 ` Tom Rini
2008-03-28 0:30 ` Leon Woestenberg
2008-03-28 9:20 ` Richard Purdie
2008-03-28 9:43 ` Koen Kooi [this message]
2008-03-28 4:23 ` Marcin Juszkiewicz
2008-03-27 23:07 ` Richard Purdie
2008-03-28 7:03 ` kernel breackage, was " Koen Kooi
2008-03-28 9:17 ` Richard Purdie
2008-03-28 9:35 ` Koen Kooi
2008-03-27 20:04 ` Marcin Juszkiewicz
2008-03-28 0:15 ` Rod Whitby
2008-03-28 6:56 ` Koen Kooi
2008-03-28 9:27 ` Richard Purdie
2008-08-21 6:48 ` Mike (mwester)
2008-03-28 16:17 ` Jeremy Lainé
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='fsiejd$340$1@ger.gmane.org' \
--to=koen@dominion.kabel.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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.