libiconv checksum wrong

libiconv checksum wrong

[Phil Blundell]

Since updating this morning I'm getting

| ERROR: Function 'File: '/home/pb/sources/libiconv-1.13.1.tar.gz' has
md5 checksum 7ab33ebd26687c744a37264a330bbe9a when
d42b97f6ef5dd0ba4469d520ed732fed was expected (from URL:
'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz')' failed
NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed

The offending commit appears to be
bd1e627bef29830f9346b4b984905fd8fcf2e716.  As far as I can tell from a
quick inspection of the files, the checksum that was added for
libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
earlier version 1.11.1.

p.

Re: libiconv checksum wrong

[Frans Meulenbroeks]

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

2011/7/20 Phil Blundell <philb@gnu.org>

> Since updating this morning I'm getting
>
> | ERROR: Function 'File: '/home/pb/sources/libiconv-1.13.1.tar.gz' has
> md5 checksum 7ab33ebd26687c744a37264a330bbe9a when
> d42b97f6ef5dd0ba4469d520ed732fed was expected (from URL:
> 'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz')' failed
> NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed
>
> The offending commit appears to be
> bd1e627bef29830f9346b4b984905fd8fcf2e716.  As far as I can tell from a
> quick inspection of the files, the checksum that was added for
> libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
> earlier version 1.11.1.
>
> This seems to indicate that the added 1.13.1 recipe has not been build by
neither the submitter nor the committer (let alone tested by someone).
is that the kind of quality we want to achieve in oe-core ?

Frans.

[-- Attachment #2: Type: text/html, Size: 1318 bytes --]

Re: libiconv checksum wrong

[Khem Raj]

On 07/20/2011 04:55 AM, Frans Meulenbroeks wrote:
> 2011/7/20 Phil Blundell<philb@gnu.org>
>
>> Since updating this morning I'm getting
>>
>> | ERROR: Function 'File: '/home/pb/sources/libiconv-1.13.1.tar.gz' has
>> md5 checksum 7ab33ebd26687c744a37264a330bbe9a when
>> d42b97f6ef5dd0ba4469d520ed732fed was expected (from URL:
>> 'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz')' failed
>> NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed
>>
>> The offending commit appears to be
>> bd1e627bef29830f9346b4b984905fd8fcf2e716.  As far as I can tell from a
>> quick inspection of the files, the checksum that was added for
>> libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
>> earlier version 1.11.1.
>>
>> This seems to indicate that the added 1.13.1 recipe has not been build by
> neither the submitter nor the committer (let alone tested by someone).
> is that the kind of quality we want to achieve in oe-core ?
>

there is already patch sent to fix it.
http://patches.openembedded.org/patch/7933/
libiconv is not default provider of virtual/libiconv on eglibc/glibc 
based systems and sometimes that can trip you over. It happens and as 
long as we find it and fix it quickly I don't see a problem. Do you ?

IMO we should not get so pedantic that people start getting scared of 
making changes

> Frans.
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: libiconv checksum wrong

[Frans Meulenbroeks]

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

2011/7/20 Khem Raj <raj.khem@gmail.com>

> On 07/20/2011 04:55 AM, Frans Meulenbroeks wrote:
>
>> 2011/7/20 Phil Blundell<philb@gnu.org>
>>
>>  Since updating this morning I'm getting
>>>
>>> | ERROR: Function 'File: '/home/pb/sources/libiconv-1.**13.1.tar.gz' has
>>> md5 checksum 7ab33ebd26687c744a37264a330bbe**9a when
>>> d42b97f6ef5dd0ba4469d520ed732f**ed was expected (from URL:
>>> 'ftp://ftp.gnu.org/gnu/**libiconv/libiconv-1.13.1.tar.**gz'<ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz%27>)'
>>> failed
>>> NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed
>>>
>>> The offending commit appears to be
>>> bd1e627bef29830f9346b4b984905f**d8fcf2e716.  As far as I can tell from a
>>> quick inspection of the files, the checksum that was added for
>>> libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
>>> earlier version 1.11.1.
>>>
>>> This seems to indicate that the added 1.13.1 recipe has not been build by
>>>
>> neither the submitter nor the committer (let alone tested by someone).
>> is that the kind of quality we want to achieve in oe-core ?
>>
>>
> there is already patch sent to fix it.
> http://patches.openembedded.**org/patch/7933/<http://patches.openembedded.org/patch/7933/>
> libiconv is not default provider of virtual/libiconv on eglibc/glibc based
> systems and sometimes that can trip you over. It happens and as long as we
> find it and fix it quickly I don't see a problem. Do you ?

Some people seem to think differently about this. I still recall the pile of
shit Koen dumped upon me about a year ago when I accidentally removed a
version of openssh or so that was still used. Even though the problem was
fixed very quickly after it was brought to my attention. Ah well. As Orwell
already said "all animals are equal but some animals are more equal than
others".

>
> IMO we should not get so pedantic that people start getting scared of
> making changes
>

It was by no means my intention to be pedantic.

Then again I *do* think it is good practice if someone creates a new recipe
that (s)he tests it before submitting it.

And my impression was that one of the goals of YP and oe-core was to
increase the quality level.
One of the ways to increase quality is to do a build after pulling changes
and before committing them.
(at least I feel that is one of the ways to increase quality, and yes there
are other ways too).

And where people work, mistakes happen. One can accept that, but one can
also see if there are ways to improve and avoid that a problem re-occurs.

My two cents. Do with it whatever you want. And remember: have fun!

Frans.

[-- Attachment #2: Type: text/html, Size: 3591 bytes --]

Re: libiconv checksum wrong

[Richard Purdie]

On Wed, 2011-07-20 at 16:26 +0200, Frans Meulenbroeks wrote
>         there is already patch sent to fix it.
>         http://patches.openembedded.org/patch/7933/
>         libiconv is not default provider of virtual/libiconv on
>         eglibc/glibc based systems and sometimes that can trip you
>         over. It happens and as long as we find it and fix it quickly
>         I don't see a problem. Do you ? 
> Some people seem to think differently about this. I still recall the
> pile of shit Koen dumped upon me about a year ago when I accidentally
> removed a version of openssh or so that was still used. Even though
> the problem was fixed very quickly after it was brought to my
> attention. Ah well. As Orwell already said "all animals are equal but
> some animals are more equal than others".
> 
>         
>         IMO we should not get so pedantic that people start getting
>         scared of making changes
> 
> It was by no means my intention to be pedantic.
> 
> Then again I *do* think it is good practice if someone creates a new
> recipe that (s)he tests it before submitting it.
> 
> And my impression was that one of the goals of YP and oe-core was to
> increase the quality level.
> One of the ways to increase quality is to do a build after pulling
> changes and before committing them.
> (at least I feel that is one of the ways to increase quality, and yes
> there are other ways too).
> 
> And where people work, mistakes happen. One can accept that, but one
> can also see if there are ways to improve and avoid that a problem
> re-occurs.

I think its fair to ask how this happened and it appears to be due to
PREFERRED_VERSION and/or PROVIDER confusion. Its unfortunate but I think
the people involved will not do it again :).

I don't think its entirely fair to immediately bring into question the
overall quality goals as we are continuing to work towards those and
this is an exception, not the norm.

Cheers,

Richard

Re: libiconv checksum wrong

[Saul Wold]

On 07/20/2011 07:42 AM, Richard Purdie wrote:
> On Wed, 2011-07-20 at 16:26 +0200, Frans Meulenbroeks wrote
>>          there is already patch sent to fix it.
>>          http://patches.openembedded.org/patch/7933/
>>          libiconv is not default provider of virtual/libiconv on
>>          eglibc/glibc based systems and sometimes that can trip you
>>          over. It happens and as long as we find it and fix it quickly
>>          I don't see a problem. Do you ?
>> Some people seem to think differently about this. I still recall the
>> pile of shit Koen dumped upon me about a year ago when I accidentally
>> removed a version of openssh or so that was still used. Even though
>> the problem was fixed very quickly after it was brought to my
>> attention. Ah well. As Orwell already said "all animals are equal but
>> some animals are more equal than others".
>>
>>
>>          IMO we should not get so pedantic that people start getting
>>          scared of making changes
>>
>> It was by no means my intention to be pedantic.
>>
>> Then again I *do* think it is good practice if someone creates a new
>> recipe that (s)he tests it before submitting it.
>>
>> And my impression was that one of the goals of YP and oe-core was to
>> increase the quality level.
>> One of the ways to increase quality is to do a build after pulling
>> changes and before committing them.
>> (at least I feel that is one of the ways to increase quality, and yes
>> there are other ways too).
>>
>> And where people work, mistakes happen. One can accept that, but one
>> can also see if there are ways to improve and avoid that a problem
>> re-occurs.
>
> I think its fair to ask how this happened and it appears to be due to
> PREFERRED_VERSION and/or PROVIDER confusion. Its unfortunate but I think
> the people involved will not do it again :).
>
Yes, the lesson has been learned, I am working on adding a UCLIBC build 
into the mix, and the Autobuilder will have a vanilla oe-core build with 
both uclibc and egligc some time soon as well.

Please chalk this up to live and learn not a common practice.

Sau!

> I don't think its entirely fair to immediately bring into question the
> overall quality goals as we are continuing to work towards those and
> this is an exception, not the norm.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: libiconv checksum wrong

[Frans Meulenbroeks]

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

2011/7/20 Richard Purdie <richard.purdie@linuxfoundation.org>

> On Wed, 2011-07-20 at 16:26 +0200, Frans Meulenbroeks wrote
> >         there is already patch sent to fix it.
> >         http://patches.openembedded.org/patch/7933/
> >         libiconv is not default provider of virtual/libiconv on
> >         eglibc/glibc based systems and sometimes that can trip you
> >         over. It happens and as long as we find it and fix it quickly
> >         I don't see a problem. Do you ?
> > Some people seem to think differently about this. I still recall the
> > pile of shit Koen dumped upon me about a year ago when I accidentally
> > removed a version of openssh or so that was still used. Even though
> > the problem was fixed very quickly after it was brought to my
> > attention. Ah well. As Orwell already said "all animals are equal but
> > some animals are more equal than others".
> >
> >
> >         IMO we should not get so pedantic that people start getting
> >         scared of making changes
> >
> > It was by no means my intention to be pedantic.
> >
> > Then again I *do* think it is good practice if someone creates a new
> > recipe that (s)he tests it before submitting it.
> >
> > And my impression was that one of the goals of YP and oe-core was to
> > increase the quality level.
> > One of the ways to increase quality is to do a build after pulling
> > changes and before committing them.
> > (at least I feel that is one of the ways to increase quality, and yes
> > there are other ways too).
> >
> > And where people work, mistakes happen. One can accept that, but one
> > can also see if there are ways to improve and avoid that a problem
> > re-occurs.
>
> I think its fair to ask how this happened and it appears to be due to
> PREFERRED_VERSION and/or PROVIDER confusion. Its unfortunate but I think
> the people involved will not do it again :).
>
> I don't think its entirely fair to immediately bring into question the
> overall quality goals as we are continuing to work towards those and
> this is an exception, not the norm.
>
> Cheers,
>
> Richard, Saul, all,

I understand that these things can happen. It is a pretty basic mistake, but
I made my share of those as well. Unfortunately some community members were
not too forgiving in those situations :-(
I feel as long as those mistakes lead to improvement of the process and we
learn from it, I have no problem with it (and I'm sure this has happened in
this case).
What slightly irridated me was the email of Khem which stated "as long as we
find it and fix it quickly I don't see a problem". I'm not sure if that is
the most desirable way of working, and definitely not a statement I had
expected from a TSC member.

Wrt commits: in the past I have been picking up oe postings from other
people without commit access and commit these for them. When I did that I
always made sure to review and to build the changed or new recipe.
I think that is good practice. Now I know that a lot of patches are being
thrown to Richard, so this might not be too workable to do it that way. It
could help though to do some automated tests after taking patches and before
pushing to the oe-core repo. (ideally it would be an (incremental?) build of
world (if there is a bitbake world in YP, actually never attempted that, but
I can also imagine a fetchall or so).

And yeah, on reading back maybe I should have formulated things a little bit
more diplomatic.

Frans.

[-- Attachment #2: Type: text/html, Size: 4174 bytes --]

Re: libiconv checksum wrong

[Richard Purdie]

On Wed, 2011-07-20 at 10:41 +0100, Phil Blundell wrote:
> Since updating this morning I'm getting
> 
> | ERROR: Function 'File: '/home/pb/sources/libiconv-1.13.1.tar.gz' has
> md5 checksum 7ab33ebd26687c744a37264a330bbe9a when
> d42b97f6ef5dd0ba4469d520ed732fed was expected (from URL:
> 'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz')' failed
> NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed
> 
> The offending commit appears to be
> bd1e627bef29830f9346b4b984905fd8fcf2e716.  As far as I can tell from a
> quick inspection of the files, the checksum that was added for
> libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
> earlier version 1.11.1.

There is a big patch out there which includes a fix for this but I'm
asking it be reworked. In the meantime I've pushed a fix for the
checksums.

Cheers,

Richard