Date   

Re: First set of fido-next changes are in testing

Martin Jansa
 

On Fri, May 01, 2015 at 12:09:43PM +0100, Joshua Lock wrote:
All,

There have been a lot of patches proposed for fido so I wanted to let
you know that I have just submitted a first fido-next test build to
the autobuilder.

The full set of changes can be seen in my fido-next branch:

http://git.yoctoproject.org/cgit/cgit.cgi/poky
-contrib/log/?h=joshuagl/fido-next
Is it the same as:
From git+ssh://git.openembedded.org/openembedded-core-contrib
* [new branch] joshuagl/fido-next -> contrib/joshuagl/fido-next
?

And shouln't this e-mail go to oe-core ML?

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


First set of fido-next changes are in testing

Joshua Lock <joshua.lock@...>
 

All,

There have been a lot of patches proposed for fido so I wanted to let
you know that I have just submitted a first fido-next test build to
the autobuilder.

The full set of changes can be seen in my fido-next branch:

http://git.yoctoproject.org/cgit/cgit.cgi/poky
-contrib/log/?h=joshuagl/fido-next

Cheers,

Joshua


Release Candidate Build for yocto-1.7.2_rc3 now available.

Poky Build User <pokybuild@...>
 

A release candidate build for yocto-1.7.2_rc3 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.2_rc3


Please begin QA on this build as soon as possible.


Build hash information:
meta-intel : c39a4bf4450845fca6f1b26ccfc0db192a4567e8
meta-fsl-arm : db1571f40c375a398a8cdbb42de4c4f272ab0cd1
meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45
meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4
poky : 29812e61736a95f1de64b3e9ebbb9c646ebd28dd


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flanagan@intel.com


Re: How to add openmp to the target image

christophe coutand <ccoutand@...>
 

Hi Paul,

Thank you for your help.

replacing
IMAGE_INSTALL += "libgomp libgomp-dev libgomp-staticdev"
with
IMAGE_INSTALL_append = " libgomp libgomp-dev libgomp-staticdev"
in local.conf seems to do the trick, the library is now part of the target image.

Regards,
Christophe

On 21.04.2015 12:12, Paul Eggleton wrote:
Hi Cristophe,

On Monday 20 April 2015 13:15:06 Christophe Coutand wrote:
Is there a way to include the openmp library on the target image? when
building the full target image for a freescale processor, I get gcc etc...
installed on the target filesystem but not libgomp. It is however correctly
deployed when installing the SDK on the host machine.
The library is packaged in a package called libgomp, headers are in a package
called libgomp-dev. You can add these to your image if you are looking to
build things on the target itself [1], but if you are simply building an
application that you want to link to this library from within the build
system, you should not need to explicitly add it because the build system will
pick up on the dynamic link and add a dependency from your application package
on the libgomp package automatically.

Cheers,
Paul

[1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage


Release Candidate Build for yocto-1.7.2_rc3 now available.

Poky Build User <pokybuild@...>
 

-e
A release candidate build for yocto-1.7.2_rc3 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.2_rc3


Please begin QA on this build as soon as possible.


Build hash information:
meta-intel : c39a4bf4450845fca6f1b26ccfc0db192a4567e8
meta-fsl-arm : db1571f40c375a398a8cdbb42de4c4f272ab0cd1
meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45
meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4
poky : 29812e61736a95f1de64b3e9ebbb9c646ebd28dd


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flanagan@intel.com


Re: fido: funny ipk behavior

Gary Thomas
 

On 2015-04-30 15:23, Robert P. J. Day wrote:
On Thu, 30 Apr 2015, Burton, Ross wrote:


On 30 April 2015 at 21:30, Robert Berger <gmane@reliableembeddedsystems.com> wrote:
Nothing, since I forgot

EXTRA_IMAGE_FEATURES_append = " package-management"
um ... i think you only need refer to EXTRA_IMAGE_FEATURES; with
that variable, i believe the "_append" part is superfluous.
Unless it's already being set somewhere else - this seems like
a safe way to make sure it gets set.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: fido: funny ipk behavior

Robert P. J. Day
 

On Thu, 30 Apr 2015, Burton, Ross wrote:


On 30 April 2015 at 21:30, Robert Berger <gmane@reliableembeddedsystems.com> wrote:
Nothing, since I forgot

EXTRA_IMAGE_FEATURES_append = " package-management"
um ... i think you only need refer to EXTRA_IMAGE_FEATURES; with
that variable, i believe the "_append" part is superfluous.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: fido: funny ipk behavior

Ross Burton
 


On 30 April 2015 at 21:30, Robert Berger <gmane@...> wrote:
Nothing, since I forgot

EXTRA_IMAGE_FEATURES_append = " package-management"

That will be it then - your image doesn't have a package database so any dependencies won't be able to be satisfied.

Either force the installation or rebuild the image with package-management enabled.

Ross


Re: fido: funny ipk behavior

Robert Berger <gmane@...>
 

Hi,


On 04/30/2015 10:35 PM, Gary Thomas wrote:

On your target, what do you get from this?
# opkg list-installed libc6
Nothing, since I forgot

EXTRA_IMAGE_FEATURES_append = " package-management"

Thanks,

Robert..."it doesn't matter how beautiful your theory is, it doesn't
matter how smart you are -- if it doesn't agree with experiment, it's
wrong." - Richard P. Feynman

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


Re: fido: funny ipk behavior

Gary Thomas
 

On 2015-04-30 12:11, Robert Berger wrote:
Hi,

I have a simple recipe like this:

---

DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"

S = "${WORKDIR}/git"

do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}

do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}

---

If I bake the .ipk, copy it over to the target and try to install it
there it complains:

opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.
On your target, what do you get from this?
# opkg list-installed libc6


---

If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.

scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp

/tmp/simple-hello-world-git
Simple Hello world git!

Am I missing something?

I think this worked with dizzy.

Regards,

Robert..."In Pascal, when you foll with a pointer of a handle, you know
you're fooling with a pointer of a handle. In C, you could be fooling
around with anything. C is the ultimate language for computational
promiscuity." -- Owen Hartnett

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


fido: funny ipk behavior

Robert Berger <gmane@...>
 

Hi,

I have a simple recipe like this:

---

DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"

S = "${WORKDIR}/git"

do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}

do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}

---

If I bake the .ipk, copy it over to the target and try to install it
there it complains:

opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.

---

If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.

scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp

/tmp/simple-hello-world-git
Simple Hello world git!

Am I missing something?

I think this worked with dizzy.

Regards,

Robert..."In Pascal, when you foll with a pointer of a handle, you know
you're fooling with a pointer of a handle. In C, you could be fooling
around with anything. C is the ultimate language for computational
promiscuity." -- Owen Hartnett

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


[dizzy] shutdown custom image will not power off the processor

kris duff <t_dufff@...>
 

Hello,

I don't know yet if this issue is bsp related or not, but I am trying to understand what is going on here.

If anybody have any clue to help me solve my problem, I would appreciate.

Using a custom image recipe, when I shutdown ( using the command ) my device will not power off.  I see the message halt on the console but nothing is happening ...

In daisy, the system were turning off correctly (with the same hardware)

I don't know where to start to look at to solve this issue. I would like to hear your suggestions.

Thank you

Kris


fido: funny ipk behavior

gmane@...
 

Hi,

I have a simple recipe like this:

---

DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI = "git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"

S = "${WORKDIR}/git"

do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}

do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}

---

If I bake the .ipk, copy it over to the target and try to install it there opkg complains:

opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.

---

If I include the package into my image it works, also if I just copy over the executable (which is included in the package) it works.

scp /home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git root@192.168.7.2:/tmp

/tmp/simple-hello-world-git
Simple Hello world git!

Am I missing something?

I am pretty sure this worked with dizzy.

Regards,

Robert


Re: Replacing HOB in Build Appliance for YP 1.9

David Stewart
 

+1

On 4/30/15, 9:06 AM, "Georgescu, Alexandru C"
<alexandru.c.georgescu@intel.com> wrote:

Hello,
In 1.9 HOB is intended to be deprecated by Toaster functionality. This
means that Build Appliance also must be changed. Since HOB is started
automatically in BA in order to help users get started quickly with YP, I
have the following proposal for updating BA in 1.9 and to replace HOB:


* Update current BA implementation in order to support Toaster (maybe few
patches needed to be included in the image in order to run Toaster)
* If Toaster is enabled in BA then the user might be able to run Toaster
from his host machine, or if BA is installed on a remote server, just
access the server via HTTP.
* this should be an easy solution to implement and maintain the BA
functionality.

There are solutions like Docker that were previously discussed, but my
opinion is that first of all Docker is limited to Linux only. Secondly it
will need much more QA effort (support at least 4 distros that YP
currently supports) and more failure prone for specific Docker
configurations.

Regards,
--
Alexandru Georgescu
Yocto QA Engineer
SSG/SSD Open Source Technology Center Romania

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


Replacing HOB in Build Appliance for YP 1.9

Georgescu, Alexandru C <alexandru.c.georgescu@...>
 

Hello,
In 1.9 HOB is intended to be deprecated by Toaster functionality. This
means that Build Appliance also must be changed. Since HOB is started
automatically in BA in order to help users get started quickly with YP, I
have the following proposal for updating BA in 1.9 and to replace HOB:


* Update current BA implementation in order to support Toaster (maybe few
patches needed to be included in the image in order to run Toaster)
* If Toaster is enabled in BA then the user might be able to run Toaster
from his host machine, or if BA is installed on a remote server, just
access the server via HTTP.
* this should be an easy solution to implement and maintain the BA
functionality.

There are solutions like Docker that were previously discussed, but my
opinion is that first of all Docker is limited to Linux only. Secondly it
will need much more QA effort (support at least 4 distros that YP
currently supports) and more failure prone for specific Docker
configurations.

Regards,
--
Alexandru Georgescu
Yocto QA Engineer
SSG/SSD Open Source Technology Center Romania


Re: Migration from 1.7.1 to 1.8 - kernel-abiversion missing

Bruce Ashfield <bruce.ashfield@...>
 

On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:
What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?
How would I see which kernel recipe is used?
This is where my brute force techniques probably break down. I just
do a 'bitbake virtual/kernel' and you'll see it display which
recipe is being built.

If you haven't added compatibility for your new machine to any
recipe, I'm betting that linux-dummy is used.


I did not customize anything except for aforementioned steps, simply copied beaglebone.conf to astro.conf in the same directory. Also I did not touch any kernel recipes (kernel is built externally), maybe that's what's missing?
It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce


Jan


Re: [meta-raspberrypi] virtual/libgles1

Gary Thomas
 

On 2015-04-30 05:11, Andrei Gherzan wrote:
Hello Gary,

I see that rpi doesn't provide gles1 in none of the graphics providers. So the only solution that I see for now is to have a new recipe (similar to mesa-gl) which will provide only
gles1. Or, we can bbappend mesa to be used and provide only gles1 (this could be pretty hacky).
Fair enough. I'll take a look at this when I have a chance (no promises...)

On Mon, Apr 13, 2015 at 2:12 PM, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:

How can I get virtual/libgles1 on the RaspberryPi? libgles2
is provided by "userland" but that package does not provide
libgles1. If I add a dependency on libgles1 (e.g. libva),
then there is a conflict which tries to install both mesa
and mesa-gl.

Looking for ideas...
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: Heads up

Gary Thomas
 

On 2015-04-30 01:45, Khem Raj wrote:
On Wed, Apr 29, 2015 at 7:18 AM, Gary Thomas <gary@mlbassoc.com> wrote:
This is just a note that the recent upgrade of util-linux
to version 2.26.1 (from 2.25.2) was much more major than
the version change implies. The 'sfdisk' tool changed a
lot and will no longer be compatible with many scripts out
there that still use it.
Can we document the needed differences and info for users ?
may be it will handy in release notes too eventually when release time comes
From the 2.26 release notes:
This version provides a completely new sfdisk(8) command; the new version is
based on libfdisk. If your use cases depend on sfdisk(8), then it is strongly
recommended to be careful and re-test your scripts. The new version supports
MBR and GPT disk labels (SGI and SUN are also supported but not well tested).
The new version no longer supports some obscure MBR-specific command-line
options nor legacy CHS addressing.

What this means is that any script (there are a ton of them out there)
that tries to create a label for a disk device using Cylinder-Head-Sectors
style will have to be rewritten as the new sfdisk only does sector unit
addressing.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: Migration from 1.7.1 to 1.8 - kernel-abiversion missing

Schaumlöffel, Jan <J.Schaumloeffel@...>
 

What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?
How would I see which kernel recipe is used?

I did not customize anything except for aforementioned steps, simply copied beaglebone.conf to astro.conf in the same directory. Also I did not touch any kernel recipes (kernel is built externally), maybe that's what's missing?

Jan


Re: Migration from 1.7.1 to 1.8 - kernel-abiversion missing

Bruce Ashfield <bruce.ashfield@...>
 

On 2015-04-30 3:14 AM, Schaumlöffel, Jan wrote:
That is really odd. I'll be interested to hear how that happened. I just did a
test and it points to where I expect:

[/home/bruc...poky/build]> bitbake -e core-image-minimal | grep
STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work-
shared/qemux86-64/kernel-build-artifacts"
So I experimented a bit more and found a minimal set of steps to reproduce the problem. Maybe that might give someone a clue as to what is happening and/or how to resolve it.

Steps to reproduce:

- clone Poky repository, checkout branch 'fido'
- go to meta-yocto-bsp/conf/machine and copy beaglebone.conf to another file (I used astro.conf)
- from poky repository do source oe-init-build-env into new build directory
- edit conf/local.conf to set MACHINE ?= "astro" (use filename from second step) and DL_DIR (if present)
- run bitbake core-image-minimal

-> kernel-abiversion is missing, build fails

- edit conf/local.conf, set MACHINE ?= "beaglebone"
- run bitbake core-image-minimal

-> image builds fine

It stays the same if the copied config is in a custom BSP layer, some minor modifications are made, etc., but to eliminate complexity I just put that into the meta-yocto-bsp layer. What strikes me as really odd is that now the only thing changed between working and non-working configuration seems to be the filename of the machine configuration - what am I missing?
What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to
another known kernel recipe ?

The big difference that I see would be the kernel recipe, and
some of the tasks not executing (and hence not generating the
abiversion file).

Bruce

How do I create a working machine configuration for Poky 1.8? (In 1.7.1 I just took some machine configuration from eldk, fiddled around with it a bit, put it into my BSP layer and never had any trouble with that.)

Regards,
Jan