Re: [yocto] Reducing the size of the image by optimizing python

2019-10-21 Thread Ross Burton

On 19/10/2019 13:45, Abhi Arora wrote:

IMAGE_INSTALL_append = " \
     python3 \




This is installing "all of python".  If you want to trim your Python 
installation then don't do that, instead determine what libraries you 
*actually* need and explicitly add those.


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


[yocto] [prelink-cross] Bug 13529 add SPDX identifier

2019-10-21 Thread Yann CARDAILLAC
Hi Mark Hatle, Jakub Jelinek,

I'm currently beginning the work on bug 13529:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13529

The purpose is to add SPDX identifier to scripts and sources.

Most of the sources have licences on the sources, however some of them
don't, and I've question about others :

- src/sha.c do not shall it be GPLV2-or-later as most of the other?
- how to licence m4/libelf.m4 ? I'd prefer you to tell me exactly what to
add in order to avoid errors
- what about *.C files ? They don't have licence header, they look like C
file to me so I'd probably add :
// SPDX-License-Identifier: GPL-2.0-or-later
- what about testsuite/ files ?

Shall every thing just be GPL-2.0-or-later?

Best Regards,

Yann CARDAILLAC

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH] [auto-upgrade-helper] Add SPDX identifier to auto-upgrade-helper

2019-10-21 Thread Yann CARDAILLAC
Hi guys,

I'm working on bug :
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13531

I've add GPLV2-or-later to all the sources, is there any modification you
want to add?

Best regards,

Yann CARDAILLAC
-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From d90316a23834c5631b352e123ebfbfb3b1bd02e5 Mon Sep 17 00:00:00 2001
From: Yann CARDAILLAC 
Date: Mon, 21 Oct 2019 14:40:35 +0200
Subject: [PATCH] add SPDX Licence identifier

Signed-off-by: Yann CARDAILLAC 
---
 modules/buildhistory.py   | 1 +
 modules/errors.py | 1 +
 modules/statistics.py | 1 +
 modules/steps.py  | 1 +
 modules/testimage.py  | 1 +
 modules/utils/__init__.py | 1 +
 modules/utils/bitbake.py  | 1 +
 modules/utils/devtool.py  | 1 +
 modules/utils/emailhandler.py | 1 +
 modules/utils/git.py  | 1 +
 upgradehelper.py  | 1 +
 11 files changed, 11 insertions(+)
 mode change 100755 => 100644 upgradehelper.py

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index e78da05..4fdc36c 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2015 Intel Corporation
diff --git a/modules/errors.py b/modules/errors.py
index ad56215..fa543f7 100644
--- a/modules/errors.py
+++ b/modules/errors.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
diff --git a/modules/statistics.py b/modules/statistics.py
index db83c5b..323d042 100644
--- a/modules/statistics.py
+++ b/modules/statistics.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
diff --git a/modules/steps.py b/modules/steps.py
index 87d7584..1465b78 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2015 Intel Corporation
diff --git a/modules/testimage.py b/modules/testimage.py
index 35e23c9..4272c84 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2015 Intel Corporation
diff --git a/modules/utils/__init__.py b/modules/utils/__init__.py
index e69de29..315c06b 100644
--- a/modules/utils/__init__.py
+++ b/modules/utils/__init__.py
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
diff --git a/modules/utils/bitbake.py b/modules/utils/bitbake.py
index 2ae3a1c..4835ca6 100644
--- a/modules/utils/bitbake.py
+++ b/modules/utils/bitbake.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
diff --git a/modules/utils/devtool.py b/modules/utils/devtool.py
index 7f5b5d4..0d27bb0 100644
--- a/modules/utils/devtool.py
+++ b/modules/utils/devtool.py
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
 import os
 import logging as log
 from logging import debug as D
diff --git a/modules/utils/emailhandler.py b/modules/utils/emailhandler.py
index 8436364..066f013 100644
--- a/modules/utils/emailhandler.py
+++ b/modules/utils/emailhandler.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
diff --git a/modules/utils/git.py b/modules/utils/git.py
index 749d24d..abdcc47 100644
--- a/modules/utils/git.py
+++ b/modules/utils/git.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
diff --git a/upgradehelper.py b/upgradehelper.py
old mode 100755
new mode 100644
index bdd6d4e..2cfa94a
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-or-later
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
-- 
2.7.4

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


[yocto] Ext4 filesystem name does not exist

2019-10-21 Thread Muhlenkamp, Lewis
Hello,

I have been doing builds using a Docker setup on a VMware ESXi 6.5 virtual 
machine running Ubuntu 18.04 for the past year.  I have been asked to move to 
building on a VM in Azure.  I created a VM in Azure using the Ubuntu 18.04 
image from Canonical.  When I try to do the same build in Azure, I get the 
following error messages:

=== Start ERROR messages ===
ERROR: docker-base-image-1.0-r0 do_image_wic: Function failed: do_image_wic 
(log file is located at 
/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/temp/log.do_image_wic.44033)
ERROR: Logfile of failure stored in: 
/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/temp/log.do_image_wic.44033
| OSError: [Errno 22] Invalid argument
| wic.filemap.Error: cannot get block size for 
'/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/deploy-foo-image-complete/foo-intel-corei7-64-0.0.13/tmp.wic.5lmon88k/boot.img':
 [Errno 22] Invalid argument
| ERROR: Function failed: do_image_wic (log file is located at 
/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/temp/log.do_image_wic.44033)
ERROR: Task 
(/home/blah/meta-stryker/common/recipes-common/images/foo.bb:do_image_wic) 
failed with exit code '1'
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR:   Ext4 filesystem name 
(/home/blah/build-0.0.13/tmp-glibc/deploy/images/intel-corei7-64/foo-intel-corei7-64-0.0.13.rootfs.ext4)
 does not exist.
=== End ERROR messages ===

The log.do_image_wic.44033 has the following stack trace.

=== Start log.do_image_wic.44033 stack trace ===
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_image_wic
INFO: Creating image(s)...

WARNING: overhead-factor was specified, but size was not, so bitbake variables 
will be used for the size. In this case both IMAGE_OVERHEAD_FACTOR and 
--overhead-factor will be applied
Traceback (most recent call last):
  File "/home/blah/oe-core/scripts/lib/wic/filemap.py", line 97, in __init__
self.block_size = get_block_size(self._f_image)
  File "/home/bruce/oe-core/scripts/lib/wic/filemap.py", line 40, in 
get_block_size
binary_data = fcntl.ioctl(file_obj, 2, struct.pack('I', 0))
OSError: [Errno 22] Invalid argument

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/blah/oe-core/scripts/wic", line 534, in 
sys.exit(main(sys.argv[1:]))
  File "/home/blah/oe-core/scripts/wic", line 529, in main
return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage, subcommands)
  File "/home/blah/oe-core/scripts/lib/wic/help.py", line 98, in 
invoke_subcommand
subcmd[0](args, usage)
  File "/home/blah/oe-core/scripts/wic", line 234, in wic_create_subcommand
native_sysroot, options)
  File "/home/blah/oe-core/scripts/lib/wic/engine.py", line 202, in wic_create
plugin.do_create()
  File "/home/blah/oe-core/scripts/lib/wic/plugins/imager/direct.py", line 101, 
in do_create
self.assemble()
  File "/home/blah/oe-core/scripts/lib/wic/plugins/imager/direct.py", line 218, 
in assemble
self._image.assemble()
  File "/home/blah/oe-core/scripts/lib/wic/plugins/imager/direct.py", line 605, 
in assemble
sparse_copy(source, self.path, seek=part.start * self.sector_size)
  File "/home/blah/oe-core/scripts/lib/wic/filemap.py", line 552, in sparse_copy
fmap = api(src_fname)
  File "/home/blah/oe-core/scripts/lib/wic/filemap.py", line 534, in filemap
return FilemapFiemap(image, log)
  File "/home/blah/oe-core/scripts/lib/wic/filemap.py", line 352, in __init__
_FilemapBase.__init__(self, image, log)
  File "/home/blah/oe-core/scripts/lib/wic/filemap.py", line 100, in __init__
% (self._image_path, err))
wic.filemap.Error: cannot get block size for 
'/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/deploy-foo-image-complete/foo-intel-corei7-64-0.0.13/tmp.wic.5lmon88k/boot.img':
 [Errno 22] Invalid argument
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_image_wic (log file is located at 
/home/blah/build-0.0.13/tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/temp/log.do_image_wic.44033)
=== End log.do_image_wic.44033 stack trace ===

For some reason, it looks like it appears on the Azure VM the build is looking 
for boot.img in a temporary directory, 
.../tmp-glibc/work/intel_corei7_64-oe-linux/foo/1.0-r0/deploy-foo-complete/foo-intel-corei7-64-0.0.13/tmp.wic.5lmon88k.
  The tmp.wic.5lmon88k does not exist.  However, in the 
.../foo-intel-corei7-64-0.0.13 there is a boot.img file.

So, I'm very confused as to why my build works on my VMware ESXi 6.5 VM but not 
on the Azure VM.  I'm using docker-ce 18.09.1 on my VMware ESXi 6.5 VM.  I am 
using docker-ce 19.03.3 on my Azure VM.  The Dockerfile and all of the files 
I'm copying into the Docker image are the same.  I've done side by side builds. 
 So, I'm very confident I'm download

Re: [yocto] [OE-core] [prelink-cross] Bug 13529 add SPDX identifier

2019-10-21 Thread Mark Hatle
On 10/21/19 4:43 AM, Yann CARDAILLAC wrote:
> Hi Mark Hatle, Jakub Jelinek,

Jakub is no longer supporting this code, but he may have valuable insights into
licensing.

> I'm currently beginning the work on bug 13529:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13529
> 
> The purpose is to add SPDX identifier to scripts and sources.
> 
> Most of the sources have licences on the sources, however some of them don't,
> and I've question about others :
> 
> - src/sha.c do not shall it be GPLV2-or-later as most of the other?

/* sha.c - Functions to compute the SHA1 hash (message-digest) of files
   or blocks of memory.  Complies to the NIST specification FIPS-180-1.

   Copyright (C) 2000, 2001, 2003 Scott G. Miller

   Credits:
  Robert Klep   -- Expansion function fix
   NOTE: The canonical source of this file is maintained in GNU coreutils.
*/

The last line is the key.  This apparently came from GNU coreutils.

From the SCM logs, sha.c was introduced in approx 2003-07-01 from what it looks
like.  So it's a pretty old version.  You will need to do some detective work,
and find older versions of coreutils until you find the one that corresponds to
the code that was checked in.  Start back in 2003 and work backwards as
necessary.  (The version that matches to the original 2003-07-01 should be the
reasonable license to use.)

> - how to licence m4/libelf.m4 ? I'd prefer you to tell me exactly what to add 
> in
> order to avoid errors

The original version of the m4/libelf.m4 was introduced 2001-09-27.  It appears
to me that it was written as part of the prelinker, so would be under the
overall license of the prelinker.

Based on this, my assumption is that it is GPL-2.0

I do not see any 'or-later' clauses anywhere.

> - what about *.C files ? They don't have licence header, they look like C file
> to me so I'd probably add :
> // SPDX-License-Identifier: GPL-2.0-or-later

There are each simply test cases.  They would be covered by the overall
'COPYING' for the package.  Thus GPL-2.0

> - what about testsuite/ files ?

Same, no specifically stated license will be GPL-2.0.

> Shall every thing just be GPL-2.0-or-later?

Also just to be clear.  As I am NOT the original author of this work, I won't
accept a patch to remove any existing license text from the headers in this
software, but I will accept the SPDX-License-Identifier to be added in addition
to the existing license text.

If an existing file does not have any License text in it, then we will need to
assume that the COPYING file covers all software unless there is some indicator
it comes from another source with a different license.  For items w/o existing
licenses, just adding the SPDX-License-Identifier will be acceptable.

So in a header similar to:

/* Copyright (C) 2001, 2002, 2003, 2007 Red Hat, Inc.
   Written by Jakub Jelinek , 2001.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software Foundation,
   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

please add the header between the 'Written by' and the existing license text,
such as:

/* Copyright (C) 2001, 2002, 2003, 2007 Red Hat, Inc.
   Written by Jakub Jelinek , 2001.

   SPDX-License-Identifier: GPL-2.0-or-later

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by


> Best Regards,
> 
> Yann CARDAILLAC
> 
> -- 
> SMILE 
> 
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> 
>   
> *Yann CARDAILLAC*
> Ingénieur Systèmes Embarqués
> 
> email yann.cardail...@smile.fr 
> url http://www.smile.eu
> 
> Twitter  Facebook
>  LinkedIn
>  Github 
> 
> 
> 
> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [layerindex-web] Add SPDX Identifier

2019-10-21 Thread Yann CARDAILLAC
Hi,

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13527

I'm beginning the work of updating the layerindex-web repo, this one is a
bit tricky, how should I treat the files generated using Django ?

*For now I've given them MIT as for the other hand written script. However
I'm kind of worried that it's not the proper licence. *

For the css side, I've added MIT to :

./rrs/static/css/rrs-additional.css
and
./layerindex/static/css/additional.css

*I've let the bootstraps css untouched since I guess that's not for us to
licence. *

I've yet to do html, txt and sh files, do you have any advices before I
start?

Regards,

-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Error while building Toolchain for IMX

2019-10-21 Thread Mohammed Abdul Mubeen
Hi Team,

I have tried building a customized toolchain for IMX based board using Yocto 
warrior release.
I am stuck with the below error, and I am unable to understand how to get to 
the root cause.

NOTE: Installing globbed packages...
ERROR: 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:do_populate_sdk(d)
 0003:
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/classes/populate_sdk_base.bbclass',
 lineno: 153, function: do_populate_sdk
 0149:
 0150:populate_sdk(d)
 0151:
 0152:fakeroot python do_populate_sdk() {
*** 0153:populate_sdk_common(d)
 0154:}
 0155:SSTATETASKS += "do_populate_sdk"
 0156:SSTATE_SKIP_CREATION_task-populate-sdk = '1'
 0157:do_populate_sdk[cleandirs] = "${SDKDEPLOYDIR}"
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/classes/populate_sdk_base.bbclass',
 lineno: 150, function: populate_sdk_common
 0146:manifest_type=Manifest.MANIFEST_TYPE_SDK_HOST)
 0147:create_manifest(d, manifest_dir=d.getVar('SDK_DIR'),
 0148:manifest_type=Manifest.MANIFEST_TYPE_SDK_TARGET)
 0149:
*** 0150:populate_sdk(d)
 0151:
 0152:fakeroot python do_populate_sdk() {
 0153:populate_sdk_common(d)
 0154:}
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/lib/oe/sdk.py',
 lineno: 417, function: populate_sdk
 0413:env_bkp = os.environ.copy()
 0414:
 0415:img_type = d.getVar('IMAGE_PKGTYPE')
 0416:if img_type == "rpm":
*** 0417:RpmSdk(d, manifest_dir).populate()
 0418:elif img_type == "ipk":
 0419:OpkgSdk(d, manifest_dir).populate()
 0420:elif img_type == "deb":
 0421:DpkgSdk(d, manifest_dir).populate()
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/lib/oe/sdk.py',
 lineno: 42, function: populate
 0038:def populate(self):
 0039:self.mkdirhier(self.sdk_output)
 0040:
 0041:# call backend dependent implementation
*** 0042:self._populate()
 0043:
 0044:# Don't ship any libGL in the SDK
 0045:self.remove(os.path.join(self.sdk_output, 
self.sdk_native_path,
 0046: self.d.getVar('libdir_nativesdk').strip('/'),
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/lib/oe/sdk.py',
 lineno: 182, function: _populate
 0178:self.target_pm.remove_packaging_data()
 0179:
 0180:bb.note("Installing NATIVESDK packages")
 0181:self._populate_sysroot(self.host_pm, self.host_manifest)
*** 0182:self.install_locales(self.host_pm)
 0183:
 0184:self.host_pm.run_intercepts(populate_sdk='host')
 0185:
 0186:execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/lib/oe/sdk.py',
 lineno: 108, function: install_locales
 0104:# Generate a locale archive of them
 0105:target_arch = self.d.getVar('SDK_ARCH')
 0106:rootfs = oe.path.join(self.sdk_host_sysroot, 
self.sdk_native_path)
 0107:localedir = oe.path.join(rootfs, 
self.d.getVar("libdir_nativesdk"), "locale")
*** 0108:generate_locale_archive(self.d, rootfs, target_arch, 
localedir)
 0109:# And now delete the binary locales
 0110:pkgs = fnmatch.filter(pm.list_installed(), 
"nativesdk-glibc-binary-localedata-*.utf-8")
 0111:pm.remove(pkgs)
 0112:else:
File: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/sources/poky/meta/lib/oe/package_manager.py',
 lineno: 134, function: generate_locale_archive
 0130:# Need to set this so cross-localedef knows where the archive is
 0131:env = dict(os.environ)
 0132:env["LOCALEARCHIVE"] = oe.path.join(localedir, "locale-archive")
 0133:
*** 0134:for name in os.listdir(localedir):
 0135:path = os.path.join(localedir, name)
 0136:if os.path.isdir(path):
 0137:cmd = ["cross-localedef", "--verbose"]
 0138:cmd += arch_options
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/build/tmp/work/imx6solopd1600_prod-poky-linux-gnueabi/clifford-sdk/1.0-r0/sdk/image/opt/pico/1.0/sysroots/i686-picodigital-linux/usr/lib/locale'

ERROR: [Errno 2] No such file or directory: 
'/home/rama/sri_clifford-1-5-jalan/meta-picodigital/build/tmp/work/imx6solopd1600_prod-poky-linux-gnueabi/clifford-sdk/1.0-r0/sdk/image/opt/pico/1.0/sysroots/i686-picodigital-linux/usr/lib/locale'
DEBUG: Python fu

Re: [yocto] Reducing the size of the image by optimizing python

2019-10-21 Thread Mike Looijmans
> Optimising to just pyc files is an optimisation further than most
> people find they need and will be much harder to do.

It's actually quite simple, just add a bbappend to the python recipe that puts 
all .py files into the "dbg" or newly created "src" package. Or simply delete 
all .py files in a do_install_append.


Here's an example of the "src" approach:

https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-devtools/python/python_2.7.13.bbappend


Simply doing this in the bbappend might also work (untested):

do_install_append() {
find ${D}${libdir}/python${PYTHON_MAJMIN}/ -name '*.py' -remove
}


Removing the ".py" files roughly cuts the disk space in half.


The "src" approach works on any package, and has the advantage that you can 
still install the source files for debugging and development.

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: {E-mail
W: www.topicproducts.com

Please consider the environment before printing this e-mail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Useradd: crypted passwords longer than 8 characters

2019-10-21 Thread Lukasz Zemla
What is the best way in Yocto (warrior) to add crypted password to /etc/shadow 
during buildtime?

Using useradd.bbclass in a standard way we may add only passwords <= 8 
characters.
"-p" parameterr followed by the output of "openssl passwd -crypt pAsswOrd" 
works fine.

I thought that class may be cheated by providing after "-p" string returned by 
"openssl passwd -6 verylongpAsswOrd", but it does not work: the password in 
/etc/shadow file is truncated:

myuser:/D163GofCVEpMgZ.w2Ro3Z.b5S8XT1:18190:0:9:7:::

Any suggestions?

Thank you in advance.
Lukasz Zemla

***
The information in this email is confidential and intended solely for the 
individual or entity to whom it is addressed.  If you have received this email 
in error please notify the sender by return e-mail, delete this email, and 
refrain from any disclosure or action based on the information.
***
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Useradd: crypted passwords longer than 8 characters

2019-10-21 Thread Mark Hatle
Crypt the password yourself and pass it in to the adduser command.

--Mark

On 10/21/19 10:25 AM, Lukasz Zemla wrote:
> What is the best way in Yocto (warrior) to add crypted password to 
> /etc/shadow during buildtime?
> 
> Using useradd.bbclass in a standard way we may add only passwords <= 8 
> characters.
> "-p" parameterr followed by the output of "openssl passwd -crypt pAsswOrd" 
> works fine.
> 
> I thought that class may be cheated by providing after "-p" string returned 
> by "openssl passwd -6 verylongpAsswOrd", but it does not work: the password 
> in /etc/shadow file is truncated:
> 
> myuser:/D163GofCVEpMgZ.w2Ro3Z.b5S8XT1:18190:0:9:7:::
> 
> Any suggestions?
> 
> Thank you in advance.
> Lukasz Zemla
> 
> ***
> The information in this email is confidential and intended solely for the 
> individual or entity to whom it is addressed.  If you have received this 
> email in error please notify the sender by return e-mail, delete this email, 
> and refrain from any disclosure or action based on the information.
> ***
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2019-10-21 Thread Stephen K Jolley
All,



The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:



https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs



The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.



Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 298
unassigned or newcomer bugs.



We're hoping people may be able to spare some time now and again to help
out with these.  Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system.  There are also roughly four different "priority"
classes right now, “3.1”, “3.2, "3.99" and "Future", the more
pressing/urgent issues being in "3.1" and then “3.2”.



Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

-- 

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] OEDEM at Yocto Project Summit after ELCE

2019-10-21 Thread Philip Balister
Just a reminder we are holding a developer meeting as part of the Yocto
Project Summit after ELCE in Lyon next week.

Please review the agenda and add items. We need to create a schedule
with times to help people involved with day 2 of the Yocto Project
Summit. Help us out by getting everything you think we should discuss in
person on the agenda!

Information on the developer meeting and links to the Yocto Project
Summit are at:

https://www.openembedded.org/wiki/OEDEM_2019

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


[yocto] [yocto-autobuilder2][yocto-autobuilder-helper]Updated the Stand-alone Installation details

2019-10-21 Thread Marco
Modified the README-Guide.md.
See thread "[yocto-autobuilder-helper] Replaced hardcoded BASE_HOMEDIR
directory"
--
Marco
From 30ed13445a01a2af759791cb39526437b43906c0 Mon Sep 17 00:00:00 2001
From: Marco Cavallini 
Date: Mon, 21 Oct 2019 18:38:22 +0200
Subject: [PATCH] README-Guide.md: Updated the Stand-alone Installation details
 according to the yocto-autobuilder-helper patch
 5ba152e55688b27c745a787a5ca968bb058ebf25

Now is no longer needed to manually modify config.json.

Signed-off-by: Marco Cavallini 
---
 README-Guide.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/README-Guide.md b/README-Guide.md
index 70f1433..e8f74a1 100644
--- a/README-Guide.md
+++ b/README-Guide.md
@@ -53,8 +53,7 @@ Next, if you do not want to edit the original `yocto-autobuilder-helper/config.j
 
 Here are some suggestions for the sake of :
 
- 1. In the original `config.json`, find all instances of whatever `BASE_HOMEDIR` was set to, for example `/home/pokybuild3`.  Copy those variables to your `config-local.json` replace `/home/pokybuild3` with `${BASE_HOMEDIR}`.  These will be variables like `BUILDPERF_STATEDIR` and `EXTRAPLAINCMDS`.
-Set `BASE_HOMEDIR` should be your build user's home directory.  (There are shell scripts where this is assumed.)
+ 1. Customization can be done by copying the variable to be overriden from the original `config.json` to your `config-local.json`, for example like `BUILDPERF_STATEDIR` and `EXTRAPLAINCMDS`. _NOTE:_ In this document and by default `BASE_HOMEDIR` is set as pokybuild3 and should be the Autobuilder2 user's home directory.
  2. Add `BASE_SHAREDDIR` and `BASE_PUBLISHDIR` such that they are subtrees of your `BASE_HOMEDIR`, e.g., `${BASE_HOMEDIR}/srv/autobuilder.yoursite.com`.
  3. Change your `WEBPUBLISH_URL` to match your `config.py` definition for `buildbotURL`.
  4. In order for this to work, you must export `ABHELPER_JSON="config.json config-local.json"` into the environment of the controller and janitor services (the example service scripts included below already have this).
@@ -281,4 +280,4 @@ Group=nogroup
 
 [Install]
 WantedBy=multi-user.target
-```
\ No newline at end of file
+```
-- 
2.7.4

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


Re: [yocto] Useradd: crypted passwords longer than 8 characters

2019-10-21 Thread Bryan Evenson
Lukasz,

You can use the the EXTRA_USER_PARAMS variable in your image recipe: 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-extrausers.
  Both usermod and useradd take a plaintext password with the -P option, but I 
believe the password is then encrypted prior to being saved in /etc/shadow.  
Then you'll need to follow proper precautions to ensure your image recipe stays 
secret since it'd include the plaintext password.

-Bryan

> -Original Message-
> From: yocto-boun...@yoctoproject.org 
> On Behalf Of Mark Hatle
> Sent: Monday, October 21, 2019 12:15 PM
> To: Lukasz Zemla ; yocto@yoctoproject.org
> Subject: Re: [yocto] Useradd: crypted passwords longer than 8 characters
> 
> Crypt the password yourself and pass it in to the adduser command.
> 
> --Mark
> 
> On 10/21/19 10:25 AM, Lukasz Zemla wrote:
> > What is the best way in Yocto (warrior) to add crypted password to
> /etc/shadow during buildtime?
> >
> > Using useradd.bbclass in a standard way we may add only passwords <= 8
> characters.
> > "-p" parameterr followed by the output of "openssl passwd -crypt
> pAsswOrd" works fine.
> >
> > I thought that class may be cheated by providing after "-p" string returned
> by "openssl passwd -6 verylongpAsswOrd", but it does not work: the
> password in /etc/shadow file is truncated:
> >
> > myuser:/D163GofCVEpMgZ.w2Ro3Z.b5S8XT1:18190:0:9:7:::
> >
> > Any suggestions?
> >
> > Thank you in advance.
> > Lukasz Zemla
> >
> > ***
> > The information in this email is confidential and intended solely for the
> individual or entity to whom it is addressed.  If you have received this 
> email in
> error please notify the sender by return e-mail, delete this email, and 
> refrain
> from any disclosure or action based on the information.
> > ***
> >
> --
> ___
> 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] [layerindex-web] Add SPDX Identifier

2019-10-21 Thread Paul Eggleton
Hi Yann

Thanks for looking into this.

On Tuesday, 22 October 2019 4:15:03 AM NZDT Yann CARDAILLAC wrote:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13527
> 
> I'm beginning the work of updating the layerindex-web repo, this one is a
> bit tricky, how should I treat the files generated using Django ?
> 
> *For now I've given them MIT as for the other hand written script. However
> I'm kind of worried that it's not the proper licence. *

I believe the correct license for Django-derived files is BSD-3-Clause:

  https://github.com/django/django/blob/master/LICENSE

> For the css side, I've added MIT to :
> 
> ./rrs/static/css/rrs-additional.css
> and
> ./layerindex/static/css/additional.css

That should be fine, those files were authored as part of the project.

> *I've let the bootstraps css untouched since I guess that's not for us to
> licence. *

Correct, and we'd be required to re-apply it every time we upgraded as well 
which is likely to get forgotten. You could always get them to add one 
upstream if you're really keen :)
 
> I've yet to do html, txt and sh files, do you have any advices before I
> start?

Note that some of the templates used for authentication originally came from 
here:

  https://github.com/macdhuibh/django-registration-templates

The LICENSE file indicates MIT for those though.

The txt files are tricky because any stray newlines will affect formatting. I 
would probably avoid touching them.

Cheers
Paul

-- 

Paul Eggleton
Intel System Software Products


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