[yocto] [autobuilder] Y-AB in a docker container?

[Robert Berger]

Hi,

I use the good old yocto autobuilder in a docker container and it still 
serves me well, but I would like to move to the shiny new yocto autobuilder.


Before I start spending hours to do it myself I wonder if someone 
already did something like this and is willing to share the Dockerfile(s).


Regards,

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

[yocto] warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)

[Robert Berger]

Hi,

I can see in some examples:

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)

which can be fixed by passing the proper CFLAGS.

Unfortunately the warning is only visible in log files.

1) Is there a way to show compiler warnings when you bitbake on the 
console (without -DDD and/or -v and filtering for warning:)


2) How would you add a check for this to insane.bbclass?

Regards,

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

Re: [yocto] Yocto Project Upcoming Conferences and Developer Days

[Robert Berger]

Hi,

I think the discussion went a bit off track, which happens on mailing 
lists after x replies;)


Please see my comments in-line.

On 03.05.19 21:01, Volosincu, Andreea S wrote:


ELCE – Monday, October 28 -30, 2019, Lyon Convention Centre, Lyon, France

   Yocto Project is a sponsor. We’ll see you on the show floor

ELCE Yocto Project Summit – Dates & Times:

Thursday, October 31, 2019 - 8:00AM - 6:00PM

    November 1, 2019 - 8:00 am - 6:00PM



As you might know I am willing to help teaching at the EU event.


Set-up:

Day 1: 1 Meeting Room - Theater Seating for 100 for Yocto Project talks

Day 2: 2 Meeting Rooms - Mixed Classroom/Theater seating for 60 & 
Classroom seating for 40 (for maintainers and users)


Includes:

Morning Break for 2 days

Buffet Lunch for 2 days

Beer & Wine Reception with light appetizers for 1 day

The goal for the second day of the summit is to build and bring the 
community together. We are interested to hear your opinions and ideas on 
how that day and those rooms should be used for. Please send your ideas 
to Andreea Volosincu and Philip Balister.


1)

I propose for the YP people to borrow some of their marketing people to 
OE ;) really I am serious about it.

(I already proposed that on the last OE Dev day, but no idea what happened).

There are quite a few cool things going on and they are not known to the 
public.


2) What kind of classes?

2.1) Basic classes
2.2) Intermediate classes
2.3) Advanced classes

It all depends on interest from trainees and from trainers and what we 
would like to present in general those 2 days.


Should it be just some veterans coming together (well the usual 
suspects) discussing things and drinking beer? (Josef will only get 
coffee and water)


... or do we want to bring in new people/beginners and give them some 
overview/initial help with the "monster" as well?


Don't get me wrong, I am delivering lots of YP/OE trainings and there is 
definitely a very high demand for this, but is that what we want to be 
covered in the 2 days as well?


3)

A different approach might be for people to "bring their own YP/OE 
problem" and we'll try to sort it out on the spot (if possible) or at 
least we'll try to propose some guidance how problems could be solved. 
That might be a quite interesting mix of simple and advanced problems. 
Having all the "brains" of the project(s) together in one place might 
help to see what problems people actually have.


Examples I came across:

3.1) People are told to use the YP in their project because the board 
manufacturer made a BSP with it, but they just need a headless system.
3.1.1) They start to remove stuff from the shiny Qt enabled demo of the 
board manufacturer - and fail.


3.2) People build some binaries with the SDK provided by the board 
manufacturer and manually copy them over to the rootfs - and can never 
reproduce again what goes in the field. - even the kernel and the boot 
loader are "maintained" outside of the YP/OE sometimes.


3.3) People build a complete image and upload it to the target with 
every little code change - instead of a different "developer" and 
"test/release" workflow.


3.4) License compliance - what this really exists?

3.5) Static libs (with autotools) (I made a speech about it last time at 
the YP dev day)


3.6) SW update vs. package management - sooner or later this is needed

3.7) Reproduce-able builds - are they?

3.8) Containers - deliver app(s) in containers

...

Now you know why I have so many gray/white hair and why I am traveling 
all the time delivering trainings ;)




We will call out an Advocacy meeting in a couple of weeks to go over 
plans and vote on the ideas for the second day of the summit.


Thanks!

Andreea

Yocto Project Advocacy Lead




Regards,

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

Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable

[Robert Berger]

Hi Ken,

Is there any particular reason you don't use the sample[1] for an out of 
tree kernel module?


[1] 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod


Regards,

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

Re: [yocto] Fetch from git every bitbake

[Robert Berger]

Hi Mauro,

Can you please elaborate a bit what exactly you try to do?

SRCREV = "${AUTOREV}"

will get the latest and greatest version from your git repo (the first 
time and afterwards only if something changed in the git repo) and a 
rebuild will only be triggered if something changed on your git repo.


If I understand it correctly you are trying to "fetch" and "build" every 
time, even if nothing changed in the git repo.


Keep in mind, that bitbake will "only" fetch a new version from git if 
there is a new version available.


In case you changed nothing in you git repo bitbake will most likely use 
the cached version and also no new build will be triggered.


In case you want to "compile" every time even if nothing changed you can 
try this:


do_compile[nostamp] = "1"

[nostamp]: When set to "1", tells BitBake to not generate a stamp file 
for a task, which implies the task should always be executed.


In case you can provide an example .bb and explain your problem I guess 
we can better help.


Regards,

Robert

On 26.01.19 17:54, Mauro Ziliani wrote:

Hi all.

I try AUTOREV in my recipe, but bitbake doesn't check the git repository 
for newer versions.


I need to do

bitbake app -c cleanall

bitbake app


to update sources from repository.


Where I mistake?


Regards,

   MZ


Il 17/01/19 15:06, Mauro Ziliani ha scritto:

Hi all.

How can I force the pull from git repository of my app every time I do

bitbake app


Best regards,

  MZ



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

[yocto] supplier workflow

[Robert Berger]

Hi,

I came across a scenario, which does not seem too strange, but I am not 
sure how this can be handled with OE/YP. (just nasty hacks with SSTATE)


1) Company A provides an SDK to to Company B - no source code provided
2) Company B provides a "binary" back to Company A - no source code povided
3) Company A integrates this "binary" back into some project and 
bitbakes the image


Ideally Company B does not just provide a "binary" executable/library, 
but a package e.g. ipk.


Company A could provide an extensible SDK and Company B could create a 
package of their stuff with it.


Now comes the question: "Is it possible for Company A to add a package 
(no source code available) back into a project and bitbake this?

If yes, how?"

The advantage would be that Company B would be forced to bitbake it 
(with the additional checks done by OE/YP) and not just compile 
something somehow with a "classic" SDK and ship it.


Regards,

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

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

[Robert Berger]

Hi,

On 02.11.18 16:27, Khem Raj wrote:


omap serial is obsolete why does linux-yocto keeps using it.
seondly, machine config should enable both consoles ttyO0 and ttyS0 if
you know that at least one kernel is using ttyO0

How about picking whatever works for you in the kernel conf and in 
machine conf?


SERIAL_CONSOLES = "115200;ttyS0 115200;ttyO0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

Like this on the first boot either ttyO0 or ttyS0 should be picked 
automatically.


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

Re: [yocto] 2.6 migration guide

[Robert Berger]

Hi Scott,

On 31.10.18 00:06, Scott Rifenbark wrote:


I have an initial section at 
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release, 
which is based on Richard's input.  I am sure there are more items.


You might want to add a link to the bitbake manual or some example from 
there for the new functionality of _remove operator:


http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334

FOO = "123 456 789 123456 123 456 123 456"
FOO_remove = "123"
FOO_remove = "456"

FOO is now: "  789 123456" instead of "789 123456"



Thanks,
Scott


Regards,

Robert

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

Re: [yocto] Problem with packages during "devtool build"

[Robert Berger]

Hi,

On 2018-04-05 21:02, Raymond Yeung wrote:
"inherit module" is already in recipes/cgosapi.bb file.  In fact, as I 
use devtool to "add" the recipe to workspace layer, this .bb file is 
autogenerated.  I only added the last line that sets KERNELDIR that 3rd 
Party software's Makefile uses.


Did you have a look at this out of tree kernel module example?

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod

You might want to use this makefile and add your stuff there.

Regards,

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

Re: [yocto] ClamAV PCRE support

[Robert Berger]

Hi Tom,

I never tried to get clamav to run, but please see my comments below.

On 2018-04-03 16:22, Tom Gibson wrote:

Hi Anuj



This is happening because clamav is looking for pcre-config (uses it to find
pcre paths) and it's not able to locate it ...

Even if you do get around this error by passing the path to configure, using
binconfig files to evaluate paths has been disabled in OE-core layer.

So, you will have to fix the configure/pcre.m4 file in clamav to do this using
.pc file from libpcre instead.



Sorry, I'm not clear on which file needs fixing? I can only find pcre.m4 at


tmp/work/armv7a-neon-poky-linux-gnueabi/clamav/0.99.2-r0/git/m4/reorganization/libs/pcre.m4

Isn't this generated during build? I'm sorry I'm also not clear on what needs 
changing, where can I find the correct .pc file for libpcre?


I guess Anuj has a much better understanding about ClamAv and friends, 
but in general:


.pc files are for the pkg-config utility[1][2].

You might want to try to compile libpcre and clamav natively on your 
target board. From there I would try to "steal" the relevant information 
and feed it back into the recipe(s).


[1] https://linux.die.net/man/1/pkg-config
[2] https://en.wikipedia.org/wiki/Pkg-config

Also I guess that the file you need to fix is:

./m4/reorganization/libs/pcre.m4

with the input of whatever libpcre has in the libpcre.pc... or so file.



Thanks for your help.

Regards,

Tom



Happy hunting,

Robert


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

Re: [yocto] U-Boot networking broken in Rocko

[Robert Berger]

On 2018-03-26 19:51, akuster808 wrote:

I found 
that this has already been fixed in U-Boot with the commit below.  I 
think it has something to do with the way GCC 7.1 onwards is now 
handling memory alignment.  


I also saw something similar and by upgrading to U-boot 2018.03 the 
problem went away as well.


Regards,

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

Re: [yocto] static libraries missing from sdk

[Robert Berger]

Hi,

I played around a bit with my autotooled lib, which produces only a 
static lib.


1) My preferred approach is this:

I add to local.conf:

TOOLCHAIN_TARGET_TASK_append = " libhw-a-staticdev libhw-a-dev"

The recipe looks like this:

https://pastebin.com/YLUvQSSx

2) But your approach works as well:

I add to local.conf:

# we need to add the empty package to the rootfs for
# IMAGE_FEATURES_append to work:
IMAGE_INSTALL_append = " libhw-a"
# add all -dev, -dbg, -staticdev pkgs to the SDK (only):
SDKIMAGE_FEATURES_append = " dev-pkgs dbg-pkgs staticdev-pkgs"

The recipe looks like this:
(needed to slightly modify my original recipe)

https://pastebin.com/VcsqNuMf

On the rootfs there is nothing with respect to this recipe.

In the SDK are:
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.a
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/include/lib_hw.h

Regards,

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

Re: [yocto] static libraries missing from sdk

[Robert Berger]

Hi,

On 2018-02-07 16:01, Mircea Gliga wrote:

With this line you try to add -dev (.so), -dbg and staticdev (.a) for 
**all** packages:



     SDKIMAGE_FEATURES += "dev-pkgs dbg-pkgs staticdev-pkgs"


I am not sure it makes sense to build and add both the static and 
dynamic libs to an SDK.


Do you really want this?

Regards,

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

Re: [yocto] static libraries missing from sdk

[Robert Berger]

Hi,

OK I think I understood.

You want a static library and apparently .h and friends as well as the 
.a file should end up in the SDK and nothing on the rootfs.


If you enable staticdev-pkgs in the SDKIMAGE_FEATURES *all* the 
staticdev pkgs should end up in the SDK (I assume), but you need to use 
TOOLCHAIN_TARGET_TASK_append = " fmt-staticdev" for the .a file to show 
up in the SDK.


You use a cmake project and try to build https://github.com/fmtlib/fmt.

Regards,

Robert



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

Re: [yocto] static libraries missing from sdk

[Robert Berger]

Hi,

On 2018-02-07 09:46, Mircea Gliga wrote:

Thanks for your answer.
I already have the ALLOW_EMPTY_${PN} = "1" in the recipe

What I still don't get is why the -dev gets installed but the -staticdev 
doesn't, even though the dependency is satisfied (the empty pkg exists).




Just to understand what you are trying to do:

Would like to have both .a and .so files for your library in your SDK?

What should be on the rootfs? I guess the .so

You can check the contents of your packages with:

oe-pkgdata-util list-pkg-files -p 

How do you build your stuff? autotools?

I needed to do the following in my recipe with autotools:

# By default EXTRA_OECONF is set to --disable-static ...
# Let's get rid of this
DISABLE_STATIC = ""
EXTRA_OECONF := "${@oe_filter_out('--disable-static', '${EXTRA_OECONF}', 
d)}"

# enable static and disable shared (for fun)
EXTRA_OECONF += "--enable-static --enable-shared"



I added this to local.conf:

# -->
IMAGE_INSTALL_append = " libhw-so-a"
# add libhw-so-a-dev and libhw-so-a-staticdev to SDK:
TOOLCHAIN_TARGET_TASK_append = " libhw-so-a-staticdev libhw-so-a-dev"
# <--

That's the content of the packages produced:

libhw-so-a:
/usr/lib/libhw.so.0
/usr/lib/libhw.so.0.0.0
libhw-so-a-dbg:
/usr/lib/debug/usr/lib/libhw.so.0.0.0.debug
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw1.c
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw2.c
libhw-so-a-dev:
/usr/include/lib_hw.h
/usr/lib/libhw.so
libhw-so-a-staticdev:
/usr/lib/libhw.a

in the rootfs:

./usr/lib/libhw.so.0
./usr/lib/libhw.so.0.0.0

in the SDK:

./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.a
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0.0.0
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/include/lib_hw.h

Can you cook up an example where we can see/reproduce your problem?



Regards,

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

Re: [yocto] static libraries missing from sdk

[Robert Berger]

Hi,

On 2018-02-06 14:53, Mircea Gliga wrote:

Hello,

I have a problem providing a static library in the SDK:
I have a recipe that builds a library. It outputs an -dev pkg with the 
/usr/{include,lib} libs in it and a -staticdev pkg with the static library.
The main pkg is empty, in my recipe I have added ALLOW_EMPTY_${PN} = "1" 
because the -dev and -staticdev depend on it


In my local.conf I have added:
     SDKIMAGE_FEATURES += "dev-pkgs dbg-pkgs staticdev-pkgs"

Then I run
     bitbake my-image -c populate_sdk
After installing the SDK, I get the headers (from the -dev pkg) but not 
the static library from the -staticdev pkg.


Why is that ? From my understanding specifying staticdev-pkgs in the 
SDKIMAGE_FEATURE should have this covered.


I was able to "force" the install of the -staticdev pks by adding to 
local.conf:


     TOOLCHAIN_TARGET_TASK_append = " mylibrary-staticdev"

Do you have to manually take care of this ? Then, what's the purpose of 
SDKIMAGE_FEATURES += " staticdev-pkgs" ?

I would like to  have all static libraries in the SDK.

Thanks and regards


This sounds like:

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







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

[yocto] [PATCH] poky: LICENSE in packagegroup makes no sense - removed

[Robert Berger]

Signed-off-by: Robert Berger 
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb

index 2ca6392..aee4a03 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -4,7 +4,6 @@
  SUMMARY = "Host packages for the standalone SDK or external toolchain"
 PR = "r12"
-LICENSE = "MIT"
  inherit packagegroup nativesdk
 -- 2.7.4

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

[yocto] more efficient debug kernel

[Robert Berger]

Hi,

I usually build a debug kernel with debug info included, which makes it 
run "suboptimal". Distros build the kernel with CONFIG_DEBUG_INFO 
enables, but strip symbols out of the resulting kernel and kernel 
modules, and place them in the separate debuginfo packages. This makes 
the kernel much smaller and also makes it run more efficiently because 
of caching.


Is this possible with the Yocto kernel tooling as well?

Regards,

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

[yocto] minimize size of SW update bundle

[Robert Berger]

Hi,

Imagine you have only a limited bandwidth to your devices available for 
SW update. So you would like to minimize what's uploaded (over the air) 
to your devices.


How would you do this with yocto?

[1] and [2] might be able to do incremental updates, but maybe there are 
more ideas out there.


Like how would you get a diff between two release builds...

[1] https://wiki.yoctoproject.org/wiki/Meta-swupd
[2] https://github.com/advancedtelematic/meta-updater

Regards,

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

Re: [yocto] image dependent pkg versions/pkg variations

[Robert Berger]

Hi,

On 2017-10-16 20:54, Andre McCurdy wrote:


[1]
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations


Good luck!


Hehe you don't seem to be convinced that this works;)

Regards,

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

Re: [yocto] image dependent pkg versions/pkg variations

[Robert Berger]

Hi Andy,

On 2017-10-12 01:08, Andre McCurdy wrote:


What would you suggest?


Create additional variants of the machine config to cover each case,
e.g. myboard.conf, myboard-debug.conf, myboard-dummy.conf, etc

The -debug, -dummy, etc variants can include the original base version
of the machine config file, so there doesn't need to be any
duplication.



Thanks, I thought about this as well, but since it's actually the same 
board I would like to avoid encoding it in the MACHINE this way.


Anyhow, following this idea I was told that there is also something like 
this[1].


So maybe something like this could work:

bitbake \
multiconfig:customerA:stable-image \
multiconfig:customerA:bleeding-image \
multiconfig:customerB:stable-image \
multiconfig:customerB:bleeding-image

where it would be the same MACHINE, but different images and package 
versions, which could be defined in the configs.


[1] 
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations


Regards,

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

[yocto] image dependent pkg versions/pkg variations

[Robert Berger]

Hi,

I would like something like this:

1) Produce just a single toolchain like

2) Choose packages depending on image recipe

So far so good. This should be pretty standard, but

3) Different package versions depending on the image recipe?
Well actually I would like to have root file systems with different 
recipe versions inside

e.g.
Customer 1: prg1_1.1.bb, prg2_2.2.bb
Customer 2: prg1_1.2.bb, prg2_2.1.bb

4) Different package variants (e.g. extra compile flags) depending on 
the image recipe? Again different content of rootfs.

e.g.
Customer 3: prg1_1.1.bb (default), prg2_2.2.bb with extra CFLAGS=-DUMMY)
Customer 4: prg1_1.2.bb (default), prg2_2.1.bb(default)

===

Is this possible at all?

I could define per distro image versions, but the name of the distro 
e.g. "poky" seems to be part of the compiler prefix, which is not nice 
and I would need to build the same toolchain multiple times, which again 
is not nice.


If the choice is based on e.g. the distro variable I could use it to 
distinguish in the recipes between different build variations, but again 
not nice.


What would you suggest?

Regards,

Robert



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

Re: [yocto] [meta-xilinx] How to include Xilinx DMA driver

[Robert Berger]

Hi,

On 2017-09-08 19:00, Fan Zhang wrote:

Hi All,
 
1. How to include xilinx_dma.c driver in to the poky image build?


In case you want to include out-of tree drivers it could work like 
this[1] in case you want in-tree it's just a kernel patch similar to[2].


Apparently you will need to turn on kernel config features. You might 
try something like this[3].


For Yocto/Xilinx specific questions you might want to ask on the Xilinx 
mailing list[4].


[1] 
https://github.com/RobertBerger/meta-mainline/tree/pyro-training-v4.9.x/multi-v7-ml/recipes-zedboard/xilinx-dma


[2] 
https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/patch/4.9.x/patches/zedboard-zynq7/zynq-qspi/0001-zynq-zedboard-non-mainline-qspi-support.patch


[3] 
https://github.com/RobertBerger/meta-mainline/tree/pyro-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/features/zynq-qspi


[4] https://lists.yoctoproject.org/listinfo/meta-xilinx

Regards,

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

Re: [yocto] How do you build 2 versions of the same recipe and a specific version from bitbake cmd line

[Robert Berger]

Hi,

On 2017-07-14 23:32, Robert Joslyn wrote:


Just to clarify, the typical way this is done is to put the major
version number as part of the package name. For example, the recipes
could be called zeromq3_3.2.2.bb and zeromq4_4.1.5.bb. This assumes
zeromq can tolerate having multiple versions installed at the same
time.

Robert



I did not try but I think in the meantime we can have the same package 
with different versions in the same image.


The docu says about (run time dependencies) RDEPENDS:

"BitBake, which the OpenEmbedded build system uses, supports specifying 
versioned dependencies. Although the syntax varies depending on the 
packaging format, BitBake hides these differences from you."[1]


[1] 
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-RDEPENDS


What's unclear to me is how this works with build time dependencies 
DEPENDS? I guess somewhere you need to say that you want to link against 
version 3.2.2 for one package and against 4.1.5 in another package and 
since it looks like DEPENDS doesn't contain versioned dependencies I 
guess you need to work with names like zeromq3_3.2.2.bb and 
zeromq4_4.1.5.bb.


Is this the case?

Which in turn makes me wonder what's the use case for RDEPENDS and 
versioned dependencies.



Regards,

(Another) Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Determining Load Addresses

[Robert Berger]

Hi,

On 2017-07-12 08:23, Kenny Koller wrote:
I'm trying to piece together the various load addresses used in the boot 
sequence. I have built core-image-minimal for a Beaglebone. How can I 
determine which load address and entry point is used when mkimage is 
called for the kernel? Should I dig in to the recipe? Search some log 
files? I've tried a few difference things without results.


You don't need to bake a board specific address into uImage.

Like this you could create an uImage without a baked in address. Check 
here between lines 98 and 112


https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/multi-v7-ml/conf/machine/multi-v7-ml.conf#L98




Thanks.




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

Re: [yocto] setting groups and users other than root

[Robert Berger]

Hi,

On 2017-07-06 08:01, Khem Raj wrote:


you can achieve it via already defined abstraction. Please read
http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#ref-classes-useradd


You might want to read[1] "user and group configuration to be applied at 
the image level" as well


[1] 
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-extrausers


Regards,

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

[yocto] minimal image without GPLv3

[Robert Berger]

Hi,

I am yocto-izing people again and someone asked how to build a minimal
Yocto image without GPLv3 components.

I said like this[1]

1. Comment out the EXTRA_IMAGE_FEATURES line
2. Set INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"

... and indeed a core-image-minimal was built with alternative packages
like busybox instead of bash ...

but it did not run on qemu due to some kernel issues.

I did not investigate it further, but is this s known problem?

Regards,

Robert


[1]
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-images...Programming
today is a race between software engineers striving to build bigger and
better idiot-proof programs, and the Universe trying to produce bigger
and better idiots. So far, the Universe is winning.

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


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

[yocto] empty packages

[Robert Berger]

Hi,

According to [1]:

"By default, BitBake does not produce empty packages."

This does not seem to be the case at least for Jethro.

If I bitbake something like this[2] for qemuarm I see empty packages
like e.g. the -dev package.

Now it's getting even more interesting.

[3] says:

The list of packages to be created from the recipe. The default value is
the following:

${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
${PACKAGE_BEFORE_PN} ${PN}

... but ...

a non empty -dbg package is being built
an empty -dev package is being built
no -locale package is being built

Is this expected behavior? If yes please explain.

Regards,

Robert


[1]
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-ALLOW_EMPTY
[2]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/documentation/ref-manual/examples/hello-single/hello.bb
[3]
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGES..."The
three principal virtues of a programmer are Laziness, Impatience, and
Hubris." - Larry Wall

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


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

[yocto] custom internal toolchain/glibc

[Robert Berger]

Hi,

I was wondering what's the process if someone wanted to use, say Jethro
or Krogoth, but with different/custom versions of gcc, binutils, glibc
e.g. to cook some syscalls and to compile ancient Linux kernels.

I came across tcmode-default.inc[1] where such things are defined:

GCCVERSION ?= "6.1%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.26%"
GDBVERSION ?= "7.11%"
GLIBCVERSION ?= "2.24"
UCLIBCVERSION ?= "1.0%"
LINUXLIBCVERSION ?= "4.4"

Would hacking/duplicating and hacking this be a good starting point?

With TCMODE I could get poky to pick up some external toolchain, but I
would like it to build a custom one instead.

Please advise.

Thanks,

Robert

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/tcmode-default.inc..."My
employer doesn't even agree with me about C indentation style." - Used
as a disclaimer

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


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

[yocto] baremetal cross-compiler

[Robert Berger]

Hi,

According to the release notes it should be possible to build a
baremetal (no glibc/Linux) cross compiler with the YP. I just can't find
any information how this could be done.

I would like to build a native compiler e.g. for a Cortex-A3 and compile
FreeRTOS with it.

Please advise,

Robert
..."The pure and simple truth is rarely pure and never simple." - Oscar
Wilde

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


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

Re: [yocto] How to include a own libary into the toolchain(SDK) for an embeeded Linux generated by Yocto?

[Robert Berger]

Hi,

On 05/31/2016 06:03 PM, s.jar...@esa-grimma.de
wrote:> Hej,
>
> I am looking for an example where is shown how to include an own library
> into the toolchain.
>
> Let's call the library "myLib". For it I created an recipe "myLib.bb"
> and added:
>
> BBCLASSEXTEND = "native nativesdk"

Like this you can build a myLib-native (for your host - x86) version and
it should be added as an x86 library to your nativesdk.

see:

http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-BBCLASSEXTEND

>
> In my "local.conf" I added:
>
> IMAGE_INSTALL_append = " myLib"
>
> When building the SDK by:
>
> $ bitbake myTarget -c populate_sdk
>
> It produces a installer for the SDK and two manifest files. "myLib" is
> only included at the target manifest and not on the host. How can I
> include myLib on the host system?

Do you want myLib-native?

>
> The idea is, that a other person can build software on his system
> without the Yocto system. Only by using the toolchain he can generate
> binaries, which can be transferred and executed at the evalboard.

I guess you want something else. You want e.g. the ARM library myLib in
your sysroot plus maybe header files.

What happens if you create a recipe like a testcase for your library
which DEPENDS_append = " myLib" and then you IMAGE_INSTALL_append = "
myLib testmyLib", rebuild the image and populate_sdk?

>
>
> Regards!

Regards,

Robert

>
> PS: I put the question on stackoverflow:
>
http://stackoverflow.com/questions/37548851/how-to-include-a-own-libary-into-the-toolchainsdk-for-an-embeeded-linux-genera
>
>
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If
> you are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
>
>
> --
>

...To go faster, slow down. Everybody who knows about orbital mechanics
understands that.- Scott Cherf

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


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

Re: [yocto] docs: standardizing on "+=" versus "_append" for clarity

[Robert Berger]

Hi,

On 05/04/2016 02:20 PM, Robert P. J. Day wrote:>
> i understand that there are times when you *want* _append to delay
> processing until the end, and i understand that conditional appending
> with OVERRIDES requires the "_append" syntax, but other than these
> special cases, is there an encouraged standard to use "+=" if either
> syntax will do?

That's my understanding:

_append (override style syntax):

append without spaces,
differs from :=,.=,=.,+=,=+ because assignment is deferred until after
parsing,
can be used with executable meta data

.= :

appending without spaces, immediate assignment

+= :

appending with spaces, immediate assignment

All of them have left and right hand side variable expansion recursive
when used.


>
> rday
>

Regards,

Robert
..."C++ is an horrible language" - Linux Torvalds

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


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

Re: [yocto] upgrade daisy -> jethro

[Robert Berger]

Hi,

On 03/23/2016 10:17 AM, Ruben Schwarz wrote:
> Hi,
> 
> we have a customized board with Texas Instruments AM335x Processor. It's
> based on Beaglebone Black and EVM Starter Kit.
> 
> We have a working yocto-daisy image running U-Boot 2013.07 and Kernel
> 3.14. No we want to upgrade to jethro, including U-Boot 2015.07 and
> Kernel 4.1.

Why don't you get a beagle bone black and retry there?

Like this it would be easier to help, since we don't have your custom board.

I use a 4.4.x kernel with the mainline device tree am335x-boneblack.dtb
which works as well for a 4.1.x kernel.

Regards,

Robert
...WANTED: Schroedinger's Cat. Dead or Alive.

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


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

[yocto] CONFIG_LATENCYTOP fragment

[Robert Berger]

Hi,

That's what I currently use:

meta-yocto-bsp= "heads/jethro:347347ad78c4c2502e83f2c2adff61f1ba8fed8b"
multi-v7-ml   =
"heads/jethro-training-v4.1.x:e297c4f7c1baf38faecd6a2fcaa4cab0acea7dc1"

The idea is to use a stable kernel + multi_v7_defconfig and add to this
patches/configuration fragments.

I can add like this ikconfig, oprofile, posix_mqueues[0], but I don't
manage to get CONFIG_LATENCYTOP on top of multi_v7_defconfig.

In order to produce the config fragments I do:

bitbake linux-yocto-custom -c menuconfig

There I do my adjustments (disable SMP and enable LATENCYTOP)

bitbake linux-yocto-custom -c diffconfig, which spits out a
configuration fragment[1]

I did a new KTYPE[2][3] which seems to be picked up:

cat log.do_patch
DEBUG: Executing shell function do_patch
[INFO] validating against known patches  (multi-v7-ml-not-smp-deb-meta)
   mark --> multi-v7-ml-not-smp-deb.scc
   mark --> not-smp-deb.scc
   mark --> latencytop.scc
   mark <-- latencytop.scc
   mark <-- not-smp-deb.scc
   mark <-- multi-v7-ml-not-smp-deb.scc
   mark --> patch_marker.scc
   mark <-- patch_marker.scc
   mark -->
gen_tmpyocto-autobuilderyocto-autobuilderyocto-workercustom-jethro-multi-v7-core-image-minimal-sato-sdk-adtbuildbuildtmpworkmulti_v7_ml-poky-linux-gnueabilinux-yocto-custom4.4-rc5-custom-ml-not-smp-deb+gitAUTOINC+9f9499ae8e-r0_desc.scc
   mark <--
gen_tmpyocto-autobuilderyocto-autobuilderyocto-workercustom-jethro-multi-v7-core-image-minimal-sato-sdk-adtbuildbuildtmpworkmulti_v7_ml-poky-linux-gnueabilinux-yocto-custom4.4-rc5-custom-ml-not-smp-deb+gitAUTOINC+9f9499ae8e-r0_desc.scc
   mark --> multi-v7-ml-user-patches.scc
   mark <-- multi-v7-ml-user-patches.scc

<=== processed .meta/cfg/scratch/multi-v7-ml-not-smp-deb-meta in 0 seconds
DEBUG: Shell function do_patch finished

... but SMP is still on.

What's the trick?

Regards,

Robert

[0]
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/features

[1]
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/features/latencytop

[2]
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/ktypes/not-smp-deb

[3]
https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-common/bsp/multi-v7-ml/multi-v7-ml-not-smp-deb.scc..."Software
is like sex, it's better when it's free"

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


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

Re: [yocto] in-tree defconfig

[Robert Berger]

Hi,

This seems to do the trick:

https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/linux-yocto-custom.inc

Regards,

Robert



..."The scientific name for an animal that doesn't either run from or
fight its enemies is lunch." - Michael Friedman

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


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

[yocto] in-tree defconfig

[Robert Berger]

Hi,

What I wanted to do is to start from an in-tree defconfig like
multi_v7_defconfig instead of a defconfig file in a kernel recipe (which
works).

Maybe we have a different definition of an in-tree defconfig file, but
what I mean is the output of make multi_v7_defconfig, I guess what you
mean is arch/arm/configs/multi_v7_defconfig without running make on it.

After stripping blank and commented lines and sorting everything the
difference is:

-rw-rw-r-- 1 student student 14K Dec  9 22:16
KBUILD_DEFCONFIG-stripped-1-sorted
-rw-rw-r-- 1 student student 42K Dec  9 22:14
make-multi_v7_defconfig-stripped-1-sorted

... and the stuff built with KBUILD_DEFCONFIG does not boot ...

So my question is:"Is there a way to tell the kernel build system to run
make multi_v7_defconfig and use this as a base configuration where
patches and configurations will be added later on?"

If so can you see anything I am obviously doing wrong?

I tried this:

# SRC_URI += " \
# file://defconfig \
# "

+# Let's try an in-tree defconfig:
#KERNEL_DEFCONFIG_multi-v7-ml ?= "multi_v7_defconfig"
KBUILD_DEFCONFIG_multi-v7-ml ?= "multi_v7_defconfig"

with the kernel recipe of my meta-layer[1]

That's the meta-layer[2].

Regards,

Robert

[1]
https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/linux-yocto-custom.inc
[2]
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.1.x/multi-v7-ml


..."What I look forward to is continued immaturity followed by death." -
Dave Barry

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


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

Re: [yocto] VFAT patent EP 0 618 540

[Robert Berger]

Hi

On 10/09/2015 11:20 PM, Ayoub Zaki wrote:
> TI Socs Boot Rom code can use Vfat but does not necessarly need it as
> Bootloaders (spl, u-boot) can be loaded directly  from Raw MMC/eMMC.

I just discovered this recently. Something like:

sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k

So even my made up scenario where you would need vfat on the first
partition does not hold anymore.

... but ...

what about the patent and the on-chip ROMs of SoCs from Ti and Freescale
(hmm NXP? or whoever bought them lately). Maybe the SoCs are affected
since they are able to load stuff from vfat, even if we don't need to
use this feature anymore.

Regards,

Robert

..."Never express yourself more clearly than you think." - Niels Bohr

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


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

Re: [yocto] VFAT patent EP 0 618 540

[Robert Berger]

Hi,

On 10/09/2015 10:58 PM, Christian Ege wrote:
> A decent U-Boot can load the kernel from ext4. And I do not know any ROM
> loader which needs vfat, except maybe this TI SOCs...

Yep that's what I mean. The on-chip loader, which loads MLO,...

Anyhow I tried to come up with a scenario where someone might possibly
want to use vfat.

> 
> Regards,
> Christian

Regards,

Robert

..."Engineering is a science of tradeoffs" -- Yale Patt (computer
architecture guru)

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


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

Re: [yocto] VFAT patent EP 0 618 540

[Robert Berger]

Hi,

On 10/09/2015 11:36 AM, Gorny Krystian wrote:
> Hi,
> 
> I have a question regarding the VFAT patent (EP 0 618 540) owned by
> Microsoft. It’s about common name space for long and short filenames. I
> have read that this patent was canceled by Germany / EU, but it’s still
> available in the US right? So is there a patch/option where we can
> activate to avoid this patent?

I am not a lawyer, but wouldn't it be easier not to use VFAT?
The only reason I would use it, would be because the bootloader of my
SoC would only be able to boot over FAT/FAT32 from a managed flash. A
patch will not help here as well;)

There are rumors that a fix was implemented a long time ago[1] ;)

> 
> Thanks
> 
> Krystian
> 

Regards,

Robert


[1]
http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/

> 
> Legal information:
> Wipotec Wiege- und Positioniersysteme GmbH
> HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner
> 
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in
> error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
> 

Since you are concerned about legal issues you might also want to remove
this footer when posting to public lists ;)

> 
> -- 
> 

..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
only): Don't do it yet." - M.A. Jackson (not the singer)

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


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

Re: [yocto] can any one please tell the difference between DEPENDS and RDEPENDS

[Robert Berger]

On 10/07/2015 09:10 AM, Vivek Per wrote:
> Hi,
>  Can any one please tell the what is the exact difference between
> DEPENDS and RDEPENDS . 

DEPENDS:
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DEPENDS

RDEPENDS:
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-RDEPENDS

> I am not able to get it . How these variables are
> exactly parsed.
> 

Do you need more info?

> 
> regards
> vivek
> 
> 
> -- 
> 

Regards,

Robert


...No matter what the problem is,it's always a people problem.- Jerry
Weinberg

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


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

[yocto] core-image-minimal + ARCHIVER_MODE[src] = xxx

[Robert Berger]

Hi,

With poky 1.8 I try to generate files for license compliance.

=

add to local.conf:

INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"

seems the only case which builds.

=

I would like to use

ARCHIVER_MODE[src] = "configured"

and get:

NOTE: Preparing RunQueue
ERROR: Task do_ar_configured in
/tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/custom-fido-phyboard-wega-am335x-1-core-image-minimal/build/meta/recipes-devtools/gcc/gcc-source_4.9.bb
depends upon non-existent task do_configure in
/tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/custom-fido-phyboard-wega-am335x-1-core-image-minimal/build/meta/recipes-devtools/gcc/gcc-source_4.9.bb

=


with:

ARCHIVER_MODE[src] = "patched"

I get:

different issues, looks like race conditions in the build.
Need to investigate this further.

=

Am I missing something?
Does anybody else see similar issues?

Regards,

Robert..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
only): Don't do it yet." - M.A. Jackson (not the singer)

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


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

Re: [yocto] gcc reports sysroot is /not/exist!

[Robert Berger]

Hi,

I had a similar problem with you, but was able to fix it by replacing in
some global makefile:

CXX=${CROSS_COMPILE}g++
CC=${CROSS_COMPILE}gcc
LINKER=${CROSS_COMPILE}gcc
LOADER=${CROSS_COMPILE}ldd

with:

#CXX=${CROSS_COMPILE}g++
#CC=${CROSS_COMPILE}gcc
#LINKER=${CROSS_COMPILE}gcc
LINKER=$(CC)
#LOADER=${CROSS_COMPILE}ldd

Regards,

Robert
..."Whereas Europeans generally pronouce my name the right way (Ni-klows
Virt), Americans invariably mangle it into 'Nickle-less Worth'. This is
to say that Europeans call me by name, but Americans call me by value."
-- Niklaus Wirth

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


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

Re: [yocto] dropbear is not working after including in IMAGE_FEATURES

[Robert Berger]

On 09/10/2015 05:17 PM, Vivek Per wrote:> Hi,
>   I have included IMAGE_FEATURES += "ssh-server-dropbear" in my
> recipe image. and created the image.

So you have something like:

image-features-image.bb with something like this?

-->

IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended"

IMAGE_FEATURES += "debug-tweaks splash x11-base ssh-server-dropbear \
   package-management x11-sato"

inherit core-image

<--

> But after flashing the image i was not able to connect to target using
> ssh from my host machine. but target to host is working fine. Can any
> one tell me why it is not working. Is there any package need to add?

check your IMAGE_FEATURES if it's really like you want it:

bitbake -e image-features-image | grep ^IMAGE_FEATURES=

I see something like this:

IMAGE_FEATURES="debug-tweaks splash x11-base ssh-server-dropbear
package-management x11-sato"

You might want to check if dropbear made it into your image with
something like this before flashing it:

bitbake -g image-features-image && cat pn-depends.dot | grep -v -e
'-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' |
sort | uniq

This will give you a list and you should find something like:

"dropbear"


"packagegroup-core-ssh-dropbear"

>
>
> Thanks and Regards
>
>
> --
>

Regards,

Robert..."Whereas Europeans generally pronouce my name the right way
(Ni-klows Virt), Americans invariably mangle it into 'Nickle-less
Worth'. This is to say that Europeans call me by name, but Americans
call me by value." -- Niklaus Wirth

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


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

Re: [yocto] gdb/gdbserver vs. eclipse

[Robert Berger]

On 09/05/2015 09:12 PM, Rudolf J Streif wrote:
> Robert,
> 
> What version of Poky/OpenEmbedded Core (meta) are you using?

I am on the fido branch commit b50596d8f6e858e2e733f2d9913a19c6f3cd5863

plus

my own meta layer (which pulls in a 4.1.2 kernel with my own config) and
I build a core-image-sato-sdk image plus those extras:

EXTRA_IMAGE_FEATURES_append = " debug-tweaks tools-debug tools-sdk
eclipse-debug tools-profile dbg-pkgs"
IMAGE_INSTALL_append = " kernel-vmlinux lttng-tools lttng-modules lttng-ust"
DISTRO_FEATURES_append = " pam"
PACKAGE_DEBUG_SPLIT_STYLE = "debug-file-directory"


> 
> I found that including Fido (1.8) the tcf-agent built by meta was stuck at 
> version 0.4.0. That causes issues with running on the target and getting the 
> console output back to Eclipse. That's now updated to 1.3 in master for 
> Eclipse Mars. I built 1.2 for Luna which works, but 1.3 works with Luna too.
> 
> Cheers,
> Rudi
> 

Regards,

Robert

..."Pascal, at least in its standard form, is just plain not suitable
for serious programming." -- Brian W. Kernighan

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


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

Re: [yocto] gdb/gdbserver vs. eclipse

[Robert Berger]

Hi,

On 09/05/2015 07:17 PM, Rudolf J Streif wrote:>>
> I do not have to do that. As a matter of fact the executable on my
target is
> copied to /usr/bin from the Eclipse workspace. See "Remote Absolute
File Path"
> in the Debug Configuration.

You are right. I erased the other folder on my target, moved it there as
well and it still works.

>
>
>> 2) .gdbinit
>>
>> I copied my gdbinit on the host to
>>
>> /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
>>
>
> Yes, that's where Eclipse's Debug Configuration expects it if you do
not change
> the setting of "GDB Command File" in the Main subtab of the Debugger
tab in
> the Debug configuration.

...

>
>
> Yes, looks like mine except that my target is a MinnowBoard Max and I
> installed my SDK in a different location.

Hmmm

>
>
>> 3) Once you enter the debug view you need to go to the gdb console and:
>>
>> source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
>>
>
> Strange. I don't have to do that if GDB command file is set to the
path in the
> workspace.

Seems to work as well without sourcing ;)

> I would expect that Eclipse passes the .gdbinit from the workspace
> explicitly to GDB. However, I do have
>


> add-auto-load-safe-path .
>
> in my global .gdbinit (~/.gdbinit).

.gdbinit loads automatically for me now, I don't need to source and also
no add-auto-load-safe-path

Which Yocto version do you use? I use 1.8

>
> Cheers,
> Rudi
>

So let's try to summarize what seems to be necessary:

1) right .gdbinit on the right place ;)
2) Debug Configurations -> Debugger -> Main -> Use full file path to set
breakpoints (might not even be necessary)
3) Debug Configurations -> Debugger -> Shared Libraries -> Load shared
library symbols automatically

Regards,

Robert
..."A successful tool is one that was used to do something undreamed of
by its author." - S. C. Johnson

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


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

[yocto] gdb/gdbserver vs. eclipse

[Robert Berger]

Hi,

I managed to step form HelloWorld into the C library and friends with a
.gdbinit file like this:

# don't use default libs from x86/Ubuntu:
set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-search-path  /opt/adt-target-sysroot/beagle-bone-black-ml
# point to the libraries with debug info:
set debug-file-directory
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug
# point to the source code:
set substitute-path /usr/src/debug
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
set substitute-path /
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
# connect to target:
target remote 192.168.42.11:
# set some breakpoints:
b main
b 32

When I try to do the same thing with Eclipse luna and the Eclipse plugin
it can not find the sources.

I am able to debug a hello world program with Eclipse, but when I step
into the C library I only see assembly code.

What magic is Eclipse doing?

Shouldn't .gdbinit work as well with Eclipse?

Regards,

Robert..."Software development is like making a baby... You can't make a
baby in one month by impregnating nine women."

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


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

[yocto] software upgrade - minimal amount of packages

[Robert Berger]

Hi,

Say I build a release with the YP and load this software onto some target.

Then I keep on developing, make changes and make another release.

At this point I would like to figure out the minimal amount of packages
required to install on the target in order to update it to the new release.

Could this be done with build history somehow? Did someone do something
like this before?

Regards,

Robert...If the code and the comments disagree, both are probably wrong.

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


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

Re: [yocto] Strange sstate problem

[Robert Berger]

Hi,

On 06/10/2015 10:58 PM, Gary Thomas wrote:
> I'm building for two similar targets and sharing sstate between
> them.  Actually, I build for target A and use that sstate cache
> in my SSTATE_MIRRORS for target B.

If I understand correctly what should happen, then SSTATE_MIRRORS should
point to some build machine, which populates SSTATE and other machines
pull from it.

something like:

SSTATE_MIRRORS ?= "file:///nfs/mount/sstate/PATH"

where PATH will be substituted.

So it looks like you do the right thing.

Is the sequence you do the following?

1) Build for target A (which is the SSTATE_MIRROR for target B)
2) After the build finished you build for target B using the shared
sstate from target A

> 
> If I try to build target B from scratch, i.e. wipe out most
> everything from my build tree:
>   % mv cache sstate-cache tmp old2; rm -fr old&
> I also have a PR server for each target - in local.conf:
>   PRSERV_HOST = "localhost:0"

I think that if you use a shared sstate whoever populates the sstate
should also use a central pr server.

something like:

bitbake-prserv --host  --port  --start on one machine
and instead of localhost:0 the :

In your case it should not matter, since only target A populates the
shared sstate, but you can give it a try.


> 
> When I build in target B, I'm getting a ton of QA errors, basically
> one for every package selected, e.g.
>   ERROR: QA Issue: Package version for package fsl-alsa-plugins went
> backwards which would break package feeds from (0:1.0.25-r0.2 to
> 0:1.0.25-r0.0) [version-going-backwards]
> 
> What could be going on here?
> 
> n.b. I'm using a fairly recent Poky/Yocto master
> (a05663bfa10352fd5af6ca9a9d7b323c1c099f35)
> 

Regards,

Robert

..."Software is getting slower more rapidly than hardware becomes
faster." - Niklaus Wirth, who attributed it to Martin Reiser.

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


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

Re: [yocto] multi-user shared state

[Robert Berger]

Hi,

On 06/10/2015 10:25 PM, Luke (Lucas) Starrett wrote:
> Hi,
> 
>  
> 
> I’m trying to understand the feasibility of shared-state across multiple
> users in a development environment.  Does anyone have first-hand
> experience with this?  Am I asking for trouble?

Have a look here [1] 3.2.1.2. Core System Development, and [2]

I did have troubles in the past. When I built e.g. for 2 different
boards both using the same compiler and the same sstate funny things
happened when 2 machines tried to work on the same package at the same
time. But everything should be fine as long as things work sequentially.
Don't know if the sstate mechanism works concurrently in the meantime.

> 
>  
> 
> If this is expected to work, a secondary question would be whether or
> not shared-state on a NFS mounted path works.  Any thoughts?

shared state works (and as a matter of fact everything on an nfs share
would work)

> 
>  
> 
> Thanks,
> 
>  
> 
> Luke Starrett 
> 
>  

[1] http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html
[2]
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#shared-state-cache
> 
> 
> 
> -- 
> 

Regards,

Robert

..."Teaching of beginners should be done by a master, not by a hack." -
Deming

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


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

Re: [yocto] fido: funny ipk behavior

[Robert Berger]

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


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

[yocto] fido: funny ipk behavior

[Robert Berger]

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


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

[yocto] How to properly add new qemu target + testimage support?

[Robert Berger]

Hi,

I hacked together a qemu target which supports vexpress-a9.

In order to get

core-image-minimal -c testimage

to work as well I had to cook

meta/lib/oeqa/utils/qemurunner.py
scripts/runqemu
scripts/runqemu-internal

This does not seem to be a generic way to do such a thing.

What's the proper way to do it?

Regards,

Robert ...To go faster, slow down. Everybody who knows about orbital
mechanics understands that.- Scott Cherf

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


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

Re: [yocto] Layer model doomed, unless we all work together

[Robert Berger]

Hi,

On 11/19/2014 05:19 PM, Philip Balister wrote:
> 
> http://layers.openembedded.org/layerindex/branch/master/duplicates/?l=91&l=123&l=30&l=147&l=168&l=148&l=31&l=65&l=66&l=32&l=124&l=164&l=67&l=149&l=77&l=101&l=118&l=33&l=3&l=34&l=142&l=169&l=35&l=137&l=171&l=139&l=108&l=162&l=81&l=82&l=95&l=125&l=145&l=146&l=114&l=4&l=36&l=68&l=140&l=83&l=132&l=5&l=154&l=120&l=84&l=6&l=93&l=112&l=7&l=37&l=167&l=38&l=8&l=98&l=39&l=165&l=40&l=105&l=69&l=9&l=10&l=110&l=107&l=11&l=12&l=13&l=14&l=41&l=15&l=99&l=151&l=170&l=85&l=42&l=43&l=113&l=159&l=16&l=78&l=92&l=103&l=157&l=97&l=119&l=70&l=152&l=153&l=71&l=126&l=115&l=136&l=44&l=45&l=163&l=17&l=102&l=150&l=46&l=18&l=19&l=79&l=2&l=138&l=174&l=20&l=21&l=128&l=129&l=130&l=131&l=47&l=104&l=48&l=135&l=22&l=173&l=121&l=23&l=160&l=49&l=106&l=24&l=50&l=117&l=143&l=87&l=51&l=52&l=25&l=133&l=116&l=53&l=72&l=122&l=73&l=54&l=55&l=172&l=88&l=109&l=56&l=57&l=100&l=26&l=155&l=90&l=58&l=144&l=59&l=60&l=74&l=61&l=75&l=158&l=134&l=62&l=111&l=27&l=76&l=28&l=141&l=1&l=64
> 
> Although that url might fail, you get the idea how to use the tool better :)

The url works for me;)

You just mention duplicated classes and recipes here, but there are more
things which should be cleaned up ;)

The worst thing about Yocto/poky/OE is, that people can do and do things
in many mysterious ways. Looking through various meta-layers you don't
see a "common coding style", which means that you either need to twist
your brain to understand what others did, or write things from scratch.

I guess we should first publish "best practices" and then try to enforce
them in a first step with maybe with something like "WARN_QA" and
"ERROR_QA" and/or extend oelint.

What do you think?

> 
> Philip
> 

Regards,

Robert


..."Stroustroup writes in the ARM: C programmers think that memory
allocation is too important to be left to the computer, Lisp programmers
think that memory allocation is too important to be left to the programmer."

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


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

Re: [yocto] Meta-toolchain, do_populate_sdk, packagegroup-cross-canadian problem

[Robert Berger]

Hi,

On 08/11/2014 08:45 AM, Lešek Franek wrote:
> ERROR: Logfile of failure stored in:
> /modemtec/linux/yocto-daisy/build-socfpga_cyclone5/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.12635

Did you check this file?

Regards,

Robert

...Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning.

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


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

Re: [yocto] Meta-toolchain, do_populate_sdk, packagegroup-cross-canadian problem

[Robert Berger]

Hi,

On 08/11/2014 08:45 AM, Lešek Franek wrote:
> ERROR: Logfile of failure stored in:
> /modemtec/linux/yocto-daisy/build-socfpga_cyclone5/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.12635

Did you check this file?

Regards,

Robert

...Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning.

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


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

[yocto] automated hardware testing

[Robert Berger]

Hi,

I just noticed this [1] and there are rumors that in the next release
hardware testing will also work with yocto-autobuilder.

I do have a couple of boards deployer in my lab and build with
autobuilder images for them.

The consoles of my boards are connected via conservers to ethernet and I
can also remotely switch on/off power.

For the beagle bone white the setup is more complex in order to press
the reset button remotely and turn on/off the power over the USB cable
remotely.

My goal would be to build something with autobuilder, deploy to a board
and run some tests.

Is this feasible with my current infrastructure?
Can someone please guide me in the right directions.

Regards,

Robert

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py...I
read the system requirements label on a software package recently. It
said "requires Windows NT or better". So I installed Unix. -- from a FAQ

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


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

Re: [yocto] [meta-raspberrypi] Problem building core-image-sato-sdk

[Robert Berger]

On 03/09/2014 02:08 PM, Federico Vitali wrote:
> Hi everyone,
> 
> I've succesfully build core-image-sato for raspberry pi, but when I try
> to build the sdk version I obtain the following error:
> 

BTW I get the error also with core-image-sato:

builder@ubuntu-srvr-lv:~/rpi/poky/raspberrypi/conf$ bitbake core-image-sato
Loading cache: 100%
|#|
ETA:  00:00:00
Loaded 1215 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.20.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi"
DISTRO= "poky"
DISTRO_VERSION= "1.5.1"
TUNE_FEATURES = "armv6 vfp"
TARGET_FPU= "vfp"
meta
meta-yocto
meta-yocto-bsp= "dora:98bd952a5b72c584fc1094e4a61eb9e2a24cc97b"
meta-raspberrypi  = "master:fbc0947e96e8989d46b1570619554cb916e24049"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Recipe mesa-gl is trying to create package libegl-mesa which was
already written by recipe mesa. This will cause corruption, please
resolve this and only provide the package from one recipe or the other
or only build one of the recipes.
ERROR: Function failed: read_subpackage_metadata
ERROR: Logfile of failure stored in:
/home/builder/rpi/poky/raspberrypi/tmp/work/armv6-vfp-poky-linux-gnueabi/mesa-gl/2_9.1.6-r0/temp/log.do_package_write_ipk.9838
ERROR: Task 2436
(/home/builder/rpi/poky/meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb,
do_package_write_ipk) failed with exit code '1'


..."To be or not to be... that is the question." - The answer is 0xff
since: 0x2b | ~0x2b = 0xff

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


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

Re: [yocto] [meta-raspberrypi] Problem building core-image-sato-sdk

[Robert Berger]

Hi,

On 03/09/2014 02:08 PM, Federico Vitali wrote:
> Hi everyone,
> 
> I've succesfully build core-image-sato for raspberry pi, but when I try
> to build the sdk version I obtain the following error:
> 
> ERROR: Multiple .bb files are due to be built which each provide
> virtual/libgles2
> (/home/vitalife/yocto/poky/meta-raspberrypi/recipes-graphics/userland/userland_git.bb
> 
> /home/vitalife/yocto/poky/meta/recipes-graphics/mesa/mesa_git.bb
> ).
>  This usually means one provides something the other doesn't and should.
> ERROR: Multiple versions of mesa are due to be built
> (/home/vitalife/yocto/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb
> 
> /home/vitalife/yocto/poky/meta/recipes-graphics/mesa/mesa_git.bb
> ). Only one version of a given PN should be built in
> any given build. You likely need to set PREFERRED_VERSION_mesa to select
> the correct version or don't depend on multiple versions.
> 
> What could be the problem? 

I hit the same problem and tried something like this [1] and
PREFERRED_VERSION_mesa ?= "9.1.6", but the problem persists.

Did you find a solution?

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/common/recipes-graphics/mesa/mesa_9.1.6.bbappend?h=dora

Regards,

Robert

> 
> Thank you in advance
> 
> Federico
> 
> 
> 
> -- 
> 

..."German programmers tend to take it as a personal insult when a fault
is detected in code that they have written." - Debora Weber-Wulff
webe...@tfh-berlin.de [comp.risks 16.94]

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


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

[yocto] fetcher from gitpod

[Robert Berger]

Hi,

I would like to fetch some get repos (currently u-boot and kernel) from
a local git caching server[1]. This means if something changed on
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
since the last invocations it updates the changes, if nothing changed it
provides the repo locally.

After setting up the right ssh keys not to ask for a password it works
like this:

git clone gp@gitpod:linux-stable.git
Cloning into 'linux-stable'...
fetching from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
remote: Counting objects: 3572381, done.
remote: Compressing objects: 100% (574164/574164), done.
Receiving objects: 100% (3572381/3572381), 752.89 MiB | 11.53 MiB/s, done.
remote: Total 3572381 (delta 3008721), reused 3531934 (delta 2968274)
Resolving deltas: 100% (3008721/3008721), done.

Should this somehow already work with existing fetchers, or do I need to
hack together my own fetcher?

Regards,

Robert

[1] https://github.com/sitaramc/gitpod..."The problem is never how to
get new, innovative thoughts into your mind, but how to get old ones
out." -- Dee Hock

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


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

Re: [yocto] u-boot 2013.10 LIC_FILES_CHKSUM points to an invalid file

[Robert Berger]

Hi Paul,

On 12/23/2013 10:56 PM, Paul Eggleton wrote:
>  
>> How do I get it to build?
> 
> In the absence of any other license statement, you'd have to point to one or 
> more of the source files and use beginline and endline to select just the 
> part 
> of the header specifying the license.

Thanks!

This might be tricky to know upfront in same cases and would in worst
case require different recipes with different license info since it
depends on what configuration you build for, or which files are being
included.

A mechanism to extract the relevant info from the executable is most
likely more accurate.

But I guess not we have a chicken and egg problem ;)

> 
> Cheers,
> Paul
> 

Regards,

Robert

..."My employer doesn't even agree with me about C indentation style." -
Used as a disclaimer

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


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

[yocto] u-boot 2013.10 LIC_FILES_CHKSUM points to an invalid file

[Robert Berger]

Hi,

I try to build instead of u-boot v2013.07 [1] the latest and greatest
released version i.e. v2013.10[2].

... which does not build because LIC_FILES_CHKSUM points to an invalid
file ...

... and yes it does, since the COPYING file is gone ...

The licencense info is contained in the source code itself as
SPDX-License-Identifiers.

How do I get it to build?

Regards,

Robert

[1]
http://git.denx.de/?p=u-boot.git;a=tree;h=63e74bc767dda75feff521c40b779018397fe1e7;hb=62c175fbb8a0f9a926c88294ea9f7e88eb898f6c

[2]
http://git.denx.de/?p=u-boot.git;a=tree;h=b6756a15fd1e165107adf57e7c4a393f7dbcba38;hb=183acb700378a8cfc5d50a01a65de93fb2c24586..."In
C++ it's harder to shoot yourself in the foot, but when you do, you blow
off your whole leg." - Bjarne Stroustrup

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


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

Re: [yocto] Embedded Linux with Xenomai support

[Robert Berger]

Hi,

On 08/30/2013 07:56 PM, Darren Hart wrote:

>> Is there any Linux distribution based on the Yocto project that lets
>> me configure my embedded kernel with Xenomai? If not, has anybody got
>> any experinece in adding Xenomai to the Yocto project? 
> 
> I am not aware of anyone using Xenomai with Yocto to date (although that
> doesn't mean nobody is). Our Real-Time focus has been on the PREEMPT_RT
> Linux kernel, which we do have recipes for.

googling for meta-xenomai reveals:

[1][2]

> 
> It appears as though Xenomai has changed quite a bit over the years. If
> my quick re-reading of their material is correct, the Xenomai core is
> implemented as a Linux kernel module which can built in to a standard
> Linux kernel?

... kind of ...

kernel space:

You need to apply a patch to a certain kernel version and configure the
kernel afterwards.

So for an ARM architecture there is a patch for the 3.8 kernel[3]

user land:

But unlike with preempt-rt you also need to build the Xenomai userland
stuff.

> 
> Out of curiosity, what sort of real-time requirements do you have?
> 

That's a good point. Shameless self promotion [4].

Regards,

Robert

[1] https://github.com/nojgosu/meta-xenomai
[2] https://github.com/DrunkenInfant/beaglebone-xenomai
[3]
http://git.xenomai.org/?p=xenomai-head.git;a=tree;f=ksrc/arch/arm/patches;h=c6045f00819318970d6bba65c397609052c9414e;hb=HEAD
[4] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf


..."A language that doesn't affect the way you think about programming
is not worth knowing." - Anonymous

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

Gary is, as usual, right ;)

Now I have the following test setup:

nfs server:

Ubuntu 12.04.2 LTS server

 *(sync,insecure,rw,no_root_squash)

client:

:   nfs
auto,noatime,nolock,intr,tcp,actimeo=1800 0 0

mkdir -p /${HOSTNAME}/manual-build/

source oe-init-build-env /${HOSTNAME}/manual-build/

I build there happily (no patch to remove hard links):

bitbake core-image-minimal-dev
bitbake core-image-sato-sdk

Regards,

Robert
..."It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC; as potential programmers
they are mentally mutilated beyond hope of regeneration." - Edsger Dijkstra

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

On 08/20/2013 07:45 PM, lot...@denx.de wrote:
> 
> Hi,
>  I have just two points here to ask:
> 
> 1) Wouldn't simply using SSTATE_MIRRORS be a better solution here, instead?

It's not the same.

SSTATE and DL_DIR are on an nfs export anyhow and this works.

The problem here is with TMP dir (and an nfs server with a funny
underlying filesystem like UFS) and hard links.

> 
> 2) Patch: wouldn't it be nicer to try the cp -al, and catch the
> CalledProcessError Exception, if it is thrown, and then run the brute
> force cp -a? Perhaps even as a general approach?

In theory yes, in practice you will find out that if you build something
like core-image-sato-sdk "cp -al" is not the only place which creates
hard links.

Regards,

Robert
..."There's an infinite number of ways to make a simple problem seem
difficult; only a handful to make a difficult problem seem simple" -
Jack Crenshaw's Law #1

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

Just for the record I was able to remove the hard link with a small
patch and now things look good (so far) - although it will consume more
disk space.

diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
index faa0f61..3225993 100644
--- a/meta/lib/oe/path.py
+++ b/meta/lib/oe/path.py
@@ -90,7 +90,7 @@ def copyhardlinktree(src, dst):
 if not len(os.listdir(src)):
 return
 src = src + "/*"
-cmd = 'cp -al %s %s' % (src, dst)
+cmd = 'cp -a %s %s' % (src, dst)
 check_output(cmd, shell=True, stderr=subprocess.STDOUT)

 def remove(path, recurse=True):

Regards,

Robert
..."But I have a slowly coagulating theory that the size of a project is
directly proportional to the possibility that significant bugs will crop
up. Exponentiate for each additional programmer involved." - Steven K.
Halliburton

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


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

Re: [yocto] [Announcement] Yocto Project 1.5 Milestone 3 now available.

[Robert Berger]

Hi,

On 08/12/2013 12:44 PM, Paul Eggleton wrote:
> 
> There's not much on the autobuilder side apart from ensuring the appropriate 
> configuration is set - one of the aims was to avoid too much intrusion into 
> the 
> autobuilder code. The main class is testimage.bbclass, so you can just do 
> INHERIT += "testimage" in local.conf and then run bitbake -c testimage 
> . The tests are in meta/lib/oeqa/runtime/ and utility code under 
> meta/lib/oeqa/utils. 
> 
> There's no documentation for this yet other than what's in the code (and 
> there 
> are some comments there), but it's coming soon.

;)

I'll have a look at it.

Regards,

Robert


...A clever person solves a problem.A wise person avoids it.- Einstein

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


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

Re: [yocto] [Announcement] Yocto Project 1.5 Milestone 3 now available.

[Robert Berger]

Hi,

On 08/12/2013 12:28 PM, Paul Eggleton wrote:
> 
> I agree. In fact our test lab would probably be limited to the reference 
> boards that the Yocto Project officially supports within meta-yocto i.e. what 
> we 
> currently test on manually.

I have the Yocto reference boards as well, but will add boards on
customer request (some are already on the queue).

BTW what should be defined what kind of extra hardware/software is
needed for remote hardware testing. As I said I have some infrastructure
to power on/off boards and monitor the serial over conserver(s).

Is that's it?

Regards,

Robert
..."100% test coverage is insufficient. 35% of the faults are missing
logic paths." - Robert Glass

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


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

Re: [yocto] [Announcement] Yocto Project 1.5 Milestone 3 now available.

[Robert Berger]

Hi,

On 08/12/2013 02:30 PM, Björn Stenberg wrote:
> Paul Eggleton wrote:
>> Right, that's what we would be aiming for. Perhaps you could talk a little
>> bit about how you manage your hardware testing and any additional software
>> and scripts you make use of there?
> 
> We run our tests from buildbot, using an expect script 

I currently run my tests manually, but the plan was to implement
something in expect as well, since this seems to be made exactly for
this kind of stuff.

... but instead of something proprietary I would rather prefer to have a
generic solution where "the community" solves problems together with me.

> to allocate the right serial port (and wait if it is busy), fetch the built 
> files, unpack the rootfs to an NFS disk, reset the board, tftp the kernel and 
> dtb, boot the kernel and start the test suite.
> 
> A line-based timeout is used for for the test suites, meaning that the 
> timeout is reset for each new line of output. This allows us to handle very 
> long-running test cases while still being able detect hung tests rather 
> quickly.
> 
> Multiple images and test suites are built and ran in parallell, which is why 
> the script waits for the serial port. One of the test suites we run is 
> ptest-runner.
> 
> The output of all tests is parsed and stored in a database, cross-referenced 
> with the buildbot build info. We have written an extension to the buildbot 
> web interface presenting the test results as they relate to each build.
> 

Are your scripts available somewhere to give it a try? Do they integrate
into autobuilder?

Regards,

Robert




..."German programmers tend to take it as a personal insult when a fault
is detected in code that they have written." - Debora Weber-Wulff
webe...@tfh-berlin.de [comp.risks 16.94]

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


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

Re: [yocto] [Announcement] Yocto Project 1.5 Milestone 3 now available.

[Robert Berger]

Hi,

On 08/10/2013 01:02 PM, Paul Eggleton wrote:
> 
> The new framework replaces the old, is written in python and makes writing 
> tests much easier. As a result we are going through a process of adding many 
> more runtime tests than we had previously.

I'm confused now. Is it autobuilder + new stuff in python and/or ptest
or something completely different? Are there already some examples in
git I could have a look at?

> 
> 
> We do definitely want automated testing on real hardware; it's just that that 
> it presents a number of problems that need solving:
> 
>  * How do you deploy the image/kernel/bootloader onto the board in an 
> automated manner? 

I use kernel over tftp and rootfs over nfs. The trivial example of a
boot loader upgrade is when you have a running (Linux) system just scp
it over. It's getting non trivial in case you manage to screw up the
boot loader. For the generic case maybe some update strategy with a
fallback solution to a known good boot loader might be needed.

> To different kinds of boards?

kernel over tftp and rootfs over nfs should work with all boards.

>  * How do you manage access to the boards when you have multiple autobuilders 
> potentially wanting to make use of them at around the same time?

Mutual exclusive access to the (serial) console can be handled by
conserver. Mutual exclusive via ssh gets more tricky.

I don't think it makes much sense to access the same board from multiple
autobuilders. This is most likely an error case which you would like to
catch.

> 
> We'll be working through these but the likelihood is that we won't have this 
> part of it for 1.5. Once we do though, connecting the currently QEMU-based 
> testing framework to it should be trivial.

OK understood. Please keep me updated.

> 
> Cheers,
> Paul

Regards,

Robert

...If you think good architecture is expensive, try bad architecture -
Brian Foote and Joseph Yoder

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


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

Re: [yocto] [Announcement] Yocto Project 1.5 Milestone 3 now available.

[Robert Berger]

Hi,

On 08/10/2013 03:22 AM, Flanagan, Elizabeth wrote:
> * Infrastructure for automated QA testing. More testcases will be
> automated in the next milestone release.

Are we talking about test automation using autobuilder here?
As far as I can see runtime testing of images using QEMU is
planned/already used.

What I'm after is runtime testing on real hardware. Assuming an
infrastructure where you can remotely turn on/off the power of the board
and where you have access e.g. via a conserver to the serial port I
guess this should be possible as well.

I'm wondering why this seems to be limited to QEMU, am I missing something?

Regards,

Robert



..."The pure and simple truth is rarely pure and never simple." - Oscar
Wilde

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

On 08/08/2013 08:52 PM, Gary Thomas wrote:
> 
> I'm trying this now with my Ubuntu 12.04 laptop and the same NFS server.
> Looks like it's working just fine, it's already made it through the first
> phase of a fresh build (building all the necessary 'native' tools), so I
> think it will work as expected (it's way past where you had problems).
> I'll let it complete and report back if there were any problems.
> 
> n.b. building this way is glacially slow :-(
> 

So let's assume it's the nfs server. Can you please tell me what's the
file system on your nfs server and how you export it?

A possible problem is, that with nfs symbolic links are not followed by
default.

My problem might be that I use a FreeBSD based nfs server.

Maybe with something like ext3, ext4 it might work.

Also do you use dylan-9.0.1 or something more recent?

Regards,

Robert
..."Premature optimisation is the root of all evil" -- Knuth

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

On 08/08/2013 06:23 PM, Gary Thomas wrote:
>>
>> How you do this?
>>
>> Do you use some magic build setting for this or a symlink to the nfs?
> 
> 
> I used the standard setup script, like this:
>   % . /local/poky/oe-init-build-env /MY_NFS_VOLUME/build_dir
> 
> This will create a build tree on MY_NFS_VOLUME named 'build_dir'.  Then
> I adjusted /MY_NFS_VOLUME/build_dir/conf/local.conf as needed and ran
> bitbake...
> 
> Note: I NEVER build inside of my Poky/Yocto tree - always in a separate
> build directory and quite often on a separate file system.
> 

I just tried this and with Ubuntu 12.04.2 LTS it does __NOT__ work (as
expected). I'm really surprised that you can have
/MY_NFS_VOLUME/build_dir due to the fact that there are hard links
required between the /MY_NFS_VOLUME/build_dir and where your host Linux
rootfs resides.

So either we have a different NFS setup or cp -al behaves differently.

Do you happen to have an Ubuntu build machine to test? I'm currently on
the road so it's a bit tricky for me to try with Fedora.

Regards,

Robert



..."As far as I know we never had an undetected error." - Anonymous

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


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

Re: [yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

On 08/08/2013 05:53 PM, Gary Thomas wrote:
> 
> Interesting.  I'm building now - OEROOT on a local ext3 file system,
> build/tmp on NFS - and it's working just fine.  My host is Fedora (15).
> 

/poky
  /beagle-xm
/cache
/conf
/tmp<--- this /tmp?

How you do this?

Do you use some magic build setting for this or a symlink to the nfs?

Regards,

Robert
..."It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC; as potential programmers
they are mentally mutilated beyond hope of regeneration." - Edsger Dijkstra

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


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

[yocto] can not build yocto on NFS mounted NAS

[Robert Berger]

Hi,

I tried to build to build bitbake core-image-minimal-dev on some nfs
mounted NAS.

Pseudo is not present but is required, building this first before the
main build
Parsing recipes: 100%
|###|
Time: 00:00:20
Parsing of 819 .bb files complete (0 cached, 819 parsed). 1126 targets,
47 skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beagle-xm-ml"
DISTRO= "poky"
DISTRO_VERSION= "1.4.1"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp=
"beagleboard_dylan-9.0.1_LOCAL:73f103bf9b2cdf985464dc53bf4f1cfd71d4531f"

It fails pretty soon with:

ERROR: Error executing a python function in
/yoctotmp/manual-build/poky/meta/recipes-devtools/quilt/quilt-native_0.60.bb:
CalledProcessError: Command 'cp -al
/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sysroot-destdir/yoctotmp/manual-build/poky/beagle-xm/tmp/sysroots/x86_64-linux/*
/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sstate-build-populate-sysroot/x86_64-linux'
returned non-zero
 exit status 1 with output cp: cannot create hard link
`/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sstate-build-populate-sysroot/x86
_64-linux/usr/share/quilt/compat/awk' to
`/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sysroot-destdir/yoctotmp/manual-build/poky/beag
le-xm/tmp/sysroots/x86_64-linux/usr/share/quilt/compat/awk': Unknown
error 524

A bit of further digging reveals that underneath
/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sysroot-destdir/yoctotmp/manual-build/poky/beagle-xm/tmp/sysroots/x86_64-linux/*
we have a symbolic link to
/yoctotmp/manual-build/poky/beagle-xm/tmp/work/x86_64-linux/quilt-native/0.60-r0/sysroot-destdir/yoctotmp/manual-build/poky/beagle-xm/tmp/sysroots/x86_64-linux/usr/share/quilt/compat/awk
-> /usr/bin/gawk

Since hard links can not be made between different file systems (local
ext4 and nfs) the cp -al fails.

Is it like this by design, or should I file a bug in bugzilla?

Previous experiments (only SSTATE and DL from NFS/NAS) seem to work and
I guess that's also your autobuilder cluster setup.

Regards,

Robert
...Under a government which imprisons any unjustly, the true place for a
just man is also a prison. -- Henry David Thoreau

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


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

Re: [yocto] gcov on beagle-xm with kernel module

[Robert Berger]

Hi,

Looks like it's an issue with the arm eabi compiler producing code,
which the kernel gcov framework can't deal with.

I guess there are 2 options:

1) toolchain not eabi (not feasible)
2) patch gcov framework in kernel

Regards,

Robert
..."In the beginning, there was software. And it wasn't good."

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


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

[yocto] gcov on beagle-xm with kernel module

[Robert Berger]

Hi,

I still try to use gcov on the beagle-xm on a kernel module and I'm not
sure this is the right mailing list to ask.

I just build it with the following modification to the makefile:

GCOV_PROFILE_debugfs.o := y

and it builds;)

... but as soon as I try and insmod I get the following:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format

and dmesg says:
[ 1628.759552] debugfs: unknown relocation: 38

Did anyone see something like this before here?

Apparently I'm not the only one having this kind of problem:

http://old.nabble.com/Problem-with-applying-Gcov-tool-to-kernel-module-to28299744.html

Does this look like a compiler bug?

Regards,

Robert..."Never express yourself more clearly than you think." - Niels Bohr

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


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

Re: [yocto] gcov on target

[Robert Berger]

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

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


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

Re: [yocto] gcov on target

[Robert Berger]

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

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


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

Re: [yocto] gcov on target

[Robert Berger]

Hi Thomas,

On 01/11/2013 06:19 PM, Thomas Petazzoni wrote:
>> Did someone manage to build/run gcov for an armv7a?
>> ... or let's put it otherwise: Why doesn't it exist on the target?
>
> I supposed the idea is to generate to coverage data on the target, and
> then analyze them with gcov on the build machine. See
>
http://gcc.gnu.org/onlinedocs/gcc/Cross_002dprofiling.html#Cross_002dprofiling.

Yes this should work. Thanks!
It's also documented in the kernel source tree [1].

>
> Best regards,
>
> Thomas
>

[1]:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=Documentation/gcov.txt;h=e7ca6478cd93d4e6422d1ae92455b347dbdf7ccb;hb=HEAD

Regards,

Robert
..."About Basic: mentally mutilated potential programmers beyond hope of
regeneration." -- Dijkstra

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


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

[yocto] gcov on target

[Robert Berger]

Hi,

I use Yocto Project, 1.3 "danny" for a beagle-xm and would like to show
kernel code coverage with a core-image-sato-sdk.
This image is pretty complete. Unfortunately there is no gcov available
on the target.

It looks like it's only built for the host.

Did someone manage to build/run gcov for an armv7a?
... or let's put it otherwise: Why doesn't it exist on the target?

Regards,

Robert...The most likely way for the world to be destroyed, most experts
agree, is by accident. That's where we come in; we're computer
professionals. We cause accidents.

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


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

Re: [yocto] Classes

[Robert Berger]

Hi,

How about these classes by the Linux Foundation?

https://training.linuxfoundation.org/courses/linux-developer/building-embedded-linux-with-yocto-crash-course

https://training.linuxfoundation.org/courses/linux-developer/building-embedded-linux-with-yocto

... and of course there is also customized stuff ...

Regards,

Robert

..."It is easier to change the specification to fit the program than
vice versa." - Anonymous

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


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

Re: [yocto] beagleboard not booting

[Robert Berger]

On 07/18/2012 02:27 PM, Edward Vidal wrote:
> Hello,
> Close to the USB I see a C and close to speaker XM I am assuming the
> This is XM-C

OK

> What would be the process to use
> 
> 3.4.x kernel and a mainline u-boot.
> I am new to poky and don't know much about bit bake and openembedded.
> 
> Can you suggest where to read about using a different kernel.
> Thanks every thing helps.
> 

I know people here will beat me up for my suggestion, but just use the
toolchain you get with Yocto/Poky and build kernel/u-boot as ususal
without it.

Regards,

Robert
..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
only): Don't do it yet." - M.A. Jackson (not the singer)

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


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

Re: [yocto] beagleboard not booting

[Robert Berger]

Hi,

On 07/18/2012 03:54 AM, Edward Vidal wrote:
> Hello,
> The beagleboard that I am using is XM.

Which revison? C?

Can you try to build a mainline 3.4.x kernel and a mainline u-boot and
see what happens?


..."I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the symptoms
rather than the underlying problems." --Linus

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


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

Re: [yocto] beagleboard not booting

[Robert Berger]

On 07/18/2012 01:40 PM, Edward Vidal wrote:
> 
> # CONFIG_PREEMPT_RCU is not set
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> For beagleboard XM should this value be CONFIG_PREEMPT_NONE=n

I guess this is what Bruce would like you to try out.


..."I believe it was Andrew Koenig who commented that purists who accept
no compromises in programming languages use either machine code or
lambda calculus :-)" - Kevlin A P Henney (kev...@wslint.demon.co.uk)

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


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

Re: [yocto] Not booting on BeagleBoard xM 0x2

[Robert Berger]

Garry/Andrea,

I am currently giving a training based on the Beagle-XM an this error
happened at the same time on 5 boards with a 3.1 kernel.


> error pattern.  It hangs at this point:
>   Waiting for root device /dev/mmcblk0p2...
>   mmc0: error -110 whilst initialising SD card
> 

The fix was to change the SD cards and use cards from a different
manufacturer, so yes, it seems to be related to some funny SD card timings.

I did not try to patch yet.

Regards,

Robert


..."To assert that the earth revolves around the sun is as erroneous as
to claim that Jesus was not born of a virgin." - Cardinal Bellarmine
1615, during the trial of Galileo

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


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

Re: [yocto] Raspberry Pi

[Robert Berger]

Hi,

On 12/17/2011 01:37 AM, Chris Tapp wrote:

> Not quite. It's been due 'any time now' for a couple of months, but it
> looks as if it's now going to be early 2012.
> 
> It looks like a few of us are going to be busy in the New Year...
> 
> Chris Tapp

According to (hopefully) reliable sources we should be able to get
something around Feb;)

Regards,

Robert

> 
> opensou...@keylevel.com
> www.keylevel.com
> 

..."Experience is what you get when you were expecting something else."

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


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

[yocto] qemu-system-mipsel

[Robert Berger]

Hi,

Can someone please tell me what needs to be done to build
qemu-system-mipsel or provide a patch for it?

openembedded seems to be able to build something like this, so maybe it
would not be too difficult to cook some of the files from oe for yocto-poky.

Please advise,

Robert..."The IQ of the group is the lowest IQ of a member of the group
divided by the number of people in the group." - unknown

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


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

Re: [yocto] Poky release is 5.0 "Bernard" confusion

[Robert Berger]

Hi Scott,

> 
> This suggests to me that your local git repository isn't up to date. The
> tag has been moved at least once since it was created, and it sounds
> like your repository is behind the most recent move of the tag.
> 
> Note: if you use git fetch --all, that will fetch new tags but doesn't
> update old ones that have moved - you need to explicitly run git fetch
> --tags.

Thanks, you are absolutely right:

git pull

is not enough;)

git fetch --tags
>From git://git.pokylinux.org/poky
 - [tag update]  bernard-5.0 -> bernard-5.0

> 
> HTH,
> 
> Scott
> 

Regards,

Robert
..."The scientific name for an animal that doesn't either run from or
fight its enemies is lunch." - Michael Friedman

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


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

[yocto] Poky release is 5.0 "Bernard" confusion

[Robert Berger]

Hi,

Can someone please tell me if there is a tag in
git://git.pokylinux.org/poky.git which corresponds to the official
release tarball and what it is?

What puzzles me is that if you check out bernard-5.0 from the git
repository it does not correspond to
http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2

OK, it does not seem to be anything seriously different between the two:

#   modified:   README.hardware
#   modified:   documentation/adt-manual/adt-prepare.xml
#   modified:   documentation/yocto-project-qs/yocto-project-qs.xml
#   modified:   meta/conf/distro/poky.conf

... but you might want to synchronize since some people prefer to work
from git and others from the tarball.

As an example the README.hardware found in the tarball suggests to build
and update u-boot for the Freescale MPC8315E-RDB, which does not exist
in the git repo.

Regards,

Robert

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

[yocto] Change Endianess for MIPS build

[Robert Berger]

Hi,

I was wondering what needs to be done to build (at least) a little
endian qemu root file system for MIPS.

Yocto builds this:

ELF 32-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), dynamically
linked (uses shared libs), not stripped

I would need this:

ELF 32-bit LSB executable, MIPS, MIPS64 version 1 (SYSV), dynamically
linked (uses shared libs), not stripped

I guess SITEINFO_ENDIANESS (endian-big, endian-little) needs to be
changed to endian-little somewhere.

Can you please point me to where this needs to be done?

... or maybe I'm completely wrong and it needs to be done elsewhere ...

Regards,

Robert

..."I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the symptoms
rather than the underlying problems." --Linus

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


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

Re: [yocto] internal compiler error with qt building poky-image-lsb-sdk

[Robert Berger]

Hi Khem,

On 03/27/2011 08:32 AM, Khem Raj wrote:
> On (26/03/11 17:53), Robert Berger wrote:
>> Hi,
>>
>> The short version:
>>
>> With commit f8539239bc473279cc475b07c22e1e96514c6d2f Thu Mar 24 13:03:50
>> 2011 + both beagleboard and routerstationpro fail to build due to an
>> internal compiler error:
>>
>> ../../include/QtCore/../../src/corelib/tools/qstring.h:187:17: note: the
>> mangling of 'va_list' has changed in GCC 4.4
>> graphicsview/qgridlayoutengine.cpp:1553:1: internal compiler error: in
>> build_abbrev_table, at dwarf2out.c:9806
> 
> Can you try after addding the following to the failing recipe with 
> 
> CXXFLAGS := "${@oe_filter_out('-feliminate-dwarf2-dups', '${CXXFLAGS}',
> d)}"

I'm sorry I can't try right now, since I'm out of office for a week and
training people in Embedded Linux ;)

I can give it a try earliest in the week of 3rd of April.

Maybe someone else could try in the meantime. It's really easy to reproduce.
*) Just check out the latest from git
*) build poky-image-lsb-sdk for beagleboard

... and wait some hours ...

Regards,

Robert

> 
> -Khem

..."At Group L, Stoffel oversees six first-rate programmers, a
managerial challenge roughly comparable to herding cats." - The
Washington Post Magazine, June 9, 1985

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


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

[yocto] internal compiler error with qt building poky-image-lsb-sdk

[Robert Berger]

Hi,

The short version:

With commit f8539239bc473279cc475b07c22e1e96514c6d2f Thu Mar 24 13:03:50
2011 + both beagleboard and routerstationpro fail to build due to an
internal compiler error:

../../include/QtCore/../../src/corelib/tools/qstring.h:187:17: note: the
mangling of 'va_list' has changed in GCC 4.4
graphicsview/qgridlayoutengine.cpp:1553:1: internal compiler error: in
build_abbrev_table, at dwarf2out.c:9806

This seems to be due to the gcc version used and how the code is written
in qt.

The longer version:

http://bugzilla.pokylinux.org/show_bug.cgi?id=932

Regards,

Robert..."C treats you like a consenting adult. Pascal treats you like a
naughty child. Ada treats you like a criminal." -- (Bruce Powel Douglass)

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


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

Re: [yocto] run-time problem - poky-image-lsb-sdk-beagleboard

[Robert Berger]

Hi,

On 03/24/2011 02:53 PM, Gary Thomas wrote:

> 
> What does /etc/network/interfaces show?  Is it different between the two
> images?
> 
> n.b. I've not tried any of the LSB images, just poking in the dark.
> 

To our both surprise they are identical (see below).
... and if you ask my uneducated guess I would say this should not work,
since usb0 is static ?!?!

... but, surprisingly enough it does on sato ...

... and if I make the following change in lsb-sdk it still does not :

iface usb0 inet dhcp

it also does not work if I hardcode the network conf for usb0 in
/etc/network/interfaces

--

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wireless interfaces
iface wlan0 inet dhcp
wireless_mode managed
wireless_essid any
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf

iface atml0 inet dhcp

# Wired or wireless interfaces
iface eth0 inet dhcp
iface eth1 inet dhcp

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.0
network 192.168.7.0
gateway 192.168.7.1

# Bluetooth networking
iface bnep0 inet dhcp

Regards,

Robert...Good judgment comes from experience... and experience comes
from bad judgment.- Fred Brooks

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


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

[yocto] run-time problem - poky-image-lsb-sdk-beagleboard

[Robert Berger]

Hi,

Using rpm instead of ipk I'm able to build
poky-image-lsb-sdk-beagleboard even with the lastest and greatest from
git (commit aeaa356a5ee77b4596c479451a9db289381a4d16 Sat Mar 19 01:30:12
2011 +)

The problem I have now is, that on my beagle-xm networking does not seem
to get an IP address from my dhcp server.

root@beagleboard:~# ifconfig -a
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:50 errors:0 dropped:0 overruns:0 frame:0
  TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:5375 (5.2 KiB)  TX bytes:5375 (5.2 KiB)

usb0  Link encap:Ethernet  HWaddr 06:ba:3b:e0:1f:b2
  BROADCAST MULTICAST  MTU:1492  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


Manually it seems to work:
root@beagleboard:~# ifconfig usb0 192.168.42.67
root@beagleboard:~# ifcusb0: link up, 100Mbps, full-duplex, lpa 0xC5E1

root@beagleboard:~# ifconfig
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:55 errors:0 dropped:0 overruns:0 frame:0
  TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:6140 (5.9 KiB)  TX bytes:6140 (5.9 KiB)

usb0  Link encap:Ethernet  HWaddr 06:ba:3b:e0:1f:b2
  inet addr:192.168.42.67  Bcast:192.168.42.255  Mask:255.255.255.0
  inet6 addr: fe80::4ba:3bff:fee0:1fb2/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:5472 (5.3 KiB)

A sato image built from exactly the same sources had dhcp working out of
the box.

Regards,

Robert

..."Experience is something you don't get until just after you need it."
- Olivier

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


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

Re: [yocto] build failure 2 - poky-image-lsb-sdk-beagleboard with bernard-5.0

[Robert Berger]

Hi Scott,

On 03/23/2011 01:01 AM, Scott Garman wrote:
> 
> Hi Robert,
> 
> Could you please report this in our bugzilla? I seem to recall running
> into something like this too.
> 
> http://bugzilla.pokylinux.org
> 

http://bugzilla.pokylinux.org/show_bug.cgi?id=924

> Thanks,
> 
> Scott
> 

Regards,

Robert...Distributed computing means that you cannot get your work done
when some computer you never heard of crashes" -- L.Lamport

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


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

Re: [yocto] build failure 2 - poky-image-lsb-sdk-beagleboard with bernard-5.0

[Robert Berger]

I think it boils down to the fact, that

meta/recipes-core/base-files/base-files/sysctl.conf
meta/recipes-extended/procps/procps-3.2.8/sysctl.conf

are different and both should end up at the rootfs.

I guess I could just remove the procps package.

But how to resolve this in a more elegant way and how did the
autobuilder get away with it?

Regards,

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


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

[yocto] build failure 2 - poky-image-lsb-sdk-beagleboard with bernard-5.0

[Robert Berger]

Hi,

After resolving the first issue I did a fresh build from scratch using
the bernard-5.0 tag and that's what I get:

Collected errors:
 * resolve_conffiles: Existing conffile
/work/rber/poky-bernard-5.0-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs/etc/sysctl.conf
is different from the conffile in the new package. The new conffile will
be placed at
/work/rber/poky-bernard-5.0-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs/etc/sysctl.conf-opkg.

And yes, indeed those files are different: http://pastebin.com/kXpCS2uC

I'm wondering what's the configuration to build
http://autobuilder.yoctoproject.org/nightly/CURRENT/machines/beagleboard/arm/poky-image-lsb-sdk-beagleboard-20110320115716.rootfs.tar.bz2

Do you see anything strange in my local.conf? http://pastebin.com/bn4iDwBF

Please advise.

Regards,

Robert..."Java is, in many ways, C++--." - Michael Feldman

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


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

Re: [yocto] build failure - poky-image-lsb-sdk-beagleboard

[Robert Berger]

Hi Scott,

On 03/21/2011 06:42 PM, Scott Garman wrote:
> 
> Hi Robert,
> 
> I'm guessing you're building on a Debian-based host distro. Please
> ensure both the groff and groff-base packages are installed.
> 
> We just recently fixed our Quick Start guide to include the groff
> package dependency for Debian-based hosts, but it appears it hasn't been
> pushed out to our production web site yet.

You guessed right. Thanks!
That got me further, but still no success:

Collected errors:
 * resolve_conffiles: Existing conffile
/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs/etc/sysctl.conf
is different from the conffile in the new package. The new conffile will
be placed at
/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs/etc/sysctl.conf-opkg.
+ '[' '!' -z '' ']'
+ export
D=/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs
+
D=/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs
+ export
OFFLINE_ROOT=/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/beagleboard-poky-linux-gnueabi/poky-image-lsb-sdk-1.0-r0/rootfs
+ echo ''

+ do_exit=1
+ for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail
+ for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail
+ test 1 = 1
+ exit 1
ERROR: Function 'do_rootfs' failed
Here are more details: http://pastebin.com/DBL9waVF

Maybe someone has a guess for this as well?

Regards,

Robert

> 
> Scott
> 

...Yesterday it worked Today it is not working Windows is like that --
Margaret Segall

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


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

[yocto] build failure - poky-image-lsb-sdk-beagleboard

[Robert Berger]

Hi,

I don't know if I'm posting to the right mailing list, but just wanted
you to know that the latest and greatest from git fails when trying to
build poky-image-lsb-sdk for beaglebaord.

| make[3]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
| [ -d sgml ] || mkdir sgml
| cd sgml; sgml2txt .././sgml/libuser.sgml
| Processing file .././sgml/libuser.sgml
| troff: fatal error: can't find macro file s
|  fmt_txt::postASP: Empty output file, error when calling groff.
Aborting...
| make[2]: *** [sgml/libuser.txt] Error 1
| make[2]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
| ERROR: Function 'do_compile' failed (see
/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/temp/log.do_compile.5485
for further information)
NOTE: package libuser-0.57.1-r1: task do_compile: Failed
ERROR: Task 1822
(/work/rber/poky/meta/recipes-extended/libuser/libuser_0.57.1.bb,
do_compile) failed with exit code '1'


Please advise

Regards,

Robert..."Giving up on assembly language was the apple in our Garden of
Eden: Languages whose use squanders machine cycles are sinful."(Epigrams
in Programming,  ACM SIGPLAN Sept. 1982)

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

NOTE: make
make  all-recursive
make[1]: Entering directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1'
Making all in po
make[2]: Entering directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/po'
make[2]: Leaving directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/po'
Making all in docs
make[2]: Entering directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
Making all in reference
make[3]: Entering directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs/reference'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs/reference'
make[3]: Entering directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
[ -d sgml ] || mkdir sgml
cd sgml; sgml2txt .././sgml/libuser.sgml
Processing file .././sgml/libuser.sgml
troff: fatal error: can't find macro file s
 fmt_txt::postASP: Empty output file, error when calling groff. Aborting...
make[2]: *** [sgml/libuser.txt] Error 1
make[2]: Leaving directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1'
make: *** [all] Error 2
FATAL: oe_runmake failed
ERROR: Function 'do_compile' failed (see 
/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/temp/log.do_compile.5586
 for further information)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto supported freescale eval boards

[Robert Berger]

Hi,


 We're currently using the following board.

 http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=MPC8315E-RDBA-ND&Site=US&Lang=EN


Just FYI it looks like this board is not available in Europe from
Digikey due to U.S. export controls. Some kind of top secret U.S.
hardware, I guess ;)

As an alternative solution, which you can actually get in Europe I
ordered this: http://www.denx-cs.de/?q=mpc8315e-rdb

No ND at the and, still I hope it's going to work.

Regards,

Robert..."The scientific name for an animal that doesn't either run from
or fight its enemies is lunch." - Michael Friedman

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


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