Re: [yocto] Package naming "exceptions" in Yocto

[Reshetova, Elena]

>One thing you'll definitely need to do is to actually include the file in
your configuration i.e.:

>require conf/distro/include/distro_alias.inc

This is what I was missing obviously since I stupidly assumed it is included
by default.  Thank you very much. Now I get the information I need :)

Best Regards,
Elena.


smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH v3 1/2] qt5: fixed raspberrypi support

[John Madieu]

Because EGL properties were not defined properly, we always had the 
following error
make: *** [egl] Error 1
| EGL disabled.
|  The EGL functionality test failed; EGL is required by some QPA 
plugins to manage cont
|  You might need to modify the include and library search paths by 
editing QMAKE_INCDIR

x11 in DISTRO_FEATURES also produced the following error
error: 'QAccessible' has not been declared
|  } else if 
(QStyleHelper::isInstanceOf(groupBox->styleObject,
QAccessible::Grouping)) {
|   ^
|Makefile:53048: recipe for target '.obj/qgtkstyle.o' failed

This bbappend definitively fix these bug

Signed-off-by: John Madieu 
---
 qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

diff --git a/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend 
b/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
new file mode 100644
index 000..f61cd1d
--- /dev/null
+++ b/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
@@ -0,0 +1,33 @@
+
+# Raspberrypi only need gles2
+PACKAGECONFIG_GL = "gles2"
+
+QT_CONFIG_FLAGS_append = "${@base_contains('DISTRO_FEATURES', 'x11', ' 
-accessibility ', '', d)}"
+do_configure_prepend_rpi() {
+
+   sed -i 's!load(qt_config)!!' ${S}/mkspecs/linux-oe-g++/qmake.conf
+if ! grep -q '^EGLFS_' ${S}/mkspecs/linux-oe-g++/qmake.conf; then
+cat >> ${S}/mkspecs/linux-oe-g++/qmake.conf <> ${S}/mkspecs/linux-oe-g++/qmake.conf <> ${S}/mkspecs/linux-oe-g++/qmake.conf <> ${S}/mkspecs/linux-oe-g++/qmake.conf 

[yocto] [meta-raspberrypi][PATCH v3 2/2] layer.conf: avoid to force users to add the qt5 layer because of qtbase bbappend

[John Madieu]

Signed-off-by: John Madieu 
---
 conf/layer.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/conf/layer.conf b/conf/layer.conf
index bea5a65..60f1bcb 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -12,3 +12,7 @@ BBFILE_PRIORITY_raspberrypi = "9"
 # Additional license directories.
 LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"
 
+# Let us add layer-specific (such as qt5-layer) bbappends which
+# are only applied when that layer is included in our configuration
+BBFILES += "${@' '.join('${LAYERDIR}/%s/recipes*/*/*.bbappend' % layer \
+   for layer in BBFILE_COLLECTIONS.split())}"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Mapping root filesystem files back into packages

[Ulf Magnusson]

Hello,

To support an in-house packaging format, we need to partition the root
filesystem into a number of packages (called "internal packages" from
here on to avoid confusion), where each internal package corresponds
to a number of (e.g. IPK) packages.

The way this is currently done is by manually maintaining a database
(implemented as a PACKAGE_CLASSES class) that maps files in the root
filesystem back to packages, along with a list of what packages should
go into each internal package. I suspect it is done this way so that
post-processing steps on the root filesystem will be included in the
internal packages.

To me this feels pretty roundabout, and I suspect that there are much
nicer solutions (suggestions welcome!). What I'm mostly curious about
at the moment though is whether there's some nicer way to map files
from the root filesystem back to packages, without having to maintain
a separate database. Having the method be independent of the package
format (e.g., IPK) would be a bonus, though I'm not sure if it's a
strict requirement.

Cheers,
Ulf
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ipv6 testing

[akuster]

Larry,

On 01/15/2016 10:52 AM, Larry Goss wrote:
> Hi,
> 
> Does Yocto do any IPv6 conformance testing?

AFAIK, the project does not preform conformance testing.

regards,
Armin
> 
> Thanks,
> 
> Larry Goss
> Sr. Field Applications Engineer
> Enea North America
> Email: larry.g...@enea.com
> Phone: (603) 475-1087
> 
> http://www.enea.com/
> 
> 
> This message, including attachments, is CONFIDENTIAL. It may also be 
> privileged or otherwise protected by law. If you received this email by 
> mistake please let us know by reply and then delete it from your system; you 
> should not copy it or disclose its contents to anyone. All messages sent to 
> and from Enea may be monitored to ensure compliance with internal policies 
> and to protect our business. Emails are not secure and cannot be guaranteed 
> to be error free as they can be intercepted, amended, lost or destroyed, or 
> contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of e-mail transmission. Anyone who communicates with us by email accepts 
> these risks.
> 
> 
> 
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Package naming "exceptions" in Yocto

[Reshetova, Elena]

> FYI we do have meta/conf/distro/include/distro_alias.inc which sets
DISTRO_PN_ALIAS for each recipe, which is intended to help map to the names
used in other distros. Will that work?

Yes, I think this is exactly what I was hoping to find! Great that you
already have smth line this in place :)
 Just one question: how is this value supposed to be fetched in a class? I
could not find any usage example through the code. Is it set for each
package automatically or do I need to enable smth?

Best Regards,
Elena.


smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Package naming "exceptions" in Yocto

[Paul Eggleton]

On Mon, 18 Jan 2016 11:14:31 Reshetova, Elena wrote:
> > FYI we do have meta/conf/distro/include/distro_alias.inc which sets
> 
> DISTRO_PN_ALIAS for each recipe, which is intended to help map to the names
> used in other distros. Will that work?
> 
> Yes, I think this is exactly what I was hoping to find! Great that you
> already have smth line this in place :)
>  Just one question: how is this value supposed to be fetched in a class? I
> could not find any usage example through the code. Is it set for each
> package automatically or do I need to enable smth?

create_distro_packages_list() in meta/lib/oe/distro_check.py is the only 
existing code that reads those values that I'm aware of, but that may not be 
in the form that you need it.

One thing you'll definitely need to do is to actually include the file in your 
configuration i.e.:

require conf/distro/include/distro_alias.inc

After that you should just be able to access DISTRO_PN_ALIAS like any other 
recipe-specific variable provided you're doing so in the context of a recipe 
(e.g. within a task for the recipe you wish to query the value for).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [matchbox-keyboard][PATCH] config-parser: Use matching printf format

[Burton, Ross]

On 13 January 2016 at 23:11, Khem Raj  wrote:

> XML_GetCurrentLineNumber() returns unsigned long as clang is telling us
> here
>
> src/config-parser.c:603:6: warning: format specifies type 'int' but the
> argument has type 'XML_Size' (aka 'unsigned long') [-Wformat]
> XML_GetCurrentLineNumber(p),
> ^~~
>
> Signed-off-by: Khem Raj 
>

Merged to matchbox-keyboard 0.1 branch, thanks.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ERROR: QA Issue: FILES in ptest-runner-dbg

[Damodar Sonone]

Hello,

I am trying to build the custom SDK using Yocto Project Jethro 2.0
. I added the recipe
and layer files to support the my SDK.

$ bitbake meta-toolchain

The build fails with following error:

ERROR: QA Issue: FILES in ptest-runner-dbg recipe should not contain the
${D} variable as it references the local build directory not the target
filesystem, best solution is to remove the ${D} reference [expanded-d]
ERROR: QA Issue: FILES in ptest-runner-dbg recipe should not contain the
${D} variable as it references the local build directory not the target
filesystem, best solution is to remove the ${D} reference [expanded-d]
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/ptest-runner/1.0-r0/temp/log.do_package_qa.18936

Any pointers on this will be really helpfull.

Thanks,
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ipv6 testing

[Larry Goss]

Hi,

Does Yocto do any IPv6 conformance testing?

Thanks,

Larry Goss
Sr. Field Applications Engineer
Enea North America
Email: larry.g...@enea.com
Phone: (603) 475-1087

http://www.enea.com/


This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, amended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission. 
Anyone who communicates with us by email accepts these risks.



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Modify the device trees for sama5d35-xplained

[Morgan Guillou]

Thanks Bruce,
It was not exactly what I ran, I ran that:
$ bitbake core-image-minimal -c compile -f
This should rebuild only the kernel as I read in that doc: 
https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf

Sorry, I'm not used with linux, I'm right or not ?

Morgan 

-Message d'origine-
De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Envoyé : vendredi 15 janvier 2016 20:09
À : Morgan Guillou
Cc : linux-yocto@yoctoproject.org
Objet : Re: [linux-yocto] Modify the device trees for sama5d35-xplained

On 16-01-15 02:00 PM, Morgan Guillou wrote:
> Thanks Bruce  for the answer,
> So I did:
> #bitbake -f -c compile core-image-minimal

This should have been your kernel recipe, not the image. Did you typo that ? Or 
is that what you really ran ?

Bruce

> #bitbake core-image-minimal
> It repackaging rootfs.ubi and ubi files, but no dtb files !
> What's wrong ?
>
> -Message d'origine-
> De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Envoyé : vendredi 15 janvier 2016 19:43 À : Morgan Guillou; 
> linux-yocto@yoctoproject.org Objet : Re: [linux-yocto] Modify the 
> device trees for sama5d35-xplained
>
> On 16-01-15 01:24 PM, Morgan Guillou wrote:
>> I've been working with hardware sama5d35-xplained.
>>
>> I used the at91 tutorial to compile and install yocto distribution on 
>> the target, that's fine.
>>
>> My next step is to redefine one interface that is custom to my board, 
>> I want to enable the USART2.
>>
>> I modify the dts file:
>> "/poky/build-atmel/tmp/work-shared/sama5d3-xplained/kernel-source/arch/arm/boot/dts/at91-sama5d3_xplained.dts"
>> to add :
>>
>> usart2: serial@f802{
>>
>> Pinctrl-0 = <_usart2>;
>>
>> Status = "okay":
>>
>> };
>>
>> Maybe I'm just tired, or maybe this is just hard... but the dtb file 
>> is not updated when I run bitbake.
>
> bitbake won't know that you've updated the source. So you'll need to force a 
> re-compile of the kernel, and then rebuild your image.
>
> bitbake -f -c compile 
>
> And then you should see things repackaging next time you build the image.
>
> Bruce
>
>>
>> So do I have to manually compile the dts file or is there some way to 
>> do it via "bitbake core-image-minimal" ?
>>
>> Thanks,
>>
>> Morgan.

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] How do I keep aliases of root profile

[Marius]

Hi
I am still learning about yocto and kernels and the whole process so 
please excuse a silly question.
Because I am still learning, I am re-compiling my BBB image on a regular 
basis as I only want the bare minimum of packages in the image.


Now I have to edit the /etc/profile after every eMMC install in order to 
set my aliases. Where can I set the aliases before running bitbake on my 
image?






-


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Modify the device trees for sama5d35-xplained

[Bruce Ashfield]

On 16-01-18 12:03 PM, Morgan Guillou wrote:

Thanks Bruce,
It was not exactly what I ran, I ran that:
$ bitbake core-image-minimal -c compile -f
This should rebuild only the kernel as I read in that doc: 
https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf

Sorry, I'm not used with linux, I'm right or not ?


You need to force the compile of the kernel package, not the
image type.

So whatever recipe is providing your kernel, that is the name
you should be using.

Bruce



Morgan

-Message d'origine-
De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Envoyé : vendredi 15 janvier 2016 20:09
À : Morgan Guillou
Cc : linux-yocto@yoctoproject.org
Objet : Re: [linux-yocto] Modify the device trees for sama5d35-xplained

On 16-01-15 02:00 PM, Morgan Guillou wrote:

Thanks Bruce  for the answer,
So I did:
#bitbake -f -c compile core-image-minimal


This should have been your kernel recipe, not the image. Did you typo that ? Or 
is that what you really ran ?

Bruce


#bitbake core-image-minimal
It repackaging rootfs.ubi and ubi files, but no dtb files !
What's wrong ?

-Message d'origine-
De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Envoyé : vendredi 15 janvier 2016 19:43 À : Morgan Guillou;
linux-yocto@yoctoproject.org Objet : Re: [linux-yocto] Modify the
device trees for sama5d35-xplained

On 16-01-15 01:24 PM, Morgan Guillou wrote:

I've been working with hardware sama5d35-xplained.

I used the at91 tutorial to compile and install yocto distribution on
the target, that's fine.

My next step is to redefine one interface that is custom to my board,
I want to enable the USART2.

I modify the dts file:
"/poky/build-atmel/tmp/work-shared/sama5d3-xplained/kernel-source/arch/arm/boot/dts/at91-sama5d3_xplained.dts"
to add :

usart2: serial@f802{

Pinctrl-0 = <_usart2>;

Status = "okay":

};

Maybe I'm just tired, or maybe this is just hard... but the dtb file
is not updated when I run bitbake.


bitbake won't know that you've updated the source. So you'll need to force a 
re-compile of the kernel, and then rebuild your image.

bitbake -f -c compile 

And then you should see things repackaging next time you build the image.

Bruce



So do I have to manually compile the dts file or is there some way to
do it via "bitbake core-image-minimal" ?

Thanks,

Morgan.




--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] yocto Digest, Vol 64, Issue 52

[Damodar]

I used the default one.
build_dir/tmp

Thanks

Sent from my iPhone

> On 19-Jan-2016, at 1:30 am, yocto-requ...@yoctoproject.org wrote:
> 
> Send yocto mailing list submissions to
>yocto@yoctoproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
>yocto-requ...@yoctoproject.org
> 
> You can reach the person managing the list at
>yocto-ow...@yoctoproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: ipv6 testing (akuster)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 18 Jan 2016 09:11:11 -0800
> From: akuster 
> To: Larry Goss ,"yocto@yoctoproject.org"
>
> Subject: Re: [yocto] ipv6 testing
> Message-ID: <569d1caf.5000...@mvista.com>
> Content-Type: text/plain; charset=windows-1252
> 
> Larry,
> 
>> On 01/15/2016 10:52 AM, Larry Goss wrote:
>> Hi,
>> 
>> Does Yocto do any IPv6 conformance testing?
> 
> AFAIK, the project does not preform conformance testing.
> 
> regards,
> Armin
>> 
>> Thanks,
>> 
>> Larry Goss
>> Sr. Field Applications Engineer
>> Enea North America
>> Email: larry.g...@enea.com
>> Phone: (603) 475-1087
>> 
>> http://www.enea.com/
>> 
>> 
>> This message, including attachments, is CONFIDENTIAL. It may also be 
>> privileged or otherwise protected by law. If you received this email by 
>> mistake please let us know by reply and then delete it from your system; you 
>> should not copy it or disclose its contents to anyone. All messages sent to 
>> and from Enea may be monitored to ensure compliance with internal policies 
>> and to protect our business. Emails are not secure and cannot be guaranteed 
>> to be error free as they can be intercepted, amended, lost or destroyed, or 
>> contain viruses. The sender therefore does not accept liability for any 
>> errors or omissions in the contents of this message, which arise as a result 
>> of e-mail transmission. Anyone who communicates with us by email accepts 
>> these risks.
> 
> 
> --
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> End of yocto Digest, Vol 64, Issue 52
> *
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Mapping root filesystem files back into packages

[Ulf Magnusson]

On Mon, Jan 18, 2016 at 9:15 PM, Paul Eggleton
 wrote:
> Hi Ulf,
>
> On Mon, 18 Jan 2016 10:56:41 Ulf Magnusson wrote:
>> To support an in-house packaging format, we need to partition the root
>> filesystem into a number of packages (called "internal packages" from
>> here on to avoid confusion), where each internal package corresponds
>> to a number of (e.g. IPK) packages.
>>
>> The way this is currently done is by manually maintaining a database
>> (implemented as a PACKAGE_CLASSES class) that maps files in the root
>> filesystem back to packages, along with a list of what packages should
>> go into each internal package. I suspect it is done this way so that
>> post-processing steps on the root filesystem will be included in the
>> internal packages.
>>
>> To me this feels pretty roundabout, and I suspect that there are much
>> nicer solutions (suggestions welcome!). What I'm mostly curious about
>> at the moment though is whether there's some nicer way to map files
>> from the root filesystem back to packages, without having to maintain
>> a separate database. Having the method be independent of the package
>> format (e.g., IPK) would be a bonus, though I'm not sure if it's a
>> strict requirement.
>
> So, aside from the "internal package" concept, there are two ways to do this:
>
> 1) oe-pkgdata-util find-path - this will tell you the build-time package name
> that provided the specified path within the image (expects a full path,
> wildcards allowed). It also provides some other lookup tools. Note that this
> relies on pkgdata so it'll only work for a particular recipe after that recipe
> has been packaged.
>
> 2) Use the Toaster web UI - it allows you to browse through the image and
> click through from any file back to the package that contained it.
>
> Cheers,
> Paul

Thanks for the hint!

Do you have any suggestions for the other direction as well, i.e.,
mapping packages to files, preferably in a way that's independent of
the packaging format?

I suspect this won't be a problem, but it shouldn't matter whether the
package contents are fetched from the sstate cache or not.

Cheers,
Ulf
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-java] failed to bitbake openjdk-8

[Chang, Rebecca Swee Fun]

Hi all,

I am trying to integrate meta-java into Common BSP. My intention is to 
integrate mraa from meta-intel-iot-devkit and meta-intel-iot-middleware.
MRAA is having dependency on openjdk-8 provided by meta-java.

The poky version that I'm using is Poky on branch Jethro.
meta-java on master branch.

I have this source fetching error when bitbake openjdk-8.
>From the logs, it mentioned the source checksum are mismatched. However, the 
>checksum are the same by manual download using wget.

I have also done modifying the SRC_URI checksum in openjdk-8-release-72b05.inc 
file in meta-java/recipes-core/openjdk.
Cleaned the build directory and rebuild.
But bitbake just doesn't get pass do_fetch stage.

Thanks in advance.

I hereby paste the error logs:

WARNING: Checksum failure encountered with download of 
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false
 - will attempt other sources if available
WARNING: Renaming 
/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2 to 
/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2_bad-checksum_746e4d38fa3d31a22239d160688ed447
ERROR: Fetcher failure for URL: 
'http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false'.
 Checksum mismatch!
File: '/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2' 
has sha256 checksum 
e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99 when 
"e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99" was expected 
If this change is expected (e.g. you have upgraded to a new version without 
updating the checksums) then you can use these lines within the recipe:
SRC_URI[jdk.md5sum] = "746e4d38fa3d31a22239d160688ed447"
SRC_URI[jdk.sha256sum] = 
"e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99"
Otherwise you should retry the download and/or check with upstream to determine 
if the file has become corrupted or otherwise unexpectedly modified.

ERROR: Function failed: Fetcher failure for URL: 
'http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false'.
 Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: 
/home/ilab/development/yocto_build/build/tmp/work/corei7-64-poky-linux/openjdk-8/72b05-r0/temp/log.do_fetch.30297
ERROR: Task 4 
(/home/ilab/development/yocto_build/meta-java/recipes-core/openjdk/openjdk-8_72b05.bb,
 do_fetch) failed with exit code '1'
WARNING: Checksum failure encountered with download of 
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false
 - will attempt other sources if available
WARNING: Renaming 
/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2 to 
/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2_bad-checksum_746e4d38fa3d31a22239d160688ed447
ERROR: Fetcher failure for URL: 
'http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false'.
 Checksum mismatch!
File: '/home/ilab/development/yocto_build/build/downloads/39baa472e20c.tar.bz2' 
has sha256 checksum 
e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99 when 
"e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99" was expected 
If this change is expected (e.g. you have upgraded to a new version without 
updating the checksums) then you can use these lines within the recipe:
SRC_URI[jdk.md5sum] = "746e4d38fa3d31a22239d160688ed447"
SRC_URI[jdk.sha256sum] = 
"e3587fa57eec72c561f0695723649a745966bb2a74803ff8a451b80fd2079f99"
Otherwise you should retry the download and/or check with upstream to determine 
if the file has become corrupted or otherwise unexpectedly modified.

ERROR: Function failed: Fetcher failure for URL: 
'http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/archive/39baa472e20c.tar.bz2;name=jdk;unpack=false'.
 Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: 
/home/ilab/development/yocto_build/build/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_fetch.30299
ERROR: Task 130 
(/home/ilab/development/yocto_build/meta-java/recipes-core/openjdk/openjdk-8-native_72b05.bb,
 do_fetch) failed with exit code '1'

Regards,
Rebecca
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Mapping root filesystem files back into packages

[Paul Eggleton]

Hi Ulf,

On Mon, 18 Jan 2016 10:56:41 Ulf Magnusson wrote:
> To support an in-house packaging format, we need to partition the root
> filesystem into a number of packages (called "internal packages" from
> here on to avoid confusion), where each internal package corresponds
> to a number of (e.g. IPK) packages.
> 
> The way this is currently done is by manually maintaining a database
> (implemented as a PACKAGE_CLASSES class) that maps files in the root
> filesystem back to packages, along with a list of what packages should
> go into each internal package. I suspect it is done this way so that
> post-processing steps on the root filesystem will be included in the
> internal packages.
> 
> To me this feels pretty roundabout, and I suspect that there are much
> nicer solutions (suggestions welcome!). What I'm mostly curious about
> at the moment though is whether there's some nicer way to map files
> from the root filesystem back to packages, without having to maintain
> a separate database. Having the method be independent of the package
> format (e.g., IPK) would be a bonus, though I'm not sure if it's a
> strict requirement.

So, aside from the "internal package" concept, there are two ways to do this:

1) oe-pkgdata-util find-path - this will tell you the build-time package name 
that provided the specified path within the image (expects a full path, 
wildcards allowed). It also provides some other lookup tools. Note that this 
relies on pkgdata so it'll only work for a particular recipe after that recipe 
has been packaged.

2) Use the Toaster web UI - it allows you to browse through the image and 
click through from any file back to the package that contained it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Modify the device trees for sama5d35-xplained

[Morgan Guillou]

So this should be : meta-atmel/recipes-bsp
I'll try 

De : Bruce Ashfield [bruce.ashfi...@windriver.com]
Envoyé : lundi 18 janvier 2016 20:41
À : Morgan Guillou
Cc : linux-yocto@yoctoproject.org
Objet : Re: [linux-yocto] Modify the device trees for sama5d35-xplained

On 16-01-18 12:03 PM, Morgan Guillou wrote:
> Thanks Bruce,
> It was not exactly what I ran, I ran that:
> $ bitbake core-image-minimal -c compile -f
> This should rebuild only the kernel as I read in that doc: 
> https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf
>
> Sorry, I'm not used with linux, I'm right or not ?

You need to force the compile of the kernel package, not the
image type.

So whatever recipe is providing your kernel, that is the name
you should be using.

Bruce

>
> Morgan
>
> -Message d'origine-
> De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Envoyé : vendredi 15 janvier 2016 20:09
> À : Morgan Guillou
> Cc : linux-yocto@yoctoproject.org
> Objet : Re: [linux-yocto] Modify the device trees for sama5d35-xplained
>
> On 16-01-15 02:00 PM, Morgan Guillou wrote:
>> Thanks Bruce  for the answer,
>> So I did:
>> #bitbake -f -c compile core-image-minimal
>
> This should have been your kernel recipe, not the image. Did you typo that ? 
> Or is that what you really ran ?
>
> Bruce
>
>> #bitbake core-image-minimal
>> It repackaging rootfs.ubi and ubi files, but no dtb files !
>> What's wrong ?
>>
>> -Message d'origine-
>> De : Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Envoyé : vendredi 15 janvier 2016 19:43 À : Morgan Guillou;
>> linux-yocto@yoctoproject.org Objet : Re: [linux-yocto] Modify the
>> device trees for sama5d35-xplained
>>
>> On 16-01-15 01:24 PM, Morgan Guillou wrote:
>>> I've been working with hardware sama5d35-xplained.
>>>
>>> I used the at91 tutorial to compile and install yocto distribution on
>>> the target, that's fine.
>>>
>>> My next step is to redefine one interface that is custom to my board,
>>> I want to enable the USART2.
>>>
>>> I modify the dts file:
>>> "/poky/build-atmel/tmp/work-shared/sama5d3-xplained/kernel-source/arch/arm/boot/dts/at91-sama5d3_xplained.dts"
>>> to add :
>>>
>>> usart2: serial@f802{
>>>
>>> Pinctrl-0 = <_usart2>;
>>>
>>> Status = "okay":
>>>
>>> };
>>>
>>> Maybe I'm just tired, or maybe this is just hard... but the dtb file
>>> is not updated when I run bitbake.
>>
>> bitbake won't know that you've updated the source. So you'll need to force a 
>> re-compile of the kernel, and then rebuild your image.
>>
>> bitbake -f -c compile 
>>
>> And then you should see things repackaging next time you build the image.
>>
>> Bruce
>>
>>>
>>> So do I have to manually compile the dts file or is there some way to
>>> do it via "bitbake core-image-minimal" ?
>>>
>>> Thanks,
>>>
>>> Morgan.
>

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] ERROR: QA Issue: FILES in ptest-runner-dbg

[Paul Eggleton]

On Mon, 18 Jan 2016 17:43:32 Damodar Sonone wrote:
> I am trying to build the custom SDK using Yocto Project Jethro 2.0
> . I added the recipe
> and layer files to support the my SDK.
> 
> $ bitbake meta-toolchain
> 
> The build fails with following error:
> 
> ERROR: QA Issue: FILES in ptest-runner-dbg recipe should not contain the
> ${D} variable as it references the local build directory not the target
> filesystem, best solution is to remove the ${D} reference [expanded-d]
> ERROR: QA Issue: FILES in ptest-runner-dbg recipe should not contain the
> ${D} variable as it references the local build directory not the target
> filesystem, best solution is to remove the ${D} reference [expanded-d]
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /ptest-runner/1.0-r0/temp/log.do_package_qa.18936
> 
> Any pointers on this will be really helpfull.

What TMPDIR path have you set in your configuration (i.e. in conf/local.conf)?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [poky][PATCH] poky.conf: Delete BB_SIGNATURE_HANDLER settings

[Khem Raj]

'OEBasicHash' is default in OE-Core, this setting can be leverages from
core defaults

Signed-off-by: Khem Raj 
---
 meta-yocto/conf/distro/poky.conf | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index e62ad4d..39419d5 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -85,9 +85,6 @@ SANITY_TESTED_DISTROS ?= " \
 Debian-8.* \n \
 openSUSE-project-13.2 \n \
 "
-
-# Default hash policy for distro
-BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
 #
 # OELAYOUT_ABI allows us to notify users when the format of TMPDIR changes in 
 # an incompatible way. Such changes should usually be detailed in the commit
-- 
2.7.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto