Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mariano Lopez <mariano.lopez@linux.intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Christopher Larson <clarson@kergoth.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] package_ipk.bbclass: Add check for empty lines in DESCRIPTION
Date: Thu, 26 Jan 2017 09:16:34 -0600	[thread overview]
Message-ID: <9d6ac8ff-f401-06fd-689c-05bf11eb209d@linux.intel.com> (raw)
In-Reply-To: <1485345378.30673.88.camel@linuxfoundation.org>



On 25/01/17 05:56, Richard Purdie wrote:
> On Tue, 2017-01-24 at 11:52 -0700, Christopher Larson wrote:
>> On Tue, Jan 24, 2017 at 1:37 AM, <mariano.lopez@linux.intel.com>
>> wrote:
>>> From: Mariano Lopez <mariano.lopez@linux.intel.com>
>>>
>>> opkg uses empty lines as separator for next package and if an ipk
>>> file was packaged with empty lines in DESCRIPTION opkg won't be
>>> able to handle such ipk file, this happens at execution time.
>>>
>>> This commit will add a check for empty lines in DESCRIPTION when
>>> generating to ipk package to avoid this issue.
>>>
>>> [YOCTO #10677]
>>>
>>> Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
>>>
>> Could it handle a line with just a space, or a period? Could you not
>> replace the lines with that instead, rather than aborting?
> FWIW package_deb uses ".".

Also opkg will strip() the lines, so an empty space is not a option here.

>
> Also, please use bb.fatal() calls with caution, I just removed several
> from that class. In this case its perhaps ok but often the correct
> thing to do is raise an exception of some kind. This means bitbake will
> generate a usable traceback rather than simply printing the fatal
> message. In this case the message is probably fine but there were
> several cases where a traceback was a much better idea as the fatal
> message wasn't enough to debug with.

Fair enough, I will consider this advice when using bb.fatal()

Regards,
Mariano


      reply	other threads:[~2017-01-26 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1485247027.git.mariano.lopez@linux.intel.com>
2017-01-24  8:37 ` [PATCH 1/1] package_ipk.bbclass: Add check for empty lines in DESCRIPTION mariano.lopez
2017-01-24 18:52   ` Christopher Larson
2017-01-25 11:56     ` Richard Purdie
2017-01-26 15:16       ` Mariano Lopez [this message]

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=9d6ac8ff-f401-06fd-689c-05bf11eb209d@linux.intel.com \
    --to=mariano.lopez@linux.intel.com \
    --cc=clarson@kergoth.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox