[yocto] [meta-gplv2][PATCH] gmp_4.2.1: prevent calls to mpn_add_nc() if HAVE_NATIVE_mpn_sub_nc is false

[Andre McCurdy]

When building for aarch64 (ie relying only on generic C code rather
than asm) libgmp.so contains undefined references to __gmpn_add_nc
and __gmpn_sub_nc which causes attempts to link with -lgmp to fail:

 | .../usr/lib/libgmp.so: undefined reference to `__gmpn_sub_nc'
 | .../usr/lib/libgmp.so: undefined reference to `__gmpn_add_nc'

Solution based on a historical patch posted to the gmp mailing list:

  https://gmplib.org/list-archives/gmp-discuss/2006-May/002344.html

Signed-off-by: Andre McCurdy 
---
 ...ls-to-mpn_add_nc-if-HAVE_NATIVE_mpn_sub_n.patch | 78 ++
 recipes-support/gmp/gmp_4.2.1.bb   |  1 +
 2 files changed, 79 insertions(+)
 create mode 100644 
recipes-support/gmp/gmp-4.2.1/prevent-calls-to-mpn_add_nc-if-HAVE_NATIVE_mpn_sub_n.patch

diff --git 
a/recipes-support/gmp/gmp-4.2.1/prevent-calls-to-mpn_add_nc-if-HAVE_NATIVE_mpn_sub_n.patch
 
b/recipes-support/gmp/gmp-4.2.1/prevent-calls-to-mpn_add_nc-if-HAVE_NATIVE_mpn_sub_n.patch
new file mode 100644
index 000..7b879c3
--- /dev/null
+++ 
b/recipes-support/gmp/gmp-4.2.1/prevent-calls-to-mpn_add_nc-if-HAVE_NATIVE_mpn_sub_n.patch
@@ -0,0 +1,78 @@
+From d4f3542fabe0797cf2d60afd957585862bd9a29b Mon Sep 17 00:00:00 2001
+From: Andre McCurdy 
+Date: Fri, 25 Aug 2017 16:16:06 -0700
+Subject: [PATCH] prevent calls to mpn_add_nc() if HAVE_NATIVE_mpn_sub_nc is 
false
+
+When building for aarch64 (ie relying only on generic C code rather
+than asm) libgmp.so contains undefined references to __gmpn_add_nc
+and __gmpn_sub_nc which causes attempts to link with -lgmp to fail:
+
+ | .../usr/lib/libgmp.so: undefined reference to `__gmpn_sub_nc'
+ | .../usr/lib/libgmp.so: undefined reference to `__gmpn_add_nc'
+
+Solution based on a historical patch posted to the gmp mailing list:
+
+  https://gmplib.org/list-archives/gmp-discuss/2006-May/002344.html
+
+Upstream-Status: Inappropriate [Fixed in current versions]
+
+Signed-off-by: Andre McCurdy 
+---
+ mpn/generic/addsub_n.c | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/mpn/generic/addsub_n.c b/mpn/generic/addsub_n.c
+index 27b2c08..0ff7ca0 100644
+--- a/mpn/generic/addsub_n.c
 b/mpn/generic/addsub_n.c
+@@ -58,13 +58,13 @@ mpn_addsub_n (mp_ptr r1p, mp_ptr r2p, mp_srcptr s1p, 
mp_srcptr s2p, mp_size_t n)
+   for (off = 0; off < n; off += PART_SIZE)
+   {
+ this_n = MIN (n - off, PART_SIZE);
+-#if HAVE_NATIVE_mpn_add_nc || !HAVE_NATIVE_mpn_add_n
++#if HAVE_NATIVE_mpn_add_nc
+ acyo = mpn_add_nc (r1p + off, s1p + off, s2p + off, this_n, acyo);
+ #else
+ acyn = mpn_add_n (r1p + off, s1p + off, s2p + off, this_n);
+ acyo = acyn + mpn_add_1 (r1p + off, r1p + off, this_n, acyo);
+ #endif
+-#if HAVE_NATIVE_mpn_sub_nc || !HAVE_NATIVE_mpn_sub_n
++#if HAVE_NATIVE_mpn_sub_nc
+ scyo = mpn_sub_nc (r2p + off, s1p + off, s2p + off, this_n, scyo);
+ #else
+ scyn = mpn_sub_n (r2p + off, s1p + off, s2p + off, this_n);
+@@ -81,13 +81,13 @@ mpn_addsub_n (mp_ptr r1p, mp_ptr r2p, mp_srcptr s1p, 
mp_srcptr s2p, mp_size_t n)
+   for (off = 0; off < n; off += PART_SIZE)
+   {
+ this_n = MIN (n - off, PART_SIZE);
+-#if HAVE_NATIVE_mpn_sub_nc || !HAVE_NATIVE_mpn_sub_n
++#if HAVE_NATIVE_mpn_sub_nc
+ scyo = mpn_sub_nc (r2p + off, s1p + off, s2p + off, this_n, scyo);
+ #else
+ scyn = mpn_sub_n (r2p + off, s1p + off, s2p + off, this_n);
+ scyo = scyn + mpn_sub_1 (r2p + off, r2p + off, this_n, scyo);
+ #endif
+-#if HAVE_NATIVE_mpn_add_nc || !HAVE_NATIVE_mpn_add_n
++#if HAVE_NATIVE_mpn_add_nc
+ acyo = mpn_add_nc (r1p + off, s1p + off, s2p + off, this_n, acyo);
+ #else
+ acyn = mpn_add_n (r1p + off, s1p + off, s2p + off, this_n);
+@@ -105,13 +105,13 @@ mpn_addsub_n (mp_ptr r1p, mp_ptr r2p, mp_srcptr s1p, 
mp_srcptr s2p, mp_size_t n)
+   for (off = 0; off < n; off += PART_SIZE)
+   {
+ this_n = MIN (n - off, PART_SIZE);
+-#if HAVE_NATIVE_mpn_add_nc || !HAVE_NATIVE_mpn_add_n
++#if HAVE_NATIVE_mpn_add_nc
+ acyo = mpn_add_nc (tp, s1p + off, s2p + off, this_n, acyo);
+ #else
+ acyn = mpn_add_n (tp, s1p + off, s2p + off, this_n);
+ acyo = acyn + mpn_add_1 (tp, tp, this_n, acyo);
+ #endif
+-#if HAVE_NATIVE_mpn_sub_nc || !HAVE_NATIVE_mpn_sub_n
++#if HAVE_NATIVE_mpn_sub_nc
+ scyo = mpn_sub_nc (r2p + off, s1p + off, s2p + off, this_n, scyo);
+ #else
+ scyn = mpn_sub_n (r2p + off, s1p + off, s2p + off, this_n);
+-- 
+1.9.1
+
diff --git a/recipes-support/gmp/gmp_4.2.1.bb b/recipes-support/gmp/gmp_4.2.1.bb
index 5e8ee29..029e728 100644
--- a/recipes-support/gmp/gmp_4.2.1.bb
+++ b/recipes-support/gmp/gmp_4.2.1.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"https://gmplib.org/download/${BPN}/archive/${BP}.tar.bz2 \
file://Use-__gnu_inline__-attribute.patch \
file://gmp_fix_for_automake-1.12.patch \

Re: [yocto] Problems building U-Boot for x86_64

[Ferry Toth]

Op Fri, 25 Aug 2017 21:22:40 +0200, schreef Ferry Toth:

> Khem Raj wrote:
> 
> 
>> 
>> 
>> On 8/23/17 3:40 PM, Ferry Toth wrote:
>>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:
>>> 
 On 8/23/17 2:29 PM, Ferry Toth wrote:
> Ferry Toth wrote:
>
>> Khem Raj wrote:
>>
>>> On 8/22/17 11:41 PM, Ferry Toth wrote:
 I am having trouble building a specific U-Boot version with
 Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it
 builds fine.

 I am extending meta-intel-edison to build a 64 bit Poke Morty,
 with a vanilla 64-bit kernel (4.12). This is working quite well.

 My host is x86_64, the target is core2 with tune=core-64.

 Without 64bit tune I can build U-Boot fine. With 64bit it can not
 link, appearently because it needs lbgcc.a
>>>
>>> what is exact error message ? is it while compiling host bits or
>>> target bits ?
>>
>> The failing line is:
>> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m
>> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3
>> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic
>> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds
>> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o
>> arch/x86/lib/built-in.o board/intel/edison/built-in.o
>> cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o
>> drivers/dma/built-in.o drivers/gpio/built-in.o
>> drivers/i2c/built-in.o drivers/mmc/built-in.o
>> drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o
>> drivers/mtd/spi/built- in.o drivers/net/built-in.o
>> drivers/net/phy/built-in.o drivers/pci/built- in.o
>> drivers/power/built-in.o drivers/power/battery/built-in.o
>> drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o
>> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o
>> drivers/power/regulator/built-in.o drivers/serial/built-in.o
>> drivers/spi/built-in.o drivers/usb/common/built-in.o
>> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o
>> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o
>> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o
>> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o
>> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o
>> dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o
>> test/built-in.o test/dm/built-in.o --end-group arch/x86/lib/lib.a
>> -Map u-boot.map ERROR: oe_runmake failed arch/x86/lib/built-in.o:
>> In function `__wrap___udivdi3':
>> /home/ferry/tmp/edison-intel/my/edison-
>> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
>>> v2017.03-
>> r0/git/arch/x86/lib/gcc.c:25: undefined reference to
>> `__normal___udivdi3'
>
> I as believe the missing lib is libgcc.a I just my sysroot and found
> it here:

 the linker cmdline above does not link with libgcc and there might be
 a good reason for that, many standalone applications dont link with
 libgcc intentionally. You could look into the code and see if it can
 be written differently such that gcc does not have to invoke a helper
 function from gcc runtime. Another option is to link with libgcc
 explicitly
>>> 
>>> If change my setup to build for a 32bit target, it build u-boot
>>> without error.
>> 
>> compiler may not be generating calls for the missing function.
>> 
>>> When I build the same git outside yocto on 64bit with multilib
>>> installed it also builds without error. In that case the make command
>>> would be: make -j8 edison_defconfig
>> 
>> same is possible. Can you do readelf -sW gcc.o and see if there is a
>> undefined reference to __normal___udivdi3
> 
>20: 22 FUNCGLOBAL HIDDEN 4 __wrap___divdi3 21:
> 0 NOTYPE  GLOBAL DEFAULT  UND __normal___divdi3 22:
>22 FUNCGLOBAL HIDDEN 6 __wrap___udivdi3 23:
> 0 NOTYPE  GLOBAL DEFAULT  UND __normal___udivdi3 24:
>22 FUNCGLOBAL HIDDEN 8 __wrap___moddi3 25:
> 0 NOTYPE  GLOBAL DEFAULT  UND __normal___moddi3 26:
>22 FUNCGLOBAL HIDDEN10 __wrap___umoddi3 27:
> 0 NOTYPE  GLOBAL DEFAULT  UND __normal___umoddi3

AFAIKT when building for a 32-bit target is only that U-Boot makefile is 
called with CROSS_COMPILE=i686-poky-linux- CC=i686-poky-linux-gcc instead 
of CROSS_COMPILE=x86_64-poky-linux- CC=x86_64-poky-linux-gcc.

Result from readelf -sW gcc.o built wuth i686:

20: 27 FUNCGLOBAL HIDDEN 4 __wrap___divdi3
21:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___divdi3
22: 27 FUNCGLOBAL HIDDEN 6 __wrap___udivdi3
23:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___udivdi3
24: 27 FUNCGLOBAL HIDDEN 8 __wrap___moddi3
25: 

Re: [yocto] [meta-raspberrypi][PATCH] bluez5: add functions for raspberrypi0-wifi

[Yusuke Mitsuki]

okay. I will try.

2017-08-25 17:51 GMT+09:00 Paul Barker :

> On Thu, Aug 24, 2017 at 1:05 PM, Yusuke Mitsuki
>  wrote:
> > hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not
> found.
> >
> > Paches that in order to use bluetooth with BCM43430 are not enabled.
> > Functions are only enabled with raspberrypi3 in bluez5_%.bbappend like
> as follows:
> >
> > - SRC_URI_append_raspberrypi3
> > - do_install_append_raspberrypi3()
> > - FILES_${PN}_append_raspberrypi3
> > - SYSTEMD_SERVICE_${PN}_append_raspberrypi3
> >
> > These should be enabled with raspberrypi0-wifi too.
> >
> > Signed-off-by: Yusuke Mitsuki 
> > ---
> >  recipes-connectivity/bluez5/bluez5_%.bbappend | 25
> +
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend
> b/recipes-connectivity/bluez5/bluez5_%.bbappend
> > index 956d776..075dc2b 100644
> > --- a/recipes-connectivity/bluez5/bluez5_%.bbappend
> > +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend
> > @@ -24,3 +24,28 @@ FILES_${PN}_append_raspberrypi3 = " \
> >  "
> >
> >  SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service"
> > +
> > +SRC_URI_append_raspberrypi0-wifi = " \
> > +file://BCM43430A1.hcd \
> > +file://0001-bcm43xx-Add-bcm43xx-3wire-variant.patch \
> > +file://0002-bcm43xx-The-UART-speed-must-be-reset-after-the-firmw.patch
> \
> > +file://0003-Increase-firmware-load-timeout-to-30s.patch \
> > +file://0004-Move-the-43xx-firmware-into-lib-firmware.patch \
> > +file://brcm43438.service \
> > +"
> > +
> > +do_install_append_raspberrypi0-wifi() {
> > +install -d ${D}/lib/firmware/brcm/
> > +install -m 0644 ${WORKDIR}/BCM43430A1.hcd ${D}/lib/firmware/brcm/
> BCM43430A1.hcd
> > +
> > +if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true',
> 'false', d)}; then
> > +install -d ${D}${systemd_unitdir}/system
> > +install -m 0644 ${WORKDIR}/brcm43438.service
> ${D}${systemd_unitdir}/system
> > +fi
> > +}
> > +
> > +FILES_${PN}_append_raspberrypi0-wifi = " \
> > +/lib/firmware/brcm/BCM43430A1.hcd \
> > +"
> > +
> > +SYSTEMD_SERVICE_${PN}_append_raspberrypi0-wifi = " brcm43438.service"
>
> I don't like the amount of duplication here. Could you define some
> common variables and use those in the appends? This will make it
> easier to change/upgrade in the future and avoid risk of the
> duplicates falling out of sync with each other.
>
> Eg.
>
> RPI_WIFI_SOURCES = ""
>
> SRC_URI_append_raspberrypi3 = "${RPI_WIFI_SOURCES}"
> SRC_URI_append_raspberrypi0-wifi = "${RPI_WIFI_SOURCES}"
>
> --
> Paul Barker
> Togán Labs Ltd
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH v2] docker : update dockerfile to start celery worker

[Diana Thayer]

Related to bug 11197
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=11197)
this WIP patch updates the Dockerfile to start a Celery worker
alongside the Gunicorn daemon. These changes allow the Docker
image to leverage the asynchronous task execution framework
established in a prior patch.

I don't have the best grasp of Docker but the image appears
to serve up a functioning layerindex.

Signed-off-by: Diana Thayer 
---
 Dockerfile  | 10 --
 README  | 10 +-
 TODO|  1 -
 layerindex/tasks.py | 24 
 layerindex/views.py |  5 ++---
 requirements.txt|  1 +
 settings.py |  4 
 7 files changed, 48 insertions(+), 7 deletions(-)
 create mode 100644 layerindex/tasks.py

diff --git a/Dockerfile b/Dockerfile
index 1f63e2a..9bb251e 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -13,11 +13,13 @@ RUN apt-get install -y --no-install-recommends \
python-mysqldb \
python-dev \
python-imaging \
-netcat-openbsd \
-vim \
+   rabbitmq-server \
+   netcat-openbsd \
+   vim \
&& rm -rf /var/lib/apt/lists/*
 RUN pip install --upgrade pip
 RUN pip install gunicorn
+RUN pip install setuptools
 CMD mkdir /opt/workdir
 ADD . /opt/layerindex
 RUN pip install -r /opt/layerindex/requirements.txt
@@ -31,4 +33,8 @@ ADD docker/migrate.sh /opt/migrate.sh
 ## do so, you will also have to edit .gitconfig appropriately
 #ADD docker/git-proxy /opt/bin/git-proxy
 
+# Start Gunicorn
 CMD ["/usr/local/bin/gunicorn", "wsgi:application", "--workers=4", 
"--bind=:5000", "--log-level=debug", "--chdir=/opt/layerindex"]
+
+# Start Celery
+CMD ["/usr/local/bin/celery", "-A", "layerindex.tasks", "worker", 
"--loglevel=info", "--workdir=/opt/layerindex"]
diff --git a/README b/README
index 62f739d..c7f7409 100644
--- a/README
+++ b/README
@@ -14,6 +14,7 @@ In order to make use of this application you will need:
 * Python 3.4+
 * Django 1.8.x - tested with 1.8.17; newer versions may work, but
   the application has not been tested with 1.9 or newer.
+* RabbitMQ 3.6.x - tested with 3.6.10.
 * For production usage, a web server set up to host Django applications
   (not needed for local-only testing)
 * A database supported by Django (SQLite, MySQL, etc.). Django takes
@@ -41,7 +42,9 @@ Setup instructions:
 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and
other settings specific to your installation. Ensure you set
LAYER_FETCH_DIR to an absolute path to a location with sufficient
-   space for fetching layer repositories.
+   space for fetching layer repositories. Modify RABBIT_BROKER
+   and RABBIT_BACKEND to reflect the settings used by your RabbitMQ
+   server.
 
 2. Run the following commands within the layerindex-web directory to
initialise the database:
@@ -64,6 +67,11 @@ Setup instructions:
production you need to use a proper web server and have DEBUG set
to False.
 
+   3.1. In order to process asynchronous tasks like sending email,
+you will need to run a Celery worker:
+
+celery -A layerindex.tasks worker --loglevel=info
+
 4. You'll need to add at least the openembedded-core layer to the
database, or some equivalent that contains conf/bitbake.conf for
the base system configuration. To add this, follow these steps:
diff --git a/TODO b/TODO
index 186219f..29986ac 100644
--- a/TODO
+++ b/TODO
@@ -27,7 +27,6 @@ Other
 * Show layer type in layer detail?
 * Usage links in list page?
 * Subdirs in list page?
-* Prevent SMTP failures from breaking submission process
 * Query backend service i.e. special URL to query information for external 
apps/scripts
 * Add comparison to duplicates page
 * Create simple script to check for unlisted layer subdirectories in all repos
diff --git a/layerindex/tasks.py b/layerindex/tasks.py
new file mode 100644
index 000..de80804
--- /dev/null
+++ b/layerindex/tasks.py
@@ -0,0 +1,24 @@
+from celery import Celery
+from django.core.mail import EmailMessage
+from . import utils
+import os
+import time
+
+try:
+import settings
+except ImportError:
+# not in a full django env, so settings is inaccessible.
+# setup django to access settings.
+utils.setup_django()
+import settings
+
+tasks = Celery('layerindex',
+broker=settings.RABBIT_BROKER,
+backend=settings.RABBIT_BACKEND)
+
+@tasks.task
+def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, 
to_emails=[]):
+# We seem to need to run this within the task
+utils.setup_django()
+msg = EmailMessage(subject, text_content, from_email, to_emails)
+msg.send()
diff --git a/layerindex/views.py b/layerindex/views.py
index 1661cb3..bcf6671 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -19,7 +19,6 @@ from layerindex.forms import EditLayerForm, 
LayerMaintainerFormSet, EditNoteForm
 from django.db import transaction
 from django.contrib.auth.models import User, Permission
 from 

Re: [yocto] Problems building U-Boot for x86_64

[Ferry Toth]

Khem Raj wrote:

> 
> 
> 
> On 8/23/17 3:40 PM, Ferry Toth wrote:
>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:
>> 
>>> On 8/23/17 2:29 PM, Ferry Toth wrote:
 Ferry Toth wrote:

> Khem Raj wrote:
>
>> On 8/22/17 11:41 PM, Ferry Toth wrote:
>>> I am having trouble building a specific U-Boot version with Yocto.
>>> Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it builds
>>> fine.
>>>
>>> I am extending meta-intel-edison to build a 64 bit Poke Morty, with
>>> a vanilla 64-bit kernel (4.12). This is working quite well.
>>>
>>> My host is x86_64, the target is core2 with tune=core-64.
>>>
>>> Without 64bit tune I can build U-Boot fine. With 64bit it can not
>>> link, appearently because it needs lbgcc.a
>>
>> what is exact error message ? is it while compiling host bits or
>> target bits ?
>
> The failing line is:
> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m elf_i386
> --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 --wrap=__moddi3
> --wrap=__umoddi3 -- gc-sections -pie -Bstatic --no-dynamic-linker
> -Ttext 0x01101000 -o u-boot -T u-boot.lds arch/x86/cpu/start.o
> --start-group arch/x86/cpu/built-in.o arch/x86/lib/built-in.o
> board/intel/edison/built-in.o cmd/built-in.o common/built-in.o
> disk/built-in.o drivers/built-in.o drivers/dma/built-in.o
> drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/mmc/built-in.o
> drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o
> drivers/mtd/spi/built- in.o drivers/net/built-in.o
> drivers/net/phy/built-in.o drivers/pci/built- in.o
> drivers/power/built-in.o drivers/power/battery/built-in.o
> drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o
> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o
> drivers/power/regulator/built-in.o drivers/serial/built-in.o
> drivers/spi/built-in.o drivers/usb/common/built-in.o
> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o
> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o
> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o
> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o
> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o dts/built-in.o
> fs/built-in.o lib/built-in.o net/built-in.o test/built-in.o
> test/dm/built-in.o --end-group arch/x86/lib/lib.a -Map u-boot.map
> ERROR: oe_runmake failed arch/x86/lib/built-in.o: In function
> `__wrap___udivdi3':
> /home/ferry/tmp/edison-intel/my/edison-
> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
>> v2017.03-
> r0/git/arch/x86/lib/gcc.c:25: undefined reference to
> `__normal___udivdi3'

 I as believe the missing lib is libgcc.a I just my sysroot and found it
 here:
>>>
>>> the linker cmdline above does not link with libgcc and there might be a
>>> good reason for that, many standalone applications dont link with libgcc
>>> intentionally. You could look into the code and see if it can be written
>>> differently such that gcc does not have to invoke a helper function from
>>> gcc runtime. Another option is to link with libgcc explicitly
>> 
>> If change my setup to build for a 32bit target, it build u-boot without
>> error.
> 
> compiler may not be generating calls for the missing function.
> 
>> When I build the same git outside yocto on 64bit with multilib installed
>> it also builds without error. In that case the make command would be:
>> make -j8 edison_defconfig
> 
> same is possible. Can you do readelf -sW gcc.o and see if there is a
> undefined reference to __normal___udivdi3

   20: 22 FUNCGLOBAL HIDDEN 4 __wrap___divdi3  
   21:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___divdi3
   22: 22 FUNCGLOBAL HIDDEN 6 __wrap___udivdi3
   23:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___udivdi3
   24: 22 FUNCGLOBAL HIDDEN 8 __wrap___moddi3
   25:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___moddi3
   26: 22 FUNCGLOBAL HIDDEN10 __wrap___umoddi3
   27:  0 NOTYPE  GLOBAL DEFAULT  UND __normal___umoddi3
 
>> 
>> My conclusion: I have some bb variable set to the wrong value or I need
>> to get multilib installed into //sysroots/x86_64-linux/lib.
>> 
>> So how to do that?
>> 
 sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
 sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32-linux/6.2.0/
 sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/
 sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/

 How compile log shows:
 NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
 CC=x86_64-poky-linux-gcc --sysroot=//sysroots/edison V=1 HOSTCC=gcc
 -isystem//sysroots/x86_64-linux/usr/include -O2 -pipe
 -L//sysroots/x86_64-linux/usr/lib -L//sysroots/x86_64-linux/lib

[yocto] [layerindex-web][PATCH] docker : update dockerfile to start celery worker

[Diana Thayer]

Related to bug 11195
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=11195)
this WIP patch updates the Dockerfile to start a Celery worker
alongside the Gunicorn daemon. These changes allow the Docker
image to leverage the asynchronous task execution framework
established in a prior patch.

I don't have the best grasp of Docker but the image appears
to serve up a functioning layerindex.

Signed-off-by: Diana Thayer 
---
 Dockerfile  | 18 --
 README  | 10 +-
 TODO|  1 -
 layerindex/tasks.py | 24 
 layerindex/views.py |  7 +++
 requirements.txt|  1 +
 settings.py |  4 
 7 files changed, 53 insertions(+), 12 deletions(-)
 create mode 100644 layerindex/tasks.py

diff --git a/Dockerfile b/Dockerfile
index 1f63e2a..2a7771d 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -9,15 +9,17 @@ ENV PYTHONUNBUFFERED 1
 
 RUN apt-get update
 RUN apt-get install -y --no-install-recommends \
-   python-pip \
-   python-mysqldb \
-   python-dev \
-   python-imaging \
-netcat-openbsd \
-vim \
+  python-dev \
+  python-imaging \
+  python-mysqldb \
+  python-pip \
+  netcat-openbsd \
+  rabbitmq-server \
+  vim \
&& rm -rf /var/lib/apt/lists/*
 RUN pip install --upgrade pip
 RUN pip install gunicorn
+RUN pip install setuptools
 CMD mkdir /opt/workdir
 ADD . /opt/layerindex
 RUN pip install -r /opt/layerindex/requirements.txt
@@ -31,4 +33,8 @@ ADD docker/migrate.sh /opt/migrate.sh
 ## do so, you will also have to edit .gitconfig appropriately
 #ADD docker/git-proxy /opt/bin/git-proxy
 
+# Start the Gunicorn workers
 CMD ["/usr/local/bin/gunicorn", "wsgi:application", "--workers=4", 
"--bind=:5000", "--log-level=debug", "--chdir=/opt/layerindex"]
+
+# Start the Celery worker
+CMD ["/usr/local/bin/celery", "-A", "layerindex.tasks", "worker", 
"--loglevel=info", "--workdir=/opt/layerindex"]
diff --git a/README b/README
index 62f739d..c7f7409 100644
--- a/README
+++ b/README
@@ -14,6 +14,7 @@ In order to make use of this application you will need:
 * Python 3.4+
 * Django 1.8.x - tested with 1.8.17; newer versions may work, but
   the application has not been tested with 1.9 or newer.
+* RabbitMQ 3.6.x - tested with 3.6.10.
 * For production usage, a web server set up to host Django applications
   (not needed for local-only testing)
 * A database supported by Django (SQLite, MySQL, etc.). Django takes
@@ -41,7 +42,9 @@ Setup instructions:
 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and
other settings specific to your installation. Ensure you set
LAYER_FETCH_DIR to an absolute path to a location with sufficient
-   space for fetching layer repositories.
+   space for fetching layer repositories. Modify RABBIT_BROKER
+   and RABBIT_BACKEND to reflect the settings used by your RabbitMQ
+   server.
 
 2. Run the following commands within the layerindex-web directory to
initialise the database:
@@ -64,6 +67,11 @@ Setup instructions:
production you need to use a proper web server and have DEBUG set
to False.
 
+   3.1. In order to process asynchronous tasks like sending email,
+you will need to run a Celery worker:
+
+celery -A layerindex.tasks worker --loglevel=info
+
 4. You'll need to add at least the openembedded-core layer to the
database, or some equivalent that contains conf/bitbake.conf for
the base system configuration. To add this, follow these steps:
diff --git a/TODO b/TODO
index 186219f..29986ac 100644
--- a/TODO
+++ b/TODO
@@ -27,7 +27,6 @@ Other
 * Show layer type in layer detail?
 * Usage links in list page?
 * Subdirs in list page?
-* Prevent SMTP failures from breaking submission process
 * Query backend service i.e. special URL to query information for external 
apps/scripts
 * Add comparison to duplicates page
 * Create simple script to check for unlisted layer subdirectories in all repos
diff --git a/layerindex/tasks.py b/layerindex/tasks.py
new file mode 100644
index 000..de80804
--- /dev/null
+++ b/layerindex/tasks.py
@@ -0,0 +1,24 @@
+from celery import Celery
+from django.core.mail import EmailMessage
+from . import utils
+import os
+import time
+
+try:
+import settings
+except ImportError:
+# not in a full django env, so settings is inaccessible.
+# setup django to access settings.
+utils.setup_django()
+import settings
+
+tasks = Celery('layerindex',
+broker=settings.RABBIT_BROKER,
+backend=settings.RABBIT_BACKEND)
+
+@tasks.task
+def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, 
to_emails=[]):
+# We seem to need to run this within the task
+utils.setup_django()
+msg = EmailMessage(subject, text_content, from_email, to_emails)
+msg.send()
diff --git a/layerindex/views.py b/layerindex/views.py
index 1661cb3..8eac866 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -19,7 +19,6 @@ from layerindex.forms 

Re: [yocto] raspberrypi3-64 target not booting

[Khem Raj]

On Fri, Aug 25, 2017 at 10:14 AM, Bill Jenkins  wrote:
>
> On Aug 25, 2017, at 9:42 AM, Khem Raj  wrote:
>
>
> On Fri, Aug 25, 2017 at 9:39 AM Bill Jenkins  wrote:
>>
>> I am trying to just get the simple 64-bit rpi-basic-image to work, but the
>> Raspberry Pi 3 seems to hang with the rainbow screen at startup.
>
>
> Can you plugin a serial cable and see if that worked or try to add ssh
> daemon on target and try to ssh into pi
>>
>>
>
> That was a good call. I can login with the ssh daemon, so it does
> successfully boot. I just
> cannot access it from the HDMI port. (I do not have the hardware for a
> serial connection
> at the moment)
>
> Any ideas on how to get the HDMI port to function the same way as it does
> for the
> 32-bit case?
>

Readding the mailing list.

what you have is exactly what I had when I submitted the port to
meta-raspberrypi. Haven;t had a chance to revisit it. but this could
be related to device tree files we are using here. I have had reports
from other devs of having been able to boot into graphics using older
kernels but I never got
that far myself.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] raspberrypi3-64 target not booting

[Khem Raj]

On Fri, Aug 25, 2017 at 9:39 AM Bill Jenkins  wrote:

> I am trying to just get the simple 64-bit rpi-basic-image to work, but the
> Raspberry Pi 3 seems to hang with the rainbow screen at startup.
>

Can you plugin a serial cable and see if that worked or try to add ssh
daemon on target and try to ssh into pi

>
> If I build with MACHINE ?= raspberrypi3, the 32-bit image works just fine.
>
> Is there something special that needs to be set in order for the
> "MACHINE ?= raspberrypi3-64" image to boot successfully?
>
> Thanks,
> Bill
> --
> ___
> 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] raspberrypi3-64 target not booting

[Bill Jenkins]

I am trying to just get the simple 64-bit rpi-basic-image to work, but the
Raspberry Pi 3 seems to hang with the rainbow screen at startup.

If I build with MACHINE ?= raspberrypi3, the 32-bit image works just fine.

Is there something special that needs to be set in order for the
"MACHINE ?= raspberrypi3-64" image to boot successfully? 

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

Re: [yocto] Pyro's uninative and libstdc++ symbols

[Chris Z.]

Hi,

You could try to build your own uninative:

bitbake uninative-tarball

and use your own uninative:

update: poky/meta/conf/distro/include/yocto-uninative.inc

Or stop using uninative.
But I'm also curios why native built with newer gcc is not using glibc
from uninative (older glibc than gcc 7 uses)

Br,
Chris Z


On Fri, Aug 25, 2017 at 2:50 PM, Raphael Kubo da Costa
 wrote:
> I've recently updated my host system to Fedora 26, which has GCC 7.
>
> This seems to be causing some issues on Pyro, where I have a -native
> recipe that is built with my system's g++ and ends up generating a
> binary with the following symbol:
>
>   DF *UND*    GLIBCXX_3.4.23 
> std::basic_string >::basic_string(std::string const&, unsigned long, std::allocator 
> const&)
>
> GLIBCXX_3.4.23 is not part of Pyro's uninative's libstdc++, so when that
> binary is invoked in another (non-native) recipe as part of do_configure
> it fails to run:
>
> gn: 
> /data/src/yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
>  version `GLIBCXX_3.4.23' not found (required by gn)
>
> Is there anything I should be doing differently here?
> --
> ___
> 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] [meta-qt4][PATCH RESEND][pyro] qt4-native: depend on icu-native to fix build on systems with icu <=58

[Alexander Kanavin]

On 08/25/2017 04:17 PM, Ioan-Adrian Ratiu wrote:

From: Cody P Schafer 

Previously, qt4-native would use the system icu to build.

Trying to build against a system ICU 59, however, fails with this root
error:

| In file included from /usr/include/unicode/uversion.h:30:0,
|  from tools/qlocale_icu.cpp:46:
| /usr/include/unicode/umachine.h:347:13: error: ‘char16_t’ does not name a 
type; did you mean ‘wchar_t’?
|  typedef char16_t UChar;
|  ^~~~
|  wchar_t

May have to do with our use of `-std=gnu98++`.


You should also send a patch to fix the same problem in meta-qt4 master, 
by disabling icu altogether (as oe-core master already has icu 59). 
Please see the previous discussion around this patch.



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

[yocto] [meta-qt4][PATCH RESEND][pyro] qt4-native: depend on icu-native to fix build on systems with icu <=58

[Ioan-Adrian Ratiu]

From: Cody P Schafer 

Previously, qt4-native would use the system icu to build.

Trying to build against a system ICU 59, however, fails with this root
error:

| In file included from /usr/include/unicode/uversion.h:30:0,
|  from tools/qlocale_icu.cpp:46:
| /usr/include/unicode/umachine.h:347:13: error: ‘char16_t’ does not name a 
type; did you mean ‘wchar_t’?
|  typedef char16_t UChar;
|  ^~~~
|  wchar_t

May have to do with our use of `-std=gnu98++`.

Signed-off-by: Cody P Schafer 
Signed-off-by: Ioan-Adrian Ratiu 
---
 recipes-qt4/qt4/qt4-native.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4-native.inc b/recipes-qt4/qt4/qt4-native.inc
index 5a873de..a14a647 100644
--- a/recipes-qt4/qt4/qt4-native.inc
+++ b/recipes-qt4/qt4/qt4-native.inc
@@ -1,5 +1,5 @@
 SUMMARY = "Qt version 4 tools and support files for the build host"
-DEPENDS = "zlib-native dbus-native"
+DEPENDS = "zlib-native dbus-native icu-native"
 SECTION = "libs"
 HOMEPAGE = "http://qt-project.org/;
 PROVIDES = "qt4-tools-native"
-- 
2.14.1

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

[linux-yocto] [kernel-cache][PATCH 4/4] intel-common: disable ixgbe modules

[Mikko Ylinen]

meta-intel (intel-* MACHINEs) plans to use the backported
ixgbe ethernet modules so disable building them in the base kernel
config.

To build the in-kernel drivers, features/ixgbe/ixgbe.scc must be
added in KERNEL_FEATURES.

Signed-off-by: Mikko Ylinen 
---
 bsp/intel-common/intel-common-drivers.scc | 1 -
 bsp/mohonpeak/mohonpeak.scc   | 1 -
 bsp/mohonpeak/mohonpeak32.scc | 1 -
 bsp/romley/romley.scc | 1 -
 features/dca/dca.cfg  | 1 -
 features/ixgbe/ixgbe.cfg  | 1 +
 features/ixgbe/ixgbe.scc  | 2 ++
 7 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index af1758af..20481e05 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -37,7 +37,6 @@ include features/intel-e1/intel-e100.scc
 include features/intel-e1/intel-e1.scc
 include features/ericsson-3g/f5521gw.scc
 include features/igb/igb.scc
-include features/ixgbe/ixgbe.scc
 include features/i40e/i40e.scc
 
 # Various RF/Wireless technologies
diff --git a/bsp/mohonpeak/mohonpeak.scc b/bsp/mohonpeak/mohonpeak.scc
index f0634de4..25f6f071 100644
--- a/bsp/mohonpeak/mohonpeak.scc
+++ b/bsp/mohonpeak/mohonpeak.scc
@@ -4,7 +4,6 @@ include cfg/x86_64.scc
 include cfg/8250.scc
 
 include features/power/intel.scc
-include features/ixgbe/ixgbe.scc
 include features/igb/igb.scc
 
 include features/usb/ehci-hcd.scc
diff --git a/bsp/mohonpeak/mohonpeak32.scc b/bsp/mohonpeak/mohonpeak32.scc
index b6a94adb..3b5d1a40 100644
--- a/bsp/mohonpeak/mohonpeak32.scc
+++ b/bsp/mohonpeak/mohonpeak32.scc
@@ -5,7 +5,6 @@ include cfg/x86.scc
 include cfg/8250.scc
 
 include features/power/intel.scc
-include features/ixgbe/ixgbe.scc
 include features/igb/igb.scc
 
 # required for Intel DPDK Support
diff --git a/bsp/romley/romley.scc b/bsp/romley/romley.scc
index 20ffb887..9a61bd43 100644
--- a/bsp/romley/romley.scc
+++ b/bsp/romley/romley.scc
@@ -5,7 +5,6 @@ include cfg/8250.scc
 include cfg/x86_64.scc
 include features/uio/uio.scc
 include features/hugetlb/hugetlb.scc
-include features/ixgbe/ixgbe.scc
 include features/igb/igb.scc
 
 # generic power management
diff --git a/features/dca/dca.cfg b/features/dca/dca.cfg
index 9061e4f7..3090212d 100644
--- a/features/dca/dca.cfg
+++ b/features/dca/dca.cfg
@@ -2,4 +2,3 @@ CONFIG_INTEL_IOATDMA=m
 CONFIG_DCA=m
 
 CONFIG_IGB_DCA=y
-CONFIG_IXGBE_DCA=y
diff --git a/features/ixgbe/ixgbe.cfg b/features/ixgbe/ixgbe.cfg
index 31d8b1d5..c7abf3b9 100644
--- a/features/ixgbe/ixgbe.cfg
+++ b/features/ixgbe/ixgbe.cfg
@@ -1,5 +1,6 @@
 CONFIG_IXGBE=m
 
 CONFIG_DCB=y
+CONFIG_IXGBE_DCA=y
 CONFIG_IXGBE_DCB=y
 CONFIG_IXGBEVF=m
diff --git a/features/ixgbe/ixgbe.scc b/features/ixgbe/ixgbe.scc
index 671a1587..d22aa5c7 100644
--- a/features/ixgbe/ixgbe.scc
+++ b/features/ixgbe/ixgbe.scc
@@ -1 +1,3 @@
 kconf hardware ixgbe.cfg
+
+include features/dca/dca.scc
-- 
2.14.1

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

[linux-yocto] [kernel-cache][PATCH 1/4] skylake/audio: enable CONFIG_CRC8 to build soundwire driver

[Mikko Ylinen]

The skylake audio driver enables CONFIG_SDW which in turn does not
correcly select/enable its dependencies so the build fails if
CONFIG_CRC8 is not explicitly enabled.

The build failure triggers when disabling common-pc-wifi.cfg.

Signed-off-by: Mikko Ylinen 
---
 features/soc/skylake/skylake.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/features/soc/skylake/skylake.cfg b/features/soc/skylake/skylake.cfg
index 954c9f89..ab11c8cb 100644
--- a/features/soc/skylake/skylake.cfg
+++ b/features/soc/skylake/skylake.cfg
@@ -17,6 +17,7 @@ CONFIG_SND_SOC_INTEL_SKL_RT286_MACH=m
 CONFIG_SND_SOC_INTEL_SST=m
 CONFIG_SND_SOC_INTEL_SST_ACPI=m
 CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_CRC8=m
 
 # Additional IO support
 CONFIG_BT_HCIUART=m
-- 
2.14.1

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

[linux-yocto] [kernel-cache][PATCH 2/4] ktypes/standard: enable CONFIG_CRYPTO_CCM and GCM

[Mikko Ylinen]

In order to build backport-iwlwifi driver (meta-intel has
the recipe) that ships its own MAC80211 and to use the crypto
drivers from the targeted kernel for it, CONFIG_CRYPTO_CCM must
be enabled.

backport-iwlwifi does have a compat implementation of crypto-ccm.c too
that would be used if CONFIG_CRYPTO_CCM is not set but that currently
fails to build (implicit function declaration).

Therefore, just enable CRYPTO_CCM. And while we're at it, enable
all crypto drivers that are needed by MAC80211.

Signed-off-by: Mikko Ylinen 
---
 ktypes/standard/standard.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ktypes/standard/standard.cfg b/ktypes/standard/standard.cfg
index c99ab8a8..06d1be11 100644
--- a/ktypes/standard/standard.cfg
+++ b/ktypes/standard/standard.cfg
@@ -1096,6 +1096,8 @@ CONFIG_CRYPTO_DEFLATE=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_CRC32C=m
 CONFIG_CRYPTO_TEST=m
+CONFIG_CRYPTO_CCM=m
+CONFIG_CRYPTO_GCM=m
 
 #
 # Layered filesystem encryption
-- 
2.14.1

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

[linux-yocto] [kernel-cache][PATCH 3/4] intel-common: disable iwlwifi and softmac modules

[Mikko Ylinen]

The default virtual/kernel for intel-common uses the backported
iwlwifi driver and softmac so disable building them in the
base kernel config.

This disables all mac80211/cfg80211 and their dependencies. If
the in-kernel drivers are needed, iwlwifi.scc must be added in
KERNEL_FEATURES.

Signed-off-by: Mikko Ylinen 
---
 bsp/intel-common/intel-common-drivers.scc | 3 ---
 features/soc/skylake/skylake.scc  | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index dace0d35..af1758af 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -10,7 +10,6 @@ include intel-common.scc
 kconf hardware bsp/common-pc/common-pc-drivers.cfg
 kconf hardware bsp/common-pc/common-pc-eth.cfg
 kconf hardware bsp/common-pc/common-pc-gfx.cfg
-kconf hardware bsp/common-pc/common-pc-wifi.cfg
 
 # OSS sound support
 include cfg/sound.scc
@@ -39,8 +38,6 @@ include features/intel-e1/intel-e1.scc
 include features/ericsson-3g/f5521gw.scc
 include features/igb/igb.scc
 include features/ixgbe/ixgbe.scc
-include features/iwlwifi/iwlwifi.scc
-include features/iwlegacy/iwlegacy.scc
 include features/i40e/i40e.scc
 
 # Various RF/Wireless technologies
diff --git a/features/soc/skylake/skylake.scc b/features/soc/skylake/skylake.scc
index 49619019..c8fc1c03 100644
--- a/features/soc/skylake/skylake.scc
+++ b/features/soc/skylake/skylake.scc
@@ -6,9 +6,6 @@
 # Enable I2C Support
 include features/i2c/i2c.scc
 
-# Enable mac 80211 + WLAN support
-include features/mac80211/mac80211.scc
-
 # Enable Skylake/Broxton LPSS support
 include features/mfd/mfd-intel-lpss.scc
 
-- 
2.14.1

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

[linux-yocto] [kernel-cache][PATCH 0/4] intel-common: networking configuration changes

[Mikko Ylinen]

meta-intel recently added a recipe to build an out-of-tree
iwlwifi driver. Additionally, there are plans to do the same for
ixgbe too.

Those changes triggered a conversation on how it should be done.
See '[meta-intel] [PATCH V2 2/3] linux-intel: remove ixgbe and ixgbevf'
for details.

Patches 1 and 2 fix some inconsistencies in the dependencies and
and be merged.

Patches 3 and 4 would need an OK from Saul first.

All patches are valid for yocto-4.9+ and 3 also for 4.4.

Mikko Ylinen (4):
  skylake/audio: enable CONFIG_CRC8 to build soundwire driver
  ktypes/standard: enable CONFIG_CRYPTO_CCM and GCM
  intel-common: disable iwlwifi and softmac modules
  intel-common: disable ixgbe modules

 bsp/intel-common/intel-common-drivers.scc | 4 
 bsp/mohonpeak/mohonpeak.scc   | 1 -
 bsp/mohonpeak/mohonpeak32.scc | 1 -
 bsp/romley/romley.scc | 1 -
 features/dca/dca.cfg  | 1 -
 features/ixgbe/ixgbe.cfg  | 1 +
 features/ixgbe/ixgbe.scc  | 2 ++
 features/soc/skylake/skylake.cfg  | 1 +
 features/soc/skylake/skylake.scc  | 3 ---
 ktypes/standard/standard.cfg  | 2 ++
 10 files changed, 6 insertions(+), 11 deletions(-)

-- 
2.14.1

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

[yocto] Pyro's uninative and libstdc++ symbols

[Raphael Kubo da Costa]

I've recently updated my host system to Fedora 26, which has GCC 7.

This seems to be causing some issues on Pyro, where I have a -native
recipe that is built with my system's g++ and ends up generating a
binary with the following symbol:

  DF *UND*    GLIBCXX_3.4.23 
std::basic_string::basic_string(std::string const&, unsigned long, std::allocator const&)

GLIBCXX_3.4.23 is not part of Pyro's uninative's libstdc++, so when that
binary is invoked in another (non-native) recipe as part of do_configure
it fails to run:

gn: 
/data/src/yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
 version `GLIBCXX_3.4.23' not found (required by gn)

Is there anything I should be doing differently here?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ERROR: Unable to connect to bitbake server, or start one

[Gera Pesikoff]

I figured out that the new function findTopdir (Submitted on July 18, 2017) does
not handle the errors of the absence of the BBPATH variable and path to the
conf/bblayers.conf in BBATH. It just returns None.

 On Thu, 2017-08-24 at 18:24 +0300, Gera Pesikoff wrote:
 > Hi
 > I started to study bitbake and decided to repeat the BitBake Hello
 > World from the manual
 > 
(http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#bitbake-hello-world).
 > I do everything according to the instructions, but when I run the
 > bitbake command, I get the following output:
 >
 > NOTE: Retrying server connection... (Traceback (most recent call
 > last):
 > File "/home/leonid/test/bitbake/lib/bb/main.py", line 432, in
 > setup_bitbake
 > topdir, lock = lockBitbake()
 > File "/home/leonid/test/bitbake/lib/bb/main.py", line 484, in
 > lockBitbake
 > lockfile = topdir + "/bitbake.lock"
 > TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
 > )
 >
 > This is repeated five times, and at the end:
 >
 > ERROR: Unable to connect to bitbake server, or start one

 Are you running bitbake from the build folder (TOPDIR)?
 >
 > Could someone please tell me what the problem is and what I can do
 > about it?
 > I'm using Kubuntu 17.04 and clear Ubuntu 17.04. BitBake Build Tool
 > Core version 1.35.0
 >
 > --
 > ___
 > 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] [meta-raspberrypi][PATCH] bluez5: add functions for raspberrypi0-wifi

[Paul Barker]

On Thu, Aug 24, 2017 at 1:05 PM, Yusuke Mitsuki
 wrote:
> hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not found.
>
> Paches that in order to use bluetooth with BCM43430 are not enabled.
> Functions are only enabled with raspberrypi3 in bluez5_%.bbappend like as 
> follows:
>
> - SRC_URI_append_raspberrypi3
> - do_install_append_raspberrypi3()
> - FILES_${PN}_append_raspberrypi3
> - SYSTEMD_SERVICE_${PN}_append_raspberrypi3
>
> These should be enabled with raspberrypi0-wifi too.
>
> Signed-off-by: Yusuke Mitsuki 
> ---
>  recipes-connectivity/bluez5/bluez5_%.bbappend | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend 
> b/recipes-connectivity/bluez5/bluez5_%.bbappend
> index 956d776..075dc2b 100644
> --- a/recipes-connectivity/bluez5/bluez5_%.bbappend
> +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend
> @@ -24,3 +24,28 @@ FILES_${PN}_append_raspberrypi3 = " \
>  "
>
>  SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service"
> +
> +SRC_URI_append_raspberrypi0-wifi = " \
> +file://BCM43430A1.hcd \
> +file://0001-bcm43xx-Add-bcm43xx-3wire-variant.patch \
> +file://0002-bcm43xx-The-UART-speed-must-be-reset-after-the-firmw.patch \
> +file://0003-Increase-firmware-load-timeout-to-30s.patch \
> +file://0004-Move-the-43xx-firmware-into-lib-firmware.patch \
> +file://brcm43438.service \
> +"
> +
> +do_install_append_raspberrypi0-wifi() {
> +install -d ${D}/lib/firmware/brcm/
> +install -m 0644 ${WORKDIR}/BCM43430A1.hcd 
> ${D}/lib/firmware/brcm/BCM43430A1.hcd
> +
> +if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
> d)}; then
> +install -d ${D}${systemd_unitdir}/system
> +install -m 0644 ${WORKDIR}/brcm43438.service 
> ${D}${systemd_unitdir}/system
> +fi
> +}
> +
> +FILES_${PN}_append_raspberrypi0-wifi = " \
> +/lib/firmware/brcm/BCM43430A1.hcd \
> +"
> +
> +SYSTEMD_SERVICE_${PN}_append_raspberrypi0-wifi = " brcm43438.service"

I don't like the amount of duplication here. Could you define some
common variables and use those in the appends? This will make it
easier to change/upgrade in the future and avoid risk of the
duplicates falling out of sync with each other.

Eg.

RPI_WIFI_SOURCES = ""

SRC_URI_append_raspberrypi3 = "${RPI_WIFI_SOURCES}"
SRC_URI_append_raspberrypi0-wifi = "${RPI_WIFI_SOURCES}"

-- 
Paul Barker
Togán Labs Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems building U-Boot for x86_64

[Ferry Toth]

Op Thu, 24 Aug 2017 21:34:56 +, schreef Ferry Toth:

> Op Thu, 24 Aug 2017 16:35:05 +, schreef Ferry Toth:
> 
>> Op Thu, 24 Aug 2017 17:48:55 +0200, schreef Stefano Babic:
>> 
>>> Hi Ferry,
>>> 
>>> On 24/08/2017 15:09, Ferry Toth wrote:
 Op Thu, 24 Aug 2017 12:40:57 +0200, schreef Stefano Babic:
 
> Hi Ferry,
>
> On 24/08/2017 08:51, Ferry Toth wrote:
>> Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj:
>>
>>> On 8/23/17 3:40 PM, Ferry Toth wrote:
 Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:

> On 8/23/17 2:29 PM, Ferry Toth wrote:
>> Ferry Toth wrote:
>>
>>> Khem Raj wrote:
>>>
 On 8/22/17 11:41 PM, Ferry Toth wrote:
> I am having trouble building a specific U-Boot version with
> Yocto.
> Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it
> builds fine.
>
> I am extending meta-intel-edison to build a 64 bit Poke
> Morty,
> with a vanilla 64-bit kernel (4.12). This is working quite
> well.
>
> My host is x86_64, the target is core2 with tune=core-64.
>
> Without 64bit tune I can build U-Boot fine. With 64bit it
> can not link, appearently because it needs lbgcc.a

 what is exact error message ? is it while compiling host bits
 or target bits ?
>>>
>>> The failing line is:
>>> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m
>>> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3
>>> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic
>>> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds
>>> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o
>>> arch/x86/lib/built-in.o board/intel/edison/built-in.o
>>> cmd/built-in.o common/built-in.o disk/built-in.o
>>> drivers/built-in.o drivers/dma/built-in.o
>>> drivers/gpio/built-in.o drivers/i2c/built-in.o
>>> drivers/mmc/built-in.o drivers/mtd/built-in.o
>>> drivers/mtd/onenand/built-in.o drivers/mtd/spi/built- in.o
>>> drivers/net/built-in.o drivers/net/phy/built-in.o
>>> drivers/pci/built-
>>> in.o drivers/power/built-in.o drivers/power/battery/built-in.o
>>> drivers/power/domain/built-in.o
>>> drivers/power/fuel_gauge/built-in.o
>>> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o
>>> drivers/power/regulator/built-in.o drivers/serial/built-in.o
>>> drivers/spi/built-in.o drivers/usb/common/built-in.o
>>> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o
>>> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o
>>> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o
>>> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o
>>> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o
>>> dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o
>>> test/built-in.o test/dm/built-in.o --end-group
>>> arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake failed
>>> arch/x86/lib/built-in.o: In function `__wrap___udivdi3':
>>> /home/ferry/tmp/edison-intel/my/edison-
>>> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/
>> edison-
 v2017.03-
>>> r0/git/arch/x86/lib/gcc.c:25: undefined reference to
>>> `__normal___udivdi3'
>>
>> I as believe the missing lib is libgcc.a I just my sysroot and
>> found it here:
>
> the linker cmdline above does not link with libgcc and there
> might be a good reason for that, many standalone applications
> dont link with libgcc intentionally. You could look into the
> code and see if it can be written differently such that gcc does
> not have to invoke a helper function from gcc runtime. Another
> option is to link with libgcc explicitly

 If change my setup to build for a 32bit target, it build u-boot
 without error.
>>>
>>> compiler may not be generating calls for the missing function.
>>
>> That would be a bug then? Regardless if I set tune=core-64 or not
>> the resulting U-Boot should be the same.
>>
 When I build the same git outside yocto on 64bit with multilib
 installed it also builds without error. In that case the make
 command would be: make -j8 edison_defconfig
>>>
>>> same is possible. Can you do readelf -sW gcc.o and see if there is
>>> a undefined reference to __normal___udivdi3
>>>
>> I will do that tonight.
>>
 My conclusion: I have some bb variable set to the wrong value or
 I need to get multilib installed into
 

Re: [yocto] Yocto plug-in not running cmake

[Tim Orling]

My _guess_ is that Cmake is not installed on the host? or you do not have the 
SDK populated?

Please look at 
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Cmake,Eclipse,_and_SDKS
and let us know if that helps.

> On Aug 24, 2017, at 4:46 PM, Paul D. DeRocco  wrote:
> 
> Yocto 2.2.1, standard SDK for RPi, Yocto plug-in for Eclipse Mars
> 
> I do File -> New -> C Project, give it a name, select Project Type ->
> Yocto Project SDK CMake Project -> Hello World C CMake Project, click
> Finish, and it creates a project. I click the build button, and it runs
> "make all" and complains "make: *** No rule to make target 'all'. Stop."
> 
> Why is it running make and not cmake? It's hard to imagine that I made a
> mistake somewhere in those two steps.
> 
> -- 
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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