[RFC] update opkg* SRCREV to 201

[RFC] update opkg* SRCREV to 201

[Koen Kooi]

Hi,

I was getting seriously annoyed with the useless error codes opkg was 
giving me and Tick pointed me to:

http://code.google.com/p/opkg/issues/detail?id=6&can=1

We're at 197 now in OE (with r201 applied as patch). I'd like to get 
r199 and r200 in as well, and since I'm lazy I though we'd get r198 in 
as well, which means instead of adding a few patches I can just bump up 
SRCREV to 201.

What do you think?

regards,

Koen

Re: [RFC] update opkg* SRCREV to 201

[Koen Kooi]

On 25-02-09 21:46, Koen Kooi wrote:
> Hi,
>
> I was getting seriously annoyed with the useless error codes opkg was
> giving me and Tick pointed me to:
>
> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>
> We're at 197 now in OE (with r201 applied as patch). I'd like to get
> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
> as well, which means instead of adding a few patches I can just bump up
> SRCREV to 201.
>
> What do you think?

Noone is thinking anything?

regards,

Koen

Re: [RFC] update opkg* SRCREV to 201

[Tom Rini]

On Thu, Feb 26, 2009 at 03:55:32PM +0100, Koen Kooi wrote:
> On 25-02-09 21:46, Koen Kooi wrote:
>> Hi,
>>
>> I was getting seriously annoyed with the useless error codes opkg was
>> giving me and Tick pointed me to:
>>
>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>
>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>> as well, which means instead of adding a few patches I can just bump up
>> SRCREV to 201.
>>
>> What do you think?
>
> Noone is thinking anything?

<sarcasm> not since I switched to debs </sarcasm>

-- 
Tom Rini

Re: [RFC] update opkg* SRCREV to 201

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Koen Kooi wrote:
> On 25-02-09 21:46, Koen Kooi wrote:
>> Hi,
>>
>> I was getting seriously annoyed with the useless error codes opkg was
>> giving me and Tick pointed me to:
>>
>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>
>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>> as well, which means instead of adding a few patches I can just bump up
>> SRCREV to 201.
>>
>> What do you think?
> 
> Noone is thinking anything?

Well, it looks ok to me, but I am not a follower of opkg.

Hearing no positive comments, does anyone object to pushing this, 
knowing that if Koen is wrong about this working, it messes up our builds?

Philip


[*] Yes, that is an awful sentence.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] update opkg* SRCREV to 201

[Graeme Gregory]

Koen Kooi wrote:
> On 25-02-09 21:46, Koen Kooi wrote:
>> Hi,
>>
>> I was getting seriously annoyed with the useless error codes opkg was
>> giving me and Tick pointed me to:
>>
>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>
>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>> as well, which means instead of adding a few patches I can just bump up
>> SRCREV to 201.
>>
>> What do you think?
>
> Noone is thinking anything?
>
Sorry been AFK, my opinion of these things is always no-one will test
until stuff is committed anyway. So you might as well go ahead! Without
the bug reports tick won't be able to improve opkg.

Graeme (XorA)

Re: [RFC] update opkg* SRCREV to 201

[Tick]

Hi,
   Koen and Graeme Thanks.
   To my understanding, the fix from R197 to R201 are some easy defect fixing.
Fixing some typos, memory leak, and giving initial value some variable.
There were no big change in these versions.
Therefore I didn't bump up versions here.
   There are still some issues in my mind and I am still finding large
chunk of time to deal with them.
   1. the algorithm calculate the dependency is not very efficient.
(Much faster than R180 now, but I know it can be faster) Because of
there were some duplicated code and ill structured code from ipkg, I
need to refactorying them first before changing the algorithm.
   2. memory leak problem, ipkg were designed for running once and
exit, and therefore there were many place are not took carefully.
Thomas and I already fixed a lot, but not all of them. Most of the
largest memory leaks were fixed, however there were still some small
leaks need to be find out. Especially libopkg is used as library, this
should be take care well. (If anyone find a leak, please report or
help. thanks)
   3. memory hungry issue, opkg will eat a large amount of memory if
you have many packages metadata. This may cause problem, however there
is dilemma. Storing metadata will make opkg faster, but may cause very
limited device run out of memory. Saving memory will cause cpu busying
malloc and free all the time, and it will be very slow. Though the
algorithm now seems to be okay, for device having so many packages
should be powerful enough. XD I am considering adding a flag decide
which policy (fast or save memory) to use while building opkg.
   4. buffer over issue, some of the code did not check the boundary
well. Actually R197 is fixing an buffer overflow issue, in which not
be found for a long long time until it cause problem (on x86_64 arch
only). >_<
Many code needs to be reviewed/tested again and again to make sure the
quality is good enough, and it's need your reports, help and patches.
  If I break anything, I am sorry.  And please mail to
opkg-devel@googlegroups.com poking me, creating a ticket with
backtrace and some analysis to
http://code.google.com/p/opkg/issues/list  is good, sending a patch is
even welcome.  When I realize if it cause serious problem to you, I
will try to fix it asap.  I will be glad if every opkg user does not
aware it's existence, except the developers.
Thank a lot.

Cheers,
Tick


2009/2/27 Graeme Gregory <dp@xora.org.uk>:
> Koen Kooi wrote:
>> On 25-02-09 21:46, Koen Kooi wrote:
>>> Hi,
>>>
>>> I was getting seriously annoyed with the useless error codes opkg was
>>> giving me and Tick pointed me to:
>>>
>>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>>
>>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>>> as well, which means instead of adding a few patches I can just bump up
>>> SRCREV to 201.
>>>
>>> What do you think?
>>
>> Noone is thinking anything?
>>
> Sorry been AFK, my opinion of these things is always no-one will test
> until stuff is committed anyway. So you might as well go ahead! Without
> the bug reports tick won't be able to improve opkg.
>
> Graeme (XorA)
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] update opkg* SRCREV to 201

[Mike (mwester)]

Philip Balister wrote:
> Koen Kooi wrote:
>> On 25-02-09 21:46, Koen Kooi wrote:
>>> Hi,
>>>
>>> I was getting seriously annoyed with the useless error codes opkg was
>>> giving me and Tick pointed me to:
>>>
>>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>>
>>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>>> as well, which means instead of adding a few patches I can just bump up
>>> SRCREV to 201.
>>>
>>> What do you think?
>>
>> Noone is thinking anything?
> 
> Well, it looks ok to me, but I am not a follower of opkg.
> 
> Hearing no positive comments, does anyone object to pushing this,
> knowing that if Koen is wrong about this working, it messes up our builds?

[I have failed -- I had intended to remain silent on the topic of opkg ;-) ]

I use PREFERRED_VERSION, for a reason -- opkg has numerous issues, few
of which seem to be well-understood much less being worked on, and it
seems that small-memory devices trigger these issues more so than the
larger more common systems.

I will be back-porting these patches for the opkg-nogpg-nocurl recipe,
regardless.

If folks would rather not have the ever-growing set of opkg-nogpg-nocurl
patches clutter up the opkg recipe directory, feel free to instruct me
to move that all to a different directory.

-Mike (mwester)

Re: [RFC] update opkg* SRCREV to 201

[Michael 'Mickey' Lauer]

Tick being available and standing by helping us to bring opkg in shape
is all I need to know. Let's co-work with him and bump it.

-- 
:M:

Re: [RFC] update opkg* SRCREV to 201

[Mike (mwester)]

I'm glad to hear that there's work on some of these issues, as outlined
below!
-Mike

Tick wrote:
> Hi,
>    Koen and Graeme Thanks.
>    To my understanding, the fix from R197 to R201 are some easy defect fixing.
> Fixing some typos, memory leak, and giving initial value some variable.
> There were no big change in these versions.
> Therefore I didn't bump up versions here.
>    There are still some issues in my mind and I am still finding large
> chunk of time to deal with them.
>    1. the algorithm calculate the dependency is not very efficient.
> (Much faster than R180 now, but I know it can be faster) Because of
> there were some duplicated code and ill structured code from ipkg, I
> need to refactorying them first before changing the algorithm.
>    2. memory leak problem, ipkg were designed for running once and
> exit, and therefore there were many place are not took carefully.
> Thomas and I already fixed a lot, but not all of them. Most of the
> largest memory leaks were fixed, however there were still some small
> leaks need to be find out. Especially libopkg is used as library, this
> should be take care well. (If anyone find a leak, please report or
> help. thanks)
>    3. memory hungry issue, opkg will eat a large amount of memory if
> you have many packages metadata. This may cause problem, however there
> is dilemma. Storing metadata will make opkg faster, but may cause very
> limited device run out of memory. Saving memory will cause cpu busying
> malloc and free all the time, and it will be very slow. Though the
> algorithm now seems to be okay, for device having so many packages
> should be powerful enough. XD I am considering adding a flag decide
> which policy (fast or save memory) to use while building opkg.
>    4. buffer over issue, some of the code did not check the boundary
> well. Actually R197 is fixing an buffer overflow issue, in which not
> be found for a long long time until it cause problem (on x86_64 arch
> only). >_<
> Many code needs to be reviewed/tested again and again to make sure the
> quality is good enough, and it's need your reports, help and patches.
>   If I break anything, I am sorry.  And please mail to
> opkg-devel@googlegroups.com poking me, creating a ticket with
> backtrace and some analysis to
> http://code.google.com/p/opkg/issues/list  is good, sending a patch is
> even welcome.  When I realize if it cause serious problem to you, I
> will try to fix it asap.  I will be glad if every opkg user does not
> aware it's existence, except the developers.
> Thank a lot.
> 
> Cheers,
> Tick
> 
> 
> 2009/2/27 Graeme Gregory <dp@xora.org.uk>:
>> Koen Kooi wrote:
>>> On 25-02-09 21:46, Koen Kooi wrote:
>>>> Hi,
>>>>
>>>> I was getting seriously annoyed with the useless error codes opkg was
>>>> giving me and Tick pointed me to:
>>>>
>>>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>>>
>>>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>>>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>>>> as well, which means instead of adding a few patches I can just bump up
>>>> SRCREV to 201.
>>>>
>>>> What do you think?
>>> Noone is thinking anything?
>>>
>> Sorry been AFK, my opinion of these things is always no-one will test
>> until stuff is committed anyway. So you might as well go ahead! Without
>> the bug reports tick won't be able to improve opkg.
>>
>> Graeme (XorA)
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: [RFC] update opkg* SRCREV to 201

[Koen Kooi]

On 26-02-09 16:40, Tom Rini wrote:
> On Thu, Feb 26, 2009 at 03:55:32PM +0100, Koen Kooi wrote:
>> On 25-02-09 21:46, Koen Kooi wrote:
>>> Hi,
>>>
>>> I was getting seriously annoyed with the useless error codes opkg was
>>> giving me and Tick pointed me to:
>>>
>>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>>
>>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>>> as well, which means instead of adding a few patches I can just bump up
>>> SRCREV to 201.
>>>
>>> What do you think?
>> Noone is thinking anything?
>
> <sarcasm>  not since I switched to debs</sarcasm>

You still going to get bitten by opkg bugs when using packaged-staging

Re: [RFC] update opkg* SRCREV to 201

[Koen Kooi]

On 25-02-09 21:46, Koen Kooi wrote:
> Hi,
>
> I was getting seriously annoyed with the useless error codes opkg was
> giving me and Tick pointed me to:
>
> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>
> We're at 197 now in OE (with r201 applied as patch). I'd like to get
> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
> as well, which means instead of adding a few patches I can just bump up
> SRCREV to 201.

Since no-one objected I'll apply it this weekend when I get some time.

regards,

Koen

Re: [RFC] update opkg* SRCREV to 201

[Tom Rini]

On Fri, Feb 27, 2009 at 08:20:51AM +0100, Koen Kooi wrote:
> On 26-02-09 16:40, Tom Rini wrote:
>> On Thu, Feb 26, 2009 at 03:55:32PM +0100, Koen Kooi wrote:
>>> On 25-02-09 21:46, Koen Kooi wrote:
>>>> Hi,
>>>>
>>>> I was getting seriously annoyed with the useless error codes opkg was
>>>> giving me and Tick pointed me to:
>>>>
>>>> http://code.google.com/p/opkg/issues/detail?id=6&can=1
>>>>
>>>> We're at 197 now in OE (with r201 applied as patch). I'd like to get
>>>> r199 and r200 in as well, and since I'm lazy I though we'd get r198 in
>>>> as well, which means instead of adding a few patches I can just bump up
>>>> SRCREV to 201.
>>>>
>>>> What do you think?
>>> Noone is thinking anything?
>>
>> <sarcasm>  not since I switched to debs</sarcasm>
>
> You still going to get bitten by opkg bugs when using packaged-staging

Something I wanna find the time to fix.

-- 
Tom Rini