Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

> On Oct 5, 2016, at 4:52 PM, Khem Raj wrote: >> On Oct 5, 2016, at 4:45 PM, Randy Mortensen >> wrote: >>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins >>> wrote: >>> >>> From what I gleaned from recent discussions

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

From what I gleaned from recent discussions of fetcher errors, this is somehow connected with rollout of Python related security fixes to various Linux distributions and/or some ...-native recipes. It was a bunch of tar balls that are named as mercurial hashes from within iced tea rather than

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

> On Oct 5, 2016, at 4:45 PM, Randy Mortensen > wrote: > > >> On Oct 5, 2016, at 5:04 PM, Darcy Watkins >> wrote: >> >> From what I gleaned from recent discussions of fetcher errors, this is >> somehow connected with rollout of

Re: [yocto] [meta-mingw][PATCH 2/3] gcc-crosssdk_%.bbappend: Do not configure with initfini-array enabled.

> On Oct 5, 2016, at 3:49 PM, Juro Bystricky wrote: > > Default configuration for gcc-crosssddk is now to enable initfini-array. > However, this works only for Linux so we disable it for mingw32. > Otherwise we will eventually encounter build error such as: > >

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

> On Oct 5, 2016, at 5:04 PM, Darcy Watkins wrote: > > From what I gleaned from recent discussions of fetcher errors, this is > somehow connected with rollout of Python related security fixes to various > Linux distributions and/or some ...-native recipes. > >

[yocto] [meta-mingw][PATCH 0/3] meta-mingw patches for master

The current master deviated enough from krogoth that it needs new meta-mingw patches (and a separate meta-mingw branch) in order to build (cross-compile) anything. Only the build itself was tested, not the actual functionality of the resulting deployables. Nevertheless, correct functionality is

[yocto] [meta-mingw][PATCH 3/3] gcc-crosssdk-initial_%.bbappend:Do not configure with initfini-array enabled

Default configuration for gcc-crosssddk-initial is now to enable initfini-array. However, this works only for Linux so we disable it for mingw32. Otherwise, (with SDKMACHINE=x86_64-mingw32) we will eventually encounter errors such as: Assembler messages: Error: invalid instruction suffix for

[yocto] [meta-mingw][PATCH 2/3] gcc-crosssdk_%.bbappend: Do not configure with initfini-array enabled.

Default configuration for gcc-crosssddk is now to enable initfini-array. However, this works only for Linux so we disable it for mingw32. Otherwise we will eventually encounter build error such as: multiple definition of `__do_global_dtors' Signed-off-by: Juro Bystricky

[yocto] [meta-mingw][PATCH 1/3] mingw-64-runtime_3.1.bb: Adapt to SDK_ARCH -> SDK_SYS chanages for crosssdk

With the change of crosssdk to use SDK_SYS instead of SDK_ARCH, we need to update the recipe to match the changes in master. [YOCTO #9281] Signed-off-by: Juro Bystricky --- recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb | 2 +- 1 file changed, 1

[yocto] openjdk build fails due to checksum mismatches from icedtea-native

Using Jethro release and attempting to build either openjdk-7 or 8 fails when fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all the SRC_URI entries). openjdk-7 did successfully build about a month ago. Is there a workaround, fix or other suggestions? Thanks --

Re: [yocto] [[yocto-autobuilder][PATCHv3]] Build sets to test new OS distribution in autobuilder

On 10/05/2016 03:54 PM, Monserrat Sedeno wrote: > As part of the process to set new OS distribution as supported on Yoctoc > Project > a new patch was created with the list of build sets that should be executed. > > Detailed information: >

[yocto] [[yocto-autobuilder][PATCHv3]] Build sets to test new OS distribution in autobuilder

As part of the process to set new OS distribution as supported on Yoctoc Project a new patch was created with the list of build sets that should be executed. Detailed information: https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan#Execute_Build_Sets Fixes [YOCTO #9905] Note:In order to add

Re: [yocto] [[yocto-autobuilder][PATCHv2]] Build sets to test new OS distribution in autobuilder

On Wed, Oct 5, 2016 at 1:47 PM, Aníbal Limón wrote: > > > On 10/05/2016 03:41 PM, Bill Randle wrote: >> I also wonder if this actually belongs in >> buildset-config.autobuilder-qa (which doesn't have any other configs), >> or in buildset-config.controller where all

Re: [yocto] [[yocto-autobuilder][PATCHv2]] Build sets to test new OS distribution in autobuilder

On 10/05/2016 03:41 PM, Bill Randle wrote: > I also wonder if this actually belongs in > buildset-config.autobuilder-qa (which doesn't have any other configs), > or in buildset-config.controller where all the others reside. I don't know what was the original target for the autobuilder-qa

Re: [yocto] [[yocto-autobuilder][PATCHv2]] Build sets to test new OS distribution in autobuilder

I also wonder if this actually belongs in buildset-config.autobuilder-qa (which doesn't have any other configs), or in buildset-config.controller where all the others reside. -Bill On Wed, Oct 5, 2016 at 1:00 PM, Aníbal Limón wrote: > Oh, I didn't notice that

Re: [yocto] [[yocto-autobuilder][PATCHv2]] Build sets to test new OS distribution in autobuilder

Oh, I didn't notice that this patch isn't applied to ab master branch. Monse, could you send a new patch over master? Cheers, alimon On 10/05/2016 09:59 AM, Aníbal Limón wrote: > > > On 09/30/2016 03:29 PM, Monserrat Sedeno wrote: >> As part of the process to set new OS distribution

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

> On Oct 5, 2016, at 11:43 AM, Dinh Nguyen (dinhn) wrote: > > > >>> then it is just going to reuse the build artifacts from last builds and not >>> checkout the sources etc. >>> all those tasks will be skipped. > >>> why are looking for sources in a build tree ? > > > Not

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

>> then it is just going to reuse the build artifacts from last builds and not >> checkout the sources etc. >> all those tasks will be skipped. >> why are looking for sources in a build tree ? Not only source under .. yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git But other data such

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) wrote: > >>> Are the files present in the image/packages? Maybe it is just the >>> bitbake cache skipping doing work it already did last time. > > If I don’t do the bitbake clean, and just do bitbake again, then yes. > > >

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

>> Are the files present in the image/packages? Maybe it is just the >> bitbake cache skipping doing work it already did last time. If I don’t do the bitbake clean, and just do bitbake again, then yes. But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the problem.

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

Thanks Khem >> I guess its getting renamed as per debian package renaming rules. Just add >> ALLOW_EMPTY_${PN} = "1" I added ALLOW_EMPTY_${PN} = “1” And encountered the same issue as specified in previous mail. For the very first time after adding it, everything went well, including the -dev,

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

>> Is that doing a compile in the install target? Yes Len. Compile was done and there is no issue there. Thanks, —Dinh On 10/5/16, 9:28 AM, "Lennart Sorensen" wrote: >On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote: >> >>> I wonder

Re: [yocto] Need inputs on integrating YP-Core Krogoth to Brilliant Blow-fish AGL release.

Hello All, Can anyone help me out on this issue. Thanks. Cheers, Vijay On Mon, Oct 3, 2016 at 6:19 PM, Vijayakumar Badiger wrote: > Hello All, > > I am trying to integrate the YP Core - Krogoth 2.1.1 to the AGL Blowfish > release. I am getting the below error when I

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

On Wed, Oct 5, 2016 at 9:06 AM, Dinh Nguyen (dinhn) wrote: > Many thanks Paul. Your help is greatly appreciated. > > 1. >>> Like the other responder I would suggest you not set PACKAGES > > Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built > as shown

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

On Wed, Oct 05, 2016 at 04:06:25PM +, Dinh Nguyen (dinhn) wrote: > Many thanks Paul. Your help is greatly appreciated. > > 1. >>> Like the other responder I would suggest you not set PACKAGES > > Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built > as shown below: >

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote: > >>> I wonder why do we want to override default PACKAGES here. If we can > >>> leave that alone things would work out on its own. > > I did remove the PACKAGES setting in my .bb — so all default packages were > built. But

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

>>> I wonder why do we want to override default PACKAGES here. If we can leave >>> that alone things would work out on its own. I did remove the PACKAGES setting in my .bb — so all default packages were built. But still having some other issue as stated in other emails. Thanks Khem. —Dinh

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

Many thanks Paul. Your help is greatly appreciated. 1. >>> Like the other responder I would suggest you not set PACKAGES Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built as shown below: dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find

Re: [yocto] Splitting a recipe into two for two kind of compilation

On Wed, Oct 5, 2016 at 7:20 AM, Nicolas Bigaouette wrote: > Hi all! > > I have an issue when trying to build two different images using conflicting > packages. > > I need to package an application of mine (built using cmake) for our Yocto > deployment. The recipe

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

I wonder why do we want to override default PACKAGES here. If we can leave that alone things would work out on its own. On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton wrote: > On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote: >> Thanks much Paul. >> >> PACKAGES

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: remove redundant IMAGEDATESTAMP

On Wed 2016-10-05 @ 11:01:15 AM, Jonathan Liu wrote: > See if the following helps: > bitbake -c cleanall core-image-minimal && bitbake core-image-minimal Odd. I had started this email to say that this wasn't working (since this is exactly what I had tried a couple times over the last several

Re: [yocto] [[yocto-autobuilder][PATCHv2]] Build sets to test new OS distribution in autobuilder

On 09/30/2016 03:29 PM, Monserrat Sedeno wrote: > As part of the process to set new OS distribution as supported on Yoctoc > Project > a new patch was created with the list of build sets that should be executed. > > Detailed information: >

[yocto] openjdk failures

Using Jethro release and attempting to build either openjdk-7 or 8 fails when fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all the SRC_URI entries). openjdk-7 did successfully build about a month ago. Is there a workaround, fix or other suggestions? Thanks --

[yocto] [PATCH] sdk-installer: Fix unclear SDK installer message

When the host and the SDK architectures are incompatible the SDK installer outputs an incomplete error message "Error: Installation machine not supported!". This commit adds a more verbose error message e.g "Error: Incompatible SDK installer! Your host is i686 and this SDK was built for x86_64

[yocto] Splitting a recipe into two for two kind of compilation

Hi all! I have an issue when trying to build two different images using conflicting packages. I need to package an application of mine (built using cmake) for our Yocto deployment. The recipe is already written and works well, except that I now need to build two different versions of that

Re: [yocto] [meta-selinux][PATCH] libpcre_%.bbappend: add missing symlink libpcre.so.1

On 5 October 2016 at 13:58, Ioan-Adrian Ratiu wrote: > (the reason why the lib is moved in the first place is to avoid a QA issue > because there's a risk for /usr to be on another partition) > I'm not a meta-selinux maintainer but this is where I ask is there actually a

[yocto] [meta-selinux][PATCH] libpcre_%.bbappend: add missing symlink libpcre.so.1

This bbappend moves sysroot lib libpcre.so.x.x.x from /usr/lib to /lib and symlinks /usr/lib/libpcre.so to ../../lib/libpcre.so.x.x.x, but this causes certain recipes dependent on libpcre (like pango) to fail because they also expect libpcre.so.1 to exist which this recipe omits to create. (the

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote: > Thanks much Paul. > > PACKAGES = "${PN}" should work > > It solved the early error “ c-mlib listed in PACKAGES multiple times, this > leads to packaging errors” — Thanks again. > > > But running into other issue. Below is my do_install >