Attendees: Dave, MichaelH, Ciby, PaulE, ScottG, BjörnS, Ramana, KevinS, TomZ, Eren, AlexG, ALexD, Richard, BrianR,Jefro, LaurentiuP, Nitin, BruceA, RossB, ScottR, JeffP, MarkH, CristianI, DarrenH,

for what it's worth, if you're building an image that's a variation of a "core" image, an alternate way of adding packages after the fact is: CORE_IMAGE_EXTRA_INSTALL = "sysfsutils strace bash" i

Hi Jeff, Sure :) At first, I will try to address the suggestions of Alex along with other modifications based on our requirements. I have checked the access rights and it works fine. Thanks!

ah, quite so ... but it's still useful to note that the problem extends even to the act of fetching. weird. rday --

"Robert P. J. Day" <rpjday@...> a écrit : It's not fetched because the build system fails to see the new package as a dependencie of the image so that's not a fetching issue but a more

<rpjday@...> wrote: Thank you for your testing and observations. But I'd like to point out that in my tests, all the relevant files have already been fetched. My DL_DIR already contains

<otavio@...> wrote: These are hosted on different organizations... I don't see any repos from git.yoctoproject.org on http://patches.openembedded.org/. Although it would be nice to

here's a test i made based on nothing but fetching. using oe-core, i selected qemuarm, added this line at the bottom of my local.conf: IMAGE_INSTALL_append = " sysfsutils strace" and ran $

Looking for comments. Thanks ________________________________________ Sent: Thursday, November 22, 2012 12:59 AM To: Venkata ramana gollamudi Cc: yocto@...; Sanil kumar; Hatle, Mark;

Since it's confirmed from different people, I think it would be better to report it using bugzilla. I guess that it's not an intended behaviour/feature of bitbake. Please inform the bug number so that

Correct. If you don't have any board specific patches, working with an existing branch in the tree is fine. Also note that the yocto-bsp tool allows the extension of an existing BSP or kernel to a

- AbstractHostShellReader is designed such that it will block in a read from the pipeline when the command is finished its execution, therefore we should not wait for this variable to be set because

- when creating a shell session for Bitbake, we cannot run "bitbake -e -b recipe.bb" just by setting DISABLE_SANITY_CHECKS=1; we must first append DISABLE_SANITY_CHECKS to

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...> --- .../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

- when deleting a file from a remote directory use the URI and not the location of the file which is null Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...> ---

Sorry for the delay in replying. I've not had to do this myself but I suspect something like this might do it: BUILD_ARCH = "i686" Cheers, Paul -- Paul Eggleton Intel Open Source Technology

Jonas Jonsson L <jonas.l.jonsson@...> a écrit : that seems to work the first time you add something using IMAGE_INSTALL_append. Then it fails when you add packages later (bitbake wants to

I can also confirm this. A package (I've tried with diffutils & bash) must be built separately before it's added to an image via IMAGE_INSTALL_append. /Jonas - fetched poky today

Thank you, Eric, for the confirmation. Just to clarify for anyone following along: the problem isn't with bash or trace-cmd themselves. If I perform the same steps but use 'bash' first, then

Hi Trevor, Trevor Woerner <twoerner@...> a écrit : I confirm the problem when following this procedure step by step. with bitbake -e we see that bash is in RDEPENDS and in IMAGE_INSTALL with