All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: libiconv checksum wrong
Date: Wed, 20 Jul 2011 09:44:53 -0700	[thread overview]
Message-ID: <4E270605.1090802@linux.intel.com> (raw)
In-Reply-To: <1311172926.2344.49.camel@rex>

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
>



  reply	other threads:[~2011-07-20 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20  9:41 libiconv checksum wrong Phil Blundell
2011-07-20 11:55 ` Frans Meulenbroeks
2011-07-20 13:30   ` Khem Raj
2011-07-20 14:26     ` Frans Meulenbroeks
2011-07-20 14:42       ` Richard Purdie
2011-07-20 16:44         ` Saul Wold [this message]
2011-07-20 21:02         ` Frans Meulenbroeks
2011-07-20 14:37 ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E270605.1090802@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.