date:20171220

[yocto] QA cycle report for 2.3.3 RC1

2017-12-20 Thread Cruz, Libertad

Hello All,
Enjoy viewing the full Report for 2.3.3 RC1:  
https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1

=== Summary 

The QA cycle for release 2.3.3 RC1 is complete.  There are 4 new bugs from 
which so far none of them are high. QA has two big concerns:

1.  Performance report shows an increase of 30% build time on the eSDK 
in fedora 23, bug has not been created until further investigation with setup 
outside of the GDC environment. 
2.  ptest comparison script is giving wrong results, bug 12441 was 
opened. 


-

ptest

Package slang show 0% pass rate in 2.3.3 rc1, the results need to be validated, 
because bug 12441 impacts the comparison script.

-

Toaster
Exploratory testing was executed in this release.

-
Performance

The performance results showed regression on some of the measurements compared 
to 2.3.2rc1 info showed below, the most important one is on building eSDK that 
is taking around 30% of increase on fedora machine.


Ubuntu 15  Test   2.3.2 rc1  2.3.3 rc1  
%
 sato   1:12:11
1:16:29+5.96
 rootfs2:49 
 2:53  +2.37
 rmwork 1:04:15
1:06:47+3.94
 kernel5:21 
 5:25  +1.25
 eSDK  2:46 
 2:46  0.00
   
   
Fedora 23   Test   2.3.2 rc1  2.3.3 rc1 
 %
 sato   1:14:51
1:21:20+8.66
 rootfs2:45 
 2:44  -0.61
 rmwork 1:07:47
1:14:54+10.50
 kernel5:56 
 6:04  +2.25
 eSDK  3:06 
 4:12  +35.48


https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1#Performance_Charts

=== QA-Hints


The build is stable enough to be released, provided the following results are 
checked and investigated:

1. Performance needs to be executed in an environment outside of GDC in 
another fedora 23, volunteers?
2. QA asks ptest for slang package be checked by development to verify that 
it is executing.

=== Bugs 

   New Bugs
    -12440[1] test_qemu_efi (oeqa.selftest.wic.Wic) fails on Fedora26
-12441[2] ptest comparison script is not showing correct results
-12436[3] [Test Case 1958] Project names cannot be blank
    -12437[4] [Test Case 1958] Toaster exploratory testingin the test 
run.

   Not new M+ bugs
    -12022[5] signing.Signing.test_signing_packages hangs on 
ubuntu1704.yocto.io

Full Bug Report:  
https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1#Bugs_Found_during_QA_Test



 Links =
    1.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12440[1] 

    2.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12441[2] 

    3.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12436[3] 

    4.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12437[4] 

    5.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12022 [5] 
   

Regards
Libertad G.


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

Re: [yocto] Rocko and Circular Dependencies

2017-12-20 Thread Barry Grussling

It does have a custom layer in it.  I am also using meta-linaro.  I have tried
to reproduce it in the stock configuration and have not been successful.

It isn't yet obvious to me what I am doing in my layer that is causing
the cirular reference in the base layers.  I will keep digging and see
what I can
learn.  I am not adding any custom tasks (add task) or anything like that.

I will work on adding my layer back in piece by piece and see if I can figure
out what the trigger criteria is.

On Wed, Dec 20, 2017 at 2:22 AM, Burton, Ross  wrote:
> Nobody else has seen this as far as I'm aware, and the autobuilder doesn't
> see it.
>
> Is that a pure oe-core/bitbake or Poky, or do you have custom layers?  Can
> you replicate with a stock configuration?
>
> On 20 December 2017 at 03:02, Barry Grussling  wrote:
>>
>> Hello all,
>>
>> I am trying to move one of my builds from Krogoth to Rocko.  I am
>> attempting to build
>> on 1c61ba0a3f bitbake: tinfoil: Ensure we clean up loggers.
>>
>> Generally, I can start the first build fine.  Unfortunately, some of
>> my code/recipes will usually fail
>> to build due to the new compilers.  When I re-run bitbake to continue
>> the build, most of
>> the time I experience a build failure of circular dependencies such as:
>>
>> Dependency loop #1 found:
>>   Task
>> /srv/BLD/yocto/meta/recipes-core/ncurses/ncurses_6.0+20170715.bb:do_package
>> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
>> 'gcc-runtime_7.2.bb:do_packagedata', 'glibc_2.26.bb:do_packagedata',
>> 'rpm_git.bb:do_populate_sysroot',
>> 'ncurses_6.0+20170715.bb:do_install',
>> 'dpkg_1.18.24.bb:do_packagedata',
>> 'libtool-cross_2.4.6.bb:do_packagedata'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-core/ncurses/ncurses_6.0+20170715.bb:do_packagedata
>> (dependent Tasks ['ncurses_6.0+20170715.bb:do_package'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_package
>> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
>> 'gcc-runtime_7.2.bb:do_packagedata', 'perl_5.24.1.bb:do_packagedata',
>> 'glibc_2.26.bb:do_packagedata', 'rpm_git.bb:do_populate_sysroot',
>> 'ncurses_6.0+20170715.bb:do_packagedata',
>> 'bzip2_1.0.6.bb:do_packagedata', 'dpkg_1.18.24.bb:do_install',
>> 'zlib_1.2.11.bb:do_packagedata',
>> 'libtool-cross_2.4.6.bb:do_packagedata',
>> 'xz_5.2.3.bb:do_packagedata'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_packagedata
>> (dependent Tasks ['dpkg_1.18.24.bb:do_package'])
>>
>> Dependency loop #2 found:
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_package
>> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
>> 'gcc-runtime_7.2.bb:do_packagedata', 'perl_5.24.1.bb:do_packagedata',
>> 'glibc_2.26.bb:do_packagedata', 'rpm_git.bb:do_populate_sysroot',
>> 'ncurses_6.0+20170715.bb:do_packagedata',
>> 'bzip2_1.0.6.bb:do_packagedata', 'dpkg_1.18.24.bb:do_install',
>> 'zlib_1.2.11.bb:do_packagedata',
>> 'libtool-cross_2.4.6.bb:do_packagedata',
>> 'xz_5.2.3.bb:do_packagedata'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_packagedata
>> (dependent Tasks ['dpkg_1.18.24.bb:do_package'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_package
>> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
>> 'gcc-runtime_7.2.bb:do_packagedata', 'glibc_2.26.bb:do_packagedata',
>> 'rpm_git.bb:do_populate_sysroot', 'dpkg_1.18.24.bb:do_packagedata',
>> 'libtool-cross_2.4.6.bb:do_packagedata', 'bzip2_1.0.6.bb:do_install'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_packagedata
>> (dependent Tasks ['bzip2_1.0.6.bb:do_package'])
>>
>> Dependency loop #3 found:
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_compile
>> (dependent Tasks ['dpkg_1.18.24.bb:do_configure'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_install
>> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
>> 'dpkg_1.18.24.bb:do_compile'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:do_populate_sysroot
>> (dependent Tasks ['dpkg_1.18.24.bb:do_install',
>> 'binutils-cross_2.29.bb:do_populate_sysroot'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_prepare_recipe_sysroot
>> (dependent Tasks ['libtool-cross_2.4.6.bb:do_populate_sysroot',
>> 'glibc_2.26.bb:do_populate_sysroot', 'bzip2_1.0.6.bb:do_fetch',
>> 'libtool-native_2.4.6.bb:do_populate_sysroot',
>> 'dpkg_1.18.24.bb:do_populate_sysroot',
>> 'gcc-runtime_7.2.bb:do_populate_sysroot',
>> 'gnu-config_git.bb:do_populate_sysroot',
>> 'gcc-cross_7.2.bb:do_populate_sysroot',
>> 'automake_1.15.1.bb:do_populate_sysroot',
>> 'autoconf_2.69.bb:do_populate_sysroot'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_configure
>> (dependent Tasks ['bzip2_1.0.6.bb:do_patch',
>> 'bzip2_1.0.6.bb:do_prepare_recipe_sysroot'])
>>   Task
>> /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_com

[yocto] add kernel modules & dtbo's for Raspberry Pi3

2017-12-20 Thread Greg Wilson-Lindberg

I'm building an image for the Raspberry Pi 3 and I'm trying to add some modules 
to the kernel and I need to add some device tree overlays. The modules and 
overlays are part of the kernel, just not built by default.


For the kernel modules I've added a linux-raspberrypi_4.4.bbappend file in the 
path .../recipes-bsp/linux. The file consists of:

# Scribe additions to Kernel configuration

FILESEXTRAPATHS_prepend += "$(THISDIR)/files"
SRC_URI += "file://Scribe.cfg"

Whether I use "+=" or ":=" as suggested in "Embedded Linux Systems withe the 
Yocto Project", I get an error that "file://0001-fix-dtbo-rules.patch" cannot 
be found. I don't get this error if my .bbappend file is not being used.


Also, if there are any quick tips on how to add dtbo's to the kernel build I 
would appreciate them.


Regards,

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

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

2017-12-20 Thread Ingo Flaschberger


Dear Patrick,

this doesn't work:
 0162:    """
 0163:    parsed_url = urllib.parse.urlsplit(url)
 0164:    if parsed_url.username != None:
 0165:    # Use the netloc with just the hostname, without 
username/password.

 *** 0166:    parsed_url.netloc = parsed_url.hostname
 0167:    # The username/password are installed permanently in 
the urllib.request module

 0168:    # for future use with all URLs beneath url.
 0169:    manager = 
urllib.request.HTTPPasswordMgrWithDefaultRealm()
 0170:    manager.add_password(None, parsed_url, 
parsed_url.username, parsed_url.password)

Exception: AttributeError: can't set attribute


Using hostname as netloc will also remove an additional portnumber - 
could this be a problem?


Bye,
    Ingo


Am 20.12.2017 um 16:50 schrieb Patrick Ohly:

Downloading content and version information via HTTP may need a
username/password for basic authentication. To support this,
SWUPD_VERSION_URL and SWUPD_CONTENT_URL can now contain URLs of the
form http(s)://:@/.

Original patch from: Ingo Flaschberger 

Signed-off-by: Patrick Ohly 
---
  lib/swupd/bundles.py | 26 --
  1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/lib/swupd/bundles.py b/lib/swupd/bundles.py
index e1eec5a..48c7455 100644
--- a/lib/swupd/bundles.py
+++ b/lib/swupd/bundles.py
@@ -5,6 +5,7 @@ import subprocess
  import shutil
  import urllib.request
  import urllib.error
+import urllib.parse
  from bb.utils import export_proxies
  from oe.package_manager import RpmPM
  from oe.package_manager import OpkgPM
@@ -153,6 +154,27 @@ def copy_bundle_contents(d):
  for bndl in bundles:
  stage_empty_bundle(d, bndl)
  
+def handle_plain_auth(url):

+"""
+Check for special urls with username/password (as in 
http://user:password@host/),
+extract those and install an auth handler which will provide them
+to the HTTP server when needed. Returns the URL that is to be instead of 
the original one.
+"""
+parsed_url = urllib.parse.urlsplit(url)
+if parsed_url.username != None:
+# Use the netloc with just the hostname, without username/password.
+parsed_url.netloc = parsed_url.hostname
+# The username/password are installed permanently in the 
urllib.request module
+# for future use with all URLs beneath url.
+manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
+manager.add_password(None, parsed_url, parsed_url.username, 
parsed_url.password)
+authHandler = urllib.request.HTTPBasicAuthHandler(manager)
+opener = urllib.request.build_opener(authHandler)
+urllib.request.install_opener(opener)
+return urllib.parse.urlunsplit(new_source)
+else:
+return url
+
  def download_manifests(content_url, version, component, to_dir):
  """
  Download one manifest file and recursively all manifests referenced by it.
@@ -204,8 +226,8 @@ def download_old_versions(d):
  a normal build and thus is not on the critical path.
  """
  
-content_url = d.getVar('SWUPD_CONTENT_BUILD_URL', True)

-version_url = d.getVar('SWUPD_VERSION_BUILD_URL', True)
+content_url = handle_plain_auth(d.getVar('SWUPD_CONTENT_BUILD_URL', True))
+version_url = handle_plain_auth(d.getVar('SWUPD_VERSION_BUILD_URL', True))
  current_format = int(d.getVar('SWUPD_FORMAT', True))
  deploy_dir = d.getVar('DEPLOY_DIR_SWUPD', True)
  www_dir = os.path.join(deploy_dir, 'www')


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

Re: [yocto] Some trivial question about git update-ref refs/heads/rocko ...

2017-12-20 Thread Andre McCurdy

On Wed, Dec 20, 2017 at 8:32 AM, Zoran Stojsavljevic
 wrote:
> I am trying to upgrade my poky distro with current HEAD:
> 65d23bd7986615fdfb0f1717b615534a2a14ab80
>
> It is ~ one month old.
>
> And to the latest HEAD:370483fce1c2429c81b19dcf8a36394dc3fc3d92
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=370483fce1c2429c81b19dcf8a36394dc3fc3d92
>
> The transcript what I do is below:
> [user@localhost poky]$ pwd
> /home/user/YOCTO/oe_core_embedded/poky
> [user@localhost poky]$ git update-ref refs/heads/rocko
> 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> fatal: update_ref failed for ref 'refs/heads/rocko': cannot update ref
> 'refs/heads/rocko': trying to write ref 'refs/heads/rocko' with nonexistent
> object 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> [user@localhost poky]$ git update-ref refs/heads/rocko HEAD
> 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> fatal: update_ref failed for ref 'refs/heads/rocko': cannot lock ref
> 'refs/heads/rocko': is at 65d23bd7986615fdfb0f1717b615534a2a14ab80 but
> expected 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> [user@localhost poky]$
>
> What I am doing wrong?!

To switch from rocko to master, try:

  git fetch origin
  git checkout -B master origin/master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Trying to make PylonGPS build with DEPENDS, does not find includes

2017-12-20 Thread cc_Smart


Greetings.

I'm trying to set up a poky layer at 
https://github.com/navdata-net/meta-navdatanet/tree/rocko


Compiling PylonGPS from https://github.com/charlesrwest/pylonGPS 
requires, amongst others Google protobuf.


I include this as

DEPENDS += "protobuf-native"

During build i get

fatal error: google/protobuf/stubs/common.h: No such file or directory
#include 

However, this file can be found at

/workdir/dev/rpi3/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/pylongps/0.1.0-r0/recipe-sysroot-native/usr/include/google/protobuf/stubs/common.h

So i assume it is a problem with visibility / build environment setup.

For running the build, i'm using the crops/poky docker image.

Where should i look for finding the correct solution ?

Thanks for your input.


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

[yocto] Some trivial question about git update-ref refs/heads/rocko ...

2017-12-20 Thread Zoran Stojsavljevic

I am trying to upgrade my poky distro with current HEAD:
65d23bd7986615fdfb0f1717b615534a2a14ab80

It is ~ one month old.

And to the latest HEAD:370483fce1c2429c81b19dcf8a36394dc3fc3d92
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=370483fce1c2429c81b19dcf8a36394dc3fc3d92

The transcript what I do is below:
[user@localhost poky]$ pwd
/home/user/YOCTO/oe_core_embedded/poky
[user@localhost poky]$ git update-ref refs/heads/rocko
370483fce1c2429c81b19dcf8a36394dc3fc3d92
fatal: update_ref failed for ref 'refs/heads/rocko': cannot update ref
'refs/heads/rocko': trying to write ref 'refs/heads/rocko' with nonexistent
object 370483fce1c2429c81b19dcf8a36394dc3fc3d92
[user@localhost poky]$ git update-ref refs/heads/rocko HEAD
370483fce1c2429c81b19dcf8a36394dc3fc3d92
fatal: update_ref failed for ref 'refs/heads/rocko': cannot lock ref
'refs/heads/rocko': is at 65d23bd7986615fdfb0f1717b615534a2a14ab80 but
expected 370483fce1c2429c81b19dcf8a36394dc3fc3d92
[user@localhost poky]$

What I am doing wrong?!

Thank you,
Zoran
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Trying to make PylonGPS build with DEPENDS, does not find includes

2017-12-20 Thread ccSmart


Greetings.

I'm trying to set up a poky layer at 
https://github.com/navdata-net/meta-navdatanet/tree/rocko


Compiling PylonGPS from https://github.com/charlesrwest/pylonGPS 
requires, amongst others Google protobuf.


I include this as

DEPENDS += "protobuf-native"

During build i get

fatal error: google/protobuf/stubs/common.h: No such file or directory
#include 

However, this file can be found at

/workdir/dev/rpi3/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/pylongps/0.1.0-r0/recipe-sysroot-native/usr/include/google/protobuf/stubs/common.h

So i assume it is a problem with visibility / build environment setup.

For running the build, i'm using the crops/poky docker image.

Where should i look for finding the correct solution ?

Thanks for your input.


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

[yocto] issue with clang-native when building with bitbake

2017-12-20 Thread Tomasz Michalski

Hi
When I build image I get such error and build stops:

ERROR: Nothing PROVIDES 'clang-native'. Close matches:

NOTE: Runtime target 'lib32-ty' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['lib32-ty', 'clang-native']
NOTE: Runtime target 'lib32-duma' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['lib32-duma', 'lib32-ty',
'clang-native']

So I grep all my repository with command
"grep -r "*clang-native*" ./
and I don't see any recipe/anything which inherits or depends on
clang-native. In fact nothing is found for keyword "*clang-native*".
Nevertheless I debugged that clang is connected with
meta-openembedded and there is meta-clang available on
https://github.com/kraj/meta-clang so I downloaded meta-clang dir and
placed it in meta-openembedded directory but nothing changes, still the
error is the same.

Could someone give some hints how to debug such problem? The strange thing
is that nothing is found for keyword "clang-native" in yocto project.
lib32-ty doesn't depend on clang-native despite the output from console is:
Missing or unbuildable dependency chain was: ['lib32-ty', 'clang-native']
I checked lib32-ty recipe.
In fact I don't need clang at all, however it is no matter for me, if I
have to I can add this to my project.

Thanks in advance for hints
Tomek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-12-20 Thread Patrick Ohly

Downloading content and version information via HTTP may need a
username/password for basic authentication. To support this,
SWUPD_VERSION_URL and SWUPD_CONTENT_URL can now contain URLs of the
form http(s)://:@/.

Original patch from: Ingo Flaschberger 

Signed-off-by: Patrick Ohly 
---
 lib/swupd/bundles.py | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/lib/swupd/bundles.py b/lib/swupd/bundles.py
index e1eec5a..48c7455 100644
--- a/lib/swupd/bundles.py
+++ b/lib/swupd/bundles.py
@@ -5,6 +5,7 @@ import subprocess
 import shutil
 import urllib.request
 import urllib.error
+import urllib.parse
 from bb.utils import export_proxies
 from oe.package_manager import RpmPM
 from oe.package_manager import OpkgPM
@@ -153,6 +154,27 @@ def copy_bundle_contents(d):
 for bndl in bundles:
 stage_empty_bundle(d, bndl)
 
+def handle_plain_auth(url):
+"""
+Check for special urls with username/password (as in 
http://user:password@host/),
+extract those and install an auth handler which will provide them
+to the HTTP server when needed. Returns the URL that is to be instead of 
the original one.
+"""
+parsed_url = urllib.parse.urlsplit(url)
+if parsed_url.username != None:
+# Use the netloc with just the hostname, without username/password.
+parsed_url.netloc = parsed_url.hostname
+# The username/password are installed permanently in the 
urllib.request module
+# for future use with all URLs beneath url.
+manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
+manager.add_password(None, parsed_url, parsed_url.username, 
parsed_url.password)
+authHandler = urllib.request.HTTPBasicAuthHandler(manager)
+opener = urllib.request.build_opener(authHandler)
+urllib.request.install_opener(opener)
+return urllib.parse.urlunsplit(new_source)
+else:
+return url
+
 def download_manifests(content_url, version, component, to_dir):
 """
 Download one manifest file and recursively all manifests referenced by it.
@@ -204,8 +226,8 @@ def download_old_versions(d):
 a normal build and thus is not on the critical path.
 """
 
-content_url = d.getVar('SWUPD_CONTENT_BUILD_URL', True)
-version_url = d.getVar('SWUPD_VERSION_BUILD_URL', True)
+content_url = handle_plain_auth(d.getVar('SWUPD_CONTENT_BUILD_URL', True))
+version_url = handle_plain_auth(d.getVar('SWUPD_VERSION_BUILD_URL', True))
 current_format = int(d.getVar('SWUPD_FORMAT', True))
 deploy_dir = d.getVar('DEPLOY_DIR_SWUPD', True)
 www_dir = os.path.join(deploy_dir, 'www')
-- 
2.11.0

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

Re: [yocto] [meta-swupd] allow username/password encoded in SWUPD_VERSION_URL and SWUPD_CONTENT_URL

2017-12-20 Thread Patrick Ohly

Hello Ingo!

Sorry for the late reply. There were quite a few things in the patch
that needed further discussion, so I kept postponing dealing with it.
That, and I am not sure due to staffing questions whether I am really
supposed to maintain meta-swupd at the moment :-/

Right now I refrain from applying patches to it until that gets
clarified.

On Sat, 2017-03-25 at 21:14 +0100, Ingo Flaschberger wrote:
> requested patch attached

Instead of attaching patches, please use "git send-email" to send the
patch directly. I needs a proper commit message, too:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Headers_and_Commit_Messages

> From f2526a7ed47b3f3c8f0cb893eadb5e6981255d4c Mon Sep 17 00:00:00
> 2001
> From: ingo 
> Date: Sat, 25 Mar 2017 21:13:33 +0100
> Subject: [PATCH] bundles.py: allow username/password encoded into
> HTTP server
>  URLs example: https://user:password@server/path
> 
> ---
>  lib/swupd/bundles.py | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/lib/swupd/bundles.py b/lib/swupd/bundles.py
> index b4c6f49..223fd3c 100644
> --- a/lib/swupd/bundles.py
> +++ b/lib/swupd/bundles.py
> @@ -4,6 +4,8 @@ import subprocess
>  import shutil
>  import urllib.request
>  import urllib.error
> +import urllib.parse
> +import re
>  from bb.utils import export_proxies
>  from oe.package_manager import RpmPM
>  from oe.package_manager import OpkgPM
> @@ -164,6 +166,15 @@ def download_manifests(content_url, version,
> component, to_dir):
>  base_versions = set()
>  if not os.path.exists(target):
>  bb.debug(1, 'Downloading %s -> %s' % (source, target))
> +parsed_source = urllib.parse.urlsplit(source)
> +if( parsed_source.username != None):
> +new_source = ( parsed_source.scheme, re.sub( re.escape(
> parsed_source.username+':'+parsed_source.password+'@'),
> '',parsed_source.netloc), parsed_source.path, parsed_source.query,
> parsed_source.fragment)

Wouldn't it be simpler to do this?
   parsed_source.netloc = parsed_source.hostname

We want the original URL, just with a simpler netloc part. Mucking
around with a regex to achieve that seems overly complicated when
urllib.parse() has already done the parsing for us.

> +source = urllib.parse.urlunsplit( new_source)
> +manager =
> urllib.request.HTTPPasswordMgrWithDefaultRealm()
> +manager.add_password(None, new_source,
> parsed_source.username, parsed_source.password)
> +authHandler =
> urllib.request.HTTPBasicAuthHandler(manager)
> +opener = urllib.request.build_opener(authHandler)
> +urllib.request.install_opener(opener)

This opener gets installed over and over again, each time some URL
derived from content_url is used. Isn't it enough to check content_url
once and then use a simpler version of it for constructing URLs?

>  response = urllib.request.urlopen(source)
>  archive = response.read()
>  bb.utils.mkdirhier(to_dir)
> @@ -228,6 +239,15 @@ def download_old_versions(d):
>  for format in range(3, current_format + 1):
>  try:
>  url = '%s/version/format%d/latest' % (content_url,
> format)
> +parsed_url = urllib.parse.urlsplit(url)
> +if( parsed_url.username != None):
> +new_url = ( parsed_url.scheme, re.sub( re.escape(
> parsed_url.username+':'+parsed_url.password+'@'),
> '',parsed_url.netloc), parsed_url.path, parsed_url.query,
> parsed_url.fragment)
> +url = urllib.parse.urlunsplit( new_url)
> +manager =
> urllib.request.HTTPPasswordMgrWithDefaultRealm()
> +manager.add_password(None, new_url,
> parsed_url.username, parsed_url.password)
> +authHandler =
> urllib.request.HTTPBasicAuthHandler(manager)
> +opener = urllib.request.build_opener(authHandler)
> +urllib.request.install_opener(opener)

Cut-and-paste... this should be in a helper function.

I tried to come up with a cleaner patch that implements the same
behavior. But I don't have a way to test it. Can you perhaps try out
the patch that I will post as a followup?

Note that it applies cleanly only on top of
https://github.com/pohly/meta-swupd/tree/master

You can also check out the patch from
https://github.com/pohly/meta-swupd/tree/basic_auth

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

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

Re: [yocto] call custom sh script in do_compile

2017-12-20 Thread Burton, Ross

On 20 December 2017 at 12:19, Mircea Gliga  wrote:

>
> Let's put it the other way around. Does anyone know a recipe that uses an
> shell script to build something (which must set the environment correctly
> and call make itself) ?
>

I can't see the difficulty.  Tasks are shell scripts by default, and you've
an external script that needs to be passed arguments to build correctly.
Pass those arguments in your do_compile when running the script.

Almost every recipe contains this pattern at some point. Concrete example:
in autotools.bbclass, do_configure sets a number of environment variables
(eg CC_FOR_BUILD and CACHED_CONFIGUREVARS) and then calls an external shell
script (configure) with arguments set in bitbake variables (such as
EXTRA_OECONF).

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

Re: [yocto] call custom sh script in do_compile

2017-12-20 Thread Mircea Gliga



Let's put it the other way around. Does anyone know a recipe that uses 
an shell script to build something (which must set the environment 
correctly and call make itself) ?


Any hints are appreciated.

Thanks
Mircea

On 20/12/17 11:37, Mircea Gliga wrote:
I'm trying to figure the proper way that the script *should* expect 
parameters...

Some excerpt:

function buildConfiguration {
    CONFIGURATION=${1}
    BINARY_TYPE=${2}
    MACHINE=${3}
    DTB=${4}
    KEY_DIR=${5}
    MAKE_OPTIONS="-j 8 VERBOSE=1 V=1"
    MAKE="make"
    echo ""
    echo "compiling u-boot configuration ${CONFIGURATION} ${DTB} 
version: ${UBOOT_BUILD_VERSION}"


    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC"  clean VERBOSE=1
    ${MAKE} ${MAKE_OPTIONS} VERBOSE=1 HOSTCC="$HOSTCC" 
${CONFIGURATION} VERBOSE=1

    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC"  tools VERBOSE=1
    if [ "${DTB}" != "" ]; then
    compileDts ../arch/arm/dts/at91-${MACHINE} ${KEY_DIR}
    fi

    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC" VERBOSE=1

    mkdir -p ${3}/binaries/
    mv u-boot${DTB}.bin 
${3}/binaries/${MACHINE}-u-boot-${BINARY_TYPE}${DTB}.bin

}


buildConfiguration first_defconfig   "debug"   "first" "-dtb" "prod_keys"
buildConfiguration second_defconfig   "loader"   "first" "-dtb" ""
buildConfiguration [...]
buildConfiguration [...]


On 20/12/17 11:20, Burton, Ross wrote:
On 20 December 2017 at 09:08, Mircea Gliga > wrote:


Hello

I have a build.sh script used to build outside yocto, after
sourcing the build environment.
I want to use the same build.sh script inside the recipe, in the
do_compile task, something like:

do_compile () {

 ./build.sh ${MACHINE}
}

The build.sh script eventually calls make for several targets,
release debug etc...
The idea with this script is to be used both inside yocto and
outside (after sourcing
build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi),
by reusing the code.

What is the proper way to use a custom shell script to build things ?
How to pass info from oe_runmake/EXTRA_OEMAKE ?


This depends on how build.sh expects to be given extra make arguments.

Ross






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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Burton, Ross

On 20 December 2017 at 12:09, Sherif Omran 
wrote:

> this does not solve the issue so far.  It seems a package installed by
> rpi-basic-image does the trick.
>
> what is the difference between :
>
> core-image-minimal
> rpi-basic-image
>

I've never used meta-raspberrypi but you can just look at the image recipes
to find out.

The minimal bit of core-image-minimal isn't a joke, it boots but is missing
*lots* of functionality you might expect.

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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Sherif Omran

this does not solve the issue so far.  It seems a package installed by
rpi-basic-image does the trick.

what is the difference between :

core-image-minimal
rpi-basic-image


On Wed, Dec 20, 2017 at 10:25 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Inside poky distro (.../poky/meta/recipes-connectivity):
>
> [user@localhost recipes-connectivity]$ pwd
> /home/user/YOCTO/oe_core_embedded/poky/meta/recipes-connectivity
> [user@localhost recipes-connectivity]$ ls -al
> total 96
> drwxrwxr-x. 24 user user 4096 Oct 18 12:49 .
> drwxrwxr-x. 19 user user 4096 Nov 18 15:13 ..
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 avahi
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bind
> *drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bluez5*
> drwxrwxr-x.  5 user user 4096 Oct 18 12:49 connman
> drwxrwxr-x.  4 user user 4096 Oct 18 12:49 dhcp
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iproute2
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 irda-utils
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iw
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libnss-mdns
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libpcap
> drwxrwxr-x.  2 user user 4096 Oct 18 12:49 mobile-broadband-provider-info
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 neard
> drwxrwxr-x.  5 user user 4096 Oct 18 12:49 nfs-utils
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ofono
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 openssh
> drwxrwxr-x.  4 user user 4096 Oct 18 12:49 openssl
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp-dialin
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 resolvconf
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 socat
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wireless-tools
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wpa-supplicant
> [user@localhost recipes-connectivity]$
>
> Or:
>
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/
> recipes-connectivity/bluez5/
>
> You should add it in .../conf/local.conf as:
>
> IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).
>
> Zoran
> ___
>
> On Tue, Dec 19, 2017 at 7:03 PM, Sherif Omran 
> wrote:
>
>> how can i add rfkill recipe?
>>
>> On Tue, Dec 19, 2017 at 4:23 PM, Sherif Omran 
>> wrote:
>>
>>> i used core-image-minimal for a raspberry pi 0w. But i get rfkill can
>>> not open control device. when i give rfkill , i get the syntanx output,
>>> this means it exists.
>>> the wifi driver is installed.
>>>
>>> What is the rfkill device? is it /dev/rfkill ?
>>>
>>>
>>
>> --
>> ___
>> 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] rfkill cannot open control device

2017-12-20 Thread Burton, Ross

On 20 December 2017 at 10:30, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > IMAGE_INSTALL_append = " bluez5"
>
> I see.
>
> This should be the another way, should'n it?
>
> CORE_IMAGE_EXTRA_INSTALL += "bluez5"
>

If you're using core-image then that's the preferred way, yes.

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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Zoran Stojsavljevic

> IMAGE_INSTALL_append = " bluez5"

I see.

This should be the another way, should'n it?

CORE_IMAGE_EXTRA_INSTALL += "bluez5"

Thank you,
Zoran

On Wed, Dec 20, 2017 at 11:21 AM, Burton, Ross 
wrote:

> On 20 December 2017 at 10:18, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).
>>
>> My bad! :-(
>>
>> Should read: IMAGE_INSTALL_append += "Bluez5"
>>
>
> Typo in the package name, no need to use += with _append, and missing
> whitespace.  No, that won't work.
>
> IMAGE_INSTALL_append = " bluez5"
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] libgfortran or cross compiling a fortran application

2017-12-20 Thread Matthias Schöpfer

Hi there,

I am trying to cross compile a fortran library (lapack), which fails
because it cannot find libgfortran.

So I am trying to build libgfortran. I added:

FORTRAN_forcevariable = ",fortran"

to enable support for fortran cross compile in local conf. Anyhow,
bitbake libgfortran still fails:

| /bin/sh ./libtool  --tag=CC   --mode=compile x86_64-idp-linux-gcc
-m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
--sysroot=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot
-DHAVE_CONFIG_H -I.
-I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran
 
-iquote../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/io
 
-I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../gcc 
-I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../gcc/config
  
-I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../.././gcc
 
-I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../libgcc
 
-I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../libgcc
 
-I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../libbacktrace
 
-I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../libbacktrace
 -I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings 
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules 
-ffunction-sections -fdata-sections   -std=gnu11  -O2 -pipe -g 
-feliminate-unused-debug-types 
-fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0=/usr/src/debug/libgfortran/7.2.0-r0
 
-fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot-native=
 
-fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot=
  -Wunknown-pragmas -c -o main.lo `test -f 'runtime/main.c' || echo 
'../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/'`runtime/main.c
|
../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/runtime/backtrace.c:36:10:
fatal error: backtrace-supported.h: No such file or directory
|  #include "backtrace-supported.h"
|   ^~~
| compilation terminated.

Any help, hints and wild guesses are welcome.

Regards,

Matthias

-- 
Dr.-Ing. Matthias Schöpfer

Softwareentwicklung



IdentPro GmbH
Camp-Spich-Str. 4
53842 Troisdorf

Tel:   +49 (0)2241 / 866 392 46
Fax:   +49 (0)2241 / 866 392 99
eMail: matthias.schoep...@identpro.de

http://www.identpro.de

identplus® – Das 3D Staplerleitsystem mit enormen Sparpotenzial: z. B.
über 67.000 EUR pro Jahr bei 500 Transporten täglich! Berechnen Sie das
Einsparpotenzial für Ihr Lager mit dem identplus® Potenzialrechner.

identplus® live erleben: Vereinbaren Sie jetzt einen Termin!

-
IdentPro GmbH
Member of Dr. Wack Holding GmbH & Co.KG
Sitz und Registergericht: St. Augustin, HRB 9770 Siegburg
Geschäftsführer: Michael Wack
Umsatzsteuer-ID-Nr.: DE 254 824 945
WEEE-Reg.-Nr. DE 79026890
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Rocko and Circular Dependencies

2017-12-20 Thread Burton, Ross

Nobody else has seen this as far as I'm aware, and the autobuilder doesn't
see it.

Is that a pure oe-core/bitbake or Poky, or do you have custom layers?  Can
you replicate with a stock configuration?

On 20 December 2017 at 03:02, Barry Grussling  wrote:

> Hello all,
>
> I am trying to move one of my builds from Krogoth to Rocko.  I am
> attempting to build
> on 1c61ba0a3f bitbake: tinfoil: Ensure we clean up loggers.
>
> Generally, I can start the first build fine.  Unfortunately, some of
> my code/recipes will usually fail
> to build due to the new compilers.  When I re-run bitbake to continue
> the build, most of
> the time I experience a build failure of circular dependencies such as:
>
> Dependency loop #1 found:
>   Task /srv/BLD/yocto/meta/recipes-core/ncurses/ncurses_6.0+20170715.bb:
> do_package
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'gcc-runtime_7.2.bb:do_packagedata', 'glibc_2.26.bb:do_packagedata',
> 'rpm_git.bb:do_populate_sysroot',
> 'ncurses_6.0+20170715.bb:do_install',
> 'dpkg_1.18.24.bb:do_packagedata',
> 'libtool-cross_2.4.6.bb:do_packagedata'])
>   Task /srv/BLD/yocto/meta/recipes-core/ncurses/ncurses_6.0+20170715.bb:
> do_packagedata
> (dependent Tasks ['ncurses_6.0+20170715.bb:do_package'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_package
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'gcc-runtime_7.2.bb:do_packagedata', 'perl_5.24.1.bb:do_packagedata',
> 'glibc_2.26.bb:do_packagedata', 'rpm_git.bb:do_populate_sysroot',
> 'ncurses_6.0+20170715.bb:do_packagedata',
> 'bzip2_1.0.6.bb:do_packagedata', 'dpkg_1.18.24.bb:do_install',
> 'zlib_1.2.11.bb:do_packagedata',
> 'libtool-cross_2.4.6.bb:do_packagedata',
> 'xz_5.2.3.bb:do_packagedata'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_packagedata
> (dependent Tasks ['dpkg_1.18.24.bb:do_package'])
>
> Dependency loop #2 found:
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_package
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'gcc-runtime_7.2.bb:do_packagedata', 'perl_5.24.1.bb:do_packagedata',
> 'glibc_2.26.bb:do_packagedata', 'rpm_git.bb:do_populate_sysroot',
> 'ncurses_6.0+20170715.bb:do_packagedata',
> 'bzip2_1.0.6.bb:do_packagedata', 'dpkg_1.18.24.bb:do_install',
> 'zlib_1.2.11.bb:do_packagedata',
> 'libtool-cross_2.4.6.bb:do_packagedata',
> 'xz_5.2.3.bb:do_packagedata'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_packagedata
> (dependent Tasks ['dpkg_1.18.24.bb:do_package'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_package
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'gcc-runtime_7.2.bb:do_packagedata', 'glibc_2.26.bb:do_packagedata',
> 'rpm_git.bb:do_populate_sysroot', 'dpkg_1.18.24.bb:do_packagedata',
> 'libtool-cross_2.4.6.bb:do_packagedata', 'bzip2_1.0.6.bb:do_install'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_packagedata
> (dependent Tasks ['bzip2_1.0.6.bb:do_package'])
>
> Dependency loop #3 found:
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_compile
> (dependent Tasks ['dpkg_1.18.24.bb:do_configure'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_install
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'dpkg_1.18.24.bb:do_compile'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_populate_sysroot
> (dependent Tasks ['dpkg_1.18.24.bb:do_install',
> 'binutils-cross_2.29.bb:do_populate_sysroot'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_prepare_recipe_sysroot
> (dependent Tasks ['libtool-cross_2.4.6.bb:do_populate_sysroot',
> 'glibc_2.26.bb:do_populate_sysroot', 'bzip2_1.0.6.bb:do_fetch',
> 'libtool-native_2.4.6.bb:do_populate_sysroot',
> 'dpkg_1.18.24.bb:do_populate_sysroot',
> 'gcc-runtime_7.2.bb:do_populate_sysroot',
> 'gnu-config_git.bb:do_populate_sysroot',
> 'gcc-cross_7.2.bb:do_populate_sysroot',
> 'automake_1.15.1.bb:do_populate_sysroot',
> 'autoconf_2.69.bb:do_populate_sysroot'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_configure
> (dependent Tasks ['bzip2_1.0.6.bb:do_patch',
> 'bzip2_1.0.6.bb:do_prepare_recipe_sysroot'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_compile
> (dependent Tasks ['bzip2_1.0.6.bb:do_configure'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_install
> (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot',
> 'bzip2_1.0.6.bb:do_compile'])
>   Task /srv/BLD/yocto/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:
> do_populate_sysroot
> (dependent Tasks ['binutils-cross_2.29.bb:do_populate_sysroot',
> 'bzip2_1.0.6.bb:do_install'])
>   Task /srv/BLD/yocto/meta/recipes-devtools/dpkg/dpkg_1.18.24.bb:
> do_prepare_recipe_sysroot
> (dependent Tasks ['libtool-cross_2.4.6.bb:do_populate_sysroot',
> 'bzip2_1.0.6.bb:do_populate_sysroot',
> 'glibc_2.26.bb:do_p

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Burton, Ross

On 20 December 2017 at 10:18, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).
>
> My bad! :-(
>
> Should read: IMAGE_INSTALL_append += "Bluez5"
>

Typo in the package name, no need to use += with _append, and missing
whitespace.  No, that won't work.

IMAGE_INSTALL_append = " bluez5"

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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Zoran Stojsavljevic

> IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).

My bad! :-(

Should read: IMAGE_INSTALL_append += "Bluez5"

Zoran

On Wed, Dec 20, 2017 at 10:25 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Inside poky distro (.../poky/meta/recipes-connectivity):
>
> [user@localhost recipes-connectivity]$ pwd
> /home/user/YOCTO/oe_core_embedded/poky/meta/recipes-connectivity
> [user@localhost recipes-connectivity]$ ls -al
> total 96
> drwxrwxr-x. 24 user user 4096 Oct 18 12:49 .
> drwxrwxr-x. 19 user user 4096 Nov 18 15:13 ..
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 avahi
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bind
> *drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bluez5*
> drwxrwxr-x.  5 user user 4096 Oct 18 12:49 connman
> drwxrwxr-x.  4 user user 4096 Oct 18 12:49 dhcp
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iproute2
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 irda-utils
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iw
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libnss-mdns
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libpcap
> drwxrwxr-x.  2 user user 4096 Oct 18 12:49 mobile-broadband-provider-info
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 neard
> drwxrwxr-x.  5 user user 4096 Oct 18 12:49 nfs-utils
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ofono
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 openssh
> drwxrwxr-x.  4 user user 4096 Oct 18 12:49 openssl
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp-dialin
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 resolvconf
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 socat
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wireless-tools
> drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wpa-supplicant
> [user@localhost recipes-connectivity]$
>
> Or:
>
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/
> recipes-connectivity/bluez5/
>
> You should add it in .../conf/local.conf as:
>
> IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).
>
> Zoran
> ___
>
> On Tue, Dec 19, 2017 at 7:03 PM, Sherif Omran 
> wrote:
>
>> how can i add rfkill recipe?
>>
>> On Tue, Dec 19, 2017 at 4:23 PM, Sherif Omran 
>> wrote:
>>
>>> i used core-image-minimal for a raspberry pi 0w. But i get rfkill can
>>> not open control device. when i give rfkill , i get the syntanx output,
>>> this means it exists.
>>> the wifi driver is installed.
>>>
>>> What is the rfkill device? is it /dev/rfkill ?
>>>
>>>
>>
>> --
>> ___
>> 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] call custom sh script in do_compile

2017-12-20 Thread Mircea Gliga

I'm trying to figure the proper way that the script *should* expect 
parameters...

Some excerpt:

function buildConfiguration {
    CONFIGURATION=${1}
    BINARY_TYPE=${2}
    MACHINE=${3}
    DTB=${4}
    KEY_DIR=${5}
    MAKE_OPTIONS="-j 8 VERBOSE=1 V=1"
    MAKE="make"
    echo ""
    echo "compiling u-boot configuration ${CONFIGURATION} ${DTB} 
version: ${UBOOT_BUILD_VERSION}"


    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC"  clean VERBOSE=1
    ${MAKE} ${MAKE_OPTIONS} VERBOSE=1 HOSTCC="$HOSTCC" ${CONFIGURATION} 
VERBOSE=1

    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC"  tools VERBOSE=1
    if [ "${DTB}" != "" ]; then
    compileDts ../arch/arm/dts/at91-${MACHINE} ${KEY_DIR}
    fi

    ${MAKE} ${MAKE_OPTIONS} HOSTCC="$HOSTCC" VERBOSE=1

    mkdir -p ${3}/binaries/
    mv u-boot${DTB}.bin 
${3}/binaries/${MACHINE}-u-boot-${BINARY_TYPE}${DTB}.bin

}


buildConfiguration first_defconfig   "debug"   "first" "-dtb" "prod_keys"
buildConfiguration second_defconfig   "loader"   "first" "-dtb"  ""
buildConfiguration [...]
buildConfiguration [...]


On 20/12/17 11:20, Burton, Ross wrote:
On 20 December 2017 at 09:08, Mircea Gliga > wrote:


Hello

I have a build.sh script used to build outside yocto, after
sourcing the build environment.
I want to use the same build.sh script inside the recipe, in the
do_compile task, something like:

do_compile () {

 ./build.sh ${MACHINE}
}

The build.sh script eventually calls make for several targets,
release debug etc...
The idea with this script is to be used both inside yocto and
outside (after sourcing
build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi),
by reusing the code.

What is the proper way to use a custom shell script to build things ?
How to pass info from oe_runmake/EXTRA_OEMAKE ?


This depends on how build.sh expects to be given extra make arguments.

Ross


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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Zoran Stojsavljevic

Inside poky distro (.../poky/meta/recipes-connectivity):

[user@localhost recipes-connectivity]$ pwd
/home/user/YOCTO/oe_core_embedded/poky/meta/recipes-connectivity
[user@localhost recipes-connectivity]$ ls -al
total 96
drwxrwxr-x. 24 user user 4096 Oct 18 12:49 .
drwxrwxr-x. 19 user user 4096 Nov 18 15:13 ..
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 avahi
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bind
*drwxrwxr-x.  3 user user 4096 Oct 18 12:49 bluez5*
drwxrwxr-x.  5 user user 4096 Oct 18 12:49 connman
drwxrwxr-x.  4 user user 4096 Oct 18 12:49 dhcp
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iproute2
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 irda-utils
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 iw
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libnss-mdns
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 libpcap
drwxrwxr-x.  2 user user 4096 Oct 18 12:49 mobile-broadband-provider-info
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 neard
drwxrwxr-x.  5 user user 4096 Oct 18 12:49 nfs-utils
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ofono
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 openssh
drwxrwxr-x.  4 user user 4096 Oct 18 12:49 openssl
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 ppp-dialin
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 resolvconf
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 socat
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wireless-tools
drwxrwxr-x.  3 user user 4096 Oct 18 12:49 wpa-supplicant
[user@localhost recipes-connectivity]$

Or:

https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-connectivity/bluez5/

You should add it in .../conf/local.conf as:

IMAGE_INSTALL_append += "rfkill" (my best guess, easiest way).

Zoran
___

On Tue, Dec 19, 2017 at 7:03 PM, Sherif Omran 
wrote:

> how can i add rfkill recipe?
>
> On Tue, Dec 19, 2017 at 4:23 PM, Sherif Omran 
> wrote:
>
>> i used core-image-minimal for a raspberry pi 0w. But i get rfkill can not
>> open control device. when i give rfkill , i get the syntanx output, this
>> means it exists.
>> the wifi driver is installed.
>>
>> What is the rfkill device? is it /dev/rfkill ?
>>
>>
>
> --
> ___
> 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] call custom sh script in do_compile

2017-12-20 Thread Burton, Ross

On 20 December 2017 at 09:08, Mircea Gliga  wrote:

> Hello
>
> I have a build.sh script used to build outside yocto, after sourcing the
> build environment.
> I want to use the same build.sh script inside the recipe, in the
> do_compile task, something like:
>
> do_compile () {
>
>  ./build.sh ${MACHINE}
> }
>
> The build.sh script eventually calls make for several targets, release
> debug etc...
> The idea with this script is to be used both inside yocto and outside
> (after sourcing
> build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi), by
> reusing the code.
>
> What is the proper way to use a custom shell script to build things ?
> How to pass info from oe_runmake/EXTRA_OEMAKE ?
>

This depends on how build.sh expects to be given extra make arguments.

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

[yocto] call custom sh script in do_compile

2017-12-20 Thread Mircea Gliga


Hello

I have a build.sh script used to build outside yocto, after sourcing the 
build environment.
I want to use the same build.sh script inside the recipe, in the 
do_compile task, something like:


do_compile () {

 ./build.sh ${MACHINE}
}

The build.sh script eventually calls make for several targets, release 
debug etc...
The idea with this script is to be used both inside yocto and outside 
(after sourcing
build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi), by 
reusing the code.


What is the proper way to use a custom shell script to build things ?
How to pass info from oe_runmake/EXTRA_OEMAKE ?

Thanks
Mircea

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

Re: [yocto] rfkill cannot open control device

2017-12-20 Thread Sherif Omran

i have it now installed as a kernel module
but still i get can not open rfkill control device at boot time


On Wed, Dec 20, 2017 at 5:28 AM, Sherif Omran 
wrote:

> Bluez5 is already added to local.conf. It gets installed, if i instal
> rpi-basic-image
> with no changes to local.conf, if i use core-image-minimal
> Bluez5 gets installed but not rfkill ..
>
> On Tue, Dec 19, 2017 at 7:16 PM, Ayoub Zaki 
> wrote:
>
>>
>>
>> On 19.12.2017 19:03, Sherif Omran wrote:
>>
>>> how can i add rfkill recipe?
>>>
>>> On Tue, Dec 19, 2017 at 4:23 PM, Sherif Omran >> > wrote:
>>>
>>> i used core-image-minimal for a raspberry pi 0w. But i get rfkill
>>> can not open control device. when i give rfkill , i get the
>>> syntanx output, this means it exists.
>>> the wifi driver is installed.
>>>
>>> What is the rfkill device? is it /dev/rfkill ?
>>>
>>>
>> rfkill is part of Bluez5, you can add it to your image recipe.
>>
>>
>>>
>>>
>>>
>>>
>> --
>> Ayoub Zaki
>> Embedded Systems Consultant
>>
>> Vaihinger Straße 2/1
>> D-71634 Ludwigsburg
>>
>> Email: ayoub.z...@embexus.com
>> Homepage : https://embexus.com
>> VAT No.  : DE313902634
>>
>> --
>> ___
>> 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] QA cycle report for 2.3.3 RC1

Re: [yocto] Rocko and Circular Dependencies

[yocto] add kernel modules & dtbo's for Raspberry Pi3

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

Re: [yocto] Some trivial question about git update-ref refs/heads/rocko ...

[yocto] Trying to make PylonGPS build with DEPENDS, does not find includes

[yocto] Some trivial question about git update-ref refs/heads/rocko ...

[yocto] Trying to make PylonGPS build with DEPENDS, does not find includes

[yocto] issue with clang-native when building with bitbake

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

Re: [yocto] [meta-swupd] allow username/password encoded in SWUPD_VERSION_URL and SWUPD_CONTENT_URL

Re: [yocto] call custom sh script in do_compile

Re: [yocto] call custom sh script in do_compile

Re: [yocto] rfkill cannot open control device

Re: [yocto] rfkill cannot open control device

Re: [yocto] rfkill cannot open control device

Re: [yocto] rfkill cannot open control device

[yocto] libgfortran or cross compiling a fortran application

Re: [yocto] Rocko and Circular Dependencies

Re: [yocto] rfkill cannot open control device

Re: [yocto] rfkill cannot open control device

Re: [yocto] call custom sh script in do_compile

Re: [yocto] rfkill cannot open control device

Re: [yocto] call custom sh script in do_compile

[yocto] call custom sh script in do_compile

Re: [yocto] rfkill cannot open control device

26 matches

Site Navigation

Mail list logo

Footer information