Re: [yocto] Issues building Extensible SDK

[Robert Yang]

Hi Martin,

Try:

$ bitbake -e | grep '^INHERIT=.*uninative'

If there is nothing, then add the following line to conf/local.conf:

INHERIT += "uninative"

// Robert

On 01/10/2018 03:46 PM, Martin Siegumfeldt wrote:

Hi,

We have a custom piece of (Zynq based) HW that we render a custom distro using 
Yocto. I am trying to build the extensible SDK but run into the below error:

pokyuser@03c19f8798ba:/workdir/krogoth/build$ bitbake core-image-minimal -c 
populate_sdk_ext
Loading cache: 100% 
||
 Time: 0:00:00
Loaded 2675 entries from dependency cache.
Parsing recipes: 100% 
|##|
 Time: 0:00:01
Parsing of 1915 .bb files complete (1913 cached, 2 parsed). 2677 targets, 377 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "ubuntu-16.04"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE   = "zynq-soft-z7000-mb-v2"
DISTRO= "gomspace"
DISTRO_VERSION= "2.0"
TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU= "hard"
meta  = "pyro:9c75151116aa293dc8567c237d7e4da5bdec90e3"
meta-xilinx   = "pyro:18097af3120a394a8e6933b7abc85e73e508c7e3"
meta-oe
meta-filesystems
meta-networking
meta-python   = "pyro:dfbdd28d206a74bf264c2f7ee0f7b3e5af587796"
meta-z7000= "pyro:b255ea4575b40d77a2f5dc9200de0718f979f175"

Initialising tasks: 100% 
|###|
 Time: 0:00:03
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:copy_buildsystem(d)
  0003:
File: 
'/workdir/krogoth/openembedded-core/meta/classes/populate_sdk_ext.bbclass', 
lineno: 298, function: copy_buildsystem
  0294:f.write('TCLIBCAPPEND = ""\n')
  0295:f.write('DL_DIR = "${TOPDIR}/downloads"\n')
  0296:
  0297:f.write('INHERIT += "%s"\n' % 'uninative')
  *** 0298:f.write('UNINATIVE_CHECKSUM[%s] = "%s"\n\n' % 
(d.getVar('BUILD_ARCH'), uninative_checksum))
  0299:f.write('CONF_VERSION = "%s"\n\n' % 
d.getVar('CONF_VERSION', False))
  0300:
  0301:# Some classes are not suitable for SDK, remove them 
from INHERIT
  0302:f.write('INHERIT_remove = "%s"\n' % 
d.getVar('SDK_INHERIT_BLACKLIST', False))
Exception: UnboundLocalError: local variable 'uninative_checksum' referenced 
before assignment

ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: 
copy_buildsystem
ERROR: Logfile of failure stored in: 
/workdir/krogoth/build/tmp-glibc/work/zynq_soft_z7000_mb_v2-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.8408
ERROR: Task 
(/workdir/krogoth/openembedded-core/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 2214 tasks of which 2210 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
   
/workdir/krogoth/openembedded-core/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


The standard SDK builds successfully all the way back from Fido throughout 
Rocko, however we would now like to build the Extensible SDK. Krogoth version 
builds it successfully, but Pyro and Rocko throws the above error (haven't 
tested Morty).

I am unable to reproduce using Poky and thus assume it to be related to the 
configuration of our distro/image. Any suggestions are highly appreciated.

Thanks,
Martin




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

Re: [yocto] Where to further modify or remove some elements in the zImage and rootfs of the core-image-minimal build?

[Robert Yang]

Hi Nguyễn,

I don't quite understand what did you mean, did you mean where are the recipes ?
(bb files) ? For kernel, you can get if by:

$ bitbake -e virtual/kernel | grep '^FILE='

And for image:

$ bitbake -e core-image-minimal | grep '^FILE='

Please check yocto's doc for more info:

https://www.yoctoproject.org/documentation

You can start from:
Yocto Project Quick Start

And for kernel/bsp:
Yocto Project Linux Kernel Development Manual
Yocto Project Board Support Package (BSP) Developer's Guide

// Robert

On 01/10/2018 11:49 PM, Nguyễn Thanh Vũ  wrote:
I'm currently trying to build a very small image for my imx freescale board by 
further reducing the size of core-image-minimal build to make it boot faster. 
However, I do not know where the recipes for building the zImage (and rootfs) 
locate inside the yocto directory (fsl-release-bsp) to start modifying. For 
example, the networking/drivers/sound part in the kernel (net/built-in.o , 
sound/built-in.o ). Can anyone give me some hints?




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

Re: [yocto] Fwd: How to make the os-release package work with local walltime instead of GMT?

[Robert Yang]

Hi Davis,

You can try to add this to conf/local.conf or redefine it in os-release.bb:

BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"

// Robert

On 01/11/2018 12:55 PM, Davis Roman wrote:

Hello,

I'm trying to fullfill a requirement which states that I must have a file in my 
root filesystem which has the timestamp of when the rootfs was generated for 
traceability purposes.


I've included the os-release package into my image recipe.

However, when I cat /etc/os-release, I notice that the BUILD_ID variable does 
not reflect the actually time that my build took place.


Upon further inspection, I noticed in the os-release recipe that BUILD_ID is 
based on the DATETIME variable.


Drilling down further, I noticed that DATETIME is defined 
in ./meta/conf/bitbake.conf


     DATE := "${@time.strftime('%Y%m%d',time.gmtime())}"
     TIME := "${@time.strftime('%H%M%S',time.gmtime())}"
     DATETIME = "${DATE}${TIME}"

So it appears to me that DATETIME is based on gmttime.

Instead, I would like this to be based on wall time.

Any suggestions on how to do this?

Thank you,

Davis




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

[yocto] Fwd: How to make the os-release package work with local walltime instead of GMT?

[Davis Roman]

Hello,

I'm trying to fullfill a requirement which states that I must have a file
in my root filesystem which has the timestamp of when the rootfs was
generated for traceability purposes.

I've included the os-release package into my image recipe.

However, when I cat /etc/os-release, I notice that the BUILD_ID variable
does not reflect the actually time that my build took place.

Upon further inspection, I noticed in the os-release recipe that BUILD_ID
is based on the DATETIME variable.

Drilling down further, I noticed that DATETIME is defined
in ./meta/conf/bitbake.conf

DATE := "${@time.strftime('%Y%m%d',time.gmtime())}"
TIME := "${@time.strftime('%H%M%S',time.gmtime())}"
DATETIME = "${DATE}${TIME}"

So it appears to me that DATETIME is based on gmttime.

Instead, I would like this to be based on wall time.

Any suggestions on how to do this?

Thank you,

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

[yocto] [meta-oic] Question about Iotivity 1.3.0/1 and fixes status

[Chanho Park]

Hi Philippe,

I found you already prepared iotivity 1.3.0, 1.3.1 recipes and fixes in
your github tree[1].
I wonder why you don’t post them in the meta-oic. Do you have a plan to
upstream them?

Best Regards,
Chanho Park

[1]:
https://github.com/TizenTeam/meta-oic/tree/sandbox/pcoval/on/master/review
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Change initscript level

[Anuj Mittal]

On 01/11/2018 03:49 AM, Bishop, Mark (STRT) wrote:
> I am just trying to change modutils.sh to run from
> /etc/rcS.d/S05modutils.sh to /etc/rcS.d/S15modutils.sh
> 
>  
> 
> I can’t figure this out.  I have modified the
> yocto/source/arm/layers/core/meta/recipes-kernel/modutils-initscripts.bb
> 
>  
> 
> From: INITSCRIPT_PARAMS = "start 05 S ."
> 
> To: INITSCRIPT_PARAMS = "start 10 S ."
> 
>  
> 
> And I still only have S05modutils.sh
> 
> 
> The pkg_postinst_modutils-initscripts still has “start 05 S .” in
> build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/modutils-initscripts/1.0-r7/pkgdata/runtime/modutils-initscripts

I tried this and I can see the correct values. Which version of
poky/OE-core are you using? Can you try to bitbake -c cleansstate and
build modutils-initscripts again?

> 
>  
> 
> It’s quite apparent that I don’t know what I’m doing here and I could
> use some sage advice on how to move these startup levels around. 
> 
>  
> 
> Thank you.
> 
>  
> 
> *Mark Bishop*
> 
> *Sr. Firmware/Software Engineer – Microwave Subsystems***
> 
> * *
> 
> cid:image001.png@01D281ED.A45F0A90**
> 
> 4726 Eisenhower Blvd.
> 
> Tampa, FL 33634
> 
> USA
> 
>   
> 
>  
> 
> T  +1 813 901 7293
> 
> *mbis...@smithsinterconnectinc.com
> *
> 
>   
> 
> *smithsinterconnect.com* 
> 
> *TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!***
> 
>  
> 
>  
> 
> 
> This e-mail contains proprietary information some or all of which may be
> legally privileged. It is intended for the recipient only. If an
> addressing or transmission error has misdirected this e-mail, please
> notify the authority by replying to this e-mail. If you are not the
> intended recipient you must not use, disclose, distribute, copy, print,
> or rely on this e-mail. In addition, information contained in or
> attached to this e-mail may be subject to either 22 C.F.R. Parts
> 120?130, or 15 C.F.R. Parts 730-774. These regulations prohibit the
> release or disclosure of certain information contained herein to anyone
> who is not a U.S. citizen or permanent resident alien, without a license
> first having been issued. Failure to observe such requirements is a
> violation of U.S. law that carries serious penalties.   ­­  
> 
> 

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

Re: [yocto] beta testing netbooting Yocto on Amazon, Google & Digital Ocean

[Andrew Stuart]

Hi William - thanks for the feedback - when you make a new thing it’s always 
really aprpeciated to get any comments.

>>I looked at your documentation.  You have a section "Is bootrino open source?”
>>You don't really answer the question.  

You’re right - I’ll remove that - it’s a website so the question that the 
documentation poses doesn’t really make sense.

>>>You also say there is an MIT licensed CLI.  OK.

Yes, an MIT license CLI is planned but not built yet.

But you do not mention the server code itself.
From that I assume the answer to the question "Is bootrino open source?" is 
no.
Am I correct?

Correct - the bootrino website/console is not open source.

>>> So for my own POV I would not want to give this access to my cloud account 
>>> without seeing the code and perhaps running it on my own server so I can be 
>>> sure of what I am getting.  

There’s not really any server behind bootrino - apart from user account 
creation it’s all client side. User accounts are created on Amazon Cognito 
which is a service purely for creating and authenticating users.  Apart from 
that bootrino has no back end. 

>>> I could setup a scratch account but I would worry even then and I would 
still have concerns ever going to "production" mode.  I am a bit picky that 
way.  

I understand the concern totally.  One of my primary considerations designing 
bootrino is your cloud account keys.  I wanted to ensure they are never sent to 
the bootrino back end because of the trust issue that anyone would reasonably 
have. So your cloud account keys are stored locally in your browser and never 
send to the bootrino back end - which consists only of Amazon Cognito anyway as 
mentioned.
Watching network requests from the browsers developer tools or setting up a 
network analyzer would show that your cloud account keys are not sent to any 
bootrino back end.

So, you might ask, if bootrino effectively has no back end, then how does it 
work?  The answer is that the bootrino JavaScript running in your web browser 
talks directly to your cloud REST API with no third party in between. That’s as 
secure as I could make it - the keys stay on your machine and your machine 
talks directly to your cloud so you need never wonder about the trust level for 
bootrino’s back end systems.

>>>Others may not feel the same way.  I wish you luck.
Thanks Bill I appreciate your feebdack and candid comments.









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

[yocto] Change initscript level

[Bishop, Mark (STRT)]

I am just trying to change modutils.sh to run from /etc/rcS.d/S05modutils.sh to 
/etc/rcS.d/S15modutils.sh

I can't figure this out.  I have modified the 
yocto/source/arm/layers/core/meta/recipes-kernel/modutils-initscripts.bb

From: INITSCRIPT_PARAMS = "start 05 S ."
To: INITSCRIPT_PARAMS = "start 10 S ."

And I still only have S05modutils.sh

The pkg_postinst_modutils-initscripts still has "start 05 S ." in 
build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/modutils-initscripts/1.0-r7/pkgdata/runtime/modutils-initscripts

It's quite apparent that I don't know what I'm doing here and I could use some 
sage advice on how to move these startup levels around.

Thank you.

Mark Bishop
Sr. Firmware/Software Engineer - Microwave Subsystems

[cid:image001.png@01D281ED.A45F0A90]

4726 Eisenhower Blvd.
Tampa, FL 33634
USA


T  +1 813 901 7293

mbis...@smithsinterconnectinc.com

smithsinterconnect.com

TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!





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

[yocto] [PATCH][meta-mingw] machine-sdk: use gettext for libintl, not mingw-runtime

[Ross Burton]

The MinGW runtime doesn't provide libintl, so set gettext as the preferred
provider for libintl.

Signed-off-by: Ross Burton 
---
 conf/machine-sdk/i686-mingw32.conf   | 3 +--
 conf/machine-sdk/x86_64-mingw32.conf | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/conf/machine-sdk/i686-mingw32.conf 
b/conf/machine-sdk/i686-mingw32.conf
index d426fe3..cb08bee 100644
--- a/conf/machine-sdk/i686-mingw32.conf
+++ b/conf/machine-sdk/i686-mingw32.conf
@@ -6,7 +6,7 @@ GCCTHREADS_mingw32 = "win32"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
-PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-mingw-w64-runtime"
+PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-gettext"
 PREFERRED_PROVIDER_virtual/nativesdk-libiconv = "nativesdk-libiconv"
 
 USE_NLS_mingw32 = "no"
@@ -33,4 +33,3 @@ BB_HASHBASE_WHITELIST_append = " WINDRES RC"
 
 # Needed to override no-static-libs.inc
 DISABLE_STATIC_mingw32 = ""
-
diff --git a/conf/machine-sdk/x86_64-mingw32.conf 
b/conf/machine-sdk/x86_64-mingw32.conf
index b9706f9..8786413 100644
--- a/conf/machine-sdk/x86_64-mingw32.conf
+++ b/conf/machine-sdk/x86_64-mingw32.conf
@@ -6,7 +6,7 @@ GCCTHREADS_mingw32 = "win32"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
-PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-mingw-w64-runtime"
+PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-gettext"
 PREFERRED_PROVIDER_virtual/nativesdk-libiconv = "nativesdk-libiconv"
 
 USE_NLS_mingw32 = "no"
@@ -33,4 +33,3 @@ BB_HASHBASE_WHITELIST_append = " WINDRES RC"
 
 # Needed to override no-static-libs.inc
 DISABLE_STATIC_mingw32 = ""
-
-- 
2.11.0

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

[yocto] Where to further modify or remove some elements in the zImage and rootfs of the core-image-minimal build?

[Nguyễn Thanh Vũ]

I'm currently trying to build a very small image for my imx freescale board
by further reducing the size of core-image-minimal build to make it boot
faster. However, I do not know where the recipes for building the zImage
(and rootfs) locate inside the yocto directory (fsl-release-bsp) to start
modifying. For example, the networking/drivers/sound part in the kernel
(net/built-in.o , sound/built-in.o ). Can anyone give me some hints?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] beta testing netbooting Yocto on Amazon, Google & Digital Ocean

[Mills, William]

Andrew,

Interesting project.

I looked at your documentation.  You have a section "Is bootrino open source?"
You don't really answer the question.  
So your site is free to use casually and paid options for more serious users.
That’s fine; it's your server.
You also say there is an MIT licensed CLI.  OK.
But you do not mention the server code itself.
From that I assume the answer to the question "Is bootrino open source?" is no.
Am I correct?

(Not sure why you are telling us how you made it if we can't see the code 
anyway. :) )

So for my own POV I would not want to give this access to my cloud account 
without seeing the code and perhaps running it on my own server so I can be 
sure of what I am getting.  I could setup a scratch account but I would worry 
even then and I would still have concerns ever going to "production" mode.  I 
am a bit picky that way.  

Others may not feel the same way.  I wish you luck.

BTW: If you don't want to go open source, you may do better if you offer full 
source (w/ proprietary license) with the payed option.

Thanks,
Bill

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Andrew Stuart
Sent: Tuesday, January 9, 2018 10:31 PM
To: Yocto Project
Subject: [yocto] beta testing netbooting Yocto on Amazon, Google & Digital Ocean

Hi folks,

I built a website to make it easy to netboot Run-From-RAM operating systems 
like Yocto Linux on cloud hosts (Google, Amazon & Digital Ocean).

I wanted to see if anyone might be interested to give it a try as a beta test.

It’s absolutely brand new so likely has bugs and issues.

website is https://www.bootrino.com
documentation is https://doc.bootrino.com console is 
https://console.bootrino.com

Let me know if you’re interested cause I’d be interested to help directly if 
any issues come up.

thanks!

Andrew

--
___
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] rdepends = "python3-modules" in recipe does not install python3-modules in image

[Alexander Kanavin]

On 01/09/2018 08:45 PM, Matt Schepers wrote:

For this recipe the base package is called users.rpm and I can see it in the 
RPM. Using 'bitbake users -e | grep PN' I was able to find that PN is also set 
to users, which seems correct.

However the recipe does not install python3-modules even though it's specified 
in RDEPENDS. I can get it to work by forcing python3-modules in the 
IMAGE_INSTALL variable, but this is not how I expect yocto to work based on the 
documentation.


Then you need to inspect the user.rpm file using the rpm toolset, and 
find out whether python3-modules is indeed in package dependencies.


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

Re: [yocto] [meta-swupd][PATCH 1/1] bundles.py: allow username/password encoded in URLs

[Patrick Ohly]

On Tue, 2018-01-09 at 19:28 +0100, Ingo Flaschberger wrote:
> Dear Patrick,
> 
> it works if you replace:
>  manager.add_password(None, parsed_url, parsed_url.username, 
> parsed_url.password)
> with:
>   manager.add_password(None, new_url, parsed_url.username, 
> parsed_url.password)

I assume this works on top of my proposal. To avoid such ambiguity and
the risk that something gets merged that is still incomplete, please
post the entire patch as tested by you. The right way would be "git
send-email", but I can also take "git diff" attached to an email.

-- 
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