> 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 of fetcher errors, this is
>>> somehow connected with rollout of Python relate
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 t
> 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 Python related security fixes to various
>> Linux distributio
> 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:
>
> multiple definition of `__do_glob
> 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.
>
> It was a bunch of tar balls tha
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 `p
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 pre
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
---
recipes-devtools/gc
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 insertion(+), 1 deletion(-)
di
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
--
___
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:
> https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan#
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 a
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 the others reside.
>
> I don't k
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
buildse
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 this patch isn't applied to ab m
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 as
> 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 only source under
>> 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 as
> 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.
>
>
> But if I do “bitba
>> 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.
Thanks,
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,
>> 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 why do we want to override defaul
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 try to build the image.
>
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 below:
>
> dinhn@rs-
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:
>
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 sti
>>> 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
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
tmp/deplo
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 is already written and works well,
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 = "${PN}" should work
>>
>> It s
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 days)
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:
> https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan#
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
--
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 host
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 co
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 risk, or is this somethi
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
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
38 matches
Mail list logo
