[yocto] Adding usb-modeswitch and minicom packages on yocto

2017-10-23 Thread vishal ashapur 
Hi
I want to add USB modeswitch and minicom packages on the target image. I am
using raspberry pi 3 for the same. How to add those two packages so that
they are enabled on target machine.
Regards
vishal
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Enabling_gcc

2017-10-23 Thread Khem Raj 
On Mon, Oct 23, 2017 at 4:57 PM, vishal ashapur  wrote:
> Ya, I want gcc compiler to be on target image. I'm using raspberry pi3
> board.

In local.conf add.

EXTRA_IMAGE_FEATURES_append = " tools-sdk tools-debug dbg-pkgs"

if you are using an image which does not inherit core-image then you can add
the needed bits to image as Randy suggested.


>
> On 24-Oct-2017 1:14 AM, "Randy MacLeod"  wrote:
>
> On 2017-10-23 01:17 PM, Khem Raj wrote:
>>
>> On Mon, Oct 23, 2017 at 4:52 AM, vishal ashapur 
>> wrote:
>>>
>>> Hi
>>> I'm building a Linux kernel from yocto, on which I have to enable gcc.
>>> Can u
>>> please tell me how to enable gcc. And also usb_modeswitch package
>>
>>
>> it uses gcc, I think you need to clarify your question a bit so
>> someone can provide you help.
>>
>
> Do you mean that you want the compiler in the target image?
>
> If so, add:
>   IMAGE_INSTALL += "packagegroup-core-buildessential"
> to your conf/local.conf file.
>
>
> ../Randy
>
>
> FYI, I looked-up that up in WR's distro feature:
>
> https://github.com/WindRiver-OpenSourceLabs/wr-base/blob/LB21_7.0_RCPL0002/templates/feature/target-toolchain/image.inc
> since I know it well. :)
>
> I didn't quickly find it in the YP manual:
>   http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
> but it should be there.
>
> --
> # Randy MacLeod.  WR Linux
> # Wind River an Intel Company
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/1] Rewrite bbvars.py to use tinfoil to find variables

2017-10-23 Thread Amanda Brindle 
Use tinfoil to collect all variable names globally and in each recipe.

No longer show the count of variables if they are undocumented.

Fixes [YOCTO #2086]

Signed-off-by: Amanda Brindle 
---
 scripts/contrib/bbvars.py | 90 ++-
 1 file changed, 66 insertions(+), 24 deletions(-)

diff --git a/scripts/contrib/bbvars.py b/scripts/contrib/bbvars.py
index d8d0594..556f652 100755
--- a/scripts/contrib/bbvars.py
+++ b/scripts/contrib/bbvars.py
@@ -23,6 +23,14 @@ import os
 import os.path
 import re
 
+# Set up sys.path to let us import tinfoil
+scripts_path = os.path.dirname(os.path.dirname(os.path.realpath(__file__)))
+lib_path = scripts_path + '/lib'
+sys.path.insert(0, lib_path)
+import scriptpath
+scriptpath.add_bitbake_lib_path()
+import bb.tinfoil
+
 def usage():
 print('Usage: %s -d FILENAME [-d FILENAME]* -m METADIR [-m MATADIR]*' % 
os.path.basename(sys.argv[0]))
 print('  -d FILENAME documentation file to search')
@@ -66,19 +74,23 @@ def collect_bbvars(metadir):
 bbvars[key] = 1
 return bbvars
 
-def bbvar_is_documented(var, docfiles):
-prog = re.compile(".*($|[^A-Z_])%s([^A-Z_]|$)" % (var))
-for doc in docfiles:
-try:
-f = open(doc)
-except IOError as err:
-print('WARNING: Failed to open doc ', doc)
-print(err.args[1])
-for line in f:
-if prog.match(line):
-return True
-f.close()
-return False
+def bbvar_is_documented(var, documented_vars):
+''' Check if variable (var) is in the list of documented 
variables(documented_vars) '''
+if var in documented_vars:
+return True
+else:
+return False
+
+def collect_documented_vars(docfiles):
+''' Walk the docfiles and collect the documented variables '''
+documented_vars = []
+prog = re.compile(".*($|[^A-Z_])')
+for d in docfiles:
+with open(d) as f:
+documented_vars += var_prog.findall(f.read())
+
+return documented_vars
 
 def bbvar_doctag(var, docconf):
 prog = re.compile('^%s\[doc\] *= *"(.*)"' % (var))
@@ -101,7 +113,7 @@ def bbvar_doctag(var, docconf):
 def main():
 docfiles = []
 metadirs = []
-bbvars = {}
+bbvars = set()
 undocumented = []
 docconf = ""
 onlydoctags = False
@@ -153,33 +165,63 @@ def main():
 usage()
 sys.exit(7)
 
-# Collect all the variable names from the recipes in the metadirs
-for m in metadirs:
-for key,cnt in collect_bbvars(m).items():
-if key in bbvars:
-bbvars[key] = bbvars[key] + cnt
+prog = re.compile("^[^a-z]*$")
+with bb.tinfoil.Tinfoil() as tinfoil:
+tinfoil.prepare(config_only=False)
+parser = bb.codeparser.PythonParser('parser', None)
+datastore = tinfoil.config_data
+
+def bbvars_update(data):
+if prog.match(data):
+bbvars.add(data)
+if tinfoil.config_data.getVarFlag(data, 'python'):
+try:
+parser.parse_python(tinfoil.config_data.getVar(data))
+except bb.data_smart.ExpansionError:
+pass
+for var in parser.references:
+if prog.match(var):
+bbvars.add(var)
 else:
-bbvars[key] = cnt
+try:
+expandedVar = 
datastore.expandWithRefs(datastore.getVar(data, False), data)
+for var in expandedVar.references:
+if prog.match(var):
+bbvars.add(var)
+except bb.data_smart.ExpansionError:
+pass
+
+# Use tinfoil to collect all the variable names globally
+for data in datastore:
+bbvars_update(data)
+
+# Collect variables from all recipes
+for recipe in tinfoil.all_recipe_files():
+print("Checking %s" % recipe)
+for data in tinfoil.parse_recipe_file(recipe):
+bbvars_update(data)
+
+documented_vars = collect_documented_vars(docfiles)
 
 # Check each var for documentation
 varlen = 0
-for v in bbvars.keys():
+for v in bbvars:
 if len(v) > varlen:
 varlen = len(v)
-if not bbvar_is_documented(v, docfiles):
+if not bbvar_is_documented(v, documented_vars):
 undocumented.append(v)
 undocumented.sort()
 varlen = varlen + 1
 
 # Report all undocumented variables
 print('Found %d undocumented bb variables (out of %d):' % 
(len(undocumented), len(bbvars)))
-header = '%s%s%s' % (str("VARIABLE").ljust(varlen), str("COUNT").ljust(6), 
str("DOCTAG").ljust(7))
+header = '%s%s' % (str("VARIABLE").ljust(varlen), str("DOCTAG").ljust(7))
 print(header)
 print(str("").ljust(len(header), '='))
 for v in undocumented:

[yocto] [PATCH 0/1] Rewrite bbvars.py to use tinfoil to find variables

2017-10-23 Thread Amanda Brindle 

The following changes since commit 65d23bd7986615fdfb0f1717b615534a2a14ab80:

  README.qemu: qemuppc64 is not supported (2017-10-16 23:54:31 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib abrindle/bbvars_tinfoil
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/bbvars_tinfoil

Amanda Brindle (1):
  Rewrite bbvars.py to use tinfoil to find variables

 scripts/contrib/bbvars.py | 90 ++-
 1 file changed, 66 insertions(+), 24 deletions(-)

-- 
2.7.4

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

Re: [yocto] Enabling_gcc

2017-10-23 Thread vishal ashapur 
Ya, I want gcc compiler to be on target image. I'm using raspberry pi3
board.

On 24-Oct-2017 1:14 AM, "Randy MacLeod"  wrote:

On 2017-10-23 01:17 PM, Khem Raj wrote:

> On Mon, Oct 23, 2017 at 4:52 AM, vishal ashapur 
> wrote:
>
>> Hi
>> I'm building a Linux kernel from yocto, on which I have to enable gcc.
>> Can u
>> please tell me how to enable gcc. And also usb_modeswitch package
>>
>
> it uses gcc, I think you need to clarify your question a bit so
> someone can provide you help.
>
>
Do you mean that you want the compiler in the target image?

If so, add:
  IMAGE_INSTALL += "packagegroup-core-buildessential"
to your conf/local.conf file.


../Randy


FYI, I looked-up that up in WR's distro feature:

https://github.com/WindRiver-OpenSourceLabs/wr-base/blob/LB2
1_7.0_RCPL0002/templates/feature/target-toolchain/image.inc
since I know it well. :)

I didn't quickly find it in the YP manual:
  http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
but it should be there.

-- 
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem with populate_sdk

2017-10-23 Thread Greg Wilson-Lindberg 
Hi Andrea,
You're right, I missed the SDK in the IMAGE_FEATURES. I just changed that in my 
image recipe and rebuit the image and then the SDK and the sdk was not rebuilt 
from the one earlier this morning.

Here is the line from my image recipe:
SDKIMAGE_FEATURES += "dev-pkgs dbg-pkgs staticdev-pkgs"

Regards,
Greg

> -Original Message-
> From: Andrea Adami [mailto:andrea.ad...@gmail.com]
> Sent: Monday, October 23, 2017 1:50 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Problem with populate_sdk
> 
> On Mon, Oct 23, 2017 at 10:31 PM, Greg Wilson-Lindberg
>  wrote:
> > Hi Andrea,
> > I added the dbg-pkgs to the IMAGE_FEATURES but it didn't seem to make a
> difference in what was included, still no .a file in the SYSROOT.
> > Regards,
> > Greg
> 
> Hi Greg,
> maybe I wasn't clear, from the manual:
> 
> SDKIMAGE_FEATURES: Lists the features to include in the "target" part of the
> SDK.
> 
> IMAGE_FEATURES: Specifies features to include in the image. Most of these
> features map to additional packages for installation.
> 
> So please use  SDKIMAGE_FEATURES = "dev-pkgs staticdev-pkgs"
> 
> Cheers
> Andrea
> 
> >
> >> -Original Message-
> >> From: Andrea Adami [mailto:andrea.ad...@gmail.com]
> >> Sent: Sunday, October 22, 2017 4:12 PM
> >> To: Greg Wilson-Lindberg 
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] Problem with populate_sdk
> >>
> >> On Thu, Oct 19, 2017 at 8:26 PM, Greg Wilson-Lindberg
> >>  wrote:
> >> > I'm trying to build an SDK for a Raspberry Pi3, and I got a problem
> >> > with the files from one of my custom recipes.
> >> >
> >> >
> >> > In my recipe I have:
> >> >
> >> > FILES_${PN}-dev = "lib/lib${PN}.a lib/lib${PN}_unix.a lib/pkgconfig
> >> > include/canfestival/*.h"
> >> >
> >> >
> >> > The *.a files get put into staticdev not dev in the package split.
> >> >
> >> >
> >> > In my image recipe I've added:
> >> >
> >> > IMAGE_FEATURES += "dev-pkgs  staticdev-pkgs"
> >> >
> >> > I get all of the libraries in my image. In the SDK I don't get the
> >> > *.a libraries from the staticdev, I do get the header files which
> >> > were put into dev.
> >> >
> >> >
> >> > So, at this point I'm a bit confused, even though I include both
> >> > the dev & staticdev I am only getting the dev files in the SDK.
> >> > And, also, why are the *.a libs being put into staticdev in the first 
> >> > place?
> >> >
> >> >
> >>
> >> Hi,
> >> these defaults are defined in meta/conf/bitbake.conf:
> >>
> >> PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc
> >> ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> >>
> >> This means that staticdev package is created before dev package, just
> >> after dbg.
> >>
> >> and
> >>
> >> FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a
> ${libdir}/${BPN}/*.a"
> >>
> >> indicates that the .a files in these dirs belongs to the staticdev package.
> >>
> >> Now, I guess you should try:
> >>
> >>  SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"
> >>
> >> Se https://lists.yoctoproject.org/pipermail/yocto/2014-
> >> September/021645.html
> >>
> >> Cheers
> >> Andrea
> >>
> >>
> >> > Regards, Greg
> >> >
> >> >
> >> > --
> >> > ___
> >> > 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] Problem with populate_sdk

2017-10-23 Thread Andrea Adami 
On Mon, Oct 23, 2017 at 10:31 PM, Greg Wilson-Lindberg
 wrote:
> Hi Andrea,
> I added the dbg-pkgs to the IMAGE_FEATURES but it didn't seem to make a 
> difference in what was included, still no .a file in the SYSROOT.
> Regards,
> Greg

Hi Greg,
maybe I wasn't clear, from the manual:

SDKIMAGE_FEATURES: Lists the features to include in the "target" part
of the SDK.

IMAGE_FEATURES: Specifies features to include in the image. Most of
these features map to additional packages for installation.

So please use  SDKIMAGE_FEATURES = "dev-pkgs staticdev-pkgs"

Cheers
Andrea

>
>> -Original Message-
>> From: Andrea Adami [mailto:andrea.ad...@gmail.com]
>> Sent: Sunday, October 22, 2017 4:12 PM
>> To: Greg Wilson-Lindberg 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Problem with populate_sdk
>>
>> On Thu, Oct 19, 2017 at 8:26 PM, Greg Wilson-Lindberg
>>  wrote:
>> > I'm trying to build an SDK for a Raspberry Pi3, and I got a problem
>> > with the files from one of my custom recipes.
>> >
>> >
>> > In my recipe I have:
>> >
>> > FILES_${PN}-dev = "lib/lib${PN}.a lib/lib${PN}_unix.a lib/pkgconfig
>> > include/canfestival/*.h"
>> >
>> >
>> > The *.a files get put into staticdev not dev in the package split.
>> >
>> >
>> > In my image recipe I've added:
>> >
>> > IMAGE_FEATURES += "dev-pkgs  staticdev-pkgs"
>> >
>> > I get all of the libraries in my image. In the SDK I don't get the *.a
>> > libraries from the staticdev, I do get the header files which were put
>> > into dev.
>> >
>> >
>> > So, at this point I'm a bit confused, even though I include both the
>> > dev & staticdev I am only getting the dev files in the SDK. And, also,
>> > why are the *.a libs being put into staticdev in the first place?
>> >
>> >
>>
>> Hi,
>> these defaults are defined in meta/conf/bitbake.conf:
>>
>> PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
>> ${PACKAGE_BEFORE_PN} ${PN}"
>>
>> This means that staticdev package is created before dev package, just after
>> dbg.
>>
>> and
>>
>> FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a 
>> ${libdir}/${BPN}/*.a"
>>
>> indicates that the .a files in these dirs belongs to the staticdev package.
>>
>> Now, I guess you should try:
>>
>>  SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"
>>
>> Se https://lists.yoctoproject.org/pipermail/yocto/2014-
>> September/021645.html
>>
>> Cheers
>> Andrea
>>
>>
>> > Regards, Greg
>> >
>> >
>> > --
>> > ___
>> > 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] Enabling_gcc

2017-10-23 Thread Randy MacLeod 

On 2017-10-23 01:17 PM, Khem Raj wrote:

On Mon, Oct 23, 2017 at 4:52 AM, vishal ashapur  wrote:

Hi
I'm building a Linux kernel from yocto, on which I have to enable gcc. Can u
please tell me how to enable gcc. And also usb_modeswitch package


it uses gcc, I think you need to clarify your question a bit so
someone can provide you help.



Do you mean that you want the compiler in the target image?

If so, add:
  IMAGE_INSTALL += "packagegroup-core-buildessential"
to your conf/local.conf file.


../Randy


FYI, I looked-up that up in WR's distro feature:

https://github.com/WindRiver-OpenSourceLabs/wr-base/blob/LB21_7.0_RCPL0002/templates/feature/target-toolchain/image.inc
since I know it well. :)

I didn't quickly find it in the YP manual:
  http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
but it should be there.

--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building kernel backports for ARM with Yocto

2017-10-23 Thread Khem Raj 
On Mon, Oct 23, 2017 at 11:07 AM, Marlon Smith  wrote:
> Khem, with a couple of modifications I was able to get this script working
> perfectly and installing the modules into the system automatically.  Thanks
> a lot!
>
> If you or anyone else would like a copy of the modified bitbake file I'd be
> happy to share it.

Please contribute it back to meta-openembedded or meta-himvis
(https://github.com/kraj/meta-himvis)

>
> On Thu, 2017-10-19 at 14:18 -0700, Khem Raj wrote:
>
> On Thu, Oct 19, 2017 at 12:38 PM, Marlon Smith 
> wrote:
>
> On Wed, 2017-10-18 at 22:50 -0700, Khem Raj wrote:
>
> On Wed, Oct 18, 2017 at 3:13 PM, Marlon Smith  om> wrote:
>
>
> Hi everyone,
>
> I'm trying to build the Linux backports project to get updated wifi
> drivers
> on an older kernel.  The problem is that when building backports,
> it first
> builds several tools that need to be run natively before cross-
> compiling the
> rest of the project.
>
> I know how to write a bitbake recipe to compile natively, and how
> to write
> one to build for the target, but I can't figure out how to combine
> the two.
> The backports project has steps for LTIB:
>
>  %Build
>  export PATH=$UNSPOOF_PATH
>
>  make menuconfig prefix=%{_prefix} \
>CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
>  export PATH=$SPOOF_PATH
>
>  make prefix=%{_prefix} \
>CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
>ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
>KLIB_BUILD=${TOP}/rpm/BUILD/linux
>
>
> I believe what I need is an equivalent to the line export
> PATH=$UNSPOOF_PATH
> but I can't find anything in the Yocto documentation or mailing
> lists that
> would be equivalent to that.
>
>
> Any help would be much appreciated!
>
> You might try this out
>
> https://github.com/kraj/meta-himvis/blob/master/recipes-kernel/linux-
> backports/linux-backports_4.14-rc4.bb
>
> it does not work out of box but with few fixes here and there it
> should work
>
>
> It looks like that recipe inherits backports_module and kernel-
> backports_module-split.. do I need those files as well?
>
>
>
> backports_module is merged into recipe itsellf. Other one can be
> replaced with inehrtiting
> module bbclasss
>
>
>
>
>
>
>
>
> Thanks
>
>
> Marlon
>
>
> --
> ___
> 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] Enabling_gcc

2017-10-23 Thread Khem Raj 
On Mon, Oct 23, 2017 at 4:52 AM, vishal ashapur  wrote:
> Hi
> I'm building a Linux kernel from yocto, on which I have to enable gcc. Can u
> please tell me how to enable gcc. And also usb_modeswitch package

it uses gcc, I think you need to clarify your question a bit so
someone can provide you help.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH v2] fscryptctl: add v0.1.0

2017-10-23 Thread André Draszik 
From: André Draszik 

fscryptctl is a low-level tool written in C that handles
raw keys and manages policies for Linux filesystem
encryption [1].

For a tool that presents a higher level interface and
manages metadata, key generation, key wrapping, PAM
integration, and passphrase hashing, see fscrypt [2].

[1] https://lwn.net/Articles/639427
[2] https://github.com/google/fscrypt

Signed-off-by: André Draszik 

---
v2: add RRECOMMENDS on keyutils, as that might be useful when
dealing with kernel keys.
---
 recipes-security/fscryptctl/fscryptctl_0.1.0.bb | 27 +
 1 file changed, 27 insertions(+)
 create mode 100644 recipes-security/fscryptctl/fscryptctl_0.1.0.bb

diff --git a/recipes-security/fscryptctl/fscryptctl_0.1.0.bb 
b/recipes-security/fscryptctl/fscryptctl_0.1.0.bb
new file mode 100644
index 000..4f0b12c
--- /dev/null
+++ b/recipes-security/fscryptctl/fscryptctl_0.1.0.bb
@@ -0,0 +1,27 @@
+SUMMARY = "low-level tool handling Linux filesystem encryption"
+DESCIPTION = "fscryptctl is a low-level tool written in C that handles raw 
keys and manages \
+policies for Linux filesystem encryption (https://lwn.net/Articles/639427). \
+For a tool that presents a higher level interface and manages metadata, key \
+generation, key wrapping, PAM integration, and passphrase hashing, see \
+fscrypt (https://github.com/google/fscrypt)."
+HOMEPAGE = "https://github.com/google/fscryptctl;
+SECTION = "base"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRCREV = "e4c4d0984dee2531897e13c32a18d5e54a2a4aa6"
+SRC_URI = "git://github.com/google/fscryptctl.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+oe_runmake DESTDIR=${D}${bindir} install
+}
+
+RRECOMMENDS_${PN} += "\
+keyutils \
+kernel-module-cbc \
+kernel-module-cts \
+kernel-module-ecb \
+kernel-module-xts \
+"
-- 
2.15.0.rc1

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

[yocto] [meta-security][PATCH] fscryptctl: add v0.1.0

2017-10-23 Thread André Draszik 
From: André Draszik 

fscryptctl is a low-level tool written in C that handles
raw keys and manages policies for Linux filesystem
encryption [1].

For a tool that presents a higher level interface and
manages metadata, key generation, key wrapping, PAM
integration, and passphrase hashing, see fscrypt [2].

[1] https://lwn.net/Articles/639427
[2] https://github.com/google/fscrypt

Signed-off-by: André Draszik 
---
 recipes-security/fscryptctl/fscryptctl_0.1.0.bb | 26 +
 1 file changed, 26 insertions(+)
 create mode 100644 recipes-security/fscryptctl/fscryptctl_0.1.0.bb

diff --git a/recipes-security/fscryptctl/fscryptctl_0.1.0.bb 
b/recipes-security/fscryptctl/fscryptctl_0.1.0.bb
new file mode 100644
index 000..5af8de1
--- /dev/null
+++ b/recipes-security/fscryptctl/fscryptctl_0.1.0.bb
@@ -0,0 +1,26 @@
+SUMMARY = "low-level tool handling Linux filesystem encryption"
+DESCIPTION = "fscryptctl is a low-level tool written in C that handles raw 
keys and manages \
+policies for Linux filesystem encryption (https://lwn.net/Articles/639427). \
+For a tool that presents a higher level interface and manages metadata, key \
+generation, key wrapping, PAM integration, and passphrase hashing, see \
+fscrypt (https://github.com/google/fscrypt)."
+HOMEPAGE = "https://github.com/google/fscryptctl;
+SECTION = "base"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRCREV = "e4c4d0984dee2531897e13c32a18d5e54a2a4aa6"
+SRC_URI = "git://github.com/google/fscryptctl.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+oe_runmake DESTDIR=${D}${bindir} install
+}
+
+RRECOMMENDS_${PN} += "\
+kernel-module-cbc \
+kernel-module-cts \
+kernel-module-ecb \
+kernel-module-xts \
+"
-- 
2.15.0.rc1

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

[yocto] Enabling_gcc

2017-10-23 Thread vishal ashapur 
Hi
I'm building a Linux kernel from yocto, on which I have to enable gcc. Can
u please tell me how to enable gcc. And also usb_modeswitch package
Regards
Vishal
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenEmbedded sole base meta layer and poky base meta layers in sync, or not (should be The Same meta base layer, used in different distros)???

2017-10-23 Thread Burton, Ross 
On 23 October 2017 at 12:39, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > poky is generated using combo-layer, which effectively cherry-picks
> commits from the parent repositories (in this case bitbake,
> > oe-core, meta-poky, meta-yocto-bsp).  This explains why the SHAs don't
> match, as the history doesn't match.
>
> This is exactly my original point. We should have here original repos'
> SHAs. Not "modified" ones. The "modified" note should be included at the
> end of this report (to understand the differences explained by you). For
> the better understanding from where/which repos' commits/clones are coming,
> and why.
>

The script is reporting the actual SHAs that are being built, which in my
opinion is better than reporting SHAs which are similar but are not in fact
the same.

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

Re: [yocto] OpenEmbedded sole base meta layer and poky base meta layers in sync, or not (should be The Same meta base layer, used in different distros)???

2017-10-23 Thread Zoran Stojsavljevic 
> poky is generated using combo-layer, which effectively cherry-picks
commits from the parent repositories (in this case bitbake,
> oe-core, meta-poky, meta-yocto-bsp).  This explains why the SHAs don't
match, as the history doesn't match.

This is exactly my original point. We should have here original repos'
SHAs. Not "modified" ones. The "modified" note should be included at the
end of this report (to understand the differences explained by you). For
the better understanding from where/which repos' commits/clones are coming,
and why.

Thank you,
Zoran

On Mon, Oct 23, 2017 at 11:25 AM, Burton, Ross 
wrote:

> On 23 October 2017 at 10:08, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > Or better yet use
>> > http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-ma
>> nual.html#ref-classes-image-buildinfo
>>
>> Since I am also (relatively) new to YOCTO, reading these emails makes me
>> think about dependencies between YOCTO distros and layers within distros.
>>
>> Looking what is written here, I decided to do couple of the tests on my
>> own to try to understand better how OpenEmbedded (oe-core) base layer and
>> Poky distro (with two layers on the top of oe-core) are correlated with
>> each other. As my best understanding, poky master tree should do nothing
>> more that follow dependencies (with two additional layers) on the
>> OpenEmbedded master tree.
>>
>> OpenEmbedded layer is YOCTO QEMU project on its own. And one can build
>> well known QEMU targets on single oe-core.
>>
>> In order to verify this, i did git clone (at the same time) on two
>> distros: oe-core master tree, and on poky master tree.
>>
>> Now, after building oe-core, I have the following in qemux86-64 target
>> /etc/build:
>>
>> ---
>> Build Configuration:  |
>> ---
>> DISTRO = nodistro
>> DISTRO_VERSION = nodistro.0
>> ---
>> Layer Revisions:  |
>> ---
>>
>> *meta  = master:3b413a80578caacd9a7f405f3c51a3921d78a60d*
>>
>> At the same time, for poky, I got the following (qemux86-64 target
>> /etc/build):
>>
>> ---
>> Build Configuration:  |
>> ---
>> DISTRO = poky
>> DISTRO_VERSION = 2.4
>> ---
>> Layer Revisions:  |
>> ---
>> *meta  = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80
>> -- modified*
>> meta-poky = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
>> modified
>> meta-yocto-bsp = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
>> modified
>> ___
>>
>> Now, the question: should meta - rocko and meta - master have (in *BOLD*)
>> the SAME master HEAD #???
>>
>
> No, they're different repositories so have different SHAs.  However:
>
> $ git show 65d23bd7986615fdfb0f1717b615534a2a14ab80
> commit 65d23bd7986615fdfb0f1717b615534a2a14ab80
> Author: Randy MacLeod 
> Date:   Mon Oct 16 11:00:44 2017 -0400
>
> README.qemu: qemuppc64 is not supported
>
> (From OE-Core rev: 3b413a80578caacd9a7f405f3c51a3921d78a60d)
>
> They're the same commit.
>
> poky is generated using combo-layer, which effectively cherry-picks
> commits from the parent repositories (in this case bitbake, oe-core,
> meta-poky, meta-yocto-bsp).  This explains why the SHAs don't match, as the
> history doesn't match.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto (Pyro) build error

2017-10-23 Thread Zoran Stojsavljevic 
> WARNING: firmware-imx-1,5.4-r0 do-fetch:failed to fetch URL...

I recall, I had the same error. Seems that this particular URL (server) is
down for some reason. Happens for this package frequently.

You should try later, but continue to do the target with bitbake -k switch.

http://wiki.kaeilos.com/index.php/Bitbake_options

Zoran

On Mon, Oct 23, 2017 at 11:17 AM, Umamahesh Yelchuruvenkata <
umamahes...@hcl.com> wrote:

> Hi,
>
>
>
> I am trying to build yocto (Pyro version) for wandboard , it frequently
> fails while fetching firmware file (Error and my modified local.conf file
> attached for reference.
>
>
>
> Looking for suggestions.
>
>
>
> Thanks
>
> UmaMahesh
>
>
>
>
>
> ::DISCLAIMER::
> 
> 
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> 
> 
> 
>
> --
> ___
> 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] OpenEmbedded sole base meta layer and poky base meta layers in sync, or not (should be The Same meta base layer, used in different distros)???

2017-10-23 Thread Zoran Stojsavljevic 
> Or better yet use
> http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-ma
nual.html#ref-classes-image-buildinfo

Since I am also (relatively) new to YOCTO, reading these emails makes me
think about dependencies between YOCTO distros and layers within distros.

Looking what is written here, I decided to do couple of the tests on my own
to try to understand better how OpenEmbedded (oe-core) base layer and Poky
distro (with two layers on the top of oe-core) are correlated with each
other. As my best understanding, poky master tree should do nothing more
that follow dependencies (with two additional layers) on the OpenEmbedded
master tree.

OpenEmbedded layer is YOCTO QEMU project on its own. And one can build well
known QEMU targets on single oe-core.

In order to verify this, i did git clone (at the same time) on two distros:
oe-core master tree, and on poky master tree.

Now, after building oe-core, I have the following in qemux86-64 target
/etc/build:

---
Build Configuration:  |
---
DISTRO = nodistro
DISTRO_VERSION = nodistro.0
---
Layer Revisions:  |
---

*meta  = master:3b413a80578caacd9a7f405f3c51a3921d78a60d*

At the same time, for poky, I got the following (qemux86-64 target
/etc/build):

---
Build Configuration:  |
---
DISTRO = poky
DISTRO_VERSION = 2.4
---
Layer Revisions:  |
---
*meta  = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
modified*
meta-poky = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
modified
meta-yocto-bsp = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 -- modified
___

Now, the question: should meta - rocko and meta - master have (in *BOLD*)
the SAME master HEAD #???

Something here seems not in order/not in sync?! Or...Please, you
tell/explain to me!?

Thank you,
Zoran
___

On Thu, Oct 12, 2017 at 4:19 PM, Philip Balister 
wrote:

> Or better yet use
> http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manu
> al.html#ref-classes-image-buildinfo
>
> to get:
>
> ---
> Build Configuration:  |
> ---
> DISTRO = nodistro
> DISTRO_VERSION = nodistro.0
> ---
> Layer Revisions:  |
> ---
> meta  = master:8ca61a5464743ff85b6d26886112750d6ddd13e0
> meta-xilinx   = master:74a0d90e52cca346d05a69bbd628c6ec9e49fbcb
> meta-oe   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
> meta-networking   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
> meta-filesystems  = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
> meta-python   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
> meta-multimedia   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
> meta-sdr  = qt5-test:dacc304b01eac7448ec1ebf0b3d0eab761c41a26 --
> modified
> meta-qt5  = master:2c3ef00f53683fbdce5b390950b49b67da85d3a1
> meta-qcom = master:bae28268a9387bb842ab7bbe8200b98c1210604c
> meta-raspberrypi  = master:9d84186870a6f9bde44575690105b9bb5e44ca24
>
> Philip
>
> On 10/12/2017 05:11 AM, Ayoub Zaki wrote:
> > Hi,
> >
> > That's easy to do :
> >
> >
> > do_install_append () {
> >
> > for layer in ${BBLAYERS}; do
> > cd $layer
> > echo -n "$(basename $layer) = "  >> ${D}${sysconfdir}/gitinfo
> > git rev-parse HEAD >> ${D}${sysconfdir}/gitinfo
> > done
> > }
> >
> >
> > add it in a recipe or add it to os-release.bbappend
> >
> >
> > On 12.10.2017 11:05, Alan Martinovic wrote:
> >> I've noticed that bitbake prints the git commit versions of the layers
> >> when the build starts.
> >>
> >> meta-python   = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
> >> meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
> >> meta-go   = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"
> >>
> >> Does this information find it's way into the rootfs?
> >> If not, any suggestions on how to achieve this?
> >>
> >> The goal is to have this info available while the image is running.
> >>
> >> Be Well,
> >> Alan
> >>
> >>
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto