From: Mario Domenech Goulart <mario@ossystems.com.br>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembeded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-oe][PATCH 1/2] wvstreams: add recipe for version 4.6.1
Date: Mon, 07 Oct 2013 14:57:45 +0000 [thread overview]
Message-ID: <8738odt9g6.fsf@parenteses.org> (raw)
In-Reply-To: <CAMKF1spqdOMP3YTawqtXtGQ3UUcGki91GJN56iT7wirmLSrrKA@mail.gmail.com> (Khem Raj's message of "Sun, 6 Oct 2013 22:45:56 -0700")
Hi Khem
On Sun, 6 Oct 2013 22:45:56 -0700 Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Oct 4, 2013 at 7:27 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> On Fri, Oct 4, 2013 at 11:19 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Tue, Sep 24, 2013 at 11:42:21AM -0300, Otavio Salvador wrote:
>>>> On Tue, Sep 24, 2013 at 9:43 AM, Mario Domenech Goulart
>>>> <mario@ossystems.com.br> wrote:
>>>> > Recipe based on OE classic's recipe for version 4.4.1, as of
>>>> > 0585ccfa49f71a81652c7f63885202e952ebd0e9.
>>>> >
>>>> > Summary of changes against OE classic's recipe:
>>>> >
>>>> > * Apply some Debian patches from
>>>> > http://patch-tracker.debian.org/package/wvstreams/4.6.1-6
>>>> >
>>>> > * Minor adjustments for the current build system (add
>>>> > LIC_FILES_CHKSUM, md5 and sha256 sums for SRC_URI, fix LICENSE, remove
>>>> > PR)
>>>> >
>>>> > * Disable parallel make, since it was causing errors like
>>>> >
>>>> > Log data follows:
>>>> > | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>>> > | common-linux', 'common-glibc', 'arm-linux',
>>>> > | arm-linux-gnueabi', 'common']
>>>> > | DEBUG: Executing shell function do_compile
>>>> > | NOTE: make -j 8
>>>> > | ./CXX -c utils/wvbuffer
>>>> > | ./CXX -c utils/wvbufferstore
>>>> > | ./CXX -c utils/wvcont
>>>> > | /bin/bash: ./CXX: No such file or directory
>>>> > | /bin/bash: ./CXX: No such file or directory
>>>> > | /bin/bash: ./CXX: No such file or directory
>>>> > | * Generating CC using c
>>>> > | make: * Generating CXX using cc
>>>> > | *** [utils/wvbuffer.o] Error 127
>>>> > | make: *** Waiting for unfinished jobs....
>>>> > | make: *** [utils/wvbufferstore.o] Error 127
>>>> > | make: *** [utils/wvcont.o] Error 127
>>>> > | ERROR: oe_runmake failed
>>>> > | WARNING: .../tmp/work/armv7a-vfp-neon-oel-linux-gnueabi/wvstreams/4.6.1-r0/temp/run.do_compile.19302:1 exit 1 from
>>>> > | exit 1
>>>> > | ERROR: Function failed: do_compile (log file is located at
>>>> > | .../tmp/work/armv7a-vfp-neon-oel-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_compile.19302)
>>>> >
>>>> > Signed-off-by: Mario Domenech Goulart <mario@ossystems.com.br>
>>>>
>>>> Just for reference, Mario and I discussed about the path for including
>>>> this recipe.
>>>>
>>>> We agreed it to be placed at wvdial subdir as it will only be used by it.
>>>>
>>>> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
>>>
>>> Sorry for huge delay caused by monster build running on jenkins for 11
>>> days.. but this needs small fix for new QA issue:
>>>
>>> wvstreams-4.6.1: wvstreams: Files/directories were installed but not
>>> shipped
>>> /usr/lib/valgrind
>>> /usr/lib/valgrind/wvstreams.supp
>>
>> Sure; Mario, can you split this into a ${PN}-valgrind package?
>
> May be they should go into ${PN}-dev package and IMHO don't disable
> it. since its a good
> thing we want to make sure the tools like valgrind can be tried easily
> out of box if possible.
Good point. I'll submit a new patch to replace --without-valigrind with
--with-valgrind (it doesn't require valgrind as a build dependency).
Since .supp files are only useful if you have valgrind installed, I
think we should add valgrind to RDEPENDS_${PN}-<?>.
Now we need to decide on -<?>. Maybe -valgrind is cleaner in the sense
that those who need the -dev files but don't need valgrind won't get
valgrind as a runtime dependency. Adding valgrind to
RDEPENDS_${PN}-valgrind sounds ok to me (those who install it will be
clearly stating that they do want valgrind stuff).
What do you think?
Best wishes.
Mario
--
http://www.ossystems.com.br
next prev parent reply other threads:[~2013-10-07 14:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-24 12:43 [meta-oe][PATCH 1/2] wvstreams: add recipe for version 4.6.1 Mario Domenech Goulart
2013-09-24 12:43 ` [meta-oe][PATCH 2/2] wvdial: add recipe for version 1.61 Mario Domenech Goulart
2013-09-24 14:42 ` Otavio Salvador
2013-09-24 14:42 ` [meta-oe][PATCH 1/2] wvstreams: add recipe for version 4.6.1 Otavio Salvador
2013-10-04 14:19 ` Martin Jansa
2013-10-04 14:27 ` Otavio Salvador
2013-10-04 17:04 ` Mario Domenech Goulart
2013-10-07 5:45 ` Khem Raj
2013-10-07 14:57 ` Mario Domenech Goulart [this message]
2013-10-07 18:27 ` Khem Raj
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=8738odt9g6.fsf@parenteses.org \
--to=mario@ossystems.com.br \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/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