Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Mike Westerhof]

Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 (Koen) breaks
opkg-nogpg-nocurl.  I have no idea what else might be broken, but the
fact that it removes all the critical patches that make it work on
small-memory machines is the most obvious cause of the breakage.

So what do you all want me to do about this?  We can revert the commit. 
Or someone can try to sort out a way to let opkg change without
impacting the tiny-memory version of opkg (which will get more and more
difficult as the two diverge).  Or I can just create
opkg-nogpg-nocurl-slugos.bb in hopes that it won't get stomped on.

Thanks,
Mike (mwester)

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Graham Gower]

2009/12/4 Mike Westerhof <mike@mwester.net>:
> Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 (Koen) breaks
> opkg-nogpg-nocurl.  I have no idea what else might be broken, but the
> fact that it removes all the critical patches that make it work on
> small-memory machines is the most obvious cause of the breakage.
>
> So what do you all want me to do about this?  We can revert the commit.
> Or someone can try to sort out a way to let opkg change without
> impacting the tiny-memory version of opkg (which will get more and more
> difficult as the two diverge).  Or I can just create
> opkg-nogpg-nocurl-slugos.bb in hopes that it won't get stomped on.
>
> Thanks,
> Mike (mwester)

Since slugos is at r160, perhaps adding those patches back in, with
maxrev= lines is best for now?

-Graham

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Andrea Adami]

FYI,

I had similar issues with opkg-cl (was linked with libldap of my
buildhost...[1]).

I thouht it was originated by bump to SRCREV to 413 but a rebuild from
scratch fixed all.

Please retry the hard way...


Regards

Andrea


[1] What I did was to unmerge openldap on my Gentoo buildhost. This
broke opkg-cl and friends..
Suspicious bits:
 /bin/grep: /usr/lib/libldap.la: No such file or directory
 /bin/sed: can't read /usr/lib/libldap.la: No such file or directory

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Mike Westerhof]

Andrea Adami wrote:
> FYI,
> 
> I had similar issues with opkg-cl (was linked with libldap of my
> buildhost...[1]).
> 
> I thouht it was originated by bump to SRCREV to 413 but a rebuild from
> scratch fixed all.
> 
> Please retry the hard way...

This is on a clean build :)

-Mike (mwester)

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Mike Westerhof]

Graham Gower wrote:
> 2009/12/4 Mike Westerhof <mike@mwester.net>:
>> Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 (Koen) breaks
>> opkg-nogpg-nocurl.  I have no idea what else might be broken, but the
>> fact that it removes all the critical patches that make it work on
>> small-memory machines is the most obvious cause of the breakage.
>>
>> So what do you all want me to do about this?  We can revert the commit.
>> Or someone can try to sort out a way to let opkg change without
>> impacting the tiny-memory version of opkg (which will get more and more
>> difficult as the two diverge).  Or I can just create
>> opkg-nogpg-nocurl-slugos.bb in hopes that it won't get stomped on.
>>
>> Thanks,
>> Mike (mwester)
> 
> Since slugos is at r160, perhaps adding those patches back in, with
> maxrev= lines is best for now?

That would fall into the category of (b) - trying to sort out how to let
the opkg-nogpg-nocurl recipe change while keeping it building for
systems with very very small memory.

As a reminder, the need is that opkg must run in 32MB of physical RAM -
it cannot be assumed that swap space is available - and an absolute
minimum of dependencies on external libraries is required because the
total rootfs image must fit in about 5 MB or so.

I don't have much flexibility with opkg.

So back to the issue.  Someone with enough smarts on how that recipe was
just changed (and opkg_svn.bb, opkg.inc are included because they too
changed) can put back the patches and anything else that would ensure
that no extraneous dependencies have been added.  I realize that someone
will point the finger at me, but honestly I have no time to do that.

Hence I suggested the other two options.  Revert the change, so that
SlugOS builds again, and then whomever decided that a wholesale cleanup
of opkg recipes was necessary can go back in and try again.

Or if OE in general decides they want the nice new tidy opkg for some
unknown benefits it provides, well, I suggested that I simply create yet
another recipe for opkg, one that will duplicate the working opkg for
SlugOS, at least until I find time to invest to try to figure out why
versions >160 have never worked.  (Please understand that testing opkg
is a laborious process, requiring many different test scenarios that
involve lots of reflashing of images... it's time I just do not have
right now to invest, particularly since there is no net benefit as far
as I can see to this recent change to all the opkg stuff.)

So I'm leaning toward the latter solution right now - I don't want to
anger those who found the opkg recipe rewrites beneficial.  So I'll
rephrase it now:  If you have valid objections to my creating a custom
SlugOS opkg recipe, voice those concerns now. :)

Thanks,
Mike (mwester)

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Dr. Michael Lauer]

Am 04.12.2009 um 15:20 schrieb Mike Westerhof:
> So I'm leaning toward the latter solution right now - I don't want to
> anger those who found the opkg recipe rewrites beneficial.  So I'll
> rephrase it now:  If you have valid objections to my creating a custom
> SlugOS opkg recipe, voice those concerns now. :)

My concern is probably not valid, since I'm not volunteering to do the hard work on it,
but obviously I do not fancy multiple versions of one software where each variant
sucks in another way...

:M:

Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Marcin Juszkiewicz]

Dnia piątek, 4 grudnia 2009 o 15:20:48 Mike Westerhof napisał(a):

> As a reminder, the need is that opkg must run in 32MB of physical RAM -
> it cannot be assumed that swap space is available - and an absolute
> minimum of dependencies on external libraries is required because the
> total rootfs image must fit in about 5 MB or so.

> Please understand that testing opkg is a laborious process, requiring many
> different test scenarios that involve lots of reflashing of images...

Build your image for qemuarm as 5MB ext2 image. Copy it to have clean image 
for testing. Boot qemu with "mem=32M" given for kernel. Do test. Then copy 
clean.ext2 as base for next test.

This way you do not have to reflash your device each time, have control over 
space available and can have small RAM.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz