Re: [yocto] How to replace an arch*.inc file?

[Paul D. DeRocco]

> > On Sat, May 27, 2017 at 2:34 AM, Paul D. DeRocco 
> >  wrote:
> > 
> > I'd like to try the Linaro version of arch-armv8.inc in 
> > an RPi3 project,
> > because it has an ilp32 tune option. What's the correct 
> > way to incorporate this?

> From: Andrei Gherzan [mailto:and...@gherzan.ro] 
> 
> Probably the easiest way would be to create a new machine 
> configuration. Where is this linaro version of arch-armv8?

It's here:



I'm not clear about how the system finds these include files. Is there a way to 
store this file, or the same file under a different name, somewhere in my own 
layer? I normally treat the rest of the metadata as read-only.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] sstate-cache question

[Chris Z.]

Hi Gary,

Have you tried to check those:
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.c45aaef0cb01f463f9a1b30bd815cd28
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4

with bitbake-diffsigs ?  Maybe it's monkey work but last time I had to
debug such issue I had to recursively check those tasks which differ
to find root cause.

Br,
Chris Z

On Thu, May 25, 2017 at 6:36 AM, Gary Thomas  wrote:
> On 2017-05-23 07:27, Gary Thomas wrote:
>>
>> On 2017-05-22 22:35, Paul Eggleton wrote:
>>>
>>> Hi Gary,
>>>
>>> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:

 I have a build where I've never manually removed anything from
 the sstate-cache and this same build has been used for hundreds
 of builds over the last 18 months.  I just tried to find out why
 gcc-cross-arm had to be rebuilt (it seems to happen almost every
 time I update my Poky/Yocto tree (master)).  Here's what I got:

 $ bitbake-diffsigs -t gcc-cross-arm compile
 Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
>>>
>>> 208373dd9ae01101a26a9412eb50b110 to

 d65095d4b9aff89f6990bd17c0ab210b
 Unable to find matching sigdata for
 /local/poky-cutting-edge/meta/recipes-
>>>
>>> devtools/gcc/gcc-cross_6.3.bb.do_configure

 with hashes 208373dd9ae01101a26a9412eb50b110 or
>>>
>>> d65095d4b9aff89f6990bd17c0ab210b


 So if I didn't remove those files, where did they go?  Am I doing
 something wrong running this tool?  (running the same command for
 qemu-native seemed to work correctly)
>>>
>>>
>>> Is this with master, pyro, morty or some other version?
>>
>>
>> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>>
>>>
>>> If you search for files with those hashes in their name do they show up?
>>
>>
>> Only .siginfo files:
>> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
>>
>> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
>> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
>>
>> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>>
>> However, I do find some in tmp/stamps:
>> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
>> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
>> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
>> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
>> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
>> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
>> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
>> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
>> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
>> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
>>
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
>>
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>>
>> I guess the sstate-cache info alone is not sufficient to use 'bitbake
>> diffsigs'?
>> I do occasionally wipe tmp & downloads, so that may explain these errors.
>>
>
> I just updated my Poky/Yocto master
> (a3d160f9e5826140cc8d6b2ed1b38bf022443b08) and it happened again.
> I'm still interested in why gcc-cross-arm had to be rebuilt _again_, so I
> ran:
>
> $ bitbake-diffsigs -t gcc-cross-arm compile
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466,
> PID: 7995
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
> d65095d4b9aff89f6990bd17c0ab210b to 1378c7a11d96284c3d53894d6434b590
> Unable to find matching sigdata for
> /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
> with hashes d65095d4b9aff89f6990bd17c0ab210b or
> 1378c7a11d96284c3d53894d6434b590
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466,
> PID: 7995
> NOTE: Terminating PRServer...
> $ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name
> 

Re: [yocto] Very strange issue where bitbake hangs at do_rootfs

[Chris Z.]

Hi,

Have you tried to find on which syscall it hangs ?  sysdig or strace ?

Maybe it's issue with python subprocess, documentation mention that
subprocess can deadlock or hang with large data and no read from pipe
is done.

Br,
Chris Z

On Fri, May 26, 2017 at 11:35 PM, Andrei Gherzan  wrote:
> On Fri, May 26, 2017 at 5:19 PM, Khem Raj  wrote:
>>
>> On Fri, May 26, 2017 at 5:52 AM, Andrei Gherzan  wrote:
>> > Hello all,
>> >
>> > I moved recently on a new arch linux host and everything works fine with
>> > one
>> > exception: when I build a custom distribution based on morty with many
>> > packages including kernel-modules (beaglebone), the build system hangs
>> > without any details. I hooked into package_manager.py RPM install and
>> > streamed output from `process = subprocess.Popen(cmd.split(),
>> > stderr=subprocess.STDOUT, stdout=subprocess.PIPE)` and it seems that it
>> > hangs in different places every time. Output example:
>> >
>> > ---
>> >
>> > Result of kernel-module-industrialio-sw-trigger postinst: 0
>> > debug: Processing
>> > kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone in
>> >
>> > /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm
>> > 1428:Installing kernel-module.. 
>> > [
>> > 55%]
>> > Output from kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone:
>> > Executing kernel-module-lm8333 postinst with: /bin/sh
>> >
>> > /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459
>> > 1
>> >
>> > # kernel-module-lm8333 - postinst
>> > #!/bin/sh
>> > if [ -z "$D" ]; then
>> > depmod -a 4.4.55+
>> > else
>> > # image.bbclass will call depmodwrapper after everything is
>> > installed,
>> > # no need to do it here as well
>> > :
>> > fi
>> > Result of kernel-module-lm8333 postinst: 0
>> > debug: Processing
>> > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone in
>> >
>> > /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm
>> > 1429:Installing kernel-module.. 
>> > [
>> > 55%]
>> > Output from
>> > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone:
>> > Executing kernel-module-tca8418-keypad postinst with: /bin/sh
>> >
>> > /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459
>> > 1
>> >
>> > ---
>> >
>> > If I don't install kernel-modules build succeeds.
>> >
>> > Any hints on how to debug this further? I can't seem to find anything
>> > relevant in smart output.
>> >
>>
>> yeah rolling ditros are always intesting when you want to build fixed
>> releases from past.
>> one of things that helped me in past was to pin python3 to 3.5 but a
>> clean reinstall of arch
>> I got that problem solved automagically
>
>
> Downgraded to 3.5 and didn't help sadly.
>
> Regards,
> Andrei
>
>
> --
> ___
> 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] How to replace an arch*.inc file?

[Andrei Gherzan]

Hi,

On Sat, May 27, 2017 at 2:34 AM, Paul D. DeRocco 
wrote:

> I'd like to try the Linaro version of arch-armv8.inc in an RPi3 project,
> because it has an ilp32 tune option. What's the correct way to incorporate
> this?
>

Probably the easiest way would be to create a new machine configuration.
Where is this linaro version of arch-armv8?

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

[yocto] How to replace an arch*.inc file?

[Paul D. DeRocco]

I'd like to try the Linaro version of arch-armv8.inc in an RPi3 project,
because it has an ilp32 tune option. What's the correct way to incorporate
this?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] Very strange issue where bitbake hangs at do_rootfs

[Andrei Gherzan]

On Fri, May 26, 2017 at 5:19 PM, Khem Raj  wrote:

> On Fri, May 26, 2017 at 5:52 AM, Andrei Gherzan  wrote:
> > Hello all,
> >
> > I moved recently on a new arch linux host and everything works fine with
> one
> > exception: when I build a custom distribution based on morty with many
> > packages including kernel-modules (beaglebone), the build system hangs
> > without any details. I hooked into package_manager.py RPM install and
> > streamed output from `process = subprocess.Popen(cmd.split(),
> > stderr=subprocess.STDOUT, stdout=subprocess.PIPE)` and it seems that it
> > hangs in different places every time. Output example:
> >
> > ---
> >
> > Result of kernel-module-industrialio-sw-trigger postinst: 0
> > debug: Processing
> > kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone in
> > /work/resin/resinos/resin-beaglebone/build/tmp/work/
> beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/
> beaglebone/kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm
> > 1428:Installing kernel-module.. 
> [
> > 55%]
> > Output from kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone:
> > Executing kernel-module-lm8333 postinst with: /bin/sh
> > /work/resin/resinos/resin-beaglebone/build/tmp/work/
> beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///
> oe_install/tmp/rpm-tmp.76459
> > 1
> >
> > # kernel-module-lm8333 - postinst
> > #!/bin/sh
> > if [ -z "$D" ]; then
> > depmod -a 4.4.55+
> > else
> > # image.bbclass will call depmodwrapper after everything is
> > installed,
> > # no need to do it here as well
> > :
> > fi
> > Result of kernel-module-lm8333 postinst: 0
> > debug: Processing
> > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone in
> > /work/resin/resinos/resin-beaglebone/build/tmp/work/
> beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/
> beaglebone/kernel-module-tca8418-keypad-4.4.55+git0+
> 903eb64c68-r22b.beaglebone.rpm
> > 1429:Installing kernel-module.. 
> [
> > 55%]
> > Output from
> > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone:
> > Executing kernel-module-tca8418-keypad postinst with: /bin/sh
> > /work/resin/resinos/resin-beaglebone/build/tmp/work/
> beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///
> oe_install/tmp/rpm-tmp.76459
> > 1
> >
> > ---
> >
> > If I don't install kernel-modules build succeeds.
> >
> > Any hints on how to debug this further? I can't seem to find anything
> > relevant in smart output.
> >
>
> yeah rolling ditros are always intesting when you want to build fixed
> releases from past.
> one of things that helped me in past was to pin python3 to 3.5 but a
> clean reinstall of arch
> I got that problem solved automagically
>

Downgraded to 3.5 and didn't help sadly.

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

Re: [yocto] Warning: unable to open an initial console

[Gerard van den Bosch]

Hello Ayoub,

Thank you very much.

Your script creates the /dev/console and the /dev/null in my rootfs and now
I keep getting console data.

Cheers,
Gerard

On Fri, May 26, 2017 at 10:35 PM, Ayoub Zaki  wrote:

> Hi Gerard,
>
> indeed your Kernel it's quite outdated.
>
> you can try to add a recipe like that in your image :
>
> SUMMARY = "basic initramfs image init script"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=
> 3da9cfbcb788c80a0384361b4de20420"
> SRC_URI = "file://init-boot.sh"
>
>
> S = "${WORKDIR}"
>
> do_install() {
> install -d ${D}${base_sbindir}
> install -m 0755 ${WORKDIR}/init-boot.sh ${D}${base_sbindir}/init
> }
>
> do_install_append() {
> install -d ${D}/dev
> mknod -m 622 ${D}/dev/console c 5 1
> mknod -m 666 ${D}/dev/null c 1 3
> }
>
> inherit allarch
>
> FILES_${PN} += "/dev /sbin/init "
>
>
> Regards,
>
> Ayoub
>
>
>
> On 26.05.2017 16:27, Gerard van den Bosch wrote:
>
> Hello Ayoub,
>
> The kernel is quite old 2.6.20 and this variable is not available in the
> config.
> On the internet I saw this is only introduced with kernel version 2.6.32.
>
> Cheers,
> Gerard
>
> On Fri, May 26, 2017 at 10:20 PM, Ayoub Zaki 
> wrote:
>
>> Hi Gerard,
>>
>> did you try to set CONFIG_DEVTMPFS=y in your Kernel config ?
>>
>> Cheers
>>
>> On 26.05.2017 15:52, Gerard van den Bosch wrote:
>>
>> Hello Andrea,
>>
>> I have tried to add the line to my machine config:
>> IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"
>>
>> But this didn't help, then I looked a bit further and also tried to set
>> the following:
>>
>> USE_DEVFS="0"
>> VIRTUAL_RUNTIME_dev_manager = "mdev"
>>
>> Unfortunately this doesn't seem to change anything.
>>
>> Cheers,
>> Gerard
>>
>> On Fri, May 26, 2017 at 7:27 PM, Andrea Adami 
>> wrote:
>>
>>> On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
>>>  wrote:
>>> > Hello,
>>> >
>>> > I have build my vendor custom kernel 2.6.20 with yocto daisy.
>>> > Daisy is used because seems to be last release supporting this old
>>> kernel.
>>> >
>>> > I tried building core-image-minimal and core-image-base.
>>> >
>>> > The kernel boots and the rootfs is mounted but then I get:
>>> >
>>> > "Warning: unable to open an initial console."
>>> >
>>> >
>>> > I found on the internet this is because "/dev/console" doesn't exists.
>>> > The dev folder in my generated rootfs is empty.
>>> >
>>> > On internet found can do the following commands:
>>> > "mknod -m 600 /dev/console c 5 1 "
>>> > "mknod -m 666 /dev/null c 1 3"
>>> >
>>> > But if this is the problem how do I add this to my recipe?
>>> > Or is there a proper way to populate this devices?
>>> >
>>> > Cheers,
>>> > Gerard
>>> >
>>> > --
>>> > ___
>>> > yocto mailing list
>>> > yocto@yoctoproject.org
>>> > https://lists.yoctoproject.org/listinfo/yocto
>>> >
>>>
>>> Hello Gerard,
>>>
>>> if your old kernel lacks devtmpfs you need a "device table".
>>> You need to set at least
>>> IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"
>>>
>>> This is a default set in image.bbclass before and after daisy...dunno
>>> what's happened with this release.
>>>
>>> Cheers
>>> Andrea
>>>
>>
>>
>>
>>
>> --
>>
>> Ayoub Zaki
>> ayoub.z...@embexus.com
>> Mobile: +49(0)176-62901545 <+49%20176%2062901545>https://embexus.com
>>
>>
>
> --
>
> Ayoub Zaki
> ayoub.z...@embexus.com
> Mobile: +49(0)176-62901545 <+49%20176%2062901545>https://embexus.com
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Warning: unable to open an initial console

[Ayoub Zaki]

Hi Gerard,

indeed your Kernel it's quite outdated.

you can try to add a recipe like that in your image :

SUMMARY = "basic initramfs image init script"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

SRC_URI = "file://init-boot.sh"


S = "${WORKDIR}"

do_install() {
install -d ${D}${base_sbindir}
install -m 0755 ${WORKDIR}/init-boot.sh ${D}${base_sbindir}/init
}

do_install_append() {
install -d ${D}/dev
mknod -m 622 ${D}/dev/console c 5 1
mknod -m 666 ${D}/dev/null c 1 3
}

inherit allarch

FILES_${PN} += "/dev /sbin/init "


Regards,

Ayoub



On 26.05.2017 16:27, Gerard van den Bosch wrote:

Hello Ayoub,

The kernel is quite old 2.6.20 and this variable is not available in 
the config.

On the internet I saw this is only introduced with kernel version 2.6.32.

Cheers,
Gerard

On Fri, May 26, 2017 at 10:20 PM, Ayoub Zaki > wrote:


Hi Gerard,

did you try to set CONFIG_DEVTMPFS=y in your Kernel config ?

Cheers


On 26.05.2017 15:52, Gerard van den Bosch wrote:

Hello Andrea,

I have tried to add the line to my machine config:
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

But this didn't help, then I looked a bit further and also tried
to set the following:

USE_DEVFS="0"
VIRTUAL_RUNTIME_dev_manager = "mdev"

Unfortunately this doesn't seem to change anything.

Cheers,
Gerard

On Fri, May 26, 2017 at 7:27 PM, Andrea Adami
> wrote:

On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
> wrote:
> Hello,
>
> I have build my vendor custom kernel 2.6.20 with yocto daisy.
> Daisy is used because seems to be last release supporting
this old kernel.
>
> I tried building core-image-minimal and core-image-base.
>
> The kernel boots and the rootfs is mounted but then I get:
>
> "Warning: unable to open an initial console."
>
>
> I found on the internet this is because "/dev/console"
doesn't exists.
> The dev folder in my generated rootfs is empty.
>
> On internet found can do the following commands:
> "mknod -m 600 /dev/console c 5 1 "
> "mknod -m 666 /dev/null c 1 3"
>
> But if this is the problem how do I add this to my recipe?
> Or is there a proper way to populate this devices?
>
> Cheers,
> Gerard
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto

>

Hello Gerard,

if your old kernel lacks devtmpfs you need a "device table".
You need to set at least
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

This is a default set in image.bbclass before and after
daisy...dunno
what's happened with this release.

Cheers
Andrea






-- 


Ayoub Zaki

ayoub.z...@embexus.com 
Mobile:+49(0)176-62901545 
https://embexus.com




--

Ayoub Zaki

ayoub.z...@embexus.com
Mobile: +49(0)176-62901545
https://embexus.com

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

Re: [yocto] Warning: unable to open an initial console

[Gerard van den Bosch]

Hello Ayoub,

The kernel is quite old 2.6.20 and this variable is not available in the
config.
On the internet I saw this is only introduced with kernel version 2.6.32.

Cheers,
Gerard

On Fri, May 26, 2017 at 10:20 PM, Ayoub Zaki  wrote:

> Hi Gerard,
>
> did you try to set CONFIG_DEVTMPFS=y in your Kernel config ?
>
> Cheers
>
> On 26.05.2017 15:52, Gerard van den Bosch wrote:
>
> Hello Andrea,
>
> I have tried to add the line to my machine config:
> IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"
>
> But this didn't help, then I looked a bit further and also tried to set
> the following:
>
> USE_DEVFS="0"
> VIRTUAL_RUNTIME_dev_manager = "mdev"
>
> Unfortunately this doesn't seem to change anything.
>
> Cheers,
> Gerard
>
> On Fri, May 26, 2017 at 7:27 PM, Andrea Adami 
> wrote:
>
>> On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
>>  wrote:
>> > Hello,
>> >
>> > I have build my vendor custom kernel 2.6.20 with yocto daisy.
>> > Daisy is used because seems to be last release supporting this old
>> kernel.
>> >
>> > I tried building core-image-minimal and core-image-base.
>> >
>> > The kernel boots and the rootfs is mounted but then I get:
>> >
>> > "Warning: unable to open an initial console."
>> >
>> >
>> > I found on the internet this is because "/dev/console" doesn't exists.
>> > The dev folder in my generated rootfs is empty.
>> >
>> > On internet found can do the following commands:
>> > "mknod -m 600 /dev/console c 5 1 "
>> > "mknod -m 666 /dev/null c 1 3"
>> >
>> > But if this is the problem how do I add this to my recipe?
>> > Or is there a proper way to populate this devices?
>> >
>> > Cheers,
>> > Gerard
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>>
>> Hello Gerard,
>>
>> if your old kernel lacks devtmpfs you need a "device table".
>> You need to set at least
>> IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"
>>
>> This is a default set in image.bbclass before and after daisy...dunno
>> what's happened with this release.
>>
>> Cheers
>> Andrea
>>
>
>
>
>
> --
>
> Ayoub Zaki
> ayoub.z...@embexus.com
> Mobile: +49(0)176-62901545 <+49%20176%2062901545>https://embexus.com
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Warning: unable to open an initial console

[Ayoub Zaki]

Hi Gerard,

did you try to set CONFIG_DEVTMPFS=y in your Kernel config ?

Cheers


On 26.05.2017 15:52, Gerard van den Bosch wrote:

Hello Andrea,

I have tried to add the line to my machine config:
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

But this didn't help, then I looked a bit further and also tried to 
set the following:


USE_DEVFS="0"
VIRTUAL_RUNTIME_dev_manager = "mdev"

Unfortunately this doesn't seem to change anything.

Cheers,
Gerard

On Fri, May 26, 2017 at 7:27 PM, Andrea Adami > wrote:


On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
> wrote:
> Hello,
>
> I have build my vendor custom kernel 2.6.20 with yocto daisy.
> Daisy is used because seems to be last release supporting this
old kernel.
>
> I tried building core-image-minimal and core-image-base.
>
> The kernel boots and the rootfs is mounted but then I get:
>
> "Warning: unable to open an initial console."
>
>
> I found on the internet this is because "/dev/console" doesn't
exists.
> The dev folder in my generated rootfs is empty.
>
> On internet found can do the following commands:
> "mknod -m 600 /dev/console c 5 1 "
> "mknod -m 666 /dev/null c 1 3"
>
> But if this is the problem how do I add this to my recipe?
> Or is there a proper way to populate this devices?
>
> Cheers,
> Gerard
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto

>

Hello Gerard,

if your old kernel lacks devtmpfs you need a "device table".
You need to set at least
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

This is a default set in image.bbclass before and after daisy...dunno
what's happened with this release.

Cheers
Andrea






--

Ayoub Zaki

ayoub.z...@embexus.com
Mobile: +49(0)176-62901545
https://embexus.com

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

Re: [yocto] Warning: unable to open an initial console

[Gerard van den Bosch]

Hello Andrea,

I have tried to add the line to my machine config:
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

But this didn't help, then I looked a bit further and also tried to set the
following:

USE_DEVFS="0"
VIRTUAL_RUNTIME_dev_manager = "mdev"

Unfortunately this doesn't seem to change anything.

Cheers,
Gerard

On Fri, May 26, 2017 at 7:27 PM, Andrea Adami 
wrote:

> On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
>  wrote:
> > Hello,
> >
> > I have build my vendor custom kernel 2.6.20 with yocto daisy.
> > Daisy is used because seems to be last release supporting this old
> kernel.
> >
> > I tried building core-image-minimal and core-image-base.
> >
> > The kernel boots and the rootfs is mounted but then I get:
> >
> > "Warning: unable to open an initial console."
> >
> >
> > I found on the internet this is because "/dev/console" doesn't exists.
> > The dev folder in my generated rootfs is empty.
> >
> > On internet found can do the following commands:
> > "mknod -m 600 /dev/console c 5 1 "
> > "mknod -m 666 /dev/null c 1 3"
> >
> > But if this is the problem how do I add this to my recipe?
> > Or is there a proper way to populate this devices?
> >
> > Cheers,
> > Gerard
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
> Hello Gerard,
>
> if your old kernel lacks devtmpfs you need a "device table".
> You need to set at least
> IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"
>
> This is a default set in image.bbclass before and after daisy...dunno
> what's happened with this release.
>
> Cheers
> Andrea
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dynamic-layers?

[Patrick Ohly]

On Fri, 2017-05-26 at 08:09 +, Takashi Matsuzawa wrote:
> Hello.
> 
> 
> So, this is the case I have to be careful about the order of conf
> files listed in BBLAYERS list?
> 
> i.e. if I have dynamic-layers line in my layer X and expansion need to
> take care of layer A, B, C, then, A, B, C needs to be apper before X
> within BBLAYERS list.

Yes, I think that's how it is meant to be used.

The reason is that layers get added one-by-one in the order in which
they appear in BBLAYERS, and then the code in
meta-freescale/conf/layer.conf only sees what has been added already.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [yocto] Can Yocto treat layers like an external package?

[Patrick Ohly]

On Thu, 2017-05-25 at 16:04 +, Koehler, Yannick (HPN Aruba) wrote:
> This is my opinion, I think we could alter bitbake to retrieve the SRC_URI 
> and S information from the bblayers.conf (instead of having recipes like for 
> package).
> 
> sample 
> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> LCONF_VERSION = "6"
> 
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
> 
> BBLAYERS ?= " \
>   ##OEROOT##/meta \
>   ##OEROOT##/meta-yocto \
>   ##OEROOT##/meta-yocto-bsp \
>   
> ##OEROOT##/meta-openembedded;SRC_URI="git://g...@github.com/openembedded/meta-openembedded;protocol=ssh;branch=master";SRCREV="${AUTOREV}"
>  \
>   "
> BBLAYERS_NON_REMOVABLE ?= " \
>   ##OEROOT##/meta \
>   ##OEROOT##/meta-yocto \
>   "
> 
> Bitbake could then fetch/update the layer from the SRC_URI into the location 
> given "##OEROOT##/meta-openembedded" prior to parsing.

Richard has indeed been thinking about a solution like that for 2.4.

I agree that it looks attractive at first glance. However, I see a
chicken-and-egg problem with no (easy?) solution: a developer who wants
to get started with a distro "foo" first needs to check out the repo
containing that distro's definition and local.conf.sample, then somehow
also check out a version of bitbake that works with that distro
revision, and only then can bitbake download the additional layers.

Perhaps we can make it so that bitbake has a separate tool that works
outside of a build environment and then sets up that environment.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[yocto] pyro not honoring TOOLCHAIN_TARGET_TASK in populate_sdk

[ALLEN,RICHARD (K-SantaClara,ex1)]

With the pyro drop , when I use an -c populate_sdk,  It appears that 
TOOLCHAIN_TARGET_TASK  is not being honored.

I have a 
TOOLCHAIN_TARGET_TASK_append = " gtest"

With morty, gtest is included in -c populate_sdk generated sdk
but with pyro, it is not.

Is this a known issue with pyro?
Thanks




Richard C. Allen
richard_al...@keysight.com


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

[yocto] Very strange issue where bitbake hangs at do_rootfs

[Andrei Gherzan]

Hello all,

I moved recently on a new arch linux host and everything works fine with
one exception: when I build a custom distribution based on morty with many
packages including kernel-modules (beaglebone), the build system hangs
without any details. I hooked into package_manager.py RPM install and
streamed output from `process = subprocess.Popen(cmd.split(),
stderr=subprocess.STDOUT, stdout=subprocess.PIPE)` and it seems that it
hangs in different places every time. Output example:

---

Result of kernel-module-industrialio-sw-trigger postinst: 0
debug: Processing
kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone in
/work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm
1428:Installing kernel-module..  [
55%]
Output from kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone:
Executing kernel-module-lm8333 postinst with: /bin/sh
/work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459
1

# kernel-module-lm8333 - postinst
#!/bin/sh
if [ -z "$D" ]; then
depmod -a 4.4.55+
else
# image.bbclass will call depmodwrapper after everything is
installed,
# no need to do it here as well
:
fi
Result of kernel-module-lm8333 postinst: 0
debug: Processing
kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone in
/work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm
1429:Installing kernel-module..  [
55%]
Output from
kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone:
Executing kernel-module-tca8418-keypad postinst with: /bin/sh
/work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459
1

---

If I don't install kernel-modules build succeeds.

Any hints on how to debug this further? I can't seem to find anything
relevant in smart output.


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

Re: [yocto] Warning: unable to open an initial console

[Andrea Adami]

On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
 wrote:
> Hello,
>
> I have build my vendor custom kernel 2.6.20 with yocto daisy.
> Daisy is used because seems to be last release supporting this old kernel.
>
> I tried building core-image-minimal and core-image-base.
>
> The kernel boots and the rootfs is mounted but then I get:
>
> "Warning: unable to open an initial console."
>
>
> I found on the internet this is because "/dev/console" doesn't exists.
> The dev folder in my generated rootfs is empty.
>
> On internet found can do the following commands:
> "mknod -m 600 /dev/console c 5 1 "
> "mknod -m 666 /dev/null c 1 3"
>
> But if this is the problem how do I add this to my recipe?
> Or is there a proper way to populate this devices?
>
> Cheers,
> Gerard
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Hello Gerard,

if your old kernel lacks devtmpfs you need a "device table".
You need to set at least
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

This is a default set in image.bbclass before and after daisy...dunno
what's happened with this release.

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

[yocto] Warning: unable to open an initial console

[Gerard van den Bosch]

Hello,

I have build my vendor custom kernel 2.6.20 with yocto daisy.
Daisy is used because seems to be last release supporting this old kernel.

I tried building core-image-minimal and core-image-base.

The kernel boots and the rootfs is mounted but then I get:

"Warning: unable to open an initial console."

I found on the internet this is because "/dev/console" doesn't exists.
The dev folder in my generated rootfs is empty.

On internet found can do the following commands:
"mknod -m 600 /dev/console c 5 1 "
"mknod -m 666 /dev/null c 1 3"

But if this is the problem how do I add this to my recipe?
Or is there a proper way to populate this devices?

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

Re: [yocto] yocto-jethro: how to define a machine which builds kernel in 64-bit whereas user space in 32bit

[sourabh banerjee]

On Fri, May 26, 2017 at 9:18 AM, sourabh banerjee 
wrote:

> For reference I looked up the default provided machine conf files inside
> poky/meta.
>
> Following seems to build qemuarm for 32bit, i.e. both kernel and user
> space 32bit
> * http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/
> conf/machine/qemuarm.conf?h=jethro
>
> And following seems to build qemuarm64 for 64 bit, i.e. both kernel and
> user space 64bit
> * http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/
> conf/machine/qemuarm64.conf?h=jethro
>
> Please guide me how can I define a machine where kernel is built 64bit but
> the user space is 32bit.
> I attempted a few things by trying to override the TUNE flags but I am not
> able to get it right.
>
> I left the tune parameters alone.  I am trying to multilib now
Setting MULTILIBS = "multilib:lib64" in machine.conf
DEFAULTTUNE_virtclass-multilib-lib64 = "aarch64"

and

DEFAULTTUNE ?= "armv7a-neon"

Is this the right approach?


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

[yocto] [meta-cgl][PATCH 1/5] openais: add systemd support

[jackie.huang]

From: Jackie Huang 

inherit systemd and add .service for systemd support

Signed-off-by: Jackie Huang 
---
 .../recipes-cgl/openais/files/openais.service   | 14 ++
 meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb| 17 +++--
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 meta-cgl-common/recipes-cgl/openais/files/openais.service

diff --git a/meta-cgl-common/recipes-cgl/openais/files/openais.service 
b/meta-cgl-common/recipes-cgl/openais/files/openais.service
new file mode 100644
index 000..230e4bb
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/openais/files/openais.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=OpenAIS Cluster Framework
+ConditionKernelCommandLine=!nocluster
+Requires=network-online.target
+After=network-online.target
+
+[Service]
+ExecStart=@DATADIR@/openais/openais start
+ExecStop=@DATADIR@/openais/openais stop
+Type=oneshot
+RemainAfterExit=yes
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
index e503cec..23da0a2 100644
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -9,10 +9,23 @@ SRC_URI = " \
 file://fix-lcrso-linkage.patch \
 file://build-cleanup-configure-ac.patch \
 file://openais-fix-bash.patch \
-   "
+file://openais.service \
+"
+
 SRC_URI[md5sum] = "e500ad3c49fdc45d8653f864e80ed82c"
 SRC_URI[sha256sum] = 
"974b4959f3c401c16156dab31e65a6d45bbf84dd85a88c2a362712e738c06934"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd
+
+SYSTEMD_SERVICE_${PN} = "openais.service"
+SYSTEMD_AUTO_ENABLE = "disable"
+
+do_install_append() {
+if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
+install -D -m 0755 ${D}${sysconfdir}/init.d/openais 
${D}${datadir}/${BPN}/openais
+install -D -m 0644 ${WORKDIR}/openais.service 
${D}${systemd_system_unitdir}/openais.service
+sed -i -e 's,@DATADIR@,${datadir},g' 
${D}${systemd_system_unitdir}/openais.service
+fi
+}
 
 FILES_${PN}-dbg += "${libexecdir}/lcrso/.debug"
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 4/5] openais: fix corosync not quit

[jackie.huang]

From: Jackie Huang 

On some targets, "/etc/init.d/openais stop" can not make
corosync quit since corosync does not respond to signal TERM.

Signed-off-by: yanjun.zhu 
Signed-off-by: Jackie Huang 
---
 .../files/openais-fix-corosync-not-quit.patch  | 53 ++
 .../recipes-cgl/openais/openais_1.1.4.bb   |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch

diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch
new file mode 100644
index 000..f3f7279
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch
@@ -0,0 +1,53 @@
+commit e26a778dc372f6c15838c16efaca2e98abd6
+Author: yanjun.zhu 
+Date:   Wed Mar 13 10:10:03 2013 +0800
+
+openais: fix corosync not quit
+
+In fsl-p5040, "/etc/init.d/openais stop" can not make corosync quit since 
corosync
+does not respond to signal TERM.
+
+Upstream-Status: Pending
+
+Signed-off-by: yanjun.zhu 
+
+diff -urpN a/init/generic.in b/init/generic.in
+--- a/init/generic.in
 b/init/generic.in
+@@ -39,18 +39,6 @@ failure()
+   echo -ne "[FAILED]\r"
+ }
+ 
+-status()
+-{
+-  pid=$(pidof $1 2>/dev/null)
+-  rtrn=$?
+-  if [ $rtrn -ne 0 ]; then
+-  echo "$1 is stopped"
+-  else
+-  echo "$1 ($proc with pid $pid) is running..."
+-  fi
+-  return $rtrn
+-}
+-
+ # rpm based distros
+ if [ -d @SYSCONFDIR@/sysconfig ]; then
+   [ -f @INITDDIR@/functions ] && . @INITDDIR@/functions
+@@ -98,16 +86,10 @@ stop()
+   ! status $proc > /dev/null 2>&1 && return
+ 
+   echo -n "Signaling $desc ($prog) to terminate: "
+-  kill -TERM $(pidof $proc) > /dev/null 2>&1
++  echo -n "Please stop corosync using /etc/init.d/corosync-daemon stop"
+   success
+   echo
+ 
+-  echo -n "Waiting for $prog services to unload:"
+-  while status $proc > /dev/null 2>&1; do
+-  sleep 1
+-  echo -n "."
+-  done
+-
+   rm -f $LOCK_FILE
+   rm -f @LOCALSTATEDIR@/run/$prog.pid
+   success
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
index d54b22f..9cc750a 100644
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -11,6 +11,7 @@ SRC_URI = " \
 file://openais-fix-bash.patch \
 file://openais-fix-init-script.patch \
 file://openais-saTmrTimerReschedule-test-error.patch \
+file://openais-fix-corosync-not-quit.patch \
 file://openais.service \
 "
 
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 5/5] openais: remove cleanup entry from openais

[jackie.huang]

From: Jackie Huang 

message_handler_req_exec_lck_resourceclose is to remove cleanup
entry from corosync. Now this job is done by pacemaker. So remove
this feature from openais.

Signed-off-by: yanjun.zhu 
Signed-off-by: Jackie Huang 
---
 .../files/openais-fix-resource-cleanup-entry.patch | 37 ++
 .../recipes-cgl/openais/openais_1.1.4.bb   |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch

diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch
 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch
new file mode 100644
index 000..55313ce
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch
@@ -0,0 +1,37 @@
+commit f70bea251f21a8bd646e59b34e6f74f6ee3fe29b
+Author: yanjun.zhu 
+Date:   Tue Mar 19 12:23:55 2013 +0800
+
+openais: remove cleanup entry from openais
+
+message_handler_req_exec_lck_resourceclose is to remove cleanup
+entry from corosync. Now this job is done by pacemaker. So remove
+this feature from openais.
+
+Upstream-Status: Pending
+
+Signed-off-by: yanjun.zhu 
+
+diff -urpN a/services/lck.c b/services/lck.c
+--- a/services/lck.c
 b/services/lck.c
+@@ -2304,17 +2304,9 @@ error_exit:
+ 
+   if (error == SA_AIS_OK) {
+   /*
+-   * Remove the cleanup entry for this resource.
++   * cleanup entry for this resource can not be removed.
++   * This will be done by pacemaker.
+*/
+-  cleanup = lck_resource_cleanup_find (
+-  req_exec_lck_resourceclose->source.conn,
+-  _exec_lck_resourceclose->resource_name);
+-
+-  if (cleanup != NULL) {
+-  list_del (>cleanup_list);
+-  free (cleanup);
+-  }
+-
+   hdb_handle_put (_hdb, 
req_exec_lck_resourceclose->resource_id);
+   hdb_handle_destroy (_hdb, 
req_exec_lck_resourceclose->resource_id);
+   }
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
index 9cc750a..cdf1454 100644
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -12,6 +12,7 @@ SRC_URI = " \
 file://openais-fix-init-script.patch \
 file://openais-saTmrTimerReschedule-test-error.patch \
 file://openais-fix-corosync-not-quit.patch \
+file://openais-fix-resource-cleanup-entry.patch \
 file://openais.service \
 "
 
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 2/5] openais: correct the use of proc name in init script

[jackie.huang]

From: Jackie Huang 

openais actually runs on top of corosync. The init
script was checking for the pid of "openais"
rather than checking for corosync's pid.

Signed-off-by: Aws Ismail 
Signed-off-by: Jackie Huang 
---
 .../openais/files/openais-fix-init-script.patch| 42 ++
 .../recipes-cgl/openais/openais_1.1.4.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch

diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch
new file mode 100644
index 000..69fddd5
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch
@@ -0,0 +1,42 @@
+commit 367f4ab0b67266e07ffedcae2df74f2576ea2aeb
+Author: Aws Ismail 
+Date:   Thu Jan 24 12:36:48 2013 -0500
+
+openais: correct the use of proc name in init script
+
+openais actually runs on top of corosync. The init
+script was checking for the pid of "openais"
+rather than checking for corosync's pid.
+
+Upstream-Status: Pending
+
+Signed-off-by: Aws Ismail 
+
+diff --git a/init/generic.in b/init/generic.in
+index ac63a5f..e8efbb3 100644
+--- a/init/generic.in
 b/init/generic.in
+@@ -46,7 +46,7 @@ status()
+   if [ $rtrn -ne 0 ]; then
+   echo "$1 is stopped"
+   else
+-  echo "$1 (pid $pid) is running..."
++  echo "$1 ($proc with pid $pid) is running..."
+   fi
+   return $rtrn
+ }
+@@ -130,12 +130,12 @@ restart|reload|force-reload)
+   restart
+ ;;
+ condrestart|try-restart)
+-  if status $prog > /dev/null 2>&1; then
++  if status $proc > /dev/null 2>&1; then
+   restart
+   fi
+ ;;
+ status)
+-  status $prog
++  status $proc
+   rtrn=$?
+ ;;
+ stop)
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
index 23da0a2..0693ddb 100644
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -9,6 +9,7 @@ SRC_URI = " \
 file://fix-lcrso-linkage.patch \
 file://build-cleanup-configure-ac.patch \
 file://openais-fix-bash.patch \
+file://openais-fix-init-script.patch \
 file://openais.service \
 "
 
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 3/5] openais: fix saTmrTimerReschedule test error

[jackie.huang]

From: Jackie Huang 

* If req_lib_tmr_timerreschedule->timer_attributes.type is
  SA_TIME_ABSOLUTE, an absolute time value must be higher
  than the current absolute time.According to the type, we
  will compare the current time with an absolute time. If
  the type is SA_TIME_ABSOLUTE, we will compare. Or else,
  we do nothing;
* For single-event timers, timerPeriodDuration = 0 is required.
  Note that saTmrTimerReschedule() cannot be used to change a
  timer from being a single-event timer to a periodic timer or
  vice versa. Since the older timerPeriodDuration is 0 in testtmr.c
  file, it is a single-event timer. The following reschedule will
  change it to  a periodic timer. It is not permitted.

Signed-off-by: yanjun.zhu 
Signed-off-by: Jackie Huang 
---
 .../openais-saTmrTimerReschedule-test-error.patch  | 50 ++
 .../recipes-cgl/openais/openais_1.1.4.bb   |  1 +
 2 files changed, 51 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch

diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch
 
b/meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch
new file mode 100644
index 000..6806fba
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch
@@ -0,0 +1,50 @@
+commit 379eb121110d22131408cedf2f200165d142852c
+Author: yanjun.zhu 
+Date:   Fri Mar 1 12:25:33 2013 +0800
+
+openais: fix saTmrTimerReschedule test error
+
+* If req_lib_tmr_timerreschedule->timer_attributes.type is
+  SA_TIME_ABSOLUTE, an absolute time value must be higher
+  than the current absolute time.According to the type, we
+  will compare the current time with an absolute time. If
+  the type is SA_TIME_ABSOLUTE, we will compare. Or else,
+  we do nothing;
+* For single-event timers, timerPeriodDuration = 0 is required.
+  Note that saTmrTimerReschedule() cannot be used to change a
+  timer from being a single-event timer to a periodic timer or
+  vice versa. Since the older timerPeriodDuration is 0 in testtmr.c
+  file, it is a single-event timer. The following reschedule will
+  change it to  a periodic timer. It is not permitted.
+
+Upstream-Status: Pending
+
+Signed-off-by: yanjun.zhu 
+--
+diff -urpN a/services/tmr.c b/services/tmr.c
+--- a/services/tmr.c
 b/services/tmr.c
+@@ -442,7 +442,8 @@ static void message_handler_req_lib_tmr_
+ 
+   current_time = (SaTimeT)(api->timer_time_get());
+ 
+-  if (current_time > 
req_lib_tmr_timerreschedule->timer_attributes.initialExpirationTime) {
++  if ((SA_TIME_ABSOLUTE == 
req_lib_tmr_timerreschedule->timer_attributes.type) &&
++  (current_time > 
req_lib_tmr_timerreschedule->timer_attributes.initialExpirationTime)) {
+   error = SA_AIS_ERR_INVALID_PARAM;
+   goto error_put;
+   }
+diff -urpN a/test/testtmr.c b/test/testtmr.c
+--- a/test/testtmr.c
 b/test/testtmr.c
+@@ -86,8 +86,8 @@ int main (void)
+   SaTmrHandleT handle;
+   SaSelectionObjectT select_obj;
+   SaTmrTimerAttributesT attrs;
+-  SaTmrTimerAttributesT attrs_a = { SA_TIME_DURATION, TMR_30_SECONDS, 0 };
+-  SaTmrTimerAttributesT attrs_b = { SA_TIME_DURATION, TMR_30_SECONDS, 0 };
++  SaTmrTimerAttributesT attrs_a = { SA_TIME_DURATION, TMR_30_SECONDS, 
TMR_30_SECONDS };
++  SaTmrTimerAttributesT attrs_b = { SA_TIME_DURATION, TMR_30_SECONDS, 
TMR_30_SECONDS };
+   SaTmrTimerAttributesT new_attrs_a = { SA_TIME_DURATION, TMR_10_SECONDS, 
TMR_10_SECONDS };
+   SaTmrTimerAttributesT new_attrs_b = { SA_TIME_DURATION, TMR_20_SECONDS, 
TMR_20_SECONDS };
+   SaTmrTimerIdT id_a;
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
index 0693ddb..d54b22f 100644
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -10,6 +10,7 @@ SRC_URI = " \
 file://build-cleanup-configure-ac.patch \
 file://openais-fix-bash.patch \
 file://openais-fix-init-script.patch \
+file://openais-saTmrTimerReschedule-test-error.patch \
 file://openais.service \
 "
 
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 0/5] openais: add systemd support and several fixes

[jackie.huang]

From: Jackie Huang 

--
The following changes since commit c0afa706e9cdb650c0e8bb79f503743632350b00:

  core-image-cgl: Remove ROOTFS_PKGMANAGE_BOOTSTRAP (2017-05-24 14:19:13 +0200)

are available in the git repository at:

  https://github.com/jackiehjm/meta-cgl.git jhuang0/up_openais_170526_0
  https://github.com//tree/jhuang0/up_openais_170526_0

Jackie Huang (5):
  openais: add systemd support
  openais: correct the use of proc name in init script
  openais: fix saTmrTimerReschedule test error
  openais: fix corosync not quit
  openais: remove cleanup entry from openais

 .../files/openais-fix-corosync-not-quit.patch  | 53 ++
 .../openais/files/openais-fix-init-script.patch| 42 +
 .../files/openais-fix-resource-cleanup-entry.patch | 37 +++
 .../openais-saTmrTimerReschedule-test-error.patch  | 50 
 .../recipes-cgl/openais/files/openais.service  | 14 ++
 .../recipes-cgl/openais/openais_1.1.4.bb   | 21 -
 6 files changed, 215 insertions(+), 2 deletions(-)
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch
 create mode 100644 meta-cgl-common/recipes-cgl/openais/files/openais.service

-- 
2.11.0

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

Re: [yocto] dynamic-layers?

[Takashi Matsuzawa]

Hello.


So, this is the case I have to be careful about the order of conf files listed 
in BBLAYERS list?

i.e. if I have dynamic-layers line in my layer X and expansion need to take 
care of layer A, B, C, then, A, B, C needs to be apper before X within BBLAYERS 
list.


From: Takashi Matsuzawa
Sent: Thursday, May 25, 2017 3:26 PM
To: yocto@yoctoproject.org
Cc: Nicolas Dechesne
Subject: Re: [yocto] dynamic-layers?


Hello.


I further did some debugging and BBFOLE_COLLECTION when used in the following 
'for' expansion contains only subset of what is avilable finally in 
BBFILE_COLLECTION (as appears in '-e' log).


>BBFILES += "${@'  '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' 
>% layer \
>   for layer in BBFILE_COLLECTIONS.split())}"

I am confused if this is a normal behavior.


From: Takashi Matsuzawa
Sent: Thursday, May 25, 2017 10:03 AM
To: Nicolas Dechesne
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?


Hello.

>e.g. if you have meta-qt5 in BBLAYERS in /conf/bblayers.conf, then the 
>recipes from "dynamic-layers/qt5-layer" are used as well.

Thanks now I can see how it is expected to work.
My issue here now is that some dynamyc-layers/ not being added to 
BBFILES list.

I tried '-e' switch with my build tree and here is what I can see.
I think this is caused by BBFILE_COLLECTIONS evaluation timing? - but I am 
still looking into to find the cause.

1) .conf files read

I think these are the conf files recognized by the build sytem.
I cansee meta-qt5 there.

#
# INCLUDE HISTORY:
#
# /home/xxx/build-root/build/conf/bblayers.conf
# /home/xxx/build-root/meta-freescale/conf/layer.conf
# /home/xxx/build-root/meta-freescale-3rdparty/conf/layer.conf
# /home/xxx/build-root/meta-freescale-distro/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-netboot/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-smack/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-framework/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-app-framework/conf/layer.conf
# /home/xxx/build-root/meta-qt5/conf/layer.conf
...

2) BBFILE_COLLECTIONS

And I can see 'qt5-layer' is being added to BBFILE_COLLECTIONS, so it 
'qt5-layer' folder in every dynamic-layers should be picked into BBFILE list.

BBFILE_COLLECTIONS=" freescale-layer fsl-arm-extra fsl-demos
meta-netboot security-smack security-framework app-framework qt5-layer
agl-demo openembedded-layer multimedia-layer efl-layer
networking-layer meta-python ivi-common agl agl-distro aglbsp core
yocto"

3) BBFILES

But I cannot find it in BBFILES list.
Only the first 4 layers (freescale-layer/fsl-arm-extra/fsl-demos/meta-netboot) 
in BBFILE_COLLECTIONS are used in wildecard parameter.

BBFILES="/home/xxx/build-root/meta-freescale/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale/recipes-*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bbappend
...



From: Nicolas Dechesne 
Sent: Wednesday, May 24, 2017 11:19 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?

On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa  wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf

>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> BBFILE_COLLECIONS.
>
> Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS
> when I want to include browser-layer in my build.
>
> Is it something to 

[yocto] xen-guest-image-minimal building error

[Pello Heriz]

Hi all,

I'm trying to build an a xen guest image for the zcu102 board with the
master branch of Yocto, but I'm having a trouble. The building process
stops due to the next error:

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'python-smartpm-native'. Close matches:
  python-rpm-native
  python-mako-native
  python-py-native
ERROR: Required build target 'xen-guest-image-minimal' has no buildable
providers.
Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
'python-smartpm-native']

Does any body know how could I solve this issue?

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