Re: [yocto] package error for custom devtool recipe

[Paul Eggleton]

Hi Greg,

On Tuesday, 3 October 2017 1:30:25 PM NZDT Greg Wilson-Lindberg wrote:
> I get some package errors when I build this:
> 
> ERROR: QA Issue: acsccid: Files/directories were installed but not shipped
> in any package:
>   /usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist
>   /usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> acsccid: 2 installed and not shipped files. [installed-vs-shipped]
> 
> 
> I've added some FILES = lines to try to get rid of the error to no avail:
> 
> FILES_${PN} = "${libdir}/libacsccid.so"
> 
> or:
> 
> FILES_${PN} = ".libs/libacsccid.so"
> 
> or just:
> 
> FILES_${PN} = "libacsccid.so"

The reason none of these work is that none of these actually match the file 
path (not to mention you are setting the value outright instead of adding to 
the existing value). The path you are trying to match is 
"/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so" so the 
value you want is either exactly that path, or something like 
"${libdir}/pcsc/drivers/*/Contents/Linux/*.so".  Also, instead of = use += so 
that you are adding to the existing value.

> and:
> 
> PACKAGE_BEFORE_PN = "info"
> FILES_${PN}-info = "Info.plist"

This isn't right - in PACKAGES (via PACKAGE_BEFORE_PN) you are placing "info" 
and then setting FILES_${PN}-info i.e. the package is named "${PN}-info". 
Probably the thing you want is to prepend this package to PACKAGES:

PACKAGES =+ "${PN}-info"

Cheers,
Paul 

-- 

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

[yocto] package error for custom devtool recipe

[Greg Wilson-Lindberg]

I've got a recipe that I'm trying to get working that was created by devtool:

# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be 
fully functional.
# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - 
it is
# your responsibility to verify that the values are complete and correct.
#
# NOTE: multiple licenses have been detected; if that is correct you should 
separate
# these in the LICENSE value using & if the multiple licenses all apply, or | 
if there
# is a choice between the multiple licenses. If in doubt, check the accompanying
# documentation to determine which situation is applicable.
#
# The following license files were not able to be identified and are
# represented as "Unknown" below, you will need to check them yourself:
#   src/towitoko/COPYING
#   src/openct/LICENSE
#
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1 \

file://src/towitoko/COPYING;md5=2fc60379096eee9073e3012488ba87cd \

file://src/openct/LICENSE;md5=ebc2e3e5ba280a30e3e1abd91a4a6c52"

SRC_URI = "https://downloads.sourceforge.net/acsccid/acsccid-${PV}.tar.bz2";
SRC_URI[md5sum] = "ac77b3aeae0a11723c96c7f98769490e"
SRC_URI[sha256sum] = 
"1607591ee0df07c0157a71f6cb61e1e11fe1fa17331f02d2dff020db0e28c0ae"

DEPENDS = "flex-native libusb1 pcsc-lite"

# NOTE: if this software is not capable of being built in a separate build 
directory
# from the source, you should replace autotools with autotools-brokensep in the
# inherit line
inherit pkgconfig autotools

# Specify any options you want to pass to the configure script using 
EXTRA_OECONF:
EXTRA_OECONF = ""


I get some package errors when I build this:

ERROR: QA Issue: acsccid: Files/directories were installed but not shipped in 
any package:
  /usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist
  /usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Linux/libacsccid.so
Please set FILES such that these items are packaged. Alternatively if they are 
unneeded, avoid installing them or delete them within do_install.
acsccid: 2 installed and not shipped files. [installed-vs-shipped]


I've added some FILES = lines to try to get rid of the error to no avail:

FILES_${PN} = "${libdir}/libacsccid.so"

or:

FILES_${PN} = ".libs/libacsccid.so"

or just:

FILES_${PN} = "libacsccid.so"

and:

PACKAGE_BEFORE_PN = "info"
FILES_${PN}-info = "Info.plist"


Where can I find what the specification is for the Info.plist & libacsccid.so 
files so that I can properly package them. I've looked in the log files but I 
haven't been able to find anywhere that has something that would look like what 
I need to use to specify packaging up the libacsccid.so and not even installing 
the Info.plist file.

Thanks in advanced
Greg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem adding first layer to yocto

[Cal Sullivan]

Your layer appears to only be adding a new recipe. It won't be built 
unless you tell it to be built, or you build something that depends on 
it, or you add it to the image you're building.

So your options are:
bitbake example
add IMAGE_INSTALL_append = " example" to your local.conf
have another recipe that requires example, and build or add that to your 
image.


---
Cal

On 10/02/2017 04:05 PM, Mark Hieber wrote:

sorry, fat-fingered send

Anyway, I created this layer. I had it create a default recipe, I 
looked at all the files, they all seem to be correct. I then ran


source oe-init-build-env

and then edited build/conf/bblayers.conf, it has

BBLAYERS ?= " \

  /yocto/poky/meta \

  /yocto/poky/meta-poky \

  /yocto/poky/meta-yocto-bsp \

  /yocto/poky/meta-mylayer \

  "


I then ran "bitbake core-image-minimal" and then ran "runqemu qemux86 
nographic"
Inside qemu, I did a 'find / -name "hello*"' and got nothing. Also, 
when I ran bitbake, it said


#/yocto/poky/build$ bitbake core-image-minimal
Loading cache: 100% 
|#| 
Time: 0:00:00

Loaded 1302 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"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "2.3.2"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp
meta-mylayer  = "pyro:717303e6fbcbbe181ad9645d762eb5a85d934523"
Initialising tasks: 100% 
|| 
Time: 0:00:04

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 2426 tasks of which 2426 didn't need to 
be rerun and all succeeded.


It seems to me that yocto is NOT picking up my new layer. I am sure 
that I have missed something, but I read the docs 3 times, and can't 
find anything I missed.


Thanks for your help,

Mark

On Mon, Oct 2, 2017 at 3:58 PM, Mark Hieber > wrote:

>
> Hi, I am just starting out with yocto, and I have an issue. I 
followed the steps in 
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#creating-a-general-layer-using-the-yocto-layer-script,

> create meta-mylayer (in the /yocto/poky directory),
>
> #/yocto/poky tree meta-mylayer/
>
> meta-mylayer/
>
> ├── conf
>
> │   └── layer.conf
>
> ├── COPYING.MIT
>
> ├── README
>
> └── recipes-example
>
> └── example
>
> ├── example-0.1
>
> │   ├── example.patch
>
> │   └── helloworld.c
>
> └── example_0.1.bb 
>




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

Re: [yocto] problem adding first layer to yocto

[Mark Hieber]

sorry, fat-fingered send

Anyway, I created this layer. I had it create a default recipe, I looked at
all the files, they all seem to be correct. I then ran

source oe-init-build-env

and then edited build/conf/bblayers.conf, it has

BBLAYERS ?= " \

  /yocto/poky/meta \

  /yocto/poky/meta-poky \

  /yocto/poky/meta-yocto-bsp \

  /yocto/poky/meta-mylayer \

  "


I then ran "bitbake core-image-minimal" and then ran "runqemu qemux86
nographic"
Inside qemu, I did a 'find / -name "hello*"' and got nothing. Also, when I
ran bitbake, it said

#/yocto/poky/build$ bitbake core-image-minimal
Loading cache: 100%
|#|
Time: 0:00:00
Loaded 1302 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"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "2.3.2"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp
meta-mylayer  = "pyro:717303e6fbcbbe181ad9645d762eb5a85d934523"
Initialising tasks: 100%
||
Time: 0:00:04
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 2426 tasks of which 2426 didn't need to be
rerun and all succeeded.

It seems to me that yocto is NOT picking up my new layer. I am sure that I
have missed something, but I read the docs 3 times, and can't find anything
I missed.

Thanks for your help,

Mark

On Mon, Oct 2, 2017 at 3:58 PM, Mark Hieber  wrote:
>
> Hi, I am just starting out with yocto, and I have an issue. I followed
the steps in
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#creating-a-general-layer-using-the-yocto-layer-script
,
> create meta-mylayer (in the /yocto/poky directory),
>
> #/yocto/poky tree meta-mylayer/
>
> meta-mylayer/
>
> ├── conf
>
> │   └── layer.conf
>
> ├── COPYING.MIT
>
> ├── README
>
> └── recipes-example
>
> └── example
>
> ├── example-0.1
>
> │   ├── example.patch
>
> │   └── helloworld.c
>
> └── example_0.1.bb
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] problem adding first layer to yocto

[Mark Hieber]

Hi, I am just starting out with yocto, and I have an issue. I followed the
steps in
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#creating-a-general-layer-using-the-yocto-layer-script,

create meta-mylayer (in the /yocto/poky directory),

#/yocto/poky tree meta-mylayer/

meta-mylayer/

├── conf

│   └── layer.conf

├── COPYING.MIT

├── README

└── recipes-example

└── example

├── example-0.1

│   ├── example.patch

│   └── helloworld.c

└── example_0.1.bb
-- 
___
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)

[Bryan Evenson]

Alex,

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of Alexander Kanavin
> Sent: Sunday, October 01, 2017 4:20 AM
> To: Dominig ar Foll (Intel Open Source) ; 
> yocto@yoctoproject.org
> Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka 
> Bash on Ubuntu on Windows)
> 
> On 09/29/2017 05:01 PM, Dominig ar Foll (Intel Open Source) wrote:
> >> Due to what our IT department can support, I am issued a Windows laptop 
> >> for development.  In the past I have used VMWare to make a Linux virtual 
> >> machine for my Yocto Project based image builds and application 
> >> development.  We are starting to get Windows 10 laptops so I am evaluating 
> >> doing my builds using the Windows Subsystem for Linux (WSL) by building a 
> >> poky/morty image.  Overall it seems to be working.  I've had an issue that 
> >> I've worked through and other issues that I'm not quite sure what is going 
> >> on.
> >>
> > Hi Brian,
> > 
> > I have been trying the same thing attempting to build Automotive Grade 
> > Linux from Linux for Windows subsystem.
> > We have many adopter of AGL who also receive Windows PC from their IT 
> > department. While VM work, they impose a serious limitation on memory 
> > and CPU usage.
> 
> Does anyone else think doing embedded linux development on windows machines 
> is a ridiculous situation, and needs to be discussed with companies 
> management? IT departments should either support product R&D work (because at 
> the end of the day that is where the company makes money), or stay out of the 
> way and let engineers self-manage their computers, including installing weird 
> operating systems.

Yes, ideally I could just get a Linux laptop and do that for development.  
Unfortunately, that's not an option for me.  Honestly, if WSL works well I 
wouldn't mind it as a working solution.  I started trying this more out of 
curiosity if it would do anything.  I was quite surprised how much did work 
with very little modification.

With the few changes I have already mentioned, I was able to build my complete 
image.  I then started working on building my development image to create and 
SDK that has gdb and tools for the Eclipse plugin.  That built all the way to 
rootfs, then failed with a blank error message.  I then tried with my VM, and 
the development image failed in the same manner.  I recently updated to a more 
recent Yocto branch, so I think I broke something with my development image 
build (unrelated to WSL) that I need to go back and fix.

The biggest issue I had with build times was with antivirus tools.  I hadn't 
setup the Windows antivirus to ignore the WSL working directory, so it was 
scanning every new file created and modified.  Once I told it to ignore the WSL 
working directory, the build times were comparable to under VMWare.

I don't know how far I'll take this, but I thought others would be interested 
in the results.

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

[yocto] [qa-tools][PATCH] scripts: Add ptest-parser to create reports for pTest executions

[jose . perez . carranza]

From: Jose Perez Carranza 

Add ptest-parser.py scrip that creates a file with the report of pTest
execution compared with the previous results provided, the data stored
on the file is in wikimedia format to be copied and pasted on the new
created wiki for pTest results of QA cycle.

Signed-off-by: Jose Perez Carranza 
---
 scripts/ptest-parser.py | 234 
 1 file changed, 234 insertions(+)
 create mode 100755 scripts/ptest-parser.py

diff --git a/scripts/ptest-parser.py b/scripts/ptest-parser.py
new file mode 100755
index 000..a3f20fb
--- /dev/null
+++ b/scripts/ptest-parser.py
@@ -0,0 +1,234 @@
+#!/usr/bin/python3
+
+import sys
+import os.path
+import codecs
+import logging
+import argparse
+
+
+prelog = {}
+currlog = {}
+
+
+def get_args():
+parser = argparse.ArgumentParser(description="Parse ptest results")
+requiredNamed = parser.add_argument_group('required arguments')
+requiredNamed.add_argument('-p', dest="pre_log", required=True, 
help='prvious log of the pTest result')
+requiredNamed.add_argument('--pre_commit', dest="pre_commit", 
required=True, help='commit of the previous log.')
+requiredNamed.add_argument('--pre_release', dest="pre_release", 
required=True, help='release of the previous log.')
+requiredNamed.add_argument('-c', dest="curr_log", required=True, 
help='current log of pTets results.')
+requiredNamed.add_argument('--curr_commit', dest="curr_commit", 
required=True, help='commit of the current log.')
+requiredNamed.add_argument('--curr_release', dest="curr_release", 
required=True, help='release of the current log.')
+
+return parser.parse_args()
+
+
+
+##Check that logs exists
+def check_args():
+if not os.path.isfile(args.pre_log):
+logging.error("Cannot find log file %s" % args.pre_log)
+sys.exit(1)
+elif not os.path.isfile(args.curr_log):
+logging.error("Cannot find log file %s" % args.pre_curr)
+
+
+def create_log_dict(argslog):
+test_id = ""
+result = ""
+failures = ""
+failures_log = []
+passed = 0
+failed = 0
+content_file = codecs.open(argslog, 'r', 'utf-8', errors='ignore')
+content = content_file.read()
+content = content.split("\n")
+res_dict = {}
+directory = 'failures'
+
+#create dir to store failures
+if not os.path.exists(directory):
+os.makedirs(directory)
+
+#Parse the logs
+for i in range (len(content)-1):
+try:
+result = content[i].split(":")[0]
+test_id = content[i].split(":")[1].strip()
+except:
+result = None
+if result:
+if result in "BEGIN":
+test_module = test_id
+test_module = test_module.replace('/usr/lib/', '')
+test_module = test_module.replace('/ptest', '')
+elif result in "PASS":
+passed = passed + 1
+elif result in "FAIL":
+failed = failed + 1
+failures = "{0}:{1}" .format(result,test_id)
+failures_log.append(failures)
+elif result in "END":
+total = passed + failed
+if total == 0:
+passrate = 0
+else:
+passrate = 100 * (passed / total)
+res_dict[test_module] = [total, passed, failed, 
round(passrate,2)]
+
+#Store Failures
+with open('failures/'+test_module+".failures", 'w') as 
failures_file:
+for fails in failures_log:
+failures_file.write("{0}\n" .format(fails))
+failures_log = []
+
+total = passed = failed = 0
+
+return res_dict
+
+
+def create_compared_dict(currlog, prelog):
+diff = set(prelog.keys()) - set(currlog.keys())
+
+for key, value in currlog .items():
+if key in prelog.keys():
+lastpastrate = prelog[key][3]
+else:
+lastpastrate = 0
+
+currlog[key].append(lastpastrate)
+
+for item in diff:
+if item in prelog.keys():
+currlog[item] = prelog[item]
+currlog[item].insert(3, 0)
+
+return currlog
+
+
+def create_header(file_name):
+header = '[https://wiki.yoctoproject.org/wiki/Ptest/archive < Archive]' + \
+ '\n\nRan on a NUC and compared with' + \
+ '[[Ptest %s| %s]]'% (args.pre_commit, args.pre_release) + \
+ '\n\n[ < FULL_LOG]'
+
+with open(file_name, 'a') as f:
+f.write(header)
+
+def create_table(file_name, finalog):
+
+nomenclature = '\n\n{| style="border-spacing:0;"\n' + \
+'| style="background-color:#ff8080;border:0.05pt solid #00' + \
+';padding:0.0382in;"| Failures\n' + \
+'|-\n' + \
+'| 
style="background-color:#99ff66;border-top:none;border-bottom:0.05pt' + \
+'solid #00;border-left:0.05pt solid #00;border-right:

Re: [yocto] Configuration fragments not making it into kernel configuration

[Bruce Ashfield]

On 2017-10-02 11:23 AM, Jonathan Haws wrote:

I know I can fix this by simply doing a menuconfig, but that
isn't
the
proper way to do it - I have multiple BSP layers that do the same
thing
and they all behave in the same way.

What am I doing wrong?  I've attached my layer that contains the
recipe.  If the fragments are getting installed I think the
recipe
is
working right - but is there something in the lower-level class
that
isn't working or do I have a configuration that is breaking it?

I did a build with morty and your BSP, and I'm not seeing
the same results.

One notable difference is that if you are using the tip of
the morty branches, you should get 4.8.17, not 4.8.3.

I did zero extra configuration, just added your layer, meta-intel
and then bitbaked linux-yocto-rt.

I just noticed that my meta-intel layer was a few commits behind, a
likely culprit for what I'm seeing.  I'm rebuilding to see what I
get.
I'll report back when I have something.

If this doesn't solve my issue, would you recommend wiping my sstate?
I've already wiped out tmp without success.


Issue resolved.  Fragments now making it into the kernel configuration
correctly.  Thanks, Bruce!



Maybe I'm misunderstanding what I see in the BSP layer, but I
did get IGB disabled:

:~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-
yocto-
rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-
intel-
common-preempt-rt-build$
grep CONFIG_IGB .config
# CONFIG_IGB is not set
CONFIG_IGBVF=m

And I did get a warning during the build:

-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From:
/home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-
source/.kernel-meta/configs/standard/preempt-
rt/intel/features/dca/dca.cfg
Requested value:  CONFIG_IGB_DCA=y
Actual value:

Config 'IGB_DCA' has the following conditionals:
    IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
    y [y] m [m] IGB [n] DCA [y]



Which explains why CONFIG_IGB_DCA didn't make it into the final
.config

Can you clarify what you were looking to get for final
configuration
settings ?

The three fragments should disable the Intel IGB driver (CONFIG_IGB
not
set), enable some GPIO I2C drivers, and enable direct cache access.

I'm guessing CONFIG_IGB_DCA was set in the original config and
CONFIG_IGB is not being set, so IGB_DCA is getting unset causing the
warning.  I'll adjust my IGB fragment to explicity disable
CONFIG_IGB_DCA as well.


I get the same warning, and I believe it is because that setting is
only available if CONFIG_IGB is 'y' or 'm'.  Since I'm removing
CONFIG_IGB, CONFIG_IGB_DCA isn't even an option.  If I add "#
CONFIG_IGB_DCA is not set" to my fragment, I get the following warning:
-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From: /opt/yocto/poky/build-teisit/tmp/work-shared/xpedite7570/kernel-
source/.kernel-meta/configs/standard/preempt-
rt/intel/features/dca/dca.cfg /opt/yocto/poky/build-teisit/tmp/work-
shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-
rt/intel/Remove_Intel_IGB_driver.cfg
Requested value:  # CONFIG_IGB_DCA is not set
Actual value:

Config 'IGB_DCA' has the following conditionals:
   IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
   y [y] m [m] IGB [n] DCA [y]

What is the best way to clean up this type of warning - one where the
setting is a conditional option and is enabled in the default
configuration but a fragment removes the parent option?


This actually shoots through a gap in the audit code. Not a bug,
but due to a historical way that the options are flagged.

Only mismatches in 'hardware' options are reported, since that could
cause a boot failure or other similary severe issue with a board.

The option in question is tagged as 'hardware' by the upper layers
and there's currently no way to undo that tag.

The warning you are getting indicates that while the option was
set to a value, it wasn't in the final .config at all .. i.e. in this
case a dependency is gone so the option doesn't make it in at all
(off or non).

Since it is only a warning, and we understand it, it can be
ignored. I'm going to add a method in master that would allow that
hardware tag of the option to be cleared, and then it wouldn't be
in the final .config.

Cheers,

Bruce






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

[yocto] [opkg-utils PATCH] opkg.py: Fix run-time error in call to ArFile

[Jeffrey Pautler]

Signed-off-by: Jeffrey Pautler 
---
opkg.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opkg.py b/opkg.py
index 4d6f020..9131755 100644
--- a/opkg.py
+++ b/opkg.py
@@ -168,7 +168,7 @@ class Package(object):
 tar = tarfile.open(fn, "r", f)
 tarStream = tar.extractfile("./control.tar.gz")
 else:
-ar = ArFile(f, fn)
+ar = arfile.ArFile(f, fn)
 tarStream = ar.open("control.tar.gz")
 tarf = tarfile.open("control.tar.gz", "r", tarStream)
 try:
--
2.7.4
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: autotooler: generation of "configure.ac" and "Makefile.am" using Kconfig

[Aaron Schwartz]

Are you looking to use menuconfig to configure your packages?  BusyBox does
this [0] pretty well in my experience, you might take a look at how they've
put that together.

0) https://busybox.net/FAQ.html#configure

On Sat, Sep 30, 2017 at 10:49 AM, Ulf Samuelsson  wrote:

> Have a need to convert a large number of libraries to use autotools.
>
> I came up with the following idea:
>
> I create an Kconfig based configuration system, where you define a number
> of configuration items needed by configure.ac and Makefile.am
>
> You choose if you want to build an application, a shared library or a
> static library.
>
> The build normally depends on other libraries, and you checkmarks
> which library you are interested in from a (small) number of supported
> libraries.
> You can likewise select to support options like "--enable-openssl",
> again from a (small) number of supported options.
>
> If you have stuff not supported, the autotooler will include Config.in
> files allowing you to add your own items.
>
> Once the configuration is complete, you will compile an application
> which will generate "configure.ac" from the configuration file.
>
> Again, if you have stuff not supported in the code, you can add it
> in a user include file.
>
> The generator will read a user-headers.inc file and
> generate an AC_CHECK_HEADERS entry.
>
>
> The autotooler is available on
> https://www.github.com/emagii/autotooler.git
>
> ===
> Currently, it does not generate any Makefile.am files, but
> the idea is to separate the source files into
> * C source
> * Public Headers
> * Local Headers
>
> A tool would then scan the directories and classify them accordingly,
> so Makefile.am files should be possible to generate fairly easy.
>
> ===
> A final step would clone a empty git tree, and populate it
> with all the files needed for a complete package.
> ===
>
> Comments appreciated.
>
> Best Regards
> Ulf Samuelsson
> ===
> Here is a typical "autoconh.h" generated by Kconfig.
>
> /*
>  * Automatically generated C config: don't edit
>  * Sat Sep 30 16:27:24 2017
>  */
> #define CONFIG_SHARED_LIB 1
> #define CONFIG_PTHREAD 1
> #define CONFIG_LIBRARY 1
> #define CONFIG_PROJECT "myproject"
> #define CONFIG_WORKDIR "${HOME}/projects/autotooler"
> #define CONFIG_OPENSSL 1
> #define CONFIG_CURL 1
> #define CONFIG_COPYRIGHT_DATE "2017"
> #define CONFIG_HOMEPAGE "http://www.emagii.com/";
> #define CONFIG_EXAMPLES 1
> #define CONFIG_DEBUG 1
> #define HAVE_DOT_CONFIG 1
> #define CONFIG_AC_PRERQ "2.59"
> #define CONFIG_BOOST 1
> #define CONFIG_OS_LINUX 1
> #define CONFIG_LIBRARY_NAME "libyocto"
> #define CONFIG_AUTHOR_EMAIL "u...@emagii.com"
> #define CONFIG_LIBRARY_VERSION "1.0"
> #define CONFIG_AC_CONFIG_HEADER "src/include/config.h"
> #define CONFIG_OS "Linux"
> #define CONFIG_EXAMPLES_VAR "examples"
> #define CONFIG_AC_CONFIG_MACRO_DIR "m4"
> #define CONFIG_DEBUG_VAR "debug"
> #define CONFIG_PROJECT_TYPE "library"
> #define CONFIG_SRCDIR "src"
> #define CONFIG_SRC_URI_REPO ""
> #define CONFIG_AUTHOR "Ulf Samuelsson"
> #define CONFIG_SRC_URI_HOST "https://www.github.com/emagii";
> #define CONFIG_CURLPP 1
> #define CONFIG_AM_INIT_AUTOMAKE "1.10 -Wall no-define"
>
> The application will from this information generate:
>
> AC_INIT([libyocto],
> [1.0],
> [Ulf Samuelsson],
> [libyocto-1.0],
> [http://www.emagii.com/])
>
> AC_PRERQ([2.59])
>
> AC_CONFIG_HEADER([src/include/config.h])
>
> AC_CONFIG_SRCDIR([src])
>
> AC_PROG_CPP
> AC_PROG_CC
> AC_INIT_AUTOMAKE([1.10 -Wall no-define])
>
> AC_PROG_MAKE_SET
> AM_MAINTAINER_MODE
> AC_HEADER_STDC
> AC_ENABLE_SHARED
> AC_DISABLE_STATIC
> AC_PROG_LIBTOOL
> AC_HEADER_STDC
>
> AC_CHECK_HEADERS( \
> ctype.h \
> errno.h \
> fcntl.h \
> openssl/bio.h \
> openssl/err.h \
> openssl/opensslconf.h \
> openssl/rand.h \
> openssl/ssl.h \
> pthread.h \
> stdio.h \
> stdlib.h \
> stdarg.h \
> stdint.h \
> string.h \
> signal.h \
> sys/ioctl.h \
> sys/socket.h \
> sys/time.h \
> sys/types.h \
> time.h \
> unistd.h \
>  \
> ,
> dnl to do if not found
> [],
> dnl to do if not found
> [],
> dnl default includes
> [
> #ifdef HAVE_SYS_TYPES_H
> #include 
> #endif
> #ifdef HAVE_SYS_TIME_H
> #include 
> #endif
> dnl We do this default-include simply to make sure that the
> nameser_compat.h
> dnl header *REALLY* can be include after the new nameser.h. It seems AIX
> 5.1
> dnl (and others?) is not designed to allow this.
> #ifdef HAVE_ARPA_NAMESER_H
> #include 
> #endif
>
> dnl *Sigh* these are needed in order for net/if.h to get prope

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

Hi Paul,

On Tue, Sep 26, 2017 at 7:18 AM, Andrea Galbusera  wrote:

> Paul,
>
> On Tue, Sep 26, 2017 at 6:33 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
>> Hi Andrea,
>>
>> On Tuesday, 26 September 2017 4:33:46 AM NZDT Andrea Galbusera wrote:
>> > I'm back to this issue after the weeken break. See below the feedback
>> from
>> > your suggestions.
>> >
>> > On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
>> > paul.eggle...@linux.intel.com> wrote:
>> >
>> > > On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
>> > > > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
>> > > > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
>> > > > > paul.eggle...@linux.intel.com> wrote:
>> > > > > > Right, so the next step would be looking for the hash for
>> > > > > > python-native.do_populate_sysroot in conf/locked_sigs.inc
>> within the
>> > > > > > failed SDK install directory and then looking for that in both
>> the
>> > > sstate-
>> > > > > > cache directory within the failed SDK and then in the
>> sstate-cache
>> > > > > > directory of the build that built it. I suspect it may not be
>> there,
>> > > but
>> > > > > > let me know what you find.
>> > > > >
>> > > > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
>> > > > > sstate-cache do include any python-native signature or object...
>> Only
>> > > > > python3-native stuff is there. Weird! As said, SDKs from the same
>> build
>> > > > > directory, used to work since a few weeks ago. May any recent
>> change in
>> > > > > poky master have caused this while periodically upgrading without
>> > > > > regenerating the sstate-cache?
>> > > >
>> > > > No, I can't see any added references to python-native anywhere in
>> the
>> > > last few
>> > > > weeks. If you do bitbake -c clean python-native and then rebuild
>> the SDK
>> > > does
>> > > > the issue go away?
>> > >
>> > > Actually scratch that, that's not going to help. The question is
>> where is
>> > > this dependency coming from and why isn't it properly picked up such
>> > > that it gets included. bitbake -g -c populate_sdk_ext your-image
>> might be
>> > > useful in determining that.
>> > >
>> >
>> > $ bitbake core-image-base-dlms -c populate_sdk_ext -g
>> >
>> > Grepping task-depends.dot for "python-native" gives no match.
>> Surprisingly
>> > enough (at least for me) I read a different story when doing the same
>> for
>> > the image itself
>> >
>> > $ bitbake core-image-base-dlms -g
>> > $ grep python-native task-depends.dot
>> >  "python-native.do_populate_lic" [label="python-native
>> > do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/smartliving
>> /distro/repo-master/build-poky/conf/../../layers/poky/meta/r
>> ecipes-devtools/python/python[18/7956]
>> > .7.13.bb"]
>> > "python-native.do_populate_lic" -> "python-native.do_patch"
>> > "python-native.do_prepare_recipe_sysroot" [label="python-native
>> > do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/s
>> martliving/distro/repo-master/build-poky/conf/../../layers/p
>> oky/meta/recipes-devtools/py
>> > thon/python-native_2.7.13.bb"]
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "openssl-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "pkgconfig-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "automake-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "expat-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "sqlite3-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "bzip2-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "readline-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "zlib-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "autoconf-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "gnu-config-native.do_populate_sysroot"
>> > "python-native.do_prepare_recipe_sysroot" ->
>> > "libtool-native.do_populate_sysroot"
>> > "python-native.do_rm_work_all" [label="python-native
>> > do_rm_work_all\n:2.7.13-r1.1\n/home/gizero/work/smartliving/
>> distro/repo-master/build-poky/conf/../../layers/poky/meta/re
>> cipes-devtools/python/python-native_2.7
>> > .13.bb"]
>> > "python-native.do_rm_work_all" -> "readline-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "gnu-config-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "openssl-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "automake-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "m4-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "makedepend-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "xproto-native.do_rm_work"
>> > "python-native.do_rm_work_all" -> "bzip2-native.do_rm_work"
>> > "pytho

Re: [yocto] poky using native pkg_resources module

[Alejandro Hernandez]

Thanks Ulf, I will provide a fix soon.


Alejandro


On 09/30/2017 05:27 PM, Ulf Samuelsson wrote:



Den 2017-09-30 kl. 21:32, skrev Alejandro Hernandez:

Hey Ulf,


Yes, the problem is that the bmap-tools script is trying to be 
executed by python3 (HOST) but it should be


executed by the native python3 we just built, so fixing the shebang 
on the script should do it,


please file the bug and email me the bug number so I can take care of 
it.


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

BR
Ulf




Alejandro | aehs29


On 09/30/2017 01:31 PM, Ulf Samuelsson wrote:



Den 2017-09-29 kl. 20:18, skrev Alejandro Hernandez:

Hey Ulf,



On 09/29/2017 04:05 AM, Ulf Samuelsson wrote:
It looks like the pkg_resource module is using the native 
installation



I cloned poky early september, and could complete a build.

When I clone poky today, the build fails.

As part of "do_image_wic" from image_types_wic.bbclass

A python program in 'bmap-tools-native' is executing

"from pkg_resources import load_entry_point"

grep'ing for pkg_resources in bmap-tools-native reveals:

bmaptool:    from pkg_resources import load_entry_point
easy3_install:    from pkg_resources import load_entry_point
easy_install-3.5:    from pkg_resources import load_entry_point
=
pkg_resources.py is not available inside poky at the moment.

It is (or used to be) part of python-setuptools.


Correct, it was and still is part of setuptools


On Ubuntu, it is present in: 
"http://archive.ubuntu.com/ubuntu/pool/main/p/python-setuptools/python-setuptools_3.3.orig.tar.gz"; 


and used in Ubuntu 14.04 and 16.04 to generate the
"python3-pkg-resource" package.

When python-setuptools is generated by Yocto, it is partly
a class, but the python-setuptools-native recipe downloads
"https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-26.2.7.zip"; 



This should be setuptools-36.2.7 btw


which does not contain "pkg_resources.py"


Its not partly a class, it uses a class to install the package 
along with distutils.


=
When bmaptool imports pkg_resources, it will not find anything in the
yocto build, but will find the native 
"/usr/lib/python3/dist-packages/pkg_resources.py" from


This requires bmap-tools == 3.4, but the native bmap-tools in 
Ubuntu-14.04 is 2.5, and in Ubuntu-16.04 it is 3.2 so the build 
fails.


Maybe Ubuntu-17.04 supports bmap-tools 3.4 and it will build there,
but using the native pkg_resource is of course not a good idea?


There is something wrong with your build although I am not sure 
what it is, pkg_resources is still part of python(3)-setuptools, in 
fact you can check that in several ways


if you do a devshell on python3-setuptools-native you can see the 
extracted package contains the pkg_resources folder (so it is still 
part of the package)

>
I do: "bitbake  -c devshell python3-setuptools-native"
A terminal windows opens in 
"tmp/work/x86_64-linux/python3-setuptools-native/36.2.7-r0/setuptools-36.2.7" 



ls
bootstrap.py  easy_install.py  PKG-INFO setuptools
build launcher.c   pkg_resources 
setuptools.egg-info

CHANGES.rst   LICENSE  pytest.ini tests
conftest.py   MANIFEST.in  README.rst tox.ini
dist  msvc-build-launcher.cmd  setup.cfg
docs  pavement.py  setup.py

so the "pkg_resources" folder is present.

cd pkg_resources ; ls -l
-rw-r--r-- 1 ulf ulf  12211 Aug  2 00:40 api_tests.txt
drwxrwxr-x 3 ulf ulf   4096 Sep 30 17:35 extern
-rw-r--r-- 1 ulf ulf 104650 Aug  2 00:40 __init__.py
-rw-r--r-- 1 ulf ulf    600 Aug  2 00:40 py31compat.py
drwxrwxr-x 2 ulf ulf   4096 Sep 30 17:35 __pycache__
drwxrwxr-x 2 ulf ulf   4096 Sep 30 17:35 tests
drwxrwxr-x 4 ulf ulf   4096 Sep 30 17:35 _vendor

so there is NO "pkg_resource.py" file inside.

The statement that fails is "from pkg_resources import 
load_entry_point"


"load_entry_point" is defined in pkg_resources/__init__.py

Somewhere, something decides that
"/usr/lib/python3/dist-packages/pkg_resources.py"
is what we want.

I have a fresh install of Ubuntu-16.04.
This has received the latest package updates.
I have also installed a set of packages I usually install on a machine.
Not much more.

environment lack anything python related.

In one test, I git cloned a fresh copy of "poky".
No layers added.'
Insignificant changes to "local.conf", only changed some directory 
location


Building the beaglebone, and problem occurs.

If I build from poky "8b4f16a9cbbaf521461f699b7264fac2ac872581" from
Mon Sep 4 11:39:24, I have no problem.

Best Regards
Ulf Samuelsson

then if you do a devshell after do_install, you can check the image 
directory and find the setuptools.egg file, which is what 
python-native uses later, if you unzip that
egg file, you can see that pkg_resources is there, so it was in 
fact packaged on Yocto / by bitbake.


Lastly, you can also do a
$ bitbake bmap-tools-nat

[yocto] sstate and multiconfigs

[Anders Montonen]

Hi,

We've been trying out a setup using multiconfigs to select the source 
control branch some set of recipes to build. The building part goes well, 
but whenever we run package-index, the packages built using this scheme 
are deleted.


The basic setup is that we have one multiconfig per branch ('master', 
'staging' etc.) In addition to providing the name of the branch, they are 
also used to configure some variables like PACKAGE_FEED_URIS. Next, we 
have a class that basically looks like this (the 'master' config was 
originally called 'devel'):


"""
def select_branch(d):
branch = d.getVar('BB_CURRENT_MC', True)
if branch == 'default' or branch == 'devel':
branch = 'master'

if not branch:
branch = 'master'
return branch

MC_BRANCH ?= "${@select_branch(d)}"
"""

In the recipe we have something like the following:
inherit git-multiconfig # our class
inherit gitpkgv

SRCREV = "${AUTOREV}"
PV = "${FOO_VERSION}.0+gitr${SRCPV}"
PKGV = "${MC_BRANCH}-${FOO_VERSION}.0+${GITPKGV}"
SRC_URI += "gitsm://git@repo/foo.git;protocol=ssh;branch=${MC_BRANCH}"

As stated above, when a specific recipe is built (bitbake 
multiconfig:master:foo), everything looks fine, but whenever package-index 
is run (with or without multiconfig), all rpms built using this scheme 
will be deleted.


If the MC_BRANCH variable is hardcoded inside the class (eg. changing the 
body of select_branch() to a single return statement) things work as 
expected. Any suggestions on what's going on, and how to fix it (or do it 
in a better way)? The ultimate goal is being able to build multiple 
branches of our project without having to encode or duplicate that 
information, ideally receiving it as a parameter from the CI system.


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

Re: [yocto] Problems when adding custom layer

[Burton, Ross]

On 2 October 2017 at 16:55, Aaron Sarginson  wrote:

> When added, I receive parsing errors at the inherit “systemd” line.
>

No quotes needed, just:

inherit systemd

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

[yocto] Problems when adding custom layer

[Aaron Sarginson]

Hello,

I am trying to add a folder and some files to a raspberry pi build which does 
build successfully with the latest Yocto.
When added, I receive parsing errors at the inherit “systemd” line.
The idea is that the web-files folder should be transferred in its entirety, 
rules.sh and the executable ‘project’ to the same folder plus ddd.service which 
is a systemd service file for ‘project’.

meta-ddd
├── conf
│   └── layer.conf
├── files
│   └── ddd.service
├── project
├── README
├── rules.sh
└── web-files
└── sub-folder

SUMMARY = “DDD software installation"
DESCRIPTION = "Transfers files and sets up systemd for DDD."

SRC_URI += "\
file://web-files/* \
file://project \
file://ddd.service \
file://rules.sh \
"
S = "${WORKDIR}"

inherit "systemd"

SYSTEMD_PACKAGES = "${PN}"

SYSTEMD_SERVICE_${PN} = " ddd.service"

FILES_${PN} += " ddd.service \
 /web-files/ \
 /opt/ddd/project \
"


do_install () {
install -d ${D}{sysconfdir}/systemd/system
install -d ${D}/opt/ddd
install -m 0755 ${WORKDIR}/web-files/ ${D}/opt/ddd
install -m 0755 ${WORKDIR}/ddd.service
${D}{sysconfdir}/systemd/system
install -m 0755 ${WORKDIR}/project ${D}/opt/ddd
}-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: autotooler: generation of "configure.ac" and "Makefile.am" using Kconfig

[Leonardo Sandoval]

On Sat, 30 Sep 2017 16:49:09 +0200
Ulf Samuelsson  wrote:

> Have a need to convert a large number of libraries to use autotools.
> 

> I came up with the following idea:

I got poor experience in enabling autotools into a project but
have you ping the autotools community to discuss your approach? perhaps there
are already other approaches that may be reused for your needs.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration fragments not making it into kernel configuration

[Jonathan Haws]

> > > I know I can fix this by simply doing a menuconfig, but that
> > > isn't
> > > the
> > > proper way to do it - I have multiple BSP layers that do the same
> > > thing
> > > and they all behave in the same way.
> > > 
> > > What am I doing wrong?  I've attached my layer that contains the
> > > recipe.  If the fragments are getting installed I think the
> > > recipe
> > > is
> > > working right - but is there something in the lower-level class
> > > that
> > > isn't working or do I have a configuration that is breaking it?
> > I did a build with morty and your BSP, and I'm not seeing
> > the same results.
> > 
> > One notable difference is that if you are using the tip of
> > the morty branches, you should get 4.8.17, not 4.8.3.
> > 
> > I did zero extra configuration, just added your layer, meta-intel
> > and then bitbaked linux-yocto-rt.
> I just noticed that my meta-intel layer was a few commits behind, a
> likely culprit for what I'm seeing.  I'm rebuilding to see what I
> get.
> I'll report back when I have something.
> 
> If this doesn't solve my issue, would you recommend wiping my sstate?
> I've already wiped out tmp without success.

Issue resolved.  Fragments now making it into the kernel configuration
correctly.  Thanks, Bruce!

> > 
> > Maybe I'm misunderstanding what I see in the BSP layer, but I
> > did get IGB disabled:
> > 
> > :~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-
> > yocto-
> > rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-
> > intel-
> > common-preempt-rt-build$ 
> > grep CONFIG_IGB .config
> > # CONFIG_IGB is not set
> > CONFIG_IGBVF=m
> > 
> > And I did get a warning during the build:
> > 
> > -- CONFIG_IGB_DCA -
> > Config: CONFIG_IGB_DCA
> > From: 
> > /home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-
> > source/.kernel-meta/configs/standard/preempt-
> > rt/intel/features/dca/dca.cfg
> > Requested value:  CONFIG_IGB_DCA=y
> > Actual value:
> > 
> > Config 'IGB_DCA' has the following conditionals:
> >    IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> > IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> > Dependency values are:
> >    y [y] m [m] IGB [n] DCA [y]
> > 
> > 
> > 
> > Which explains why CONFIG_IGB_DCA didn't make it into the final
> > .config
> > 
> > Can you clarify what you were looking to get for final
> > configuration
> > settings ?
> The three fragments should disable the Intel IGB driver (CONFIG_IGB
> not
> set), enable some GPIO I2C drivers, and enable direct cache access.
> 
> I'm guessing CONFIG_IGB_DCA was set in the original config and
> CONFIG_IGB is not being set, so IGB_DCA is getting unset causing the
> warning.  I'll adjust my IGB fragment to explicity disable
> CONFIG_IGB_DCA as well.

I get the same warning, and I believe it is because that setting is
only available if CONFIG_IGB is 'y' or 'm'.  Since I'm removing
CONFIG_IGB, CONFIG_IGB_DCA isn't even an option.  If I add "#
CONFIG_IGB_DCA is not set" to my fragment, I get the following warning:
-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From: /opt/yocto/poky/build-teisit/tmp/work-shared/xpedite7570/kernel-
source/.kernel-meta/configs/standard/preempt-
rt/intel/features/dca/dca.cfg /opt/yocto/poky/build-teisit/tmp/work-
shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-
rt/intel/Remove_Intel_IGB_driver.cfg
Requested value:  # CONFIG_IGB_DCA is not set
Actual value: 

Config 'IGB_DCA' has the following conditionals: 
  IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are: 
  y [y] m [m] IGB [n] DCA [y]

What is the best way to clean up this type of warning - one where the
setting is a conditional option and is enabled in the default
configuration but a fragment removes the parent option?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration fragments not making it into kernel configuration

[Jonathan Haws]

On Mon, 2017-10-02 at 10:54 -0400, Bruce Ashfield wrote:
> On 09/30/2017 11:22 PM, Jonathan Haws wrote:
> > 
> > All,
> > 
> > I've created a bbappend that appends to the linux-yocto-rt recipe
> > to
> > simply apply configuration fragments.  I've been using this recipe
> > for
> > some time (through many releases) but since I moved to the morty
> > branch
> > my fragments aren't getting applied to the actual kernel
> > configuration.
> >   The kernel_configcheck task doesn't catch the error either.
> > 
> > What I'm trying to do in a nutshell is disable the in-kernel IGB
> > driver
> > and use my own, patched version.  The configuration fragments are
> > installed by my recipe in:
> > 
> > /tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
> > rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/
> > 
> > However the .config file at:
> > 
> >   /tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
> > rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/linux-corei7-64-intel-
> > common-preempt-rt-build/.config
> > 
> > doesn't have the necessary configuration - it still has the
> > default.
> > 
> > I know I can fix this by simply doing a menuconfig, but that isn't
> > the
> > proper way to do it - I have multiple BSP layers that do the same
> > thing
> > and they all behave in the same way.
> > 
> > What am I doing wrong?  I've attached my layer that contains the
> > recipe.  If the fragments are getting installed I think the recipe
> > is
> > working right - but is there something in the lower-level class
> > that
> > isn't working or do I have a configuration that is breaking it?
> I did a build with morty and your BSP, and I'm not seeing
> the same results.
> 
> One notable difference is that if you are using the tip of
> the morty branches, you should get 4.8.17, not 4.8.3.
> 
> I did zero extra configuration, just added your layer, meta-intel
> and then bitbaked linux-yocto-rt.

I just noticed that my meta-intel layer was a few commits behind, a
likely culprit for what I'm seeing.  I'm rebuilding to see what I get.
I'll report back when I have something.

If this doesn't solve my issue, would you recommend wiping my sstate?
I've already wiped out tmp without success.

> Maybe I'm misunderstanding what I see in the BSP layer, but I
> did get IGB disabled:
> 
> :~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-
> rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-intel-
> common-preempt-rt-build$ 
> grep CONFIG_IGB .config
> # CONFIG_IGB is not set
> CONFIG_IGBVF=m
> 
> And I did get a warning during the build:
> 
> -- CONFIG_IGB_DCA -
> Config: CONFIG_IGB_DCA
> From: 
> /home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-
> source/.kernel-meta/configs/standard/preempt-
> rt/intel/features/dca/dca.cfg
> Requested value:  CONFIG_IGB_DCA=y
> Actual value:
> 
> Config 'IGB_DCA' has the following conditionals:
>    IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> Dependency values are:
>    y [y] m [m] IGB [n] DCA [y]
> 
> 
> 
> Which explains why CONFIG_IGB_DCA didn't make it into the final
> .config
> 
> Can you clarify what you were looking to get for final configuration
> settings ?

The three fragments should disable the Intel IGB driver (CONFIG_IGB not
set), enable some GPIO I2C drivers, and enable direct cache access.

I'm guessing CONFIG_IGB_DCA was set in the original config and
CONFIG_IGB is not being set, so IGB_DCA is getting unset causing the
warning.  I'll adjust my IGB fragment to explicity disable
CONFIG_IGB_DCA as well.

> > 
> > 
> > Any help or direction is appreciated.  This has been really
> > frustrating
> > since I know I've done this before and all the threads I've found
> > on
> > the lists from before haven't really given an answer - maybe I just
> > missed the golden thread?
> > 
> > Thanks!
> > Jon
> > 
> > 
> > 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW40’17

[Jolley, Stephen K]

Current Dev Position: YP 2.4 M4 - rc1 is in QA

Next Deadline: YP 2.4 Final Cut off has passed.


SWAT team rotation: Maxin -> Cal on Sept. 29, 2017.

SWAT team rotation: Cal -> Joshua on Oct. 6, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·YP 2.4 (Rocko) Final rc1 is in QA.  See status at: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status.  We expect the QA report to 
be published around midweek.

·YP 2.5 Planning has begun.  Please enter your enhancement requests 
into Bugzilla.  Target milestone dates will be selected over the next few weeks.

·YP 2.3.2 (Pyro) and 2.2.2 (Morty) have both been released with the 
usual collection of security and bug fixes.  It is recommended that users 
upgrade.

·As a reminder, we are still in feature freeze and working on bug 
fixing. As such, recipe upgrades are not going to be taken, nor are patches 
which cause changes in behavior or break compatibility. In future releases our 
policy regarding version upgrades will be to identify anything that needs to 
change in M4 in advance (e.g. kernel or u-boot) so this issue becomes clearer 
and only known changes come in.


Planned upcoming dot releases:

YP 2.2.3 is planned, but date TBD during YP 2.5 planning.

YP 2.3.3 is planned, but date TBD during YP 2.5 planning.

YP 2.4.1 is planned, but date TBD during YP 2.5 planning.


Key YP 2.4 Dates are:

YP 2.4 M4 (Final) is in QA.

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Key YP 2.5 Dates are still TBD


Tracking Metrics:

WDD 2405 (last week 2380)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:  stephen.k.jol...@intel.com

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

Re: [yocto] mono 5.0.1.1 TypeLoadException

[Alex J Lennon]

Hi Robin,

If you supply a test case I’ll take a look.

Regards,

Alex

> On 2 Oct 2017, at 15:02, MUGRIDGE Robin  wrote:
> 
> Hi,
>  
> I am using mono with Krogoth.  The current version of mono we are building 
> with is 4.2.2.30.
>  
> I am trying to move mono forward to 5.0.1.1 to avoid an issue in the 
> HttpListener class, but now get a TypeLoadException which I assume is a 
> missing assembly or a build configuration error, but I’m struggling to work 
> out what’s wrong…
>  
> System.TypeLoadException: Could not load type of field 
> 'System.Net.HttpListener:tlsSettings' (9) due to: Could not resolve type with 
> token 0134 (from typeref, class/assembly 
> Mono.Security.Inteace.MonoTlsSettings, Mono.Security, Version=4.0.0.0, 
> Culture=neutral, PublicKeyToken=0738eb9f132ed756) assembly:Mono.Security, 
> Version=4.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 
> typMono.Security.Interface.MonoTlsSettings member:
>  
> Has anyone else come across this and know what the root cause is?
>  
> Thanks,
>  
> Robin
>  
>  
>  
> 
> 
> ___
> This e-mail is confidential and is for the addressee only.   Please refer to 
> www.oxinst.com/email-statement for regulatory 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

[yocto] mono 5.0.1.1 TypeLoadException

[MUGRIDGE Robin]

Hi,

I am using mono with Krogoth.  The current version of mono we are building with 
is 4.2.2.30.

I am trying to move mono forward to 5.0.1.1 to avoid an issue in the 
HttpListener class, but now get a TypeLoadException which I assume is a missing 
assembly or a build configuration error, but I'm struggling to work out what's 
wrong...

System.TypeLoadException: Could not load type of field 
'System.Net.HttpListener:tlsSettings' (9) due to: Could not resolve type with 
token 0134 (from typeref, class/assembly 
Mono.Security.Inteace.MonoTlsSettings, Mono.Security, Version=4.0.0.0, 
Culture=neutral, PublicKeyToken=0738eb9f132ed756) assembly:Mono.Security, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 
typMono.Security.Interface.MonoTlsSettings member:

Has anyone else come across this and know what the root cause is?

Thanks,

Robin





___This 
e-mail is confidential and is for the addressee only.  Please refer to 
www.oxinst.com/email-statement for regulatory information.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration fragments not making it into kernel configuration

[Bruce Ashfield]

On 09/30/2017 11:22 PM, Jonathan Haws wrote:

All,

I've created a bbappend that appends to the linux-yocto-rt recipe to
simply apply configuration fragments.  I've been using this recipe for
some time (through many releases) but since I moved to the morty branch
my fragments aren't getting applied to the actual kernel configuration.
  The kernel_configcheck task doesn't catch the error either.

What I'm trying to do in a nutshell is disable the in-kernel IGB driver
and use my own, patched version.  The configuration fragments are
installed by my recipe in:

/tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/

However the .config file at:

  /tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/linux-corei7-64-intel-
common-preempt-rt-build/.config

doesn't have the necessary configuration - it still has the default.

I know I can fix this by simply doing a menuconfig, but that isn't the
proper way to do it - I have multiple BSP layers that do the same thing
and they all behave in the same way.

What am I doing wrong?  I've attached my layer that contains the
recipe.  If the fragments are getting installed I think the recipe is
working right - but is there something in the lower-level class that
isn't working or do I have a configuration that is breaking it?


I did a build with morty and your BSP, and I'm not seeing
the same results.

One notable difference is that if you are using the tip of
the morty branches, you should get 4.8.17, not 4.8.3.

I did zero extra configuration, just added your layer, meta-intel
and then bitbaked linux-yocto-rt.

Maybe I'm misunderstanding what I see in the BSP layer, but I
did get IGB disabled:

:~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-intel-common-preempt-rt-build$ 
grep CONFIG_IGB .config

# CONFIG_IGB is not set
CONFIG_IGBVF=m

And I did get a warning during the build:

-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From: 
/home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-rt/intel/features/dca/dca.cfg

Requested value:  CONFIG_IGB_DCA=y
Actual value:

Config 'IGB_DCA' has the following conditionals:
  IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
  y [y] m [m] IGB [n] DCA [y]



Which explains why CONFIG_IGB_DCA didn't make it into the final .config

Can you clarify what you were looking to get for final configuration
settings ?

Bruce




Any help or direction is appreciated.  This has been really frustrating
since I know I've done this before and all the threads I've found on
the lists from before haven't really given an answer - maybe I just
missed the golden thread?

Thanks!
Jon





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

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

[Andrei Gherzan]

On Wed, Sep 27, 2017 at 02:45:07PM -0300, Otavio Salvador wrote:
> Hello Martin,
>
> On Wed, Sep 27, 2017 at 2:34 PM, Martin Jansa  wrote:
> ...
> >> Martin, do you have any idea how other alternative we have?
> >
> > In theory you can set QT_PACKAGES_ARCH to MACHINE_ARCH in rpi-base.inc
> > to make it explicit, but that's also really bad (as e.g. rpi2 and rpi3
> > will each build it's own qtwebengine and all it's deps even when it
> > should be the same for both).
>
> Agreed and that was the reason of we create MACHINE_SOCARCH in
> meta-freescale. It allows for SoC specific packages but compatible
> across machines.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750

Merged to master in the meanwhile.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto