Re: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib on rootfs

The steps shared by you is telling about customizing the image on existing recipes. But I query is how to add prebuild libraries directly to rootfs. Thanks in Advance. Regards Meena From: Vladimir Redzhepov [vladimir_redzhe...@epam.com] Sent: Friday,

Re: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib on rootfs

On Thu, Jul 24, 2014 at 11:08 PM, Meenakumari Shedole meenakumar...@hcl.com wrote: The steps shared by you is telling about customizing the image on existing recipes. But I query is how to add prebuild libraries directly to rootfs. Thanks in Advance. even though its a bad idea to package

[yocto] are there any more obvious candidates for ASSUME_PROVIDED?

asked about this once upon a time ... are there any other possibilities for adding to ASSUME_PROVIDED in local.conf.sample, given that there are surely more native utilities that are fairly safe by now? for example, it's still weird that current default ASSUME_PROVIDED includes bzip2 but not

Re: [yocto] Bitbake error for rpm-native -- do compile failed

On 25 July 2014 13:42, Anoop Babu babu.an...@gmail.com wrote: My apologies for pushing all issues to yocto forum. Can you please let me know the meta-tizen forum. As far as I'm aware you'll have to email the maintainers directly. I had started bitbake procedure after cloning below mentioned

Re: [yocto] [oe] [meta-oracle-java][PATCH] Version update and Java for ARM

Can someone forward me the patch please, I can't apply it from web interface. Here is the link: https://lists.yoctoproject.org/pipermail/yocto/2014-June/020223.html Cheers, -- ___ yocto mailing list yocto@yoctoproject.org

Re: [yocto] Yocto Bitbake Error - rmp-native task failure

thank you I applied the patch the earlier stated error is not seen . but I have hit on another error. Patch redhat-portability.diff does not apply (enforce with -f) ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in:

Re: [yocto] Bitbake error for rpm-native -- do compile failed

Dear Ross, My apologies for pushing all issues to yocto forum. Can you please let me know the meta-tizen forum. I had started bitbake procedure after cloning below mentioned repo git clone ssh://${YOUR_TIZEN_ID}@review.tizen.org:29418/scm/bb/meta-tizen Today did a fetch from tizen branch. I

[yocto] [yocto-docs][PATCH] dev-manual: Add some links, update another.

Add in a few links to member orgs, and update the BitBake link. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- yeah, i'm bored ... diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml index f3cf489..92d67e0 100644 ---

[yocto] don't all core images use openssh instead of dropbear?

dev manual, ch 2, final note claims, The core-image-sato QEMU image has a Dropbear secure shell (SSH) server that runs with the root password disabled. but core-image.bbclass contains the line: IMAGE_FEATURES_REPLACES_ssh-server-openssh = ssh-server-dropbear so wouldn't *all* image recipes

Re: [yocto] don't all core images use openssh instead of dropbear?

On 25 July 2014 17:03, Robert P. J. Day rpj...@crashcourse.ca wrote: IMAGE_FEATURES_REPLACES_ssh-server-openssh = ssh-server-dropbear so wouldn't *all* image recipes derived from core-image replace dropbear with openssh? That means that the image feature ssh-server-openssh replaces

[yocto] change in base-files recipe does not trigger rebuild

I'm on dora. I am using a different /etc/profile for base-files via a bbappend. Subsequent builds of my image does not add the new base-files package as I think it should. Running bitbake of my image after the modification reports nothing to do. Bumping the PR on the bbappend rebuilds base-files

Re: [yocto] don't all core images use openssh instead of dropbear?

On Fri, 25 Jul 2014, Burton, Ross wrote: On 25 July 2014 17:03, Robert P. J. Day rpj...@crashcourse.ca wrote: IMAGE_FEATURES_REPLACES_ssh-server-openssh = ssh-server-dropbear so wouldn't *all* image recipes derived from core-image replace dropbear with openssh? That means that the

Re: [yocto] are there any more obvious candidates for ASSUME_PROVIDED?

On Fri, Jul 25, 2014 at 5:39 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: asked about this once upon a time ... are there any other possibilities for adding to ASSUME_PROVIDED in local.conf.sample, given that there are surely more native utilities that are fairly safe by now? for

Re: [yocto] are there any more obvious candidates for ASSUME_PROVIDED?

On Fri, 25 Jul 2014, Khem Raj wrote: On Fri, Jul 25, 2014 at 5:39 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: asked about this once upon a time ... are there any other possibilities for adding to ASSUME_PROVIDED in local.conf.sample, given that there are surely more native

Re: [yocto] [oe] [meta-oracle-java][PATCH] Version update and Java for ARM

On 07/25/2014 11:47 AM, Daniel Hilst Selli wrote: Can someone forward me the patch please, I can't apply it from web interface. Here is the link: https://lists.yoctoproject.org/pipermail/yocto/2014-June/020223.html Cheers, Ok I got the patch, but can't apply it, got this message `fatal:

Re: [yocto] are there any more obvious candidates for ASSUME_PROVIDED?

On Fri, Jul 25, 2014 at 9:51 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: fair enough, but what about the simpler example of gzip as opposed to bzip2? it's just trying to understand what makes the list and what doesn't. gzip can be replaced by pigz and it can be used to provide

Re: [yocto] change in base-files recipe does not trigger rebuild

On Fri, Jul 25, 2014 at 9:10 AM, Jate S jate...@gmail.com wrote: I'm on dora. I am using a different /etc/profile for base-files via a bbappend. Subsequent builds of my image does not add the new base-files package as I think it should. Running bitbake of my image after the modification

Re: [yocto] are there any more obvious candidates for ASSUME_PROVIDED?

On Fri, 25 Jul 2014, Khem Raj wrote: On Fri, Jul 25, 2014 at 9:51 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: fair enough, but what about the simpler example of gzip as opposed to bzip2? it's just trying to understand what makes the list and what doesn't. gzip can be replaced

[yocto] dev manual definition of Image is totally wrong

here: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms the definition of Image refers to the generated artifacts of a build, whereas the standard usage (as typified by the link) more correctly refers to things like core-image-minimal. i'll let someone

[yocto] [yocto-dosc][PATCH] dev-manual: Mention wildcard bbappends, grammar fix.

Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 434a7d1..0f7708e 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++

Re: [yocto] change in base-files recipe does not trigger rebuild

base-files_3.0.14.bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/base-files: PR := ${PR}.0 Here's output from the tree command. recipes-core/base-files/ |-- base-files | `-- profile `-- base-files_3.0.14.bbappend 1 directory, 2 files On Fri, Jul 25, 2014 at 1:30 PM, Khem Raj

Re: [yocto] dev manual definition of Image is totally wrong

On Fri, Jul 25, 2014 at 10:47 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: here: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms the definition of Image refers to the generated artifacts of a build, whereas the standard usage (as typified by the

Re: [yocto] dev manual definition of Image is totally wrong

here: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms the definition of Image refers to the generated artifacts of a build, whereas the standard usage (as typified by the link) more correctly refers to things like core-image-minimal. The term

[yocto] libpcap-ng

Hello all, Meta-security and Meta-selinux both have libcap-ng. Instead of maintaining the same package in both places, can we get it into OE where libcap resides? regards, Armin -- ___ yocto mailing list yocto@yoctoproject.org

Re: [yocto] [OE-core] libpcap-ng

On Fri, Jul 25, 2014 at 3:45 PM, akuster akus...@mvista.com wrote: Meta-security and Meta-selinux both have libcap-ng. Instead of maintaining the same package in both places, can we get it into OE where libcap resides? I think at very least you can propose it for meta-oe if not or-core. But I

[linux-yocto] [PATCH 01/14] ARM: Fix missing includes in kprobes sources

From: David A. Long dave.l...@linaro.org commit 21254ebc9e509967317ad8c6922797e21137ad53 upstream Make sure includes in ARM kprobes sources are done explicitly. Do not rely on includes from other includes. Signed-off-by: David A. Long dave.l...@linaro.org Acked-by: Jon Medhurst t...@linaro.org

[linux-yocto] [PATCH 02/14] uprobes: allow ignoring of probe hits

From: David A. Long dave.l...@linaro.org commit 6fe50a28ba6e5fafb4a549dea666dd15297dd8bd upstream Allow arches to decided to ignore a probe hit. ARM will use this to only call handlers if the conditions to execute a conditionally executed instruction are satisfied. Signed-off-by: David A. Long

[linux-yocto] [PATCH 03/14] ARM: move shared uprobe/kprobe definitions into new include file

From: David A. Long dave.l...@linaro.org commit b2531dd5e5f19ea01d67aed82d81c5f778ec0fb7 upstream Separate the kprobe-only definitions from the definitions needed by both kprobes and uprobes. Signed-off-by: David A. Long dave.l...@linaro.org Acked-by: Jon Medhurst t...@linaro.org Signed-off-by:

[linux-yocto] [PATCH 09/14] ARM: Change more ARM kprobes symbol names to something more generic

From: David A. Long dave.l...@linaro.org commit eb73ea97e63bb06bf98ff052615ce181bc7f69ec upstream Change kprobe_emulate_none, kprobe_simulate_nop, and arm_kprobe_decode_init function names to something more appropriate for code being shared outside of the kprobes subsystem. Also, move the new

[linux-yocto] [PATCH 08/14] ARM: Make the kprobes condition_check symbol names more generic

From: David A. Long dave.l...@linaro.org commit f145d664df502585618b12ed68c681f82153e02a upstream In preparation for sharing the ARM kprobes instruction interpreting code with uprobes, make the symbols names less kprobes-specific. Signed-off-by: David A. Long dave.l...@linaro.org Acked-by: Jon

[linux-yocto] [PATCH 06/14] ARM: use a function table for determining instruction interpreter action

From: David A. Long dave.l...@linaro.org commit 3e6cd394bb10c2d65322e5f5d2ff0a9074d903a1 upstream Make the instruction interpreter call back to semantic action functions through a function pointer array provided by the invoker. The interpreter decodes the instructions into groups and uses the

[linux-yocto] [PATCH 07/14] ARM: Remove use of struct kprobe from generic probes code

From: David A. Long dave.l...@linaro.org commit 7579f4b3764337b39087d10496af0e741cbfe570 upstream Change the generic ARM probes code to pass in the opcode and architecture-specific structure separately instead of using struct kprobe, so we do not pollute code being used only for uprobes or

[linux-yocto] [PATCH 05/14] ARM: move generic thumb instruction parsing code to new files for use by other feature

From: David A. Long dave.l...@linaro.org commit 87abef63ead5ac9e2c67f0c07c461eda6be16aeb upstream Move the thumb version of the kprobes instruction parsing code into more generic files from where it can be used by uprobes and possibly other subsystems. The symbol names will be made more generic

[linux-yocto] [PATCH 04/14] ARM: Move generic arm instruction parsing code to new files for sharing between features

From: David A. Long dave.l...@linaro.org commit c18377c303787ded44b7decd7dee694db0f205e9 upstream Move the arm version of the kprobes instruction parsing code into more generic files from where it can be used by uprobes and possibly other subsystems. The symbol names will be made more generic in

[linux-yocto] [PATCH 13/14] ARM: Make arch_specific_insn a define for new arch_probes_insn structure

From: David A. Long dave.l...@linaro.org commit b4cd605ca92d9a8a2f71355cb45dd943ebcb0c97 upstream Because the common underlying code for ARM kprobes and uprobes needs to share a common architecrure-specific context structure, and because the generic kprobes include file insists on defining this

[linux-yocto] [PATCH 12/14] ARM: Add an emulate flag to the kprobes/uprobes instruction decode functions

From: David A. Long dave.l...@linaro.org commit 602cd2609eee92d338a83e400774e97c60535ba2 upstream Add an emulate flag into the instruction interpreter, primarily for uprobes support. Signed-off-by: David A. Long dave.l...@linaro.org Acked-by: Jon Medhurst t...@linaro.org Signed-off-by: Yang Shi

[linux-yocto] [PATCH 11/14] ARM: Change the remaining shared kprobes/uprobes symbols to something generic

From: David A. Long dave.l...@linaro.org commit 47e190fafde49ff8ca732fa137e39cb2b8baba8c upstream Any more ARM kprobes/uprobes symbols which have kprobe in the name must be changed to the more generic probes or other non-kprobes specific symbol. Signed-off-by: David A. Long dave.l...@linaro.org

[linux-yocto] [PATCH 14/14] ARM: add uprobes support

From: David A. Long dave.l...@linaro.org commit c7edc9e326d53ca5ef9bed82de0740c6b107d55b upstream Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes support on ARM. Caveats: - Thumb is not supported Signed-off-by: Rabin Vincent ra...@rab.in Signed-off-by: David A. Long

Re: [linux-yocto] [PATCH v2 0/2][3.14][dev] meta: Industrial IO Support

On 14-07-22 05:52 PM, Darren Hart wrote: Add a new config fragment enabling Industrial IO (IIO) and all the non-staging drivers. Add this to the intel-common-standard. Please apply to 3.14 and -dev. Sorry for the delay .. 3.16 got in the way. This is now pushed to 3.14 and -dev. Bruce v2: