[yocto] [layerindex-web][PATCH] views : add check for superusers in layer update notifications

[Diana Thayer]

When a user submits a layer, notification emails are sent to users
with a certain permission. Superusers technically have all
permissions, but Q ignores them currently so that such emails
are not sent to superusers. This patch expands the check to
include superusers.

A few folks have discussed including this so I put this patch
up for consideration.
---
 layerindex/views.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/layerindex/views.py b/layerindex/views.py
index 1661cb3..c1a624c 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, 
branch='master', slug=None):
 # Send email
 plaintext = get_template('layerindex/submitemail.txt')
 perm = Permission.objects.get(codename='publish_layer')
-users = User.objects.filter(Q(groups__permissions=perm) | 
Q(user_permissions=perm) ).distinct()
+users = User.objects.filter(Q(groups__permissions=perm) | 
Q(user_permissions=perm) | Q(is_superuser=True) ).distinct()
 for user in users:
 if user.first_name:
 user_name = user.first_name
-- 
2.7.4

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

[yocto] [layerindex-web][PATCH v4] Asynchronous email notifications, task execution

[Diana Thayer]

This patch adds asynchronous task execution using a Celery backend
and RabbitMQ task queue, so that the layer submission process to
proceed even in the event that sending the notification email fails,
and establishing an asynchronous execution mechanism that we can use
in the future e.g. for triggering parse operations from the web UI.
This pertains to bug 11195:

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

It updates the README to reflect the installation and configuration
of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task
definitions, updates the 'edit_layer_view' function to send
emails to administrators about new and updated layers asynchronously,
and modifies the 'settings.py' to include a default configuration
for a RabbitMQ connection.

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

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 django.db.models import Q, Count, Sum
-from django.core.mail import EmailMessage
 from django.template.loader import get_template
 from django.template import Context
 from django.utils.decorators import method_decorator
@@ -28,6 +27,7 @@ from django.contrib import messages
 from reversion.models import Revision
 from . import utils
 from . import simplesearch
+from . import tasks
 import settings
 from django.dispatch import receiver
 import reversion
@@ -181,8 +181,7 @@ def edit_layer_view(request, template_name, 
branch='master', slug=None):
 from_email = settings.SUBMIT_EMAIL_FROM
 to_email = user.email
 

Re: [yocto] RDEPENDS dependency problem

[Khem Raj]

On Thu, Aug 24, 2017 at 1:41 AM, Stefano Pagnottelli
 wrote:
> First of all, thanks for your reply.
>
> Il giorno mer 23 ago 2017 alle ore 20:56 Khem Raj  ha
> scritto:
>>
>> On 8/23/17 1:12 AM, Stefano Pagnottelli wrote:
>> > Hi to all,
>> >
>> > I'm trying to build this layer:
>> > (https://github.com/bachp/meta-homeassistant) using the yocto pyro on a
>> > raspberry pi 3 target and the opkg package system.
>> >
>> > Inside the recipe
>> >
>> > (https://github.com/bachp/meta-homeassistant/blob/master/recipes-homeassistant/homeassistant/python3-homeassistant_0.51.2.bb)
>> > there  are some RDEPENDS with strict equal
>> > dependencies (ex:python3-aiohttp (= 2.2.5)).
>> >
>> > We I build the image with the opgk package system the system fail in the
>> > do_rootfs task because is not finding the package python3-aiohttp =
>> > 2.2.5.. If I understood correctly this happens because the build system
>> > si appending the recipe revision (PR variable) at end of package name
>> > and the results is  python3-aiohttp_2.2.5-r0 and not
>> > python3-aiohttp_2.2.5 as opkg is expecting.
>>
>> I dont think r0 is in play here. You can test it by changing dependency
>> check to look for  (= for 2.2.5-r0), I think it should still fail.
>
>
> I do some tests of on rdendps on the recipe:
>
> With python3-aiohttp (= 2.2.5-r0) the image is built without problems, with
> python3-aiohttp (>= 2.2.5) the image is built without problems, with
> python3-aiohttp (= 2.2.5) the task fail with the following error:
>
> Problem 1/1:
>   - nothing provides python3-aiohttp = 2.2.5 needed by
> python3-homeassistant-0.51.2-r0.cortexa7hf-neon-vfpv4
>
> So it seems to me that know the recipe revision is mandatory if you want to
> put a strict dependency on a rdpends. But if I understood correctly the
> yocto build system it's not possible to predict the recipe revision because
> is automatically computed,  And a change in the recipe will break the
> dependency also if the source software version is the same because this will
> change the recipe version.

Yeah ok PV as well as PR both are considered.

>
>>
>>
>> >
>> > As workaround I changed all strict = with a >= and the build complete
>> > without errors.
>>
>> this is ok as long as the package can work with newer versions of this
>> package. I am not sure if thats the case, you might have to check with
>> authors intent for using = instead of >=
>
>
> I think that ,in that case the author is using strict = dependencies because
> we are trying to compile a python project that strictly depend python module
> with a specific version.  Can be useful to have strict = dependency in a
> recipe but it is not mandatory, the project compile well also with >=.
>
> Regards
> Stefano
>
>>
>>
>> >
>> > My question is: It's possible to  instruct the build system to ignore
>> > the recipe revision when it match the version of the package? Or in
>> > alternative it's possible to automatically detect the recipe revision of
>> > the package?
>> >
>> > Thanks in advance
>> > Stefano
>> > …
>> > --
>> >
>> > There are 10 types of people in this world, those who understand binary
>> > and those who dont
>> >
>> >
>>
> --
>
> There are 10 types of people in this world, those who understand binary and
> those who dont
>
>
> --
> ___
> 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] [layerindex-web][PATCH v3] Asynchronous email notifications, task execution

[Diana Thayer]

This patch adds asynchronous task execution using a Celery backend
and RabbitMQ task queue, so that the layer submission process to
proceed even in the event that sending the notification email fails,
and establishing an asynchronous execution mechanism that we can use
in the future e.g. for triggering parse operations from the web UI.

It updates the README to reflect the installation and configuration
of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task
definitions, updates the 'edit_layer_view' function to send
emails to administrators about new and updated layers asynchronously,
and modifies the 'settings.py' to include a default configuration
for a RabbitMQ connection.

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

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..c582505 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 django.db.models import Q, Count, Sum
-from django.core.mail import EmailMessage
 from django.template.loader import get_template
 from django.template import Context
 from django.utils.decorators import method_decorator
@@ -28,6 +27,7 @@ from django.contrib import messages
 from reversion.models import Revision
 from . import utils
 from . import simplesearch
+from . import tasks
 import settings
 from django.dispatch import receiver
 import reversion
@@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, 
branch='master', slug=None):
 # Send email
 plaintext = get_template('layerindex/submitemail.txt')
 perm = Permission.objects.get(codename='publish_layer')
-

Re: [yocto] Python module and build_ext args

[Khem Raj]

On Thu, Aug 24, 2017 at 9:42 PM, Craig McQueen
 wrote:
> Khem Raj wrote:
>
>
>
> On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen 
> wrote:
>
> I wrote:
>> I'm trying to make a recipe for python3-uvloop, using setuptools3.
>>
>> The Python 3 uvloop module depends on libuv. It bundles a version of
>> libuv,
>> and setup.py tries to build it, but it doesn't work well for
>> cross-compilation.
>> However, it also provides a build_ext parameter "--use-system-libuv",
>> which
>> seems to work when I try running it manually in devshell. (I have made a
>> suitable recipe for libuv and added libuv to DEPENDS.)
>>
>> How can I specify the "--use-system-libuv" parameter for build_ext in the
>> python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS,
>> but it doesn't seem to be functional.
>
>
> I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch:
> https://patchwork.openembedded.org/patch/66071/
>
> However, in the Yocto poky repository, I see commit
> 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken
> version of the above patch with the separate build_ext step not actually
> executed with the DISTUTILS_BUILD_EXT_ARGS parameters.
>
>
>
> You did not explain broken in which sense ?
>
>
>
> It is broken in the sense that: The separate build_ext step is not actually
> executed with the DISTUTILS_BUILD_EXT_ARGS parameters. The original patch
> submission contained:
>
>
>
>   STAGING_INCDIR=${STAGING_INCDIR} \
>
>   STAGING_LIBDIR=${STAGING_LIBDIR} \
>
>   BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
>
> - ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
> build ${DISTUTILS_BUILD_ARGS} || \
>
> + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
> \
>
> + build_ext --include-dirs
> ${STAGING_INCDIR}/${PYTHON_DIR}${PYTHON_ABI} \
>
> + --library-dirs ${STAGING_LIBCDIR}/${PYTHON_DIR} \
>
> + ${DISTUTILS_BUILD_EXT_ARGS} \
>
> + build ${DISTUTILS_BUILD_ARGS} || \
>
> + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
> build_ext ${DISTUTILS_BUILD_ARGS} || \
>
>   bbfatal "${PYTHON_PN} setup.py build_ext execution failed."
>
> }
>
>
>
> However that part of the patch is not present in commit
> 0221af0f4ee9e8bfb8796841bdf806e38bc600c6.
>

IIRC there were some breakages with this but it was long time ago. Can
you appy this change and test it out ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python module and build_ext args

[Craig McQueen]

Khem Raj wrote:

On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen 
> wrote:
I wrote:
> I'm trying to make a recipe for python3-uvloop, using setuptools3.
>
> The Python 3 uvloop module depends on libuv. It bundles a version of libuv,
> and setup.py tries to build it, but it doesn't work well for 
> cross-compilation.
> However, it also provides a build_ext parameter "--use-system-libuv", which
> seems to work when I try running it manually in devshell. (I have made a
> suitable recipe for libuv and added libuv to DEPENDS.)
>
> How can I specify the "--use-system-libuv" parameter for build_ext in the
> python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS,
> but it doesn't seem to be functional.


I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch:
https://patchwork.openembedded.org/patch/66071/

However, in the Yocto poky repository, I see commit 
0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken version 
of the above patch with the separate build_ext step not actually executed with 
the DISTUTILS_BUILD_EXT_ARGS parameters.

You did not explain broken in which sense ?

It is broken in the sense that: The separate build_ext step is not actually 
executed with the DISTUTILS_BUILD_EXT_ARGS parameters. The original patch 
submission contained:

  STAGING_INCDIR=${STAGING_INCDIR} \
  STAGING_LIBDIR=${STAGING_LIBDIR} \
  BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
- ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
build ${DISTUTILS_BUILD_ARGS} || \
+ ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
+ build_ext --include-dirs ${STAGING_INCDIR}/${PYTHON_DIR}${PYTHON_ABI} 
\
+ --library-dirs ${STAGING_LIBCDIR}/${PYTHON_DIR} \
+ ${DISTUTILS_BUILD_EXT_ARGS} \
+ build ${DISTUTILS_BUILD_ARGS} || \
+ ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
build_ext ${DISTUTILS_BUILD_ARGS} || \
  bbfatal "${PYTHON_PN} setup.py build_ext execution failed."
}

However that part of the patch is not present in commit 
0221af0f4ee9e8bfb8796841bdf806e38bc600c6.

--
Craig McQueen

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

Re: [yocto] Python module and build_ext args

[Khem Raj]

On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen 
wrote:

> I wrote:
> > I'm trying to make a recipe for python3-uvloop, using setuptools3.
> >
> > The Python 3 uvloop module depends on libuv. It bundles a version of
> libuv,
> > and setup.py tries to build it, but it doesn't work well for
> cross-compilation.
> > However, it also provides a build_ext parameter "--use-system-libuv",
> which
> > seems to work when I try running it manually in devshell. (I have made a
> > suitable recipe for libuv and added libuv to DEPENDS.)
> >
> > How can I specify the "--use-system-libuv" parameter for build_ext in the
> > python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS,
> > but it doesn't seem to be functional.
>
>
> I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch:
> https://patchwork.openembedded.org/patch/66071/
>
> However, in the Yocto poky repository, I see commit
> 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken
> version of the above patch with the separate build_ext step not actually
> executed with the DISTUTILS_BUILD_EXT_ARGS parameters.


You did not explain broken in which sense ?

>
>
> --
> Craig McQueen
>
> --
> ___
> 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] Python module and build_ext args

[Craig McQueen]

I wrote:
> I'm trying to make a recipe for python3-uvloop, using setuptools3.
> 
> The Python 3 uvloop module depends on libuv. It bundles a version of libuv,
> and setup.py tries to build it, but it doesn't work well for 
> cross-compilation.
> However, it also provides a build_ext parameter "--use-system-libuv", which
> seems to work when I try running it manually in devshell. (I have made a
> suitable recipe for libuv and added libuv to DEPENDS.)
> 
> How can I specify the "--use-system-libuv" parameter for build_ext in the
> python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS,
> but it doesn't seem to be functional.


I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch:
https://patchwork.openembedded.org/patch/66071/

However, in the Yocto poky repository, I see commit 
0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken version 
of the above patch with the separate build_ext step not actually executed with 
the DISTUTILS_BUILD_EXT_ARGS parameters.

-- 
Craig McQueen

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

[yocto] Python module and build_ext args

[Craig McQueen]

I'm trying to make a recipe for python3-uvloop, using setuptools3.

The Python 3 uvloop module depends on libuv. It bundles a version of libuv, and 
setup.py tries to build it, but it doesn't work well for cross-compilation. 
However, it also provides a build_ext parameter "--use-system-libuv", which 
seems to work when I try running it manually in devshell. (I have made a 
suitable recipe for libuv and added libuv to DEPENDS.)

How can I specify the "--use-system-libuv" parameter for build_ext in the 
python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, but it 
doesn't seem to be functional.

-- 
Craig McQueen

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

[yocto] Yocto plug-in not running cmake

[Paul D. DeRocco]

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

Re: [yocto] [layerindex-web][PATCH v2] Asynchronous email notifications, task execution

[Paul Eggleton]

Hi Diana,

On Thursday, 24 August 2017 12:58:38 PM NZST Diana Thayer wrote:
> This patch adds asynchronous task execution using a Celery backend
> and RabbitMQ task queue.
> 
> It updates the README to reflect the installation and configuration
> of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task
> definitions, updates the 'edit_layer_view' function to send
> emails to administrators about new and updated layers asynchronously,
> and modifies the 'settings.py' to include a default configuration
> for a RabbitMQ connection.

This summarises what the patch does, which is useful, but it misses out the
most important bit - why we're making this change, i.e. to allow layer
submission process to proceed even in the event that sending the notification
email fails, and establishing an asynchronous execution mechanism that we can
use in future e.g. for triggering parse operations from the web UI. If you
could also include a reference to the bug in the form [YOCTO #11197] that
would be great.

Please also add your Signed-off-by which is missing.

One other comment below.

>
> --- 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 django.db.models import Q, Count, Sum
> -from django.core.mail import EmailMessage
>  from django.template.loader import get_template
>  from django.template import Context
>  from django.utils.decorators import method_decorator
> @@ -28,6 +27,7 @@ from django.contrib import messages
>  from reversion.models import Revision
>  from . import utils
>  from . import simplesearch
> +from . import tasks
>  import settings
>  from django.dispatch import receiver
>  import reversion
> @@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, 
> branch='master', slug=None):
>  # Send email
>  plaintext = get_template('layerindex/submitemail.txt')
>  perm = Permission.objects.get(codename='publish_layer')
> -users = User.objects.filter(Q(groups__permissions=perm) 
> | Q(user_permissions=perm) ).distinct()
> +users = User.objects.filter(Q(groups__permissions=perm) 
> | Q(user_permissions=perm) | Q(is_superuser=True)).distinct()

I forgot to mention this earlier - can you make this a separate patch? It's not
directly related. (It was mostly intentional, but I can see that it's a 
permission
and therefore it can be argued that a superuser should logically have it, so
I'm OK with it.)

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
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 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
>>> //sysroots/x86_64-linux/lib.
>>>
>>> So how to do that?
>>>
> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
> 

[yocto] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

[Philip Balister]

Once again we will have a developer meeting in Prague the Sunday before
ELCE.

Please go to https://www.openembedded.org/wiki/OEDEM_2017 and add
yourself if you are attending and ideas for topics.

Although it is called a developer meeting, we invite members of the
larger community to attend. The core developers are always interested in
hearing how OpenEmbedded is used, and what we can do to make it better
for building the embedded devices of the future.

Thanks,

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

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

[Leonardo Sandoval]

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] Problems building U-Boot for x86_64

[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
>> //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/

 

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

[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 //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 

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

[Gera Pesikoff]

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

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

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Alexander Kanavin]

On 08/24/2017 05:34 PM, Zoran Stojsavljevic wrote:

Do you agree to continue keeping DNF package (in 
.../meta/recipe_devtools/) for handling of .rpm type of packages in the 
future releases of YOCTO (it is, after all, much better and more mature 
tool that smartpm)?


The smart to dnf transition is now complete, and it has been well 
documented:


http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#migration-2.3-package-management-changes

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

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Zoran Stojsavljevic]

> No. Yocto is not an operating system, it's a toolset that can be used to
build many wildly different operating systems. An rpm repo would
> only be compatible with one of those OSes.

YOCTO is a custom made distro for eLinuxes, on this I agree with you. At
least, you should keep DNF (instead smartpm) as package representative for
dealing with .rpms, in all future YOCTO releases. This should be (as
considering embedded use cases) enough.

And, yes, I see your point, if anybody has so big project that he would
like to make master servers and maintain his own source code packages
(.src.rpm), and plain .rpm (as Fedora does, I just run there on Fedora 26
command: dnf list all | wc -l and got package # around 60K), he should do
this on his own. ;-)

Do you agree to continue keeping DNF package (in .../meta/recipe_devtools/)
for handling of .rpm type of packages in the future releases of YOCTO (it
is, after all, much better and more mature tool that smartpm)?

Thank you,
Zoran

On Thu, Aug 24, 2017 at 12:40 PM, Jussi Kukkonen 
wrote:

> On 24 August 2017 at 10:33, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> >
> > Hello Jussi,
> >
> > I would like to thank you very much for the useful reply. It was a bit
> different with me, but most boiled down as you said/explained (the
> difference are in client/server IP addresses, but everything else is almost
> the same - I guess, I do not have complete set of .rpms on my server side).
> >
> > I issued the following comand on client (qemux86-64): dnf list all | wc
> -l, and got the following response:
> > Repository 'oe-packages' is missing name in configuration, using id.
> > Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017
> UTC
> > 7909
> >
> > Regarding the command's answer, I have two questions to ask: one easy,
> and one tough. ;-)
> >
> > Easy one. What is the reason for this message: Repository 'oe-packages'
> is missing name in configuration, using id???
>
> I'm not a yum/dnf expert at all but the error seems to be saying that
> oe-packages.repo is missing a line like "name =  OpenEmbedded packages".
>
> > Tough one: 7909 packages overall on server. Could you (YOCTO
> maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in
> YOCTO, and make/create master YOCTO download servers, the same what Fedora
> distro does for almost two decades (with YUM, prior DNF)?
> >
> > The positive answer on the second question will make (for many thousand
> people using .rpms in YOCTO) life much easier, won't it?!
>
> No. Yocto is not an operating system, it's a toolset that can be used to
> build many wildly different operating systems. An rpm repo would only be
> compatible with one of those OSes.
>
> If a Yocto user builds and maintains a specific OS with Yocto, it might
> make sense for them to maintain rpm repos for that OS. It does not make
> sense for Yocto project.
>
>  - Jussi
>
-- 
___
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 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 //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] [meta-yocto-bsp][PATCH] machine: mpc8315e-rdb: change kernel provider assignment to default

[Stefan Müller-Klieser]

To be able to configure the kernel provider at other locations, we need
a default assignment here.

Signed-off-by: Stefan Müller-Klieser 
---
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf 
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index ce5015256a23..b6cb49b58358 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -15,7 +15,7 @@ SERIAL_CONSOLE = "115200 ttyS0"
 MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"
 
 PREFERRED_VERSION_linux-yocto ?= "4.10%"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
-- 
1.9.1

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

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

[Yusuke Mitsuki]

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"
-- 
2.7.4

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

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

[Yusuke Mitsuki]

I could not use bluetooth with raspberrypi0-wifi.
hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not found.

Functions in bluez5_%.bbappend should be enabled with raspberrypi0-wifi too.

I know that these changes are redundant.

If you have any ideas for better solution, let me know.


Yusuke Mitsuki (1):
  bluez5: add functions for raspberrypi0-wifi

 recipes-connectivity/bluez5/bluez5_%.bbappend | 25 +
 1 file changed, 25 insertions(+)

-- 
2.7.4

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

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

[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 //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
> -Wl,-rpath-link,//sysroots/x86_64-linux/usr/lib
> -Wl,-rpath-link,//sysroots/x86_64-linux/lib
> -Wl,-rpath,//sysroots/x86_64-linux/usr/lib
> -Wl,-rpath,//sysroots/x86_64-linux/lib -Wl,-O1 -C

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Jussi Kukkonen]

On 24 August 2017 at 10:33, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
>
> Hello Jussi,
>
> I would like to thank you very much for the useful reply. It was a bit
different with me, but most boiled down as you said/explained (the
difference are in client/server IP addresses, but everything else is almost
the same - I guess, I do not have complete set of .rpms on my server side).
>
> I issued the following comand on client (qemux86-64): dnf list all | wc
-l, and got the following response:
> Repository 'oe-packages' is missing name in configuration, using id.
> Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017
UTC
> 7909
>
> Regarding the command's answer, I have two questions to ask: one easy,
and one tough. ;-)
>
> Easy one. What is the reason for this message: Repository 'oe-packages'
is missing name in configuration, using id???

I'm not a yum/dnf expert at all but the error seems to be saying that
oe-packages.repo is missing a line like "name =  OpenEmbedded packages".

> Tough one: 7909 packages overall on server. Could you (YOCTO
maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in
YOCTO, and make/create master YOCTO download servers, the same what Fedora
distro does for almost two decades (with YUM, prior DNF)?
>
> The positive answer on the second question will make (for many thousand
people using .rpms in YOCTO) life much easier, won't it?!

No. Yocto is not an operating system, it's a toolset that can be used to
build many wildly different operating systems. An rpm repo would only be
compatible with one of those OSes.

If a Yocto user builds and maintains a specific OS with Yocto, it might
make sense for them to maintain rpm repos for that OS. It does not make
sense for Yocto project.

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

Re: [yocto] [feature request] avoid getting the server stuck because of high "-j" value

[Gianfranco Costamagna]

Thanks you all for the valuable answers!

cheers,

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

Re: [yocto] Runtime Dependencies dependent on lowercase recipe name?

[Gianfranco Costamagna]

Hello,

>Now the strange thing happens: copy the helloworld_0.1.bb to
>Helloworld_0.1.bb
>So the only difference is the lowercase vs capital "H" in the recipe name.

welcome to the club!

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

Hopefully we will have a big red warning/error when we use capital letters 
again :)

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

Re: [yocto] RDEPENDS dependency problem

[Stefano Pagnottelli]

First of all, thanks for your reply.

Il giorno mer 23 ago 2017 alle ore 20:56 Khem Raj  ha
scritto:

> On 8/23/17 1:12 AM, Stefano Pagnottelli wrote:
> > Hi to all,
> >
> > I'm trying to build this layer:
> > (https://github.com/bachp/meta-homeassistant) using the yocto pyro on a
> > raspberry pi 3 target and the opkg package system.
> >
> > Inside the recipe
> > (
> https://github.com/bachp/meta-homeassistant/blob/master/recipes-homeassistant/homeassistant/python3-homeassistant_0.51.2.bb
> )
> > there  are some RDEPENDS with strict equal
> > dependencies (ex:python3-aiohttp (= 2.2.5)).
> >
> > We I build the image with the opgk package system the system fail in the
> > do_rootfs task because is not finding the package python3-aiohttp =
> > 2.2.5.. If I understood correctly this happens because the build system
> > si appending the recipe revision (PR variable) at end of package name
> > and the results is  python3-aiohttp_2.2.5-r0 and not
> > python3-aiohttp_2.2.5 as opkg is expecting.
>
> I dont think r0 is in play here. You can test it by changing dependency
> check to look for  (= for 2.2.5-r0), I think it should still fail.
>

I do some tests of on rdendps on the recipe:

With python3-aiohttp (= 2.2.5-r0) the image is built without problems, with
python3-aiohttp (>= 2.2.5) the image is built without problems, with
python3-aiohttp (= 2.2.5) the task fail with the following error:

Problem 1/1:
  - nothing provides python3-aiohttp = 2.2.5 needed by
python3-homeassistant-0.51.2-r0.cortexa7hf-neon-vfpv4

So it seems to me that know the recipe revision is mandatory if you want to
put a strict dependency on a rdpends. But if I understood correctly the
yocto build system it's not possible to predict the recipe revision because
is automatically computed,  And a change in the recipe will break the
dependency also if the source software version is the same because this
will change the recipe version.


>
> >
> > As workaround I changed all strict = with a >= and the build complete
> > without errors.
>
> this is ok as long as the package can work with newer versions of this
> package. I am not sure if thats the case, you might have to check with
> authors intent for using = instead of >=
>

I think that ,in that case the author is using strict = dependencies
because we are trying to compile a python project that strictly depend
python module with a specific version.  Can be useful to have strict =
dependency in a recipe but it is not mandatory, the project compile well
also with >=.

Regards
Stefano


>
> >
> > My question is: It's possible to  instruct the build system to ignore
> > the recipe revision when it match the version of the package? Or in
> > alternative it's possible to automatically detect the recipe revision of
> > the package?
> >
> > Thanks in advance
> > Stefano
> > …
> > --
> >
> > There are 10 types of people in this world, those who understand binary
> > and those who dont
> >
> >
>
> --

There are 10 types of people in this world, those who understand binary and
those who dont
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] refpolicy: fix a typo in RDEPENDS

[jackie.huang]

From: Jackie Huang 

Underscore ("_") should be used for variable overrides.

Signed-off-by: Jackie Huang 
---
 recipes-security/refpolicy/refpolicy_common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 6a45e79..4a7b7eb 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -31,7 +31,7 @@ EXTRANATIVEPATH += "bzip2-native"
 
 DEPENDS += "bzip2-replacement-native checkpolicy-native policycoreutils-native 
m4-native"
 
-RDEPENDS-${PN}-dev =+ " \
+RDEPENDS_${PN}-dev =+ " \
 python \
 "
 
-- 
2.11.0

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

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Zoran Stojsavljevic]

Hello Jussi,

I would like to thank you very much for the useful reply. It was a bit
different with me, but most boiled down as you said/explained (the
difference are in client/server IP addresses, but everything else is almost
the same - I guess, I do not have complete set of .rpms on my server side).

I issued the following comand on client (qemux86-64): dnf list all | wc -l,
and got the following response:
*Repository 'oe-packages' is missing name in configuration, using id.*
Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017 UTC
*7909*

Regarding the command's answer, I have two questions to ask: one easy, and
one tough. ;-)

Easy one. What is the reason for this message: *Repository 'oe-packages' is
missing name in configuration, using id*???

Tough one: 7909 packages overall on server. Could you (YOCTO maintainers),
please, keep DNF (for .rpm packages) onwards indefinitely in YOCTO, and
make/create master YOCTO download servers, the same what Fedora distro does
for almost two decades (with YUM, prior DNF)?

The positive answer on the second question will make (for many thousand
people using .rpms in YOCTO) life much easier, won't it?!

Thank you,
Zoran Stojsavljevic

On Wed, Aug 23, 2017 at 2:39 PM, Jussi Kukkonen 
wrote:

>
>
> On 23 August 2017 at 14:51, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Hello Jussi,
>>
>> Let me start giving you all the hints. So you can see where I lead. You
>> made few mistakes, so DNF won't work as such/is (by default) in Pyro 2.3.1.
>>
>> I investigated a bit (I already wrote that I am quite familiar with DNF
>> and its concepts).
>>
>> For the starters: Your DNF repo on Pyro 2.3.1 is in the following
>> directory (I built full SATO image for target qemux86-64), transcript from
>> my bare metal F26 follows:
>>
>> [user@localhost poky]$ cd build/tmp/deploy/rpm
>> [user@localhost rpm]$ ls -al
>> total 564
>> drwxr-xr-x. 5 user user   4096 Aug 22 13:33 .
>> drwxr-xr-x. 5 user user   4096 Aug 22 13:28 ..
>> drwxr-xr-x. 2 user user 462848 Aug 22 13:32 core2_64
>> drwxr-xr-x. 2 user user  16384 Aug 22 13:32 noarch
>> drwxr-xr-x. 2 user user  81920 Aug 22 13:32 qemux86_64
>> [user@localhost rpm]$ cd noarch
>> [user@localhost noarch]$ ls -al | wc -l
>> 189
>> [user@localhost noarch]$ ls -al *.xml
>> ls: cannot access '*.xml': No such file or directory
>> [user@localhost noarch]$
>>
>> As we see here, there are three .rpm repos on the server (let say, I am
>> starting client qemux86-64). If you do the same, and built it for sato (or
>> minimal, does not matter), you'll have the same. None of these .rpm repos
>> have file which MUST be present there: repomd.xml???
>>
>> Where is this file? How to generate it, for/per each local server repo,
>> one instance of repomd.xml???
>>
>
> repomd.xml is created into TMPDIR/deploy/rpm/repodata/ when you run
> "bitbake package-index" as the documentation suggested.
>
> I don't have Pyro but I've just tried this on master and it seems to work
> fine (the docs might need updating on the baseurl format though).
>
> ** On the server:
> ~/src/poky/build/tmp/deploy/rpm$ python -m SimpleHTTPServer
> Serving HTTP on 0.0.0.0 port 8000 ...
>
> ** On target qemu:
> root@qemux86-64:~# cat /etc/yum.repos.d/oe-packages.repo
> [oe-packages]
> baseurl=http://192.168.7.3:8000/
> root@qemux86-64:~# dnf makecache
> Repository 'oe-packages' is missing name in configuration, using id.
> Last metadata expiration check: 0:06:49 ago on Wed Aug 23 12:23:22 2017.
> Metadata cache created.
> root@qemux86-64:~# dnf --nogpgcheck install libinput-bin
> Repository 'oe-packages' is missing name in configuration, using id.
> Last metadata expiration check: 0:10:09 ago on Wed Aug 23 12:23:22 2017.
> Dependencies resolved.
> 
> 
> 
>  PackageArch   Version
>  Repository Size
> 
> 
> 
> Installing:
>  libinput-bin   core2_64
> 1.8.1-r0 oe-packages12 k
>
> Transaction Summary
> 
> 
> 
> Install  1 Package
>
> Total download size: 12 k
> Installed size: 19 k
> Is this ok [y/N]: y
> Downloading Packages:
> libinput-bin-1.8.1-r0.core2_64.rpm
>323 kB/s |  12 kB 00:00
> 
> 
> 
> Total
>   134 kB/s |  12 kB 00:00
> Running 

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

[Ferry Toth]

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 //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
 -Wl,-rpath-link,//sysroots/x86_64-linux/usr/lib
 -Wl,-rpath-link,//sysroots/x86_64-linux/lib
 -Wl,-rpath,//sysroots/x86_64-linux/usr/lib
 -Wl,-rpath,//sysroots/x86_64-linux/lib -Wl,-O1 -C
 //out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
 v2017.03-r0/git
 O=//out/linux64/build/tmp/work/edison-poky-linux/u-