[yocto] Moving to Yocto 2.3 - recipe-specific sysroots - improving the documentation

[CHMIELARZ Radoslaw]

Hi all,

I think the documentation on migrating between Yocto 2.2 and 2.3 needs more 
clarification as to how did the sysroots have changed.

I wanted to migrate our build system from 2.2 to 2.5 and one package in 
particular has caused me a day worth of scratching my head and trying different 
ideas.
We have a custom recipe for openssh-server which among other things had a line:
EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR}/${MACHINE}/usr/local/openssl-1.0"

This is due the fact that openssl-1.0 is being installed to 
/usr/local/openssl-1.0.

Now when trying to migrate I have noticed that STAGING_DIR is not populated any 
more and this is clearly explained by the documentation. What is not explained 
however is how to get the files from other recipes. The documentation simply 
states that each recipe has its own staging directory. Hence what I have tried 
to is steer this directory to the staging directory of openssl-1.0.

Of course the real solution is that openssh-server recipe installs header files 
of all packages in DEPENDS into openssh-server STAGING_DIR_TARGET (in my case, 
could be other STAGING_* directories apart from STAGING_DIR which is empty 
right now) and the simple solution was to change the above line to:
EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR_TARGET}/usr/local/openssl-1.0"

And thus to save other people time I think it would be best to add another 
point to the documentation 
(https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#migration-2.3-recipe-specific-sysroots)
"Consider the following:
[..]

  *   Examine the recipes that use STAGING_DIR: STAGING_DIR is a shared 
directory not populated any more. Instead if You want to use files from another 
recipe in Your recipe include that recipe in DEPENDS variable which will copy 
the files from another recipe into Your recipe's staging directories. Now You 
can refer to those files using STAGING_DIR* pointing to Your recipe's staging 
directories. For example instead of:
EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR}/${MACHINE}/usr/local/openssl-1.0"
Write the following:
   DEPENDS += "openssl-1.0"
EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR_TARGET}/usr/local/openssl-1.0"
"

Of course this can be made more general and a precaution could be added that 
this is taken care of by most of the packages. Maybe in my case it could also 
be changed to be automatic but this I haven't yet explored.

Cheers,
Radek Chmielarz
Leica Geosystems AG
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] include own script

[Zolee K]

Hi All,


Could you help me out with this? I've been experimenting with this without
success, some of you have given me suggestions but neither of them worked
yet.

###

/recipes-z/testing$ cat testscript.bb
DESCRIPTION = "test script"
LICENSE = "Zoli"

SRC_URI = "file://testscript"

SRC_URI[md5sum] = "e51375ed8c617ea7a6ac39b81c757e39"

FILESEXTRAPATHS_prepend := "${THISDIR}/file:"

S= "${WORKDIR}"

do_install() {
install -d ${D}${bindir}
install -m 0770 testscript ${D}${bindir}
}

#

recipes-z/testing$ cat files/testscript
#!/bin/sh

echo "hello world"



ERROR: testscript-1.0-r0 do_populate_lic: Fatal QA errors found, failing
task.
ERROR: testscript-1.0-r0 do_populate_lic: Function failed:
populate_lic_qa_checksum
ERROR: Logfile of failure stored in:
/home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/testscript/1.0-r0/temp/log.do_populate_lic.4044
ERROR: Task (/home//recipes-z/testing/testscript.bb:do_populate_lic)
failed with exit code '1'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] include own script

[ChenQi]

On 10/30/2018 04:42 PM, Zolee K wrote:

Hi All,


Could you help me out with this? I've been experimenting with this 
without success, some of you have given me suggestions but neither of 
them worked yet.


###

/recipes-z/testing$ cat testscript.bb 
DESCRIPTION = "test script"
LICENSE = "Zoli"

SRC_URI = "file://testscript"

SRC_URI[md5sum] = "e51375ed8c617ea7a6ac39b81c757e39"

FILESEXTRAPATHS_prepend := "${THISDIR}/file:"

S= "${WORKDIR}"

do_install() {
install -d ${D}${bindir}
install -m 0770 testscript ${D}${bindir}
}

#

recipes-z/testing$ cat files/testscript
#!/bin/sh

echo "hello world"



ERROR: testscript-1.0-r0 do_populate_lic: Fatal QA errors found, 
failing task.
ERROR: testscript-1.0-r0 do_populate_lic: Function failed: 
populate_lic_qa_checksum
ERROR: Logfile of failure stored in: 
/home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/testscript/1.0-r0/temp/log.do_populate_lic.4044
ERROR: Task 
(/home//recipes-z/testing/testscript.bb:do_populate_lic) failed 
with exit code '1'




I guess the problem is about LIC_FILES_CHKSUM. Your LICENSE is set to 
'Zoli'. So where do you put your Zoli license and what's the checksum of 
it? How about using the following two lines if you do not care about 
license?


LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

Best Regards,

Chen Qi

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

[yocto] do_unpack: already exists and is not an empty directory

[Tomasz Dziendzielski]

Hi,
in some recipes that fetches git repository and has S variable set to
"${WORKDIR}/git/foo" once per many builds we're having error:

fatal: destination path
'foobar/work/x86_64-linux/squashfs-tools-native/4.2-r2/git' already
exists and is not an empty directory.

It happens for squashfs-tools-native, vim-native (and maybe more of
them but we didn't find it yet).

I think this happens because of the race condition.

If the S = "${WORKDIR}/git/foo" and B=${S}, then during do_unpack in
parallel the ${B} directory is created and git repository is extracted
to the place where ${B} directory already exists.

Is this issue known?

Best regards,

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

Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure

[Burton, Ross]

On Tue, 30 Oct 2018 at 03:05, Joe Flowers  wrote:
> Below is the output you requested.  gdk-x11-3.0.pc does not seem to exist.
>
> Below, should that be "wandboard" and not "qemux86" ?
>
> joe@ubuntu:/opt/yocto/build$
> joe@ubuntu:/opt/yocto/build$ oe-pkgdata-util find-path '*/gdk-x11-3.0.pc'
> ERROR: Unable to find pkgdata directory /opt/yocto/build/tmp/pkgdata/qemux86
> joe@ubuntu:/opt/yocto/build$ cd ..
> joe@ubuntu:/opt/yocto$ oe-pkgdata-util find-path '*/gdk-x11-3.0.pc'
> ERROR: Unable to find pkgdata directory /opt/yocto/build/tmp/pkgdata/qemux86
> joe@ubuntu:/opt/yocto$
> joe@ubuntu:/opt/yocto$
> joe@ubuntu:/opt/yocto$ find /opt/yocto -name *.pc* 1> ~/find4.txt 2>/dev/null
> joe@ubuntu:/opt/yocto$ cat ~/find4.txt | grep gdk | grep x11
> joe@ubuntu:/opt/yocto$

Yes, the pkgdata directory should be wandaboard but you haven't set
that in local.conf (you should), you've been setting it in the
environment so you need to set it in the environment when calling
oe-pkgdata-util (this is why you should set it in local.conf).

Was this after building gtk+3? If I'm reading your build paths
correctly, what is the content of
/opt/yocto/build/tmp/sysroots-components/cortexa9hf-neon-poky-linux-gnueabi/gtk+3/usr/lib/pkgconfig/

Any file on the host isn't what we're after, they're not used in cross
compilation.

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

Re: [yocto] [meta-selinux][sumo][PATCH 1/7] layer.conf: update LAYERSERIES_COMPAT `sumo' -> `thud'

[Joe MacDonald]

The patch set is definitely confusing.  I'm not able to access
git.yoctoproject.org at the moment, so I've pushed all three proposed
branch updates to my fork on github.  I think that's a more useful way to
review these changes anyway:

https://github.com/joeythesaint/meta-selinux/tree/jjm/master
https://github.com/joeythesaint/meta-selinux/tree/jjm/sumo
https://github.com/joeythesaint/meta-selinux/tree/jjm/thud

-J.


On Mon, Oct 29, 2018 at 3:16 PM akuster  wrote:

>
> On 10/29/18 11:32 AM, Joe MacDonald wrote:
> > From: Hongxu Jia 
> >
> > Since `9ec5a8a layer.conf: Drop sumo from LAYERSERIES_CORENAMES' and
> > `9867924 layer.conf: Add thud to LAYERSERIES_CORENAMES' applied in
> oe-core,
> > update LAYERSERIES_COMPAT `sumo' -> `thud'
>
> the subject branch and change confuse me. Shouldn't his be for "Thud"?
>
> - armin
>
> >
> > Signed-off-by: Hongxu Jia 
> > Signed-off-by: Joe MacDonald 
> > ---
> >  conf/layer.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/conf/layer.conf b/conf/layer.conf
> > index 0f9ea41..5fecac6 100644
> > --- a/conf/layer.conf
> > +++ b/conf/layer.conf
> > @@ -18,7 +18,7 @@ BBFILE_PRIORITY_selinux = "5"
> >  # cause compatibility issues with other layers
> >  LAYERVERSION_selinux = "1"
> >
> > -LAYERSERIES_COMPAT_selinux = "sumo"
> > +LAYERSERIES_COMPAT_selinux = "thud"
> >
> >  LAYERDEPENDS_selinux = " \
> >  core \
>


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

[yocto] busybox build failure

[Matthew Singer]

I turned on syslog in busybox via its menu config and the build now fails
with the following error


ERROR: busybox-1.24.1-r0 do_package: QA Issue: busybox: Files/directories
were installed but not shipped in any package:
  /lib
  /lib/systemd
  /lib/systemd/system
  /lib/systemd/system/busybox-syslog.service
Please set FILES such that these items are packaged. Alternatively if they
are unneeded, avoid installing them or delete them within do_install.
busybox: 4 installed and not shipped files. [installed-vs-shipped]
ERROR: busybox-1.24.1-r0 do_package: Fatal QA errors found, failing task.
ERROR: busybox-1.24.1-r0 do_package: Function failed: do_package
ERROR: Logfile of failure stored in:
/home/keyw/projects/phytec/yocto/build/tmp/work/cortexa9hf-neon-phytec-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.15516
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Moving to Yocto 2.3 - recipe-specific sysroots - improving the documentation

[Uwe Geuder]

On Tue, Oct 30, 2018 at 9:05 AM CHMIELARZ Radoslaw 
radoslaw.chmielarz-at-leica-geosystems.com wrote:
>
> Hi all,
>
>  
>
> I think the documentation on migrating between Yocto 2.2 and 2.3 needs
> more clarification as to how did the sysroots have changed.
>
[...]
>  
>
> Now when trying to migrate I have noticed that STAGING_DIR is not
> populated any more and this is clearly explained by the
> documentation. What is not explained however is how to get the files
> from other recipes. The documentation simply states that each recipe
> has its own staging directory.
[...]

Have you seen this chapter?

https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#new-sharing-files-between-recipes

(well, that's not 2.3 but the newest one, but I am not aware that
anything significant has changed once more)

The headline promises to answer the question, but at least I don't fully
follow the explanations. They are talking about *the* sysroot. As we
know sysroots are recipe-specifc now. So if we are talking about sharing
files between recipes, we have an "exporting" recipe and an "importing"
recipe, so at least in theory 2 sysroots could be involved. From the
text in the manual I do not understand which one they mean and what they
try to explain.

So yes, I agree that the documentation should be clarified. Unfortunatly
I am not in the situation to suggest the solution.

Regards,

Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gexder at neuroeventlabs.com (Bot check: fix one obvious typo)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [selinux] sumo compilation

[Sinan Kaya]

On 10/24/2018 7:49 PM, Joe MacDonald wrote:

Hey all,

I just thought I should quickly follow up on this.  I have a change set
ready that includes tagging and a minor tweak for sumo, integration of
the current outstanding patch list and a tag for thud and a couple of
additional things (possibly) for post-thud.  I'll send out a set for
sumo and maybe an additional one for thud/post- possibly tomorrow or
after I get home on Friday.


Thanks, we are looking forward to see it on yocto.



-J.


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

[yocto] Yocto and Debian package repositories

[Mauro Ziliani]

Hi all.

I often work with Debian and I build my own repository accessible with apt.

I look that when I build the image recipe many deb pacakages are
produced with Packages and Release ready.

How can I use this pakcages to upload all packages to a Debian customer
server?

Best regards,

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

[yocto] Yocto Project Status WW44’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M4 is in QA.

Next Deadline: YP 2.6 M4 Release Target was Oct. 26, 2018


SWAT Team Rotation:

· SWAT lead is currently: Tracy

· SWAT team rotation: Tracy -> Chen on Nov. 2, 2018

· SWAT team rotation: Chen  -> Armin on Nov. 9, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· YP 2.6 M4 rc1 is in QA.  It is just getting set up, but status will 
show at https://wiki.yoctoproject.org/wiki/2.6_QA_Status when progress begins.

· YP 2.6 rc1 was delayed significantly in order to sort out various QA 
test logging pieces with a view to being better able to maintain the release 
through its “stable series” period going forward with the loss of some of the 
existing QA processes and manpower.

· There were many interesting discussions at ELC-E in Edinburgh and it 
was great to see everyone who stopped by the booth, participated at the BoF, 
attended OEDEM, helped with the Yocto Project Dev Day  and/or otherwise helped 
out with the project.

· Richard Purdie attended the Automated Test Summit on behalf of the 
Yocto Project and represented the project’s tool and techniques there (e.g. 
ptest), it was productive and good to see more interest and collaboration 
around automated testing.

· We’re starting to see patches being submitted for master but these 
will continue to be a secondary priority until 2.6 is released.


Planned Releases for YP 2.6:

· YP 2.6 M4 Build is in QA

· YP 2.6 M4 Release Target was Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.

· YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.


Tracking Metrics:

· WDD 2367 (last week 2387) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1690 (last week 1690)

oPercentage of patches in the Pending State: 739 (44%) [last week 738 (44%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

[yocto] Fetcher failure on mpfr 4.0.1

[Gunnar Andersson]

I'm right now seeing a fetcher failure on mpfr-4.0.1.tar.xz

As far as mirrors I believe we rely on this through the inclusion of
poky.conf?

http://downloads.yoctoproject.org/mirror/sources/

but we also add our own (PRE)MIRRORS in the conf files.  Regardless of the
project, it's not enough to rely on an external source.  But unfortunately I
found our own mirror was out-of-date and not updated and I have to look into
what's needed to fix.  (Our build agents generally cache the sources locally
 on disk as well, so that's why the network mirror is rarely hit.)

Now, looking at yoctoproject downloads above, the mpfr-4.0.1 tarball seems
missing there too.  This led me to two questions:

1.  First, is there a point to posting fetcher failures to this list or is
that just noise?

2. Nonetheless it led me ask what the normal situation is for updating the
yoctoproject.org mirror?  Maybe it's deliberately not done for the latest
master, only for released versions?  (Although thud branch now exists...)

Just for reference, looks like the mpfr recipe was updated on poky
master/thud at:

470327eb1f5 (Khem Raj 2018-08-15)

Best Regards
- Gunnar


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

[yocto] Help with Nano Recipe

[nick]

Greetings All, 
I am trying to get the below recipe to build:
SUMMARY = "Recipe to build the 'nano' editor"

PN = "nano"
PV = "2.2.6"
LICENSE="GPLv3"

SITE = "http://www.nano-editor.org/dist";
PV_MAJOR = "${@d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${@d.getVar('PV',d,1).split('.')[1]}"
LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"

SRC_URI = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/${PN}-${PV}.tar.gz"
SRC_URI[md5sum] = "03233ae480689a008eb98feb1b599807"
SRC_URI[sha256sum] = \
"be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a"
LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949


python do_fetch() {
bb.plain("Downloading source tarball from ${SRC_URI} ...")
src_uri = (d.getVar('SRC_URI', True) or "").split()
if len(src_uri) == 0:
   bb.fatal("Empty URI")
try:
   fetcher = bb.fetch2.Fetch(src_uri, d)
   fetcher.download()
except bb.fetch2.BBFetchException:
   bb.fatal("Could not fetch source tarball.")
bb.plain("Download successful.")
}

addtask fetch before do_build

python do_unpack() {
bb.plain("Unpacking source tarball ...")
os.system("tar x -C ${WORKDIR} -f ${DL_DIR}/${P}.tar.gz")
bb.plain("Unpacked source tarball.")
}

addtask unpack before do_build after do_fetch

python do_configure() {
bb.plain("Configuring source package ...")
os.system("cd ${WORKDIR}/${P} && ./configure")
bb.plain("Configured source package.")
}

addtask configure before do_build after do_unpack

python do_compile() {
bb.plain("Compiling package...")
os.system("cd ${WORKDIR}/${P} && make")
bb.plain("Compiled package.")
}

addtask compile before do_build after do_configure

do_clean[nostamp] = "1"
do_clean() {
rm -rf ${WORKDIR}/${P}
rm -f ${TMPDIR}/stamps/*
}

addtask clean

And am working why this error is occuring:
ERROR: ParseError at /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb:15: 
unparsed line: 'LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949' 

I looked through the logs already and it was reported but only changed the file 
number seemed to change it. I am wondering if there is a better
solution or why that's a bad CHSUM variable according to bitbake.

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

Re: [yocto] Help with Nano Recipe

[Nicolas Dechesne]

On Tue, Oct 30, 2018 at 5:38 PM nick  wrote:
>
> Greetings All,
> I am trying to get the below recipe to build:
> SUMMARY = "Recipe to build the 'nano' editor"
>
> PN = "nano"
> PV = "2.2.6"
> LICENSE="GPLv3"
>
> SITE = "http://www.nano-editor.org/dist";
> PV_MAJOR = "${@d.getVar('PV',d,1).split('.')[0]}"
> PV_MINOR = "${@d.getVar('PV',d,1).split('.')[1]}"
> LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
>
> SRC_URI = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/${PN}-${PV}.tar.gz"
> SRC_URI[md5sum] = "03233ae480689a008eb98feb1b599807"
> SRC_URI[sha256sum] = \
> "be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a"
> LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949

You are missing a quote at the end.

>
>
> python do_fetch() {
> bb.plain("Downloading source tarball from ${SRC_URI} ...")
> src_uri = (d.getVar('SRC_URI', True) or "").split()
> if len(src_uri) == 0:
>bb.fatal("Empty URI")
> try:
>fetcher = bb.fetch2.Fetch(src_uri, d)
>fetcher.download()
> except bb.fetch2.BBFetchException:
>bb.fatal("Could not fetch source tarball.")
> bb.plain("Download successful.")
> }

It is very unusual to implement a recipe this way , and you should
rely on base classes to do that for you. For reference there is a
recipe for 'nano' in meta-oe already.

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/nano/nano_3.0.bb?h=master

>
> addtask fetch before do_build
>
> python do_unpack() {
> bb.plain("Unpacking source tarball ...")
> os.system("tar x -C ${WORKDIR} -f ${DL_DIR}/${P}.tar.gz")
> bb.plain("Unpacked source tarball.")
> }
>
> addtask unpack before do_build after do_fetch
>
> python do_configure() {
> bb.plain("Configuring source package ...")
> os.system("cd ${WORKDIR}/${P} && ./configure")
> bb.plain("Configured source package.")
> }
>
> addtask configure before do_build after do_unpack
>
> python do_compile() {
> bb.plain("Compiling package...")
> os.system("cd ${WORKDIR}/${P} && make")
> bb.plain("Compiled package.")
> }
>
> addtask compile before do_build after do_configure
>
> do_clean[nostamp] = "1"
> do_clean() {
> rm -rf ${WORKDIR}/${P}
> rm -f ${TMPDIR}/stamps/*
> }
>
> addtask clean
>
> And am working why this error is occuring:
> ERROR: ParseError at /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb:15: 
> unparsed line: 'LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949'
>
> I looked through the logs already and it was reported but only changed the 
> file number seemed to change it. I am wondering if there is a better
> solution or why that's a bad CHSUM variable according to bitbake.
>
> Thanks,
> Nick
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to update YP kernel image (run-time)

[Raymond Yeung]

Let's say I've a working run-time system running 2016 April release (Krogoth) 
Poky image.  I've it installed previously from a USB thumb drive onto a much 
bigger SSD with all partitions setup.  I don't need to change the partition 
from here onward.

Is there an easy way to replace it with, say 2017 Oct release (Rocko) Poky 
image (and vice versa)?  E.g. by replacing just one file (e.g. bzImage)?  Or is 
there a script that would take care of it?  What happens to all the existing 
directories, e.g. /etc, /bin etc.?

I've been trying to adapt init_install.sh under 
poky/meta/recipes-core/initrdScripts/files, but it seems to assume I've a 
separate device (like USB drive).

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

Re: [yocto] How to update YP kernel image (run-time)

[Kosta Zertsekel]

On Tuesday, 30 October 2018 4:23 Raymond Yeung wrote:
> Let's say I've a working run-time system running 2016 April release (Krogoth) 
> Poky image.
> I've it installed previously from a USB thumb drive onto a much bigger SSD 
> with all partitions setup.
> I don't need to change the partition from here onward.
> Is there an easy way to replace it with, say 2017 Oct release (Rocko) Poky 
> image (and vice versa)?
> E.g. by replacing just one file (e.g. bzImage)?
> Or is there a script that would take care of it?
> What happens to all the existing directories, e.g. /etc, /bin etc.?

The question has no connection to a specific Yocto release at all.
If I rephrase the question it becomes "How do I upgrade my Linux system at 
all?".
Take a look at ResinOS partition scheme here:
https://www.balena.io/docs/reference/OS/overview/2.x/#image-partition-layout
May be it can shed a bit of a light.

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

Re: [yocto] Help with Nano Recipe

[Kosta Zertsekel]

> It is very unusual to implement a recipe this way , and you should
> rely on base classes to do that for you. For reference there is a
> recipe for 'nano' in meta-oe already.
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/nano/nano_3.0.bb?h=master

And if you find anything amiss in this ``nano_3.0.bb`` recipe, you should have 
definitely begun with ``devtool``.
For example:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-devtool-in-your-sdk-workflow

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

Re: [yocto] How to update YP kernel image (run-time)

[Stefano Babic]

On 30/10/18 03:23, Raymond Yeung wrote:
> Let's say I've a working run-time system running 2016 April release
> (Krogoth) Poky image.  I've it installed previously from a USB thumb
> drive onto a much bigger SSD with all partitions setup.  I don't need to
> change the partition from here onward.
> 
> Is there an easy way to replace it with, say 2017 Oct release (Rocko)
> Poky image (and vice versa)?  E.g. by replacing just one file (e.g.
> bzImage)?  Or is there a script that would take care of it?  What
> happens to all the existing directories, e.g. /etc, /bin etc.?

You get an overview about Yocto's updater at:

https://wiki.yoctoproject.org/wiki/System_Update

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] busybox build failure

[Andre McCurdy]

On Tue, Oct 30, 2018 at 5:49 AM Matthew Singer  wrote:
>
> I turned on syslog in busybox via its menu config and the build now fails 
> with the following error

The correct way to turn on syslog in busybox is to ensure that
"file://syslog.cfg" is included in SRC_URI.

However, it looks like it's included by default so in your case you
may need to find and disable a custom local .bbappend etc which is
removing it?

In general, if a busybox config fragment exists for a particular
feature then it should be used (added or removed from SRC_URI) to
enable or disable that feature. Manually editing the busybox config
should be reserved for features which don't have their own config
fragment.

> ERROR: busybox-1.24.1-r0 do_package: QA Issue: busybox: Files/directories 
> were installed but not shipped in any package:
>   /lib
>   /lib/systemd
>   /lib/systemd/system
>   /lib/systemd/system/busybox-syslog.service
> Please set FILES such that these items are packaged. Alternatively if they 
> are unneeded, avoid installing them or delete them within do_install.
> busybox: 4 installed and not shipped files. [installed-vs-shipped]
> ERROR: busybox-1.24.1-r0 do_package: Fatal QA errors found, failing task.
> ERROR: busybox-1.24.1-r0 do_package: Function failed: do_package
> ERROR: Logfile of failure stored in: 
> /home/keyw/projects/phytec/yocto/build/tmp/work/cortexa9hf-neon-phytec-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.15516
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Moving to Yocto 2.3 - recipe-specific sysroots - improving the documentation

[Khem Raj]

On Tue, Oct 30, 2018 at 1:06 AM CHMIELARZ Radoslaw
 wrote:
>
> Hi all,
>
>
>
> I think the documentation on migrating between Yocto 2.2 and 2.3 needs more 
> clarification as to how did the sysroots have changed.
>
>
>
> I wanted to migrate our build system from 2.2 to 2.5 and one package in 
> particular has caused me a day worth of scratching my head and trying 
> different ideas.
>
> We have a custom recipe for openssh-server which among other things had a 
> line:
>
> EXTRA_OECONF += 
> "--with-ssl-dir=${STAGING_DIR}/${MACHINE}/usr/local/openssl-1.0"
>
>
>
> This is due the fact that openssl-1.0 is being installed to 
> /usr/local/openssl-1.0.
>
>
>
> Now when trying to migrate I have noticed that STAGING_DIR is not populated 
> any more and this is clearly explained by the documentation. What is not 
> explained however is how to get the files from other recipes. The 
> documentation simply states that each recipe has its own staging directory. 
> Hence what I have tried to is steer this directory to the staging directory 
> of openssl-1.0.
>
>
>
> Of course the real solution is that openssh-server recipe installs header 
> files of all packages in DEPENDS into openssh-server STAGING_DIR_TARGET (in 
> my case, could be other STAGING_* directories apart from STAGING_DIR which is 
> empty right now) and the simple solution was to change the above line to:
>
> EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR_TARGET}/usr/local/openssl-1.0"
>
>
>
> And thus to save other people time I think it would be best to add another 
> point to the documentation 
> (https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#migration-2.3-recipe-specific-sysroots)
>
> “Consider the following:
>
> [..]
>
> Examine the recipes that use STAGING_DIR: STAGING_DIR is a shared directory 
> not populated any more. Instead if You want to use files from another recipe 
> in Your recipe include that recipe in DEPENDS variable which will copy the 
> files from another recipe into Your recipe’s staging directories. Now You can 
> refer to those files using STAGING_DIR* pointing to Your recipe’s staging 
> directories. For example instead of:
>
> EXTRA_OECONF += 
> "--with-ssl-dir=${STAGING_DIR}/${MACHINE}/usr/local/openssl-1.0"
>
> Write the following:
>
>DEPENDS += “openssl-1.0”
>
> EXTRA_OECONF += "--with-ssl-dir=${STAGING_DIR_TARGET}/usr/local/openssl-1.0"
>
> “
>
>
>
> Of course this can be made more general and a precaution could be added that 
> this is taken care of by most of the packages. Maybe in my case it could also 
> be changed to be automatic but this I haven’t yet explored.

Thanks for this and I think it would be good if you are willing to add
it to How do I section of wiki here
https://wiki.yoctoproject.org/wiki/How_do_I


>
>
>
> Cheers,
>
> Radek Chmielarz
>
> Leica Geosystems AG
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] qemu and grub

[Dimitris Tassopoulos]

Hi all.

Usually I have a small x86_64 board that I test images. But for the first
time I've tried to use yocto to do some development on grub. I've used
qemu to do grub development before and I know that this works fine. I
just use grub-mkrescue to create images with my grub script and then
boot.

Now I've tried to do the same with yocto after setting these to local.conf

MACHINE ??= "qemux86"
IMAGE_FSTYPES += " wic wic.vmdk"
WKS_FILE ?= "directdisk-multi-rootfs.wks"
IMAGE_INSTALL_append = " grub-efi"

In my wks file I've set:
part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk
sda --label boot --active --align 1024
part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align
1024
part /rescue --source rootfs --ondisk sda --fstype=ext4 --label secondary
--align 1024

bootloader --ptable gpt --timeout=10 --append="rootwait rootfstype=ext4
video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"

So, the problem is that the resulting images are using syslinux instead of
grub and also the runqemu doesn't work with the produced images and
complains the some of the parameters of the architecture is wrong.

Any ideas?

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

Re: [yocto] Yocto and Debian package repositories

[Khem Raj]

On Tue, Oct 30, 2018 at 8:14 AM Mauro Ziliani  wrote:
>
> Hi all.
>
> I often work with Debian and I build my own repository accessible with apt.
>
> I look that when I build the image recipe many deb pacakages are
> produced with Packages and Release ready.
>
> How can I use this pakcages to upload all packages to a Debian customer
> server?

So I am assuming you are thinking of installing these .debs onto a
debian base target
if so then its not quite the right direction. with OE build system we
can generate output packages
as ipks, rpms, debs and tarballs, its just another output format but
is not meant to be consumed
on rpm-like or deb-like linux systems which are built using non-OE
distros, because packages have
dependencies and sometimes version specific dependencies which may not
match between two ecosystems.

>
> Best regards,
>
>   MZ
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.6 migration guide

[Scott Rifenbark]

Paul,

Thanks for sending.

Contributors

I have an initial section at
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
which is based on Richard's input.  I am sure there are more items.

Thanks,
Scott

On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton 
wrote:

> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu and grub

[Mittal, Anuj]

On Tue, 2018-10-30 at 22:14 +0100, Dimitris Tassopoulos wrote:
> Hi all.
> 
> Usually I have a small x86_64 board that I test images. But for the
> first
> time I've tried to use yocto to do some development on grub. I've
> used
> qemu to do grub development before and I know that this works fine. I
> just use grub-mkrescue to create images with my grub script and then
> boot.
> 
> Now I've tried to do the same with yocto after setting these to
> local.conf
> 
> MACHINE ??= "qemux86"
> IMAGE_FSTYPES += " wic wic.vmdk"
> WKS_FILE ?= "directdisk-multi-rootfs.wks"
> IMAGE_INSTALL_append = " grub-efi"

Can you check if MACHINE_FEATURES includes efi and include and try
again if not?

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