ipkg/opkg offical response

ipkg/opkg offical response

[Richard Purdie]

Hi,

The core team has been discussing various issues at length. On the
opkg/ipkg issue the official position is that:

a) the commit was badly thought out
b) we need to document procedures for making changes
c) there should be no more infrastructure changes until documentation on
   the process is written and agreed[1]
d) the commit won't be reverted due to the reasons below
e) we agree some method is needed to select between ipkg and opkg ASAP
   to fix the damage that was done. 

Why not outright disapprove the revision?:

* Its been in too long, we needed to have acted quicker, now we'd need 
  some setup to handle reverting it properly and safely.
* The changes to meta-toolchain and packaged-staging.bbclass 'ok'
* rwhitby added now added a partial solution to address some of the 
  issues (thanks!)

Where do we go from here?

I think Marcin has a nogpg version opkg he will commit so people don't
have any issues with the increased size of ipkg. Does that and rwhitby's
symlink fix address everyone's concerns? If not can we document the
remaining issues and then hopefully address them.

Do we need something to select between opkg and ipkg or is everyone ok
with the symlinks?

OE management is more than aware there is a problem. The underlying
issue is we can't even seem to agree on how we make decisions :(.
Various topics are under discussion but until we solve that one I doubt
we can move forwards on anything else...

[1] There is work still in progress on packaged staging and I'd like to
propose that we see the packaged staging changes through to completion.
Off the top of the head there are the following remaining changes:

* Adding do_deploy to packaged-staging's knowledge. This is best done
with the patch for kernel.bbclass that thesing was been working on. I've
made some suggestions for tweaks (looking at the version already in
poky) and suggested he commits it after that.
* Fixing the problem with autotools_stage_all and multiple libraries of
the same name. We know what the problem is, we're just not sure of the
best way to fix it. This isn't any disagreement, just us (mainly me) not
wanting to change anything too much more in case it breaks again...

Regards,

Richard (on behalf of the majority of the core team)

Re: ipkg/opkg offical response

[Koen Kooi]

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

Richard Purdie schreef:

| * Adding do_deploy to packaged-staging's knowledge. This is best done
| with the patch for kernel.bbclass that thesing was been working on. I've
| made some suggestions for tweaks (looking at the version already in
| poky) and suggested he commits it after that.

That patch broke uImage kernels *real bad*, I just pushed a fix for it.

Proper review on mailinglist first next time?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH6/SZMkyGM64RGpERAlQqAJ9TQZ14UlkUvuJGALQaw6cshS01gACgkWkd
HtY0P54Pk5HXV+qPkEGmxtw=
=4YKa
-----END PGP SIGNATURE-----

Re: ipkg/opkg offical response

[Jeremy Lainé]

Koen Kooi wrote:
> Richard Purdie schreef:
> 
> | * Adding do_deploy to packaged-staging's knowledge. This is best done
> | with the patch for kernel.bbclass that thesing was been working on. I've
> | made some suggestions for tweaks (looking at the version already in
> | poky) and suggested he commits it after that.
> 
> That patch broke uImage kernels *real bad*, I just pushed a fix for it.

I have pushed an additional fix for the changes to kernel.bbclass.
The DEPENDS added by kernel.bbclass (u-boot-mkimage-native) conflicted
with the one added by linux.inc (u-boot-mkimage-openmoko-native).

I changed the DEPENDS to u-boot-mkimage-openmoko-native in
kernel.bbclass and removed the DEPENDS from linux.inc. The assumption
here is that u-boot-mkimage-openmoko-native is a strict superset of
u-boot-mkimage-native.

Cheers,
Jeremy

Re: ipkg/opkg offical response

[Tom Rini]

On Thu, Mar 27, 2008 at 11:57:37PM +0100, Jeremy Lainé wrote:
> Koen Kooi wrote:
> > Richard Purdie schreef:
> > 
> > | * Adding do_deploy to packaged-staging's knowledge. This is best done
> > | with the patch for kernel.bbclass that thesing was been working on. I've
> > | made some suggestions for tweaks (looking at the version already in
> > | poky) and suggested he commits it after that.
> > 
> > That patch broke uImage kernels *real bad*, I just pushed a fix for it.
> 
> I have pushed an additional fix for the changes to kernel.bbclass.
> The DEPENDS added by kernel.bbclass (u-boot-mkimage-native) conflicted
> with the one added by linux.inc (u-boot-mkimage-openmoko-native).
> 
> I changed the DEPENDS to u-boot-mkimage-openmoko-native in
> kernel.bbclass and removed the DEPENDS from linux.inc. The assumption
> here is that u-boot-mkimage-openmoko-native is a strict superset of
> u-boot-mkimage-native.

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?

-- 
Tom Rini

Re: ipkg/opkg offical response

[Leon Woestenberg]

Hello,

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? :-)

Thanks,
-- 
Leon

Re: ipkg/opkg offical response

[Richard Purdie]

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. Using a simpler recipe kind
of makes sense but I'll let the openmoko people answer.

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?

Cheers,

Richard

Re: ipkg/opkg offical response

[Koen Kooi]

-----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-----

Re: ipkg/opkg offical response

[Marcin Juszkiewicz]

Dnia Friday 28 of March 2008, Tom Rini napisał:
> > I changed the DEPENDS to u-boot-mkimage-openmoko-native in
> > kernel.bbclass and removed the DEPENDS from linux.inc. The assumption
> > here is that u-boot-mkimage-openmoko-native is a strict superset of
> > u-boot-mkimage-native.
>
> 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?

It was other way. We had u-boot recipes (target ones) which staged 
mkimage. This was wrong as it mixed target and host in one run. Then 
Openmoko guys started to use u-boot and one day someone created recipe 
just for mkimage from their overpatched version.

u-boot-mkimage-native was created by me in Poky few days ago to get rid of 
overpatched Openmoko version. I used 1.3.2 (latest upstream) version as a 
base. Now I see that u-boot-tools-native (1.2.0) is in OE and do the 
same.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

          Monday is a hard way to spend one-seventh of your life.

Re: ipkg/opkg offical response

[Richard Purdie]

On Thu, 2008-03-27 at 20:25 +0100, Koen Kooi wrote:
> Richard Purdie schreef:
> 
> | * Adding do_deploy to packaged-staging's knowledge. This is best done
> | with the patch for kernel.bbclass that thesing was been working on. I've
> | made some suggestions for tweaks (looking at the version already in
> | poky) and suggested he commits it after that.
> 
> That patch broke uImage kernels *real bad*, I just pushed a fix for it.
> 
> Proper review on mailinglist first next time?

Well, it was posted for review on the mailing list and I was one of the
few people who actually responded ;-).

but yes, if it broke things thats bad, if we've fixed it great ;-).

Cheers,

Richard

kernel breackage, was Re: ipkg/opkg offical response

[Koen Kooi]

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

Richard Purdie schreef:
| On Thu, 2008-03-27 at 20:25 +0100, Koen Kooi wrote:
|> Richard Purdie schreef:
|>
|> | * Adding do_deploy to packaged-staging's knowledge. This is best done
|> | with the patch for kernel.bbclass that thesing was been working on.
I've
|> | made some suggestions for tweaks (looking at the version already in
|> | poky) and suggested he commits it after that.
|>
|> That patch broke uImage kernels *real bad*, I just pushed a fix for it.
|>
|> Proper review on mailinglist first next time?
|
| Well, it was posted for review on the mailing list and I was one of the
| few people who actually responded ;-).

You're being deliberatly obtuse.
http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-March/004613.html
looks nothing like the patch that was committed, it doesn't have bugs
Jeremy and I fixed.
Or are you saying it's okay that people commit something different than
what was reviewed?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH7JhVMkyGM64RGpERAjcBAJ44PFUYtx86MAFoPwCQfJLGbUjxTACePy/y
KdT7FnpKR9ElE/JNayfIqww=
=JaFL
-----END PGP SIGNATURE-----

Re: kernel breackage, was Re: ipkg/opkg offical response

[Richard Purdie]

On Fri, 2008-03-28 at 08:03 +0100, Koen Kooi wrote:
> You're being deliberatly obtuse.

Pot, kettle, black? ;-)

> http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-March/004613.html
> looks nothing like the patch that was committed, it doesn't have bugs
> Jeremy and I fixed.
> Or are you saying it's okay that people commit something different than
> what was reviewed?

I hadn't realised it was quite as different, sorry :/. The main thing is
its in, we've moved forwards and the bugs are hopefully fixed. If there
are any more issues, let me know and I'll try and take care of them.

I'll follow up about Jeremy's change in the appropriate thread.

Cheers,

Richard

Re: kernel breackage, was Re: ipkg/opkg offical response

[Koen Kooi]

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

Richard Purdie schreef:
| On Fri, 2008-03-28 at 08:03 +0100, Koen Kooi wrote:
|> You're being deliberatly obtuse.
|
| Pot, kettle, black? ;-)

SCNR :)

|
|>
http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-March/004613.html
|> looks nothing like the patch that was committed, it doesn't have bugs
|> Jeremy and I fixed.
|> Or are you saying it's okay that people commit something different than
|> what was reviewed?
|
| I hadn't realised it was quite as different, sorry :/. The main thing is
| its in, we've moved forwards and the bugs are hopefully fixed. If there
| are any more issues, let me know and I'll try and take care of them.
|
| I'll follow up about Jeremy's change in the appropriate thread.
|
| Cheers,
|
| Richard

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

iD8DBQFH7LvqMkyGM64RGpERAkZJAJ404NJDQt4UmbQ03R/FXV9+nPBtnwCgolte
gmgL0fiv6v8vOwARXaFiog8=
=u0oh
-----END PGP SIGNATURE-----

Re: ipkg/opkg offical response

[Marcin Juszkiewicz]

Dnia Thursday 27 of March 2008, Richard Purdie napisał:

> Where do we go from here?
>
> I think Marcin has a nogpg version opkg he will commit so people don't
> have any issues with the increased size of ipkg. 

Opkg can be made smaller by two changes:

1. disable GPG support in opkg (--disable-gpg)
2. disable GnuTLS support in curl

First step gains ~350KB of uncompressed storage. Second step gains ~1MB as 
libcurl is 20K smaller and we get rid of gnutls and gcrypt libraries. But 
even then it is bigger then ipkg.

So creation of "opkg-nogpg":

require opkg_svn.bb
EXTRA_OECONF += "--disable-gpg"

would be nice addon. Creation of "curl-nossl" and selecting it is 
something which should be rather DISTRO choice as it generate same 
packages as "curl" recipe.

> Does that and rwhitby's symlink fix address everyone's concerns? If not
> can we document the remaining issues and then hopefully address them.

> Do we need something to select between opkg and ipkg or is everyone ok
> with the symlinks?

Solution would be creating DISTRO_IPK_PACKAGE_MANAGER ?= "opkg" and using 
it in package_ipk/rootfs_ipk and other places. Then staging 
ipkg-cl/opkg-cl as ipkg/opkg so we can use "${DISTRO_IPK_PACKAGE_MANAGER} 
update". Distros which prefer to use ipkg will stay with it, others will 
move to opkg.

Opinions?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

    I used to think the brain is the most wonderfull organ in my body, 
    till I realised what was telling me that

Re: ipkg/opkg offical response

[Rod Whitby]

Marcin Juszkiewicz wrote:
> So creation of "opkg-nogpg":
> 
> require opkg_svn.bb
> EXTRA_OECONF += "--disable-gpg"
> 
> would be nice addon. Creation of "curl-nossl" and selecting it is 
> something which should be rather DISTRO choice as it generate same 
> packages as "curl" recipe.

+1

> Solution would be creating DISTRO_IPK_PACKAGE_MANAGER ?= "opkg" and using 
> it in package_ipk/rootfs_ipk and other places. Then staging 
> ipkg-cl/opkg-cl as ipkg/opkg so we can use "${DISTRO_IPK_PACKAGE_MANAGER} 
> update". Distros which prefer to use ipkg will stay with it, others will 
> move to opkg.

Can we simplify to DISTRO_PACKAGE_MANAGER?  Will we ever want ipks and 
debs to be produced at the same time?

-- Rod

Re: ipkg/opkg offical response

[Koen Kooi]

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

Rod Whitby schreef:

|
| Can we simplify to DISTRO_PACKAGE_MANAGER?  Will we ever want ipks and
| debs to be produced at the same time?

No, yes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH7Ja3MkyGM64RGpERAgOJAJ9yvm2/eqwhKtiti/Y/UvAL4FbT1QCfZ5f2
yYqY0EZanGzybtMLOswNxwY=
=EvSA
-----END PGP SIGNATURE-----

Re: ipkg/opkg offical response

[Richard Purdie]

On Fri, 2008-03-28 at 10:45 +1030, Rod Whitby wrote:
> Marcin Juszkiewicz wrote:
> > So creation of "opkg-nogpg":
> > 
> > require opkg_svn.bb
> > EXTRA_OECONF += "--disable-gpg"
> > 
> > would be nice addon. Creation of "curl-nossl" and selecting it is 
> > something which should be rather DISTRO choice as it generate same 
> > packages as "curl" recipe.
> 
> +1

Creation of that has my backing too.

> > Solution would be creating DISTRO_IPK_PACKAGE_MANAGER ?= "opkg" and using 
> > it in package_ipk/rootfs_ipk and other places. Then staging 
> > ipkg-cl/opkg-cl as ipkg/opkg so we can use "${DISTRO_IPK_PACKAGE_MANAGER} 
> > update". Distros which prefer to use ipkg will stay with it, others will 
> > move to opkg.
> 
> Can we simplify to DISTRO_PACKAGE_MANAGER?  Will we ever want ipks and 
> debs to be produced at the same time?

This is useful and I'd like to continue to be able to do that. Its
useful in automated test configurations since dpkg is a lot more strict
about its control field contents and I've seen it fail when ipkg-build
has been happy. Poky's autobuilder therefore builds both.

Cheers,

Richard

Re: ipkg/opkg offical response

[Mike (mwester)]

Richard Purdie wrote:
> On Fri, 2008-03-28 at 10:45 +1030, Rod Whitby wrote:
>> Marcin Juszkiewicz wrote:
>>> So creation of "opkg-nogpg":
>>>
>>> require opkg_svn.bb
>>> EXTRA_OECONF += "--disable-gpg"
>>>
>>> would be nice addon. Creation of "curl-nossl" and selecting it is 
>>> something which should be rather DISTRO choice as it generate same 
>>> packages as "curl" recipe.
>> +1
> 
> Creation of that has my backing too.

The first part of this has been done, and opkg builds.  I'm not sure the
no-gpg version works yet, but that's another issue.

The second part of the proposal above seems to not yet exist
(curl-nossl) -- unless I'm missing something.  There's no bb recipe, and
the existing curl bb file has no DISTRO-specific overrides to remove the
>1MB of stuff it hauls in to replace wget.  Hints anyone?  Is this
supposed to be a separate recipe, that perhaps never got committed?  Or
is there some other magic config stuff that needs to be created?

Mike (mwester)

Re: ipkg/opkg offical response

[Jeremy Lainé]

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


>
> So creation of "opkg-nogpg":
>
> require opkg_svn.bb EXTRA_OECONF += "--disable-gpg"
+1 for providing a gpg-less opkg

My main reason for not wanting gpg is not size (in my case gcrypt &
friends
get pulled into my image anyhow), it's that there is no indication of how
Packages.sig should be generated!

=> does package_ipk.bbclass need updating to generate Packages.sig?

- --
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH7RopCL1n3lVB9EYRAkHkAKCrqjdCAdHw6QAZ72L3XzyATJN2hQCgw6uP
lotiZINAIi0I4mQr15gUxEs=
=8anQ
-----END PGP SIGNATURE-----