Re: [yocto] Fwd: do_configure error

2017-09-27 Thread Khem Raj 
On Sat, Sep 23, 2017 at 12:33 PM, Burton, Ross  wrote:
> On 23 September 2017 at 06:56, mohammed aqdam 
> wrote:
>>
>> i'm getting the following error...
>>
>> root@pcz-ee207837-2:/u/my_poky/poky-2/poky/build# bitbake -k
>> rpi-test-image
>
>   
>
>>  configure: error: you should not run configure as root
>
> As it says, you're running as root.  I thought we bailed early if this
> happened but obviously not.  Don't build as root, build as a normal user.
>

this should be added to sanity check I think.

> Ross
>
> --
> ___
> 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] [meta-intel] meta-intel has been split into meta-dpdk and meta-intel-qat

2017-09-27 Thread Lai Eddy 
is this mean I don't need meta-intel anymore? (but still can be found in
the git)
just choose to use meta-dpdk and/or meta-intel-qat

2017-09-28 11:27 GMT+08:00 Saul Wold :

>
> In an effort to create more consistency in Yocto Project layer, we are
> splitting the meta-intel to remove some application/libraries that
> should really be in their own layers.
>
> The new meta-dpdk will serve as a place for the Linux Foundation's DPDK
> project to host meta-data.
>
> The meta-intel-qat will carry the Quick Assist Technology libraries and
> associated applications.
>
> They are both hosted at https://git.yoctoproject.org
>
>
> Sau!
> --
> ___
> meta-intel mailing list
> meta-in...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-intel has been split into meta-dpdk and meta-intel-qat

2017-09-27 Thread Saul Wold 

In an effort to create more consistency in Yocto Project layer, we are
splitting the meta-intel to remove some application/libraries that
should really be in their own layers.  

The new meta-dpdk will serve as a place for the Linux Foundation's DPDK
project to host meta-data.

The meta-intel-qat will carry the Quick Assist Technology libraries and
associated applications.

They are both hosted at https://git.yoctoproject.org


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

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Manjukumar Harthikote Matha 
Hi Otavio,

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Otavio Salvador
> Sent: Wednesday, September 27, 2017 10:29 AM
> To: Khem Raj 
> Cc: yo...@lists.yoctoproject.org; Otavio Salvador 
> Subject: Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS
> support"
> 
> On Wed, Sep 27, 2017 at 2:20 PM, Khem Raj  wrote:
> >
> > On Wed, Sep 27, 2017 at 10:17 AM Andrei Gherzan  wrote:
> >>
> >> On Wed, Sep 27, 2017 at 4:23 PM, Martin Jansa
> >> 
> >> wrote:
> >>>
> >>> * this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb.
> >>> * this makes qtbase and everything which depends on some qt* recipe to
> >>>   be effectivelly MACHINE_ARCH
> >>>
> >>> Signed-off-by: Martin Jansa 
> >>> ---
> >>>  dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 ---
> >>>  1 file changed, 3 deletions(-)
> >>>  delete mode 100644
> >>> dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> >>>
> >>> diff --git
> >>> a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> >>> b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> >>> deleted file mode 100644
> >>> index ae3f1d3..000
> >>> --- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> >>> +++ /dev/null
> >>> @@ -1,3 +0,0 @@
> >>> -# Copyright (C) 2017 O.S. Systems Software LTDA.
> >>> -
> >>> -PACKAGECONFIG_GL_rpi   = "gles2 eglfs"
> >>
> >>
> >> What would be the solution though?
> >
> > I think check for OpenGL feature to enable it I think another thing is
> > to also check for X11 in distro features before enabling it
> >
> > Gl support is quite soc specific so I don't think there is an elegant
> > way unless qt components can be built with soc specific elements as
> > plugins or something which then can have independent recipe
> 
> https://github.com/Freescale/meta-freescale/blob/master/classes/fsl-dynamic-
> packagearch.bbclass
> 
> Something like this?
> 

This is very useful, can this concept be upstreamed to OE-Core?

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

Re: [yocto] advice on recipe for shared lib mDNSResponder

2017-09-27 Thread Andre McCurdy 
On Wed, Sep 27, 2017 at 3:58 PM, Steve Pavao  wrote:
> Hello,
>
> I am fairly new to Yocto, yet have been able to successfully add a custom 
> kernel object to my Yocto poky build, no problem.  However, I am having some 
> difficulty adding a shared library, namely mDNSResponder.
>
> Right now, my recipe is very simple and does not use autotools.  There are 
> just a few tweaks for cross-building which I’ve added to the supplied 
> mDNSResponder Makefile for mDNSPosix, in order to target 64-bit ARM hardware. 
>  Here is the build error I encounter.  Obviously the environment is not being 
> set 100% correctly, because it can not find stdio.h.  Is there an easy way to 
> avoid this problem?

You need to ensure that the Makefiles etc for the package you are
building respect the ${CC} environment variable defined by OE. It
includes not only the name of the cross compiler but also important
command line options, e.g. tuning for the correct target CPU and the
correct --sysroot option. From your build log the --sysroot option is
missing, therefore the compiler can not find standard include files
etc.

Unfortunately packages with build with custom Makefiles are so diverse
that there's no single approach to making them work. Sometimes you can
force CC=${CC} etc via the make command line to over-ride incorrect
defaults in the Makefile, sometime the Makefile needs to be patched,
etc. Even if the build succeeds it's wise to carefully check the build
log to ensure that all calls to the compiler, linker, etc contain the
flags defined by OE.

Note however that according to the layer index there does already seem
to be at least one recipe for mDNSResponder. It includes a Makefile
patch which looks like it will address your issue (and some others):

  
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/tree/recipes-connectivity/mdns/mdns_544.bb?h=master

>
> - Steve Pavao
> Korg R
>
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 4
> | ERROR: oe_runmake failed
> | make os=EmbeddedLinuxAarch64 Daemon libdns_sd -C mDNSPosix
> | make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> | make[1]: Entering directory 
> '/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mDNSResponder/333.10-r0/mDNSPosix'
> | aarch64-poky-linux-gcc -I../mDNSCore -I../mDNSShared 
> -Iobjects/prod/EmbeddedLinuxAarch64 -fwrapv -W -Wall 
> -DPID_FILE=\"/var/run/mdnsd.pid\" -DMDNS_UDS_SERVERPATH=\"/var/run/mdnsd\" 
> -DNOT_HAVE_SA_LEN -DUSES_NETLINK -DHAVE_LINUX -DTARGET_OS_LINUX 
> -fno-strict-aliasing -Os -DMDNS_DEBUGMSGS=0   -c -o 
> objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o PosixDaemon.c
> | PosixDaemon.c:31:19: fatal error: stdio.h: No such file or directory
> |  #include 
> |^
> | compilation terminated.
> | Makefile:553: recipe for target 
> 'objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o' failed
> | make[1]: *** [objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o] Error 1
> --
> ___
> 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] advice on recipe for shared lib mDNSResponder

2017-09-27 Thread Steve Pavao 
Hello,

I am fairly new to Yocto, yet have been able to successfully add a custom 
kernel object to my Yocto poky build, no problem.  However, I am having some 
difficulty adding a shared library, namely mDNSResponder.

Right now, my recipe is very simple and does not use autotools.  There are just 
a few tweaks for cross-building which I’ve added to the supplied mDNSResponder 
Makefile for mDNSPosix, in order to target 64-bit ARM hardware.  Here is the 
build error I encounter.  Obviously the environment is not being set 100% 
correctly, because it can not find stdio.h.  Is there an easy way to avoid this 
problem?

- Steve Pavao
Korg R

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4
| ERROR: oe_runmake failed
| make os=EmbeddedLinuxAarch64 Daemon libdns_sd -C mDNSPosix
| make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
| make[1]: Entering directory 
'/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mDNSResponder/333.10-r0/mDNSPosix'
| aarch64-poky-linux-gcc -I../mDNSCore -I../mDNSShared 
-Iobjects/prod/EmbeddedLinuxAarch64 -fwrapv -W -Wall 
-DPID_FILE=\"/var/run/mdnsd.pid\" -DMDNS_UDS_SERVERPATH=\"/var/run/mdnsd\" 
-DNOT_HAVE_SA_LEN -DUSES_NETLINK -DHAVE_LINUX -DTARGET_OS_LINUX 
-fno-strict-aliasing -Os -DMDNS_DEBUGMSGS=0   -c -o 
objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o PosixDaemon.c
| PosixDaemon.c:31:19: fatal error: stdio.h: No such file or directory
|  #include 
|^
| compilation terminated.
| Makefile:553: recipe for target 
'objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o' failed
| make[1]: *** [objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o] Error 1
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-27 Thread Burton, Ross 
On 27 September 2017 at 21:59, Bryan Evenson 
wrote:

>
> I think I found the problem.  I started looking at more file properties
> for the files that worked and the ones that didn’t, and I noticed that all
> the ones that failed show a link count of 1024.  The Windows filesystem has
> a link limit of 1023 links per file (at least as reported here:
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> aa363860(v=vs.85).aspx), so I think the hard link is failing due to the
> Windows link limit.  If that is the case, then I don’t think it’ll be a
> quick fix to get a working solution under WSL.
>

That link count doesn't seem feasible though...  we hardlink frequently
during a recipe build, but I'd expect to see 10 links, not over a
thousand.  You've definitely found the problem, just need to figure out
what is causing such excessive linking,

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

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-27 Thread Bryan Evenson 
Ross,


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Wednesday, September 27, 2017 9:06 AM
To: Bryan Evenson 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash 
on Ubuntu on Windows)

On 27 September 2017 at 13:57, Bryan Evenson 
> wrote:

Feel free to compress and email it directly to me, but simply grepping for 
EINVAL (invalid argument error) might be enough.

I did a search on EINVAL and I got a bunch of entries of that look like this:

  linkat(AT_FDCWD, “”, AT_FDCWD, “”, 0) = -1 
EINVAL (Invalid argument)

I checked a few entries by doing a stat on the source and destination.  In each 
case, the source file exists at the specified path, was owned by the user 
account with which I’m doing the build, and had access rights of 0644.  Also in 
each case, the destination file did not exist but the destination directory did 
exist, the destination directory was owned by the user account with which I’m 
doing the build, and the destination directory had access rights of 0755.  From 
reading the man page for linkat, linkat should only return EINVAL if the flags 
argument is invalid, and 0 should be a valid value for flags.

I think there may be something missing from WSL’s implementation of linkat.  I 
am doing OPKG packages, so I’m guessing there is something different about the 
resulting function calls in the libc-package class as opposed to the 
package_ipk class.  I think I may enable the other package types to see if it 
is as successfully with RPMs and DEB packages.  I’m also going to see if there 
is an easier way to reproduce the problem to report the issue to Microsoft.

Good digging.  At least you can replicate it on demand, and have a strace 
showing it.  This bit of packaging happens before the rpm/opkg/deb specific 
code, so changing the packaging format won't help.

I think I found the problem.  I started looking at more file properties for the 
files that worked and the ones that didn’t, and I noticed that all the ones 
that failed show a link count of 1024.  The Windows filesystem has a link limit 
of 1023 links per file (at least as reported here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860(v=vs.85).aspx),
 so I think the hard link is failing due to the Windows link limit.  If that is 
the case, then I don’t think it’ll be a quick fix to get a working solution 
under WSL.

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

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Manjukumar Harthikote Matha 
Hi Otavio,

> -Original Message-
> From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br]
> Sent: Wednesday, September 27, 2017 12:23 PM
> To: Manjukumar Harthikote Matha 
> Cc: Khem Raj ; yo...@lists.yoctoproject.org; Otavio
> Salvador 
> Subject: Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS
> support"
> 
> On Wed, Sep 27, 2017 at 3:53 PM, Manjukumar Harthikote Matha
>  wrote:
> ...
> >> https://github.com/Freescale/meta-freescale/blob/master/classes/fsl-dynamic-
> >> packagearch.bbclass
> >>
> >> Something like this?
> >>
> >
> > This is very useful, can this concept be upstreamed to OE-Core?
> 
> I think so; if people agree with this concept I can work in upstreaming it.
> 
> There is also the machine-overrides-extender.bbclass[1] which allows
> for overrides to be added/removed based on other overrides.
> 
> 1. https://github.com/Freescale/meta-freescale/blob/master/classes/machine-
> overrides-extender.bbclass
> 
> This was how I could generalize the BSP in a kind of SoC feature set.
> 
> You can see the original commit where I enable it:
> 
> https://github.com/Freescale/meta-
> freescale/commit/ad4611ab16bcd09eef11d630159253a12c5ecced#diff-
> 7bac7755a2891a94e863ed0a7af1876a
> 
Thanks for the patch.

We were thinking on similar lines for SOC variants and MACHINE variants 
(basically boards supporting different features like GPU, VCU etc).  These 
configuration mechanism will help resolve these cases. 
SOARCH can also help in package-feed mechanism for boards

You should definitely considering up streaming these to OE-core

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

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Trevor Woerner 
On Wed, Sep 27, 2017 at 3:22 PM, Otavio Salvador
 wrote:
>> This is very useful, can this concept be upstreamed to OE-Core?
>
> I think so; if people agree with this concept I can work in upstreaming it.
>
> There is also the machine-overrides-extender.bbclass[1] which allows
> for overrides to be added/removed based on other overrides.
>
> 1. 
> https://github.com/Freescale/meta-freescale/blob/master/classes/machine-overrides-extender.bbclass

I've been trying (begging) since the start of August to get the above
one added to OE-core
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Otavio Salvador 
On Wed, Sep 27, 2017 at 5:14 PM, Manjukumar Harthikote Matha
 wrote:
>> -Original Message-
>> From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br]
>> Sent: Wednesday, September 27, 2017 12:23 PM
>> To: Manjukumar Harthikote Matha 
>> Cc: Khem Raj ; yo...@lists.yoctoproject.org; Otavio
>> Salvador 
>> Subject: Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS
>> support"
>>
>> On Wed, Sep 27, 2017 at 3:53 PM, Manjukumar Harthikote Matha
>>  wrote:
>> ...
>> >> https://github.com/Freescale/meta-freescale/blob/master/classes/fsl-dynamic-
>> >> packagearch.bbclass
>> >>
>> >> Something like this?
>> >>
>> >
>> > This is very useful, can this concept be upstreamed to OE-Core?
>>
>> I think so; if people agree with this concept I can work in upstreaming it.
>>
>> There is also the machine-overrides-extender.bbclass[1] which allows
>> for overrides to be added/removed based on other overrides.
>>
>> 1. https://github.com/Freescale/meta-freescale/blob/master/classes/machine-
>> overrides-extender.bbclass
>>
>> This was how I could generalize the BSP in a kind of SoC feature set.
>>
>> You can see the original commit where I enable it:
>>
>> https://github.com/Freescale/meta-
>> freescale/commit/ad4611ab16bcd09eef11d630159253a12c5ecced#diff-
>> 7bac7755a2891a94e863ed0a7af1876a
>>
> Thanks for the patch.
>
> We were thinking on similar lines for SOC variants and MACHINE variants 
> (basically boards supporting different features like GPU, VCU etc).  These 
> configuration mechanism will help resolve these cases.
> SOARCH can also help in package-feed mechanism for boards
>
> You should definitely considering up streaming these to OE-core

That was the goal. I will work on this.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_populate_sdk_ext always being triggered

2017-09-27 Thread Paul Eggleton 
Hi Andrea,

On Wednesday, 27 September 2017 10:17:42 PM NZDT Andrea Galbusera wrote:
> I noticed that periodically running 'bitbake -c do_populate_sdk_ext' for an
> image in my CI loop does always trigger the task to be executed even if no
> changes where applied either to metadata or to the configuration between
> two iterations. Is this expected? If so, why? Shouldn't SDK artifacts
> exploit the sstate as i.e. images do?

Ideally yes, but it's hard for us to tell if the metadata has changed or not, 
given that we care not just about the actual metadata but also any other files 
(scripts etc.) that come with it. Thus we've erred on the side of making it 
build every time.

Cheers,
Paul

-- 

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

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Otavio Salvador 
On Wed, Sep 27, 2017 at 3:53 PM, Manjukumar Harthikote Matha
 wrote:
...
>> https://github.com/Freescale/meta-freescale/blob/master/classes/fsl-dynamic-
>> packagearch.bbclass
>>
>> Something like this?
>>
>
> This is very useful, can this concept be upstreamed to OE-Core?

I think so; if people agree with this concept I can work in upstreaming it.

There is also the machine-overrides-extender.bbclass[1] which allows
for overrides to be added/removed based on other overrides.

1. 
https://github.com/Freescale/meta-freescale/blob/master/classes/machine-overrides-extender.bbclass

This was how I could generalize the BSP in a kind of SoC feature set.

You can see the original commit where I enable it:

https://github.com/Freescale/meta-freescale/commit/ad4611ab16bcd09eef11d630159253a12c5ecced#diff-7bac7755a2891a94e863ed0a7af1876a

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Otavio Salvador 
On Wed, Sep 27, 2017 at 2:20 PM, Khem Raj  wrote:
>
> On Wed, Sep 27, 2017 at 10:17 AM Andrei Gherzan  wrote:
>>
>> On Wed, Sep 27, 2017 at 4:23 PM, Martin Jansa 
>> wrote:
>>>
>>> * this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb.
>>> * this makes qtbase and everything which depends on some qt* recipe to
>>>   be effectivelly MACHINE_ARCH
>>>
>>> Signed-off-by: Martin Jansa 
>>> ---
>>>  dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>  delete mode 100644
>>> dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
>>>
>>> diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
>>> b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
>>> deleted file mode 100644
>>> index ae3f1d3..000
>>> --- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
>>> +++ /dev/null
>>> @@ -1,3 +0,0 @@
>>> -# Copyright (C) 2017 O.S. Systems Software LTDA.
>>> -
>>> -PACKAGECONFIG_GL_rpi   = "gles2 eglfs"
>>
>>
>> What would be the solution though?
>
> I think check for OpenGL feature to enable it
> I think another thing is to also check for X11 in distro features before
> enabling it
>
> Gl support is quite soc specific so I don't think there is an elegant way
> unless qt components can be built with soc specific elements as plugins or
> something which then can have independent recipe

https://github.com/Freescale/meta-freescale/blob/master/classes/fsl-dynamic-packagearch.bbclass

Something like this?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] want to execute a script having sudo : sudo cryptsetup

2017-09-27 Thread John Finley 
pseudo can't do some of the cryptsetup functions that really require root,
or at least I could not convince it to. Using sudo is not so good, but I
don't think there's an easy way around it for the cryptsetup stuff.

On Wed, Sep 27, 2017 at 10:22 AM, Khem Raj  wrote:

>
> On Wed, Sep 27, 2017 at 9:21 AM John Finley  wrote:
>
>> Try making it so the user doing the build is not prompted for a password
>> when they do "sudo". I have this in my vm:
>>
>
> I think you can leverage pseudo tool to emulate the root user during build
>
> john@vbox-ubuntu-16$ cat /etc/sudoers.d/john
>> john ALL=(ALL) NOPASSWD: ALL
>> john@vbox-ubuntu-16$
>> I don't know if that's all that's needed; I have to google it every time.
>>
>> On Mon, Sep 25, 2017 at 2:48 AM, Kumar, Shrawan > > wrote:
>>
>>> Hello Team ,
>>>
>>>
>>>
>>> I am trying to achieve below from yocto , do we have a way  ?
>>>
>>>
>>>
>>>
>>>
>>> dd if=/dev/zero of=hello.enc bs=4k count=$400
>>>
>>> mknod /dev/loop_dev_0
>>>
>>> losetup /dev/loop_dev_0 hello.enc
>>>
>>> *sudo* cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks and Regards
>>>
>>> Shrawan
>>>
>>>
>>>
>>> --
>>> ___
>>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] want to execute a script having sudo : sudo cryptsetup

2017-09-27 Thread Khem Raj 
On Wed, Sep 27, 2017 at 9:21 AM John Finley  wrote:

> Try making it so the user doing the build is not prompted for a password
> when they do "sudo". I have this in my vm:
>

I think you can leverage pseudo tool to emulate the root user during build

john@vbox-ubuntu-16$ cat /etc/sudoers.d/john
> john ALL=(ALL) NOPASSWD: ALL
> john@vbox-ubuntu-16$
> I don't know if that's all that's needed; I have to google it every time.
>
> On Mon, Sep 25, 2017 at 2:48 AM, Kumar, Shrawan 
> wrote:
>
>> Hello Team ,
>>
>>
>>
>> I am trying to achieve below from yocto , do we have a way  ?
>>
>>
>>
>>
>>
>> dd if=/dev/zero of=hello.enc bs=4k count=$400
>>
>> mknod /dev/loop_dev_0
>>
>> losetup /dev/loop_dev_0 hello.enc
>>
>> *sudo* cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks and Regards
>>
>> Shrawan
>>
>>
>>
>> --
>> ___
>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Andrei Gherzan 
On Wed, Sep 27, 2017 at 4:23 PM, Martin Jansa 
wrote:

> * this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb.
> * this makes qtbase and everything which depends on some qt* recipe to
>   be effectivelly MACHINE_ARCH
>
> Signed-off-by: Martin Jansa 
> ---
>  dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 ---
>  1 file changed, 3 deletions(-)
>  delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.
> bbappend
>
> diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> deleted file mode 100644
> index ae3f1d3..000
> --- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -# Copyright (C) 2017 O.S. Systems Software LTDA.
> -
> -PACKAGECONFIG_GL_rpi   = "gles2 eglfs"


What would be the solution though?

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

Re: [yocto] want to execute a script having sudo : sudo cryptsetup

2017-09-27 Thread John Finley 
Try making it so the user doing the build is not prompted for a password
when they do "sudo". I have this in my vm:
john@vbox-ubuntu-16$ cat /etc/sudoers.d/john
john ALL=(ALL) NOPASSWD: ALL
john@vbox-ubuntu-16$
I don't know if that's all that's needed; I have to google it every time.

On Mon, Sep 25, 2017 at 2:48 AM, Kumar, Shrawan 
wrote:

> Hello Team ,
>
>
>
> I am trying to achieve below from yocto , do we have a way  ?
>
>
>
>
>
> dd if=/dev/zero of=hello.enc bs=4k count=$400
>
> mknod /dev/loop_dev_0
>
> losetup /dev/loop_dev_0 hello.enc
>
> *sudo* cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2
>
>
>
>
>
>
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> --
> ___
> 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] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

2017-09-27 Thread Martin Jansa 
* this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb.
* this makes qtbase and everything which depends on some qt* recipe to
  be effectivelly MACHINE_ARCH

Signed-off-by: Martin Jansa 
---
 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 ---
 1 file changed, 3 deletions(-)
 delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend 
b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
deleted file mode 100644
index ae3f1d3..000
--- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-# Copyright (C) 2017 O.S. Systems Software LTDA.
-
-PACKAGECONFIG_GL_rpi   = "gles2 eglfs"
-- 
2.7.4

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

[yocto] want to execute a script having sudo : sudo cryptsetup

2017-09-27 Thread Kumar, Shrawan 
Hello Team ,

I am trying to achieve below from yocto , do we have a way  ?


dd if=/dev/zero of=hello.enc bs=4k count=$400
mknod /dev/loop_dev_0
losetup /dev/loop_dev_0 hello.enc
sudo cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2




Thanks and Regards
Shrawan

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

[yocto] do_configure error

2017-09-27 Thread mohammed aqdam 
Hi all,
i was trying to build rpi-test-image for my rpi3.

i'm getting the following error...

root@pcz-ee207837-2:/u/my_poky/poky-2/poky/build# bitbake -k rpi-test-image
Loading cache: 100%
|#|
Time: 0:00:01
Loaded 3160 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal-4.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
callconvention-hard cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
meta-raspberrypi  = "pyro:8ba2d6fc80b31c87d25c87c863e2a77752b07c3c"
meta-qt5  = "pyro:c6aa602d0640040b470ee81de39726276ddc0ea3"
meta-qt5-extra= "master:05d63591612623ce7751f5536690c40998188ad2"
meta-oe
meta-networking
meta-python
meta-multimedia   = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"

Initialising tasks: 100%
||
Time: 0:00:11
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
 configure: error: you should not run configure as root (set
FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
| See `config.log' for more details
| ERROR: Function failed: do_configure (log file is located at
/u/my_poky/poky-2/poky/build/tmp/work/x86_64-linux/coreutils-native/8.26-r0/temp/log.do_configure.17147)
ERROR: Task 
(virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/coreutils/coreutils_8.26.bb:do_configure)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4168 tasks of which 4167 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
  
virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/coreutils/coreutils_8.26.bb:do_configure
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

i checked for same branch while cloning the data, except for the
qt5-extra layer all are pyro.

what is that i'm missing?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SocketCan support for Yocto

2017-09-27 Thread Subramanian Ramachandran 
Hi Yocto Team,

I am using a custom Yocto linux distribution for my project and am interested 
in implementing socket can support for it.

I understand that socketcan is a kernel feature and needs to be included at 
build time while using the bitbake/toaster toolset.

The default yocto distribution of Krogoth I used does not contain socketcan by 
default. What flag do I need to enable to add socketcan support in the kernel? 
What is the variable I need to use in the bitbake/toaster environment to do 
this?  - I have already tried adding libsocketcan and can-utils to the image 
install append variable in toaster and it has not helped to incorporate socket 
can support.

Please advise.

Thanks,

Subbu



Disclaimer: This message (and any other messages in this email thread) contains 
information that may be privileged or confidential and is the property of 
AgJunction Inc and its subsidiaries. It is intended for the person to whom it 
is addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any 
part thereof. If you receive this message in error, please notify the sender 
immediately and delete all copies of this message.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-27 Thread Bryan Evenson 
Ross,

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, September 26, 2017 6:15 PM
To: Bryan Evenson 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash 
on Ubuntu on Windows)

On 26 September 2017 at 22:01, Bryan Evenson 
> wrote:
Now this *is* interesting.  Try removing the repeated slashes just in case the 
WSL ln is being incredibly pedantic (ie sstate-build-package//packages-split), 
but I don't seriously expect that to be the problem.  Running stat on the 
source and verifying the destination doesn't exist would be helpful.  Can you 
tell if that is the first ln that it is trying to do, or do many work and that 
one fails?  Does WSL have a working strace or similar to identify which exact 
syscall is failing?

I am about 60% through the full image build when it gets to glibc-locale with 
about half of the packages for the image fully complete.  I did a stat on one 
of the source files and verified it did exist, and it had 0644 for access 
rights and is owned by me.  I also verified that the destination file doesn’t 
exist.  WSL does have a working strace.  I ran strace on the failed cp command 
shown above and I now have a 56MB strace output file.  What should I be looking 
for in this file?

Feel free to compress and email it directly to me, but simply grepping for 
EINVAL (invalid argument error) might be enough.

I did a search on EINVAL and I got a bunch of entries of that look like this:

  linkat(AT_FDCWD, “”, AT_FDCWD, “”, 0) = -1 
EINVAL (Invalid argument)

I checked a few entries by doing a stat on the source and destination.  In each 
case, the source file exists at the specified path, was owned by the user 
account with which I’m doing the build, and had access rights of 0644.  Also in 
each case, the destination file did not exist but the destination directory did 
exist, the destination directory was owned by the user account with which I’m 
doing the build, and the destination directory had access rights of 0755.  From 
reading the man page for linkat, linkat should only return EINVAL if the flags 
argument is invalid, and 0 should be a valid value for flags.

I think there may be something missing from WSL’s implementation of linkat.  I 
am doing OPKG packages, so I’m guessing there is something different about the 
resulting function calls in the libc-package class as opposed to the 
package_ipk class.  I think I may enable the other package types to see if it 
is as successfully with RPMs and DEB packages.  I’m also going to see if there 
is an easier way to reproduce the problem to report the issue to Microsoft.

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

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-27 Thread Burton, Ross 
On 27 September 2017 at 13:57, Bryan Evenson 
wrote:

>
> Feel free to compress and email it directly to me, but simply grepping for
> EINVAL (invalid argument error) might be enough.
>
>
>
> I did a search on EINVAL and I got a bunch of entries of that look like
> this:
>
>
>
>   linkat(AT_FDCWD, “”, AT_FDCWD, “”, 0)
> = -1 EINVAL (Invalid argument)
>
>
>
> I checked a few entries by doing a stat on the source and destination.  In
> each case, the source file exists at the specified path, was owned by the
> user account with which I’m doing the build, and had access rights of
> 0644.  Also in each case, the destination file did not exist but the
> destination directory did exist, the destination directory was owned by the
> user account with which I’m doing the build, and the destination directory
> had access rights of 0755.  From reading the man page for linkat, linkat
> should only return EINVAL if the flags argument is invalid, and 0 should be
> a valid value for flags.
>
>
>
> I think there may be something missing from WSL’s implementation of
> linkat.  I am doing OPKG packages, so I’m guessing there is something
> different about the resulting function calls in the libc-package class as
> opposed to the package_ipk class.  I think I may enable the other package
> types to see if it is as successfully with RPMs and DEB packages.  I’m also
> going to see if there is an easier way to reproduce the problem to report
> the issue to Microsoft.
>

Good digging.  At least you can replicate it on demand, and have a strace
showing it.  This bit of packaging happens before the rpm/opkg/deb specific
code, so changing the packaging format won't help.

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

[yocto] do_populate_sdk_ext always being triggered

2017-09-27 Thread Andrea Galbusera 
I noticed that periodically running 'bitbake -c do_populate_sdk_ext' for an
image in my CI loop does always trigger the task to be executed even if no
changes where applied either to metadata or to the configuration between
two iterations. Is this expected? If so, why? Shouldn't SDK artifacts
exploit the sstate as i.e. images do?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto