2011/7/20 Khem Raj <raj.k...@gmail.com> > On 07/20/2011 04:55 AM, Frans Meulenbroeks wrote: > >> 2011/7/20 Phil Blundell<ph...@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.
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
