Re: [yocto] Multiple ubifs partition

[Marc Ferland]

> On Mon, Mar 4, 2019 at 6:17 AM Gabriele Zampieri
>  wrote:
> >
> > Hi all,
> >
> > I'm trying to build a distribution that has multiple partitions. The 
> > desiderata is something like:
> >
> > - rootfs.ubifs mounted on /
> > - data.ubifs mounted on /data
> > - opt.ubifs mounted on /opt
> >
> > I was wondering if there is a standard way to achieve the goal. I see that 
> > there is a tool called wic, but it does not seems to support ubifs. I could 
> > post process the tarball image and doing stuff with my scripts, but I'd 
> > prefer doing this in a single bitbake run. Can you suggest something?
> >

Hummm just reread your mail, and I think you will probably have to
roll up your own image type. The meta-raspberrypi layer contains a
custom image bbclass which you could use as an example.

Good luck!
Marc
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple ubifs partition

[Marc Ferland]

Look for the multiubi fstype:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n151


On Mon, Mar 4, 2019 at 6:17 AM Gabriele Zampieri
 wrote:
>
> Hi all,
>
> I'm trying to build a distribution that has multiple partitions. The 
> desiderata is something like:
>
> - rootfs.ubifs mounted on /
> - data.ubifs mounted on /data
> - opt.ubifs mounted on /opt
>
> I was wondering if there is a standard way to achieve the goal. I see that 
> there is a tool called wic, but it does not seems to support ubifs. I could 
> post process the tarball image and doing stuff with my scripts, but I'd 
> prefer doing this in a single bitbake run. Can you suggest something?
>
> Thanks,
> Gabriele
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] readonly rootfs - storing data in separate partition

[Marc Ferland]

On Mon, Feb 18, 2019 at 11:37 AM Belisko Marek 
wrote:

> Hi,
>
> I plan to use readonly rootfs option and store some custom data in
> separate partition (like hostname, wpa_supplicant.conf etc). I have wic
> file which create rootfs + then rest is for data storage. I can adjust
> various recipes to symlink to /data partition. My question is if there
> exists some mechanism how to store some pieces in non-rootfs partition? I
> know some projects which put those extra files to deploy dir and then by dd
> create dummy storage nd put files there and finally create partition from
> that. Thanks a log for any pointers.
>
>

You could potentially use overlayfs to have a RO rootfs and a separate RW
layer in another partition for example. I think linux-yocto also support
AUFS.

Good luck,

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

Re: [yocto] yocto touchscreen

[Marc Ferland]

Looks like: https://bugzilla.redhat.com/show_bug.cgi?id=1650634

Good luck!

On Tue, Feb 5, 2019 at 10:30 AM Stanisavljevic <
n.stanisavlje...@polycaptil.fr> wrote:

> Hy Marc,
>
>
>
> Here is the log file attached in this mail.
>
>
>
> Nikola
>
> *De :* Marc Ferland 
> *Envoyé :* mardi 5 février 2019 16:10
> *À :* Stanisavljevic 
> *Cc :* Yocto discussion list 
> *Objet :* Re: [yocto] yocto touchscreen
>
>
>
> On Mon, Feb 4, 2019 at 6:17 AM Stanisavljevic <
> n.stanisavlje...@polycaptil.fr> wrote:
>
> Hy Team,
>
>
>
> I have a problem
>
>
>
> I buid a custom os for AM335x processor and I used yocto to do it.
>
>
>
> I build a first version of this os with version krogoth and it work fine.
>
>
>
> Now I build a second version of this os with version sumo and the
> touchscreen work fine during boot process but when kernel is loaded,
> touchscreen freeze / lock and impossible to use it.
>
> The terminal is printed on the touchscreen but the screen is locked,
> impossible to write a command or to move the mouse to select, ….
>
>
>
> Here is the log of boot to the user session (log got with serial
> communication between PC and board) :
>
>
>
> ...
>
> X.Org X Server 1.19.6
>
> Release Date: 2017-12-20
>
> X Protocol Version 11, Revision 0
>
> Build Operating System: Linux 4.15.0-38-generic x86_64
>
> Current Operating System: Linux polycaptil-machine-am335x-evmsk
> 4.4.19-ge581bb1cac #1 PREEMPT Thu May 24 11:42:17 CEST 2018 armv7l
>
> Kernel command line: console=ttyO0,115200 root=/dev/mmcblk0p3 rw
>
> Build Date: 05 November 2018  09:33:21PM
>
>
>
> Current version of pixman: 0.34.0
>
> Before reporting problems, check http://wiki.x.org
>
> to make sure that you have the latest version.
>
> Markers: (--) probed, (**) from config file, (==) default setting,
>
> (++) from command line, (!!) notice, (II) informational,
>
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  1 20:08:02 2019
>
> (==) Using config file: "/etc/X11/xorg.conf"
>
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>
> done.
>
>
>
> Please post the full /var/log/Xorg.log.
>
>
>
> Marc
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto touchscreen

[Marc Ferland]

On Mon, Feb 4, 2019 at 6:17 AM Stanisavljevic <
n.stanisavlje...@polycaptil.fr> wrote:

> Hy Team,
>
>
>
> I have a problem
>
>
>
> I buid a custom os for AM335x processor and I used yocto to do it.
>
>
>
> I build a first version of this os with version krogoth and it work fine.
>
>
>
> Now I build a second version of this os with version sumo and the
> touchscreen work fine during boot process but when kernel is loaded,
> touchscreen freeze / lock and impossible to use it.
>
> The terminal is printed on the touchscreen but the screen is locked,
> impossible to write a command or to move the mouse to select, ….
>
>
>
> Here is the log of boot to the user session (log got with serial
> communication between PC and board) :
>
>
>
...

> X.Org X Server 1.19.6
>
> Release Date: 2017-12-20
>
> X Protocol Version 11, Revision 0
>
> Build Operating System: Linux 4.15.0-38-generic x86_64
>
> Current Operating System: Linux polycaptil-machine-am335x-evmsk
> 4.4.19-ge581bb1cac #1 PREEMPT Thu May 24 11:42:17 CEST 2018 armv7l
>
> Kernel command line: console=ttyO0,115200 root=/dev/mmcblk0p3 rw
>
> Build Date: 05 November 2018  09:33:21PM
>
>
>
> Current version of pixman: 0.34.0
>
> Before reporting problems, check http://wiki.x.org
>
> to make sure that you have the latest version.
>
> Markers: (--) probed, (**) from config file, (==) default setting,
>
> (++) from command line, (!!) notice, (II) informational,
>
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  1 20:08:02 2019
>
> (==) Using config file: "/etc/X11/xorg.conf"
>
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>
> done.
>

Please post the full /var/log/Xorg.log.

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

Re: [yocto] rpmdeps buffer overflow

[Marc Ferland]

On Fri, Aug 10, 2018 at 11:01 AM, Alexander Kanavin
 wrote:
> 2018-08-10 16:50 GMT+02:00 Marc Ferland :
>> | Processing files: pylon-5.0.12-r0.aarch64
>> | *** buffer overflow detected ***:
>> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/rpmbuild
>> terminated
>> | Aborted (core dumped)
>
> This is not a yocto issue, but a rpm issue. You need to deal with it
> the hard way I'm afraid: inspect the core dump with gdb, and take the
> result to rpm upstream.
>

Looking at the backtrace of rpmbuild in gdb I see that libmagic is the culprit:

*** buffer overflow detected ***:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/rpmbuild
terminated

Program received signal SIGABRT, Aborted.
0x76f6f66a in raise () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
(gdb) bt
#0  0x76f6f66a in raise () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#1  0x76f70741 in abort () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#2  0x76fb0a07 in ?? () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#3  0x7703dcde in ?? () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#4  0x7703dd11 in __fortify_fail () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#5  0x7703bdc0 in __chk_fail () from
/home/vagrant/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#6  0x76d1e0b1 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/./libmagic.so.1
#7  0x76d1f105 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/./libmagic.so.1
#8  0x76d2a888 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/./libmagic.so.1
#9  0x76d2c782 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/./libmagic.so.1
#10 0x76d1fc43 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/./libmagic.so.1
#11 0x77bca16d in rpmfcClassify ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/librpmbuild.so.7
#12 0x77bcab26 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/librpmbuild.so.7
#13 0x77bbc671 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/librpmbuild.so.7
#14 0x77bb8113 in ?? ()
   from 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/bin/../lib/librpmbuild.so.7
#15 0x7abf in ?? ()
#16 0x7c5b in ?? ()

I did a quick test and bumped the file recipe (was 5.31 on rocko
branch) to 5.34 and the problem went away, no more buffer overflows
and now my recipe builds correctly.

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

Re: [yocto] rpmdeps buffer overflow

[Marc Ferland]

On Thu, Aug 9, 2018 at 2:34 PM, Marc Ferland  wrote:
> Hi,
>
> I'm creating a recipe for a precompiled SDK. This SDK contains various
> precompiled libraries and executables. When I get to the packaging
> step bitbake aborts with the following error:
>
> ERROR: pylon-5.0.12-r0 do_package: Error executing a python function
> in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:package_do_filedeps(d)
>  0003:
> File: '/vagrant/yocto/poky/meta/classes/package.bbclass', lineno:
> 1484, function: package_do_filedeps
>  1480:continue
>  1481:for files in chunks(pkgfiles[pkg], 100):
>  1482:pkglist.append((pkg, files, rpmdeps, pkgdest))
>  1483:
>  *** 1484:processed = oe.utils.multiprocess_exec( pkglist,
> oe.package.filedeprunner)
>  1485:
>  1486:provides_files = {}
>  1487:requires_files = {}
>  1488:
> File: '/vagrant/yocto/poky/meta/lib/oe/utils.py', lineno: 240,
> function: multiprocess_exec
>  0236:mapresult = pool.map_async(function, commands,
> error_callback=failures)
>  0237:
>  0238:pool.close()
>  0239:pool.join()
>  *** 0240:results = mapresult.get()
>  0241:except KeyboardInterrupt:
>  0242:pool.terminate()
>  0243:pool.join()
>  0244:raise
> File: '/usr/lib/python3.6/multiprocessing/pool.py', lineno: 644, function: get
>  0640:raise TimeoutError
>  0641:if self._success:
>  0642:return self._value
>  0643:else:
>  *** 0644:raise self._value
>  0645:
>  0646:def _set(self, i, obj):
>  0647:self._success, self._value = obj
>  0648:if self._callback and self._success:
> Exception: subprocess.CalledProcessError: Command
> '['/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps',
> '--alldeps', 
> '/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/lib64/libpylon_TL_bcon-5.0.12.so',
>
> REMOVED FOR BREVITY
>
> '/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/platforms/libqxcb.so']'
> died with .
>
> Subprocess output:
> *** buffer overflow detected ***:
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
> terminated
>
> ERROR: pylon-5.0.12-r0 do_package: Function failed: package_do_filedeps
> ERROR: Logfile of failure stored in:
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/temp/log.do_package.30101
> ERROR: Task 
> (/vagrant/yocto/meta-telops/recipes-basler/pylon5/pylon_5.0.12.bb:do_package)
> failed with exit code '1'
>
> Digging a little deeper, it looks like certain files cause rpmdeps to
> blowup. For example, issuing:
>
> rpmdeps --alldeps
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2
>
> I get the expected:
>   0 
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2
> P libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit)
> P libQt5Core.so.5(Qt_5)(64bit)
> P libQt5Core.so.5(Qt_5.0)(64bit)
> P libQt5Core.so.5(Qt_5.0)(64bit)
> 
>
> But running rpmdeps on one of their proprietary lib:
> rpmdeps --alldeps
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libPylonQtBase.so.1.0.0
> *** buffer overflow detected ***:
> /home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
> terminated
> Aborted (core dumped)
>

Got a little bit further by disabling filedeps with
SKIP_FILEDEPS_${PN} = "1". Now I get a buffer overflow from rpmbuild:

ERROR: pylon-5.0.12-r0 do_package_write_rpm: Function failed:
BUILDSPEC (log file is located at
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/temp/log.do_package_write_rpm.32236)
ERROR: Logfile of failure stored in:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/temp/log.do_package_write_rpm.32236
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are
['virtual:native:/vagrant/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
'virtual:native:/vagrant/yocto/poky/meta/reci

[yocto] rpmdeps buffer overflow

[Marc Ferland]

Hi,

I'm creating a recipe for a precompiled SDK. This SDK contains various
precompiled libraries and executables. When I get to the packaging
step bitbake aborts with the following error:

ERROR: pylon-5.0.12-r0 do_package: Error executing a python function
in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:package_do_filedeps(d)
 0003:
File: '/vagrant/yocto/poky/meta/classes/package.bbclass', lineno:
1484, function: package_do_filedeps
 1480:continue
 1481:for files in chunks(pkgfiles[pkg], 100):
 1482:pkglist.append((pkg, files, rpmdeps, pkgdest))
 1483:
 *** 1484:processed = oe.utils.multiprocess_exec( pkglist,
oe.package.filedeprunner)
 1485:
 1486:provides_files = {}
 1487:requires_files = {}
 1488:
File: '/vagrant/yocto/poky/meta/lib/oe/utils.py', lineno: 240,
function: multiprocess_exec
 0236:mapresult = pool.map_async(function, commands,
error_callback=failures)
 0237:
 0238:pool.close()
 0239:pool.join()
 *** 0240:results = mapresult.get()
 0241:except KeyboardInterrupt:
 0242:pool.terminate()
 0243:pool.join()
 0244:raise
File: '/usr/lib/python3.6/multiprocessing/pool.py', lineno: 644, function: get
 0640:raise TimeoutError
 0641:if self._success:
 0642:return self._value
 0643:else:
 *** 0644:raise self._value
 0645:
 0646:def _set(self, i, obj):
 0647:self._success, self._value = obj
 0648:if self._callback and self._success:
Exception: subprocess.CalledProcessError: Command
'['/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps',
'--alldeps', 
'/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/lib64/libpylon_TL_bcon-5.0.12.so',

REMOVED FOR BREVITY

'/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/platforms/libqxcb.so']'
died with .

Subprocess output:
*** buffer overflow detected ***:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
terminated

ERROR: pylon-5.0.12-r0 do_package: Function failed: package_do_filedeps
ERROR: Logfile of failure stored in:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/temp/log.do_package.30101
ERROR: Task 
(/vagrant/yocto/meta-telops/recipes-basler/pylon5/pylon_5.0.12.bb:do_package)
failed with exit code '1'

Digging a little deeper, it looks like certain files cause rpmdeps to
blowup. For example, issuing:

rpmdeps --alldeps
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2

I get the expected:
  0 
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libQt5Core.so.5.6.2
P libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit)
P libQt5Core.so.5(Qt_5)(64bit)
P libQt5Core.so.5(Qt_5.0)(64bit)
P libQt5Core.so.5(Qt_5.0)(64bit)


But running rpmdeps on one of their proprietary lib:
rpmdeps --alldeps
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/packages-split/pylon/opt/pylon5/bin/libPylonQtBase.so.1.0.0
*** buffer overflow detected ***:
/home/vagrant/build/tmp/work/aarch64-poky-linux/pylon/5.0.12-r0/recipe-sysroot-native/usr/lib/rpm/rpmdeps
terminated
Aborted (core dumped)

Any idea of what might be causing this?

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

Re: [yocto] rfkill cannot open control device

[Marc Ferland]

On Tue, Dec 19, 2017 at 10:23 AM, Sherif Omran
 wrote:
> i used core-image-minimal for a raspberry pi 0w. But i get rfkill can not
> open control device. when i give rfkill , i get the syntanx output, this
> means it exists.
> the wifi driver is installed.
>
> What is the rfkill device? is it /dev/rfkill ?
>
Use

rfkill list

to list all devices. Then (for example):

rfkill unblock bluetooth
or
rfkill unblock all

to unblock the bluetooth device or all devices (resp.).

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

Re: [yocto] /etc/resolv.conf symlink

[Marc Ferland]

FWIW,

I'm using pyro and had to cherry-pick:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=00e4662e55f66570cae29240c22b4d74b79d3ca5

To make systemd-resolved and systemd-networkd work as expected.

Marc

On Mon, Oct 30, 2017 at 11:54 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 10/30/2017 05:37 PM, Anders Montonen wrote:
>
>> I'm hoping someone could clarify how the symlink generation from
>> /etc/resolv.conf to systemd's runtime /run/systemd/resolve/resolv.conf
>> is supposed to work when resolved is not enabled.
>>
>
> I think we have a bug for it:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=11969
>
> Please comment, propose patches etc.
>
> Alex
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] minimize size of SW update bundle

[Marc Ferland]

On Tue, Oct 17, 2017 at 9:12 AM, Robert Berger
 wrote:
> 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...
>

Some ideas:

- SquashFS with agressive compression settings can be quite
impressive. I was able to reduce my image size from 650MB
(uncompressed) down to maybe 120MB. This was for a complete system
update though.
- The new zstd algo from facebook looks promising (haven't tried it
yet) and might be worth investigating, I think it is supported as a
squashfs decompressor.
- bsdiff can generate diffs from binary files (be carefull if diffing
compressed files, i.e.: gzip --rsyncable).
- there's also casync (never tried it): https://github.com/systemd/casync/

Enjoy!

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

[yocto] Removing/Disabling /etc/version

[Marc Ferland]

Hi,

Easy question!

I would like to disable the /etc/version file from being installed to
the rootfs. How do I proceed? It looks hard-coded at first glance...?

Regards,

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

Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily

[Marc Ferland]

On Mon, Mar 10, 2014 at 11:59:08AM +0100, Josef Holzmayr wrote:
 Howdy!
 
 After looking more and more into yocto, one of the main issues for me is the
 process to set up a project properly, including all layers and conf options.
 Especially those which would be needed to set exactly the same way again and
 again every time somebody needs to reproduce a build.
 
 So I've come up with an idea: a small tool that can handle these things for 
 me.
 And here it is for your enjoyment/use/abuse/comments:
 
You should have a look at the 'repo' tool from the android
community. I think it already does part of what you're trying to do
here.

The freescale yocto bsp already uses repo:
https://github.com/Freescale/fsl-community-bsp-platform

Cheers!

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

Re: [yocto] Cedartrail zero-copy texture updates

[Marc Ferland]

On Mon, Feb 24, 2014 at 03:46:07PM +, Chris Tapp wrote:
 I'm trying to get zero-copy GLES textures working using Danny /
 Cedartrail (PVR) so I can stream video frames into a GLES
 application.
 
 Googling hasn't really helped that much with how to do this, but I
 think I need to use eglCreateImageKHR and a client-side buffer so
 that glEGLImageTargetTexture2DOES() can be used to bind the texture
 to an image in memory.
 
 eglCreatePixmapSurfaceHI() looks like it allows client memory to be
 used as a colour-buffer which can be passed to eglCreateImageKHR,
 but I can't seem to be able to create a context which supports
 pixmaps.
 
 Are there any examples out there to show how to put all of this
 together?
 
Documentation about this stuff is indeed sparse and hard to find!

I once tried (and failed!) to do something similar on crownbay but the
texture data was mapped to a polygon mesh (no video acceleration
stuff).

The documentation that I came across mentionned using the
GL_TEXTURE_STREAM_IMG extension to implement the zero-copy texture
transfers. Maybe the same extension is available on cedartrail.

The pdf used to be hosted on intel (emgd section) web site, but it
looks like it was taken down. I can check if I still have it somewhere
if you're interested.

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

Re: [yocto] Boot loader/boot times

[Marc Ferland]

On Sun, Nov 24, 2013 at 06:28:40PM -0600, Michael Gloff wrote:
What bootloaders are most people here using (x86)? I'm using lilo and
it seems slow. Even skipping the data check it sits for about 5-8 secs
on a D525 Atom board. Total boot is about 20-25 secs, but I would like
to minimize it as much as possible. I know where the other delays are,
but Ubuntu on the same machine gives a login in about 5 sec total.

I think the default bootloader for x86 machines on yocto is
syslinux.

To reduce the bootloader time try reducing your kernel/initrd sizes,
also check if there isn't any default timeout value configured in.

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

[yocto] variable override question

[Marc Ferland]

Hi,

I have a linux-yocto_3.4.bbappend file in which I try to override the
KERNEL_FEATURES variable. I want it to be empty (I don't want the
netfilter stuff that's there by default).

So I've tried (in my bbappend):

KERNEL_FEATURES = 

but somehow the netfilter.scc file still gets merged in.

What am I doing wrong?

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

Re: [yocto] variable override question

[Marc Ferland]

Bruce Ashfield bruce.ashfi...@windriver.com writes:

 On 13-06-25 03:59 PM, Marc Ferland wrote:
 Hi,

 I have a linux-yocto_3.4.bbappend file in which I try to override the
 KERNEL_FEATURES variable. I want it to be empty (I don't want the
 netfilter stuff that's there by default).

 So I've tried (in my bbappend):

 KERNEL_FEATURES = 

 but somehow the netfilter.scc file still gets merged in.

 What am I doing wrong?

 Nothing. It's an artifact of the _appends that are present
 in the linux-yocto recipe bbappends. You can clear it, but they'll
 still append.

 Those config fragments weren't optional when the recipes were
 created, we've since evolved to the point where they are.

 I squeezed in a change to linux-yocto_3.8 before the yocto 1.4
 cutoff, and have changed linux-yocto_3.4 to match, and strangely,
 was about to send a consolidated pull request that contains the
 change.

 You can either locally make the same change, and clear:

  KERNEL_EXTRA_FEATURES

 or wait for my latest update.

Nice, exactly what I was looking for!

Thanks,

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

Re: [yocto] Qt build error for Debug and Release mode

[Marc Ferland]

Navani Srivastava navani.srivast...@gmail.com writes:

 Hi,

 I am using poky-danny (Poky-8.0). I am facing problem in building Qt
 application.

  When we are building Qt application with “qmake CONFIG+=debug 
 make” it appends “-g” to build the application in debug mode but when
 we are building application in release mode by issuing following
 command  “qmake CONFIG+=debug  make”, then also it appends “-g” to
 it.

 So building Qt application in release mode also results in debug mode
 output.

 Any fix for this?

You could override the OE_QMAKE_CFLAGS env variable like this:
OE_QMAKE_CFLAGS=-O2 -pipe -feliminate-unused-debug-types make

If you look in the Makefile generated by qmake you should see something
like:

CFLAGS = -pipe -pipe $(OE_QMAKE_CFLAGS) -O2 

This OE_QMAKE_CFLAGS variable is evaluated by make from the
environment. Also look at your environment-setup-* file from the
SDK, this is where all OE_QMAKE variables are sourced from.

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

[yocto] kernel-module in initramfs

[Marc Ferland]

Hi,

I have an application recipe wich RDEPENDS on a couple of kernel modules
and is installed in my initramfs image. The dependency on the kernel
modules is expressed by:

RDEPENDS_${PN}_mymachine += kernel-module-abc kernel-module-def

This seems to work fine, expect that I now have a copy of the bzImage
packaged in the initramfs. This has a negative effect on boot
performance and the final image size.

Is there a way to get rid of this 'extra' bzImage?

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

[yocto] udev not starting on first boot

[Marc Ferland]

Hi,

I'm currently upgrading from 1.3 to 1.4 and I'm having some issues on
the first boot because it seems udev won't start.

I'm using udev 182 from meta/recipes-core/udev. The system uses a
read-only root filesystem (squashfs) paired with a RW partition joined
together with AUFS to give the illusion of a RW filesystem.

The system is not configured with 'read-only-rootfs'.

On the first boot no /var/run/udev is created clearly showing that udevd
wasn't started.

At first sight it seems to be caused by the fact that populate-volatile
is called after udev, so some symlinks could be missing... that or some
weird race issue.

Any ideas?

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

Re: [yocto] Can't find guile-2.0

[Marc Ferland]

Paul D. DeRocco pdero...@ix.netcom.com writes:

 From: Burton, Ross
 
 On 12 March 2013 18:20, Paul D. DeRocco 
 pdero...@ix.netcom.com wrote:
  It says attempted 145 tasks of which 145 didn't need to be 
  rerun. So it thinks it's already there.
 
 Indeed.   Something is breaking - you'll have to mail the whole
 configure log from autogen to attempt to debug this.

 One thing that I notice is that in my build/tmp/work/i686-linux, I have two
 directories, autogen-native-5.12-r2 and autogen-native-5.12-r3. The first is
 from my successful out-of-the-box build of a week ago; the second is from my
 current failed build. What I did in between was to add the
 openembedded-core/meta and meta-openembedded/meta-oe layers in order to
 include Samba. The two logs deviate at line 275 where the old successful one
 says checking whether with-libguile was specified... no and the new failed
 one says checking for i686-linux-pkg-config... no. I suspect something in
 the OE stuff appended to a recipe, which is leading to the problem.

Same thing here. Everything was building fine until I added the meta-oe
layer.

Does one of you have a workaround for this?

Thanks,

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

Re: [yocto] lmsensors-apps builds, but not in final image?

[Marc Ferland]

r10kindsofpeople r10kindsofpeo...@gmail.com writes:

 I'm hoping someone can quickly spot my mistake.  I'm attempting to use
 this recipe:
 http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_
 sensors/lmsensors-apps_3.3.2.bb

 with my meta-intel/crownbay build under denzil 7.0.1.  

 I put the recipe in my layer, and added lmsensors-apps to my
 IMAGE_INSTALL_append in my layer's layer.conf.  

 The software builds, and I can see the files in
 tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2.

 But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs
 or the .hddimage file.


You have to use one of the packages specified in the recipe. Like
'libsensors' or 'lmsensors-sensors'. lmsensors-apps is empty.

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

Re: [yocto] lmsensors-apps builds, but not in final image?

[Marc Ferland]

r10kindsofpeople r10kindsofpeo...@gmail.com writes:

 Thanks, Marc, that's got me moving forward.  However, it may not be
 strictly true that lmsensors-apps is empty or at least has no effect.
  So far, I'm up to lmsensors lmsensors-scripts lmsensors-apps with
 the last being needed {sufficient?} to get strict.pm, needed to do
 sensors-detect.  

You could also use the new lmsensors recipe which I updated from the old
one (the one you're using atm).

It's available here:
https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-support/lm_sensors/lmsensors_3.3.2.bb

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

[yocto] rootless X emgd

[Marc Ferland]

Hi,

I'm trying to make my machine work with rootless X. The machine looks a
lot like crownbay (with emgd).

I'm getting the following when X starts:

[2910604.796] (II) EMGD: Intel(R) Embedded Media and Graphics Driver version 
1.10.2209 for:   
Intel US15W Class   
  
[2910604.796] (--) using VT number 3
 

   
[2910604.871] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card 
support  
[2910604.871] (==) EMGD(0): RGB weight 888  
   
[2910604.871] (==) EMGD(0): Default visual is TrueColor 
   
[2910604.873] drmOpenDevice: node name is /dev/dri/card0
   
[2910604.875] (WW) LoadKernelModule: Setting of real/effective user Id to 0/0 
failed[2910604.883] [drm] failed to load kernel module emgd
[2910604.883] (II) EMGD(0): Graphics hardware initialization failed.
   
[2910604.883] (II) EMGD(0):   The cause was a failure to connect with the DRM 
during PreInit().
[2910604.884] (II) EMGD(0): Cannot open a connection with the DRM   
   
[2910604.884] (II) UnloadModule: emgd 
   
[2910604.884] (EE) Screen(s) found, but none have a usable configuration.   
   
[2910604.884]   
   
Fatal server error: 
   
[2910604.884] no screens found

Anyway to solve this?

BTW, I'm using denzil.

Regards,

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

Re: [yocto] Unreadable menuconfig

[Marc Ferland]

Jonathan Haws jonathan.h...@sdl.usu.edu writes:

 When I run 'bitbake linux-yocto -c menuconfig' I was not getting a
 menuconfig - I had to tell my local.conf to use screen because auto
 was selecting a gnome terminal which would resize itself to something
 too small and menuconfig would exit with an error.

 Now I can get menuconfig and make changes, but it is extremely
 difficult to read.  I have attached a screenshot of what I am talking
 about.

 Can anyone point me in the right direction on how to fix this?  I
 would like to use the correct commands so that I don't mess anything
 up.  Right now I have resorted to running menuconfig down in my build
 directory where the .config file is stored with the kernel source.

 Thoughts?

Try:

OE_TERMINAL = xterm

in your local.conf

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

[yocto] Problem genrerating module autoloading commands

[Marc Ferland]

Hi,

I'm having trouble generating the module auto-loading instructions in
/etc for one of my modules. I have already many modules that all work
fine, but for some reason this one does not get listed in /etc/modules
nor /etc/modules-load.d.

The only thing that distinguishes this module from the other ones is that
it has the same name has the MACHINE and layer. So basically I have
something like:

build/conf/local.conf:
MACHINE = foo

poky/meta-foo/conf/machine/foo.conf:
module_autoload_foo = foo

The module gets built correctly and is included in the images. Running
'modprobe foo' works as intended on the target hardware.

Did I fall in some edge case?

Regards,

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

Re: [yocto] Problem genrerating module autoloading commands

[Marc Ferland]

Martin Jansa martin.ja...@gmail.com writes:

 On Thu, Oct 18, 2012 at 11:13:13AM -0400, Marc Ferland wrote:
 Hi,
 
 I'm having trouble generating the module auto-loading instructions in
 /etc for one of my modules. I have already many modules that all work
 fine, but for some reason this one does not get listed in /etc/modules
 nor /etc/modules-load.d.
 
 The only thing that distinguishes this module from the other ones is that
 it has the same name has the MACHINE and layer. So basically I have
 something like:
 
 build/conf/local.conf:
 MACHINE = foo
 
 poky/meta-foo/conf/machine/foo.conf:
 module_autoload_foo = foo
 
 The module gets built correctly and is included in the images. Running
 'modprobe foo' works as intended on the target hardware.
 
 Did I fall in some edge case?

 Does foo have any '-' or '_'?

No. Just lower case letters.
Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] lm-sensors not available as a package?

[Marc Ferland]

Jonathan Haws jonathan.h...@sdl.usu.edu writes:

 Marc,

 If you have a working recipe, I would love to see it.  Maybe you have
 already solved some of the issues I have been seeing.

 I have a recipe that installs the software, however, I would like to
 have it run sensors-detect on first boot as well as install the
 lm_sensors.init script to /etc/init.d.  My recipe now looks like this:

Hi Jonathan,

I have posted a firt version of my recipe to the oe-core mailing
list. You can try this.

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-October/031002.html

I'll probably post a revised version by the end of the week to the
meta-oe mailing list as suggested by Paul and Martin.

Enjoy!

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

Re: [yocto] lm-sensors not available as a package?

[Marc Ferland]

Paul Eggleton paul.eggle...@linux.intel.com writes:

 On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:
 I would be surprised if a recipe for lm-sensors has not already been
 created, however I cannot find one.  Can someone point me in the right
 direction?
 
 All I can find is a sysstat package that I can include via
 IMAGE_INSTALL_append, however I cannot see how I can get the same
 information out of it that lm-sensors gives me.
 
 Has anyone got lm-sensors included in their image?  If so, can you share the
 recipe?

 Unless anyone else pipes up, my local index suggests that this is something 
 that hasn't yet been brought up-to-date from OE-Classic.

 http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

 Assuming nothing else is available you should be able to use this as a base. 
 There is a brief guide on the main things that need to be changed when 
 updating a recipe from OE-Classic here:

 http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

 If you do come up with an updated recipe we'd love to have it added to 
 meta-oe 
 or some other layer ;)

I have a lmsensors recipe somewhere around here. I'll dust it off and
post it to the oe-core mailing list.

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

Re: [yocto] lm-sensors not available as a package?

[Marc Ferland]

Paul Eggleton paul.eggle...@linux.intel.com writes:

 On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:
 I would be surprised if a recipe for lm-sensors has not already been
 created, however I cannot find one.  Can someone point me in the right
 direction?
 
 All I can find is a sysstat package that I can include via
 IMAGE_INSTALL_append, however I cannot see how I can get the same
 information out of it that lm-sensors gives me.
 
 Has anyone got lm-sensors included in their image?  If so, can you share the
 recipe?

 Unless anyone else pipes up, my local index suggests that this is something 
 that hasn't yet been brought up-to-date from OE-Classic.

 http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

 Assuming nothing else is available you should be able to use this as a base. 
 There is a brief guide on the main things that need to be changed when 
 updating a recipe from OE-Classic here:

 http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

 If you do come up with an updated recipe we'd love to have it added to 
 meta-oe 
 or some other layer ;)

Paul,

In what section should the lmsensors recipe be added? Would 'recipe-bsp'
be ok?

Regards,

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

Re: [yocto] lm-sensors not available as a package?

[Marc Ferland]

Jonathan Haws jonathan.h...@sdl.usu.edu writes:

 I got the oe-classic recipe building with the latest version of
 lm-sensors.  However, I am now running into perl issues - when I try
 to run sensors-detect, I get errors with the @INC paths - strict.pm is
 not found anywhere on the filesystem.  I went back to see if I had
 left out perl support, but it was present and included.  Where is
 strict.pm?  How can I get that in my image?

 Thanks!

You might want to add 'perl-modules' to RDEPENDS_lmsensors-scripts.

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

Re: [yocto] Revision file in images

[Marc Ferland]

Anders Darander and...@chargestorm.se writes:

 * Marc Ferland ferla...@sonatest.com [121012 17:40]:

 Hi,

 Is a revision file populated in the images produced by the build process?
 Something listing the revisions of the different layers used. Just like
 the OE Build Configuration summary.

 As Saul wrote, I don't know any way of getting this info.


 I'd like to easily identify what a target system currently runs.

 In my own project, I'm using something like:


 IMAGE_PREPROCESS_COMMAND += rootfs_update_timestamp ;\
  git describe --dirty --long --always
${IMAGE_ROOTFS}/etc/build ;\
  

 This doesn't explicitly put the SHA1's of the included layers into the
 rootfs, but it does put my the most recent tag from my top-layer,
 together with the number of commits after that tag, and an abreviated version
 of the current commits SHA1 into the file /etc/build. This will give me
 all info I need.

FYI, I was able to put the SHA1 of each meta data layer by doing:

def print_layers_version(d):
layertext = Configured metadata layers:\n%s\n % 
'\n'.join(get_layers_branch_rev(d))
return layertext

IMAGE_PREPROCESS_COMMAND += echo ${@print_layers_version(d)}  /
${IMAGE_ROOTFS}/etc/build; 

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

Re: [yocto] Build failure using Master branch for Crownbay

[Marc Ferland]

Jim Abernathy jfaberna...@gmail.com writes:

 On 10/11/2012 11:10 AM, Jim Abernathy wrote:
 I just did a pull today and tried to rebuild Crownbay BSP which I
 successfully built yesterday.  I'm looking for a case where the
 rebuild fails on a previously successful build with just running
 bitbake core-image-sato without deleting any files or cleaning
 anything, as I've been instructed previously.

 I got such a failure today and the console log is below.  I'll hold
 off deleting the build directory and rebuilding as I usually do when
 this happens, until I hear from the experts on how to proceed.

 JIm A

 Since I didn't get any response, I went ahead and did bitbake -c 
 cleansstate emgd-driver-bin and then did a bitbake core-image-sato.
 The image built fine and booted fine.

Had the same problem today. I'm using the denzil branch.

This is probably worth opening a bug report.

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

[yocto] Revision file in images

[Marc Ferland]

Hi,

Is a revision file populated in the images produced by the build process?
Something listing the revisions of the different layers used. Just like
the OE Build Configuration summary.

I'd like to easily identify what a target system currently runs.

Regards,

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

Re: [yocto] Runtime update of yocto-images

[Marc Ferland]

Julian Scheel jul...@jusst.de writes:

 Hi,

 I wonder how everyone deals with runtime updates of yocto based
 systems? Are you using the package management for this? Actually I'd
 prefer a one-file update, which would replace the whole rootfs. I
 think having a squashfs image containing the rootfs and place it on
 some ext-partition would be nice. One would just need an initramfs,
 that could mount the squashfs file as root.

 Is anyone following an approach like this?

This is the approach that I've taken. Works fairly well.

You will need to:
- Create your own init script (look in:
meta/recipes-core/initrdscripts/files as a starting point)
- Patch your kernel with AUFS/unionfs/overlayfs if you want something
that is not 100% volatile.
- Create an install/update script that actually takes care of updating
your squashfs rootfs from the initramfs.

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

[yocto] About bug 2331

[Marc Ferland]

Hi,

I'm currently trying to create a live system with squashfs+unionfs and
I stumbled on the same bug described here:

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

I was wondering if there was a plan to resolve this issue for 1.3?

Regards,

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

Re: [yocto] About bug 2331

[Marc Ferland]

Saul Wold s...@linux.intel.com writes:

 On 09/19/2012 01:41 PM, Marc Ferland wrote:
 Hi,

 I'm currently trying to create a live system with squashfs+unionfs and
 I stumbled on the same bug described here:

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

 I was wondering if there was a plan to resolve this issue for 1.3?

 Marc,

 It seems to be marked as resolved and verified, is there still and
 issue?  If so we need to reopen this bug.  Or are you referring to the
 underlying issue?

I was referring to the underlying issue.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] About bug 2331

[Marc Ferland]

Saul Wold s...@linux.intel.com writes:

 On 09/19/2012 01:53 PM, Marc Ferland wrote:
 Saul Wold s...@linux.intel.com writes:

 On 09/19/2012 01:41 PM, Marc Ferland wrote:
 Hi,

 I'm currently trying to create a live system with squashfs+unionfs and
 I stumbled on the same bug described here:

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

 I was wondering if there was a plan to resolve this issue for 1.3?

 Marc,

 It seems to be marked as resolved and verified, is there still and
 issue?  If so we need to reopen this bug.  Or are you referring to the
 underlying issue?

 I was referring to the underlying issue.


 No, unfortunately it seems that did not have visibility, I think bug
 1487 is open against that issue, at least with an ISO image, which is
 what got partially reverted.  I think the issue was upstream unionfs,
 do you know if any changes to resolve the problem upstream?

Unfortunately no. Maybe I'll have more chance using aufs or maybe
overlayfs. Unionfs looks pretty much dead... I'm probably better off
without it!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Replace netbase with connman

[Marc Ferland]

Hi,

I'm trying to replace netbase from my image with connman and I need help
on how to proceed. So far I see that:
- udev includes some event scripts that bring up interfaces
- netbase is included by default in core-image (which I use).

Should I remove both the udev scripts and netbase from my image and just
install connman?

So far I successfully removed the udev scripts with a bbappend to udev
but I don't know how to remove netbase from the 'core-boot' task.

Also, will connman work when booting with nfsroot?

Thanks,

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

Re: [yocto] adding drivers to the kernel

[Marc Ferland]

Jim Abernathy jfaberna...@gmail.com writes:

 If I need to add a driver for a networking device that should be in
 the 3.0 kernel, but seems to be turned off, I usually follow the
 example in sections B.2.3 in the Development Manual. When I get to the
 stage of running bitbake linux-yocto -c menuconfig, I can search for
 my device with the / command and search for CONFIG_RTL8192CE and I
 find this:

 Symbol: RTL8192CE [=n] │
 │ Type : tristate │
 │ Prompt: Realtek RTL8192CE/RTL8188CE Wireless Network Adapter │
 │ Defined at drivers/net/wireless/rtlwifi/Kconfig:1 │
 │ Depends on: NETDEVICES [=y]  WLAN [=y]  MAC80211 [=n]  PCI [=y] │
 │ Location: │
 │ - Device Drivers │
 │ - Network device support (NETDEVICES [=y]) │
 │ - Wireless LAN (WLAN [=y]) │
 │ Selects: FW_LOADER [=y]  RTLWIFI [=n]  RTL8192C_COMMON [=n]

 However, I can't find this device where is should be or anywhere in
 the .config file. I've tried just adding the CONFIG_RTL8192CE=y to a
 config fragment file anyway and that didn't work. After building the
 image, the .config still didn't have the CONFIG_RTL8192CE=y. The 3.0
 kernel should have support for the RTL8192CE devices.

 Also if I manual add CONFIG_RTL8192CE=y to the .config file and then
 compile and build the kernel, the RTL8192CE parameter is removed from
 the .config file after the kernel build.

You probably need to enable MAC80211 first. Your RTL8192CE driver will
be selectable afterwards.
Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] psplash: Trivial, cleanup some comments.

[Marc Ferland]

This patch fixes some minor comment mistakes.

Signed-off-by: Marc Ferland ferla...@sonatest.com
---
 psplash-colors.h  |2 +-
 psplash-console.c |2 +-
 psplash-console.h |2 +-
 psplash-fb.c  |2 +-
 psplash-fb.h  |2 +-
 psplash-write.c   |2 +-
 psplash.c |4 ++--
 psplash.h |2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/psplash-colors.h b/psplash-colors.h
index d701089..d574afa 100644
--- a/psplash-colors.h
+++ b/psplash-colors.h
@@ -1,5 +1,5 @@
 /*
- *  pslash - a lightweight framebuffer splashscreen for embedded devices.
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices.
  *
  *  Copyright (c) 2012 sleep(5) ltd
  *  Author: Tomas Frydrych to...@sleepfive.com
diff --git a/psplash-console.c b/psplash-console.c
index 9b7dfb9..1ee49e6 100644
--- a/psplash-console.c
+++ b/psplash-console.c
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
diff --git a/psplash-console.h b/psplash-console.h
index c444d27..2cf7555 100644
--- a/psplash-console.h
+++ b/psplash-console.h
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
diff --git a/psplash-fb.c b/psplash-fb.c
index 71740cd..72505b0 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -1,5 +1,5 @@
 /*
- *  pslash - a lightweight framebuffer splashscreen for embedded devices.
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices.
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
diff --git a/psplash-fb.h b/psplash-fb.h
index ef5b39e..244ab67 100644
--- a/psplash-fb.h
+++ b/psplash-fb.h
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
diff --git a/psplash-write.c b/psplash-write.c
index 3fdba95..1a81270 100644
--- a/psplash-write.c
+++ b/psplash-write.c
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
diff --git a/psplash.c b/psplash.c
index 09cf0d0..aa6568a 100644
--- a/psplash.c
+++ b/psplash.c
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
@@ -263,7 +263,7 @@ main (int argc, char** argv)
  goto fb_fail;
   }
 
-  /* Clear the background with #ecece1 */
+  /* Clear screen with background color */
   psplash_fb_draw_rect (fb, 0, 0, fb-width, fb-height,
 PSPLASH_BACKGROUND_COLOR);
 
diff --git a/psplash.h b/psplash.h
index f78c117..9b60ce1 100644
--- a/psplash.h
+++ b/psplash.h
@@ -1,5 +1,5 @@
 /* 
- *  pslash - a lightweight framebuffer splashscreen for embedded devices. 
+ *  psplash - a lightweight framebuffer splashscreen for embedded devices. 
  *
  *  Copyright (c) 2006 Matthew Allum mal...@o-hand.com
  *
-- 
1.7.5.4

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

Re: [yocto] xserver-xorg

[Marc Ferland]

Laurentiu Palcu laurentiu.pa...@linux.intel.com writes:

 Hi Marc,

 Apparently, these tests were removed upstream. As we are going to
 upgrade xserver-xorg package to 1.12.3, those fixes will be included
 too. However, if you need the fix now, I attached the patch.


Just in case someone else stumbles on this issue, setting the preferred
version of xserver-xorg to 1.11.2 in the machine.conf also solves the
issue.

PREFERRED_VERSION_xserver-xorg ?= 1.11.2

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

[yocto] xserver-xorg

[Marc Ferland]

Hi all,

I'm having trouble building the xserver-xorg package. The build fails
with:

| render2.c: In function '__glXDisp_Map1d':
| render2.c:104:5: error: the comparison will always evaluate as 'true' for the 
address of 'u1' will never be NULL [-Werror=address]
| render2.c:105:5: error: the comparison will always evaluate as 'true' for the 
address of 'u2' will never be NULL [-Werror=address]
| render2.c: In function '__glXDisp_Map2d':
| render2.c:147:5: error: the comparison will always evaluate as 'true' for the 
address of 'u1' will never be NULL [-Werror=address]
| render2.c:148:5: error: the comparison will always evaluate as 'true' for the 
address of 'u2' will never be NULL [-Werror=address]
| render2.c:149:5: error: the comparison will always evaluate as 'true' for the 
address of 'v1' will never be NULL [-Werror=address]
| render2.c:150:5: error: the comparison will always evaluate as 'true' for the 
address of 'v2' will never be NULL [-Werror=address]
| cc1: some warnings being treated as errors

The target machine is a x86_64. Looks like the compiler doesn't like how
the __GLX_GET_DOUBLE macro tests the address of stack variables against
NULL.

I would like to know if there is a patch upstream or if this is a known
issue? What surprises me the most is that this machine looks a lot like
the meta-sugarbay which builds correctly.

Regards,

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

Re: [yocto] FW: Unable to start X on Yocto 1.2

[Marc Ferland]

Murugayah, Kanapathy kanapathy.muruga...@intel.com writes:

 Hi I am having some issues with Yocto 1.2 on Crownbay. 

 After building an image (core-image-sato) with crownbay bsp + emgd, it
 fails to startx. 

Your problem is surely related to this:
[1442948.073] (II) LoadModule: emgd
[1442948.075] (WW) Warning, couldn't open module emgd
[1442948.075] (II) UnloadModule: emgd
[1442948.075] (EE) Failed to load module emgd (module does not exist,
0)

Looks like the module is absent from your image. Check that you
correctly selected crownbay and not crownbay-noemgd in your
local.conf.

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

Re: [yocto] basic recipe building - iperf

[Marc Ferland]

jfabernathy jfaberna...@gmail.com writes:

I needed to do some network performance testing on a Crownbay board and
needed iperf in that environment.  Since I had the core-image-sato-sdk
image created, I just booted that and took the tarball from Sourceforge
and built it  per the readme file instructions:
./configure
make
make install
After I completed my test, I thought about why not put that in my list
of personal recipes.  I found the previous version of iperf in the
openembedded collection of benchmark recipes and just copied it over.
It built and worked fine.  There were a lot of items in the .bb that I
didn't understand, so I thought for fun I'd just try to build a recipe
for iperf 2.0.5 and see what happened.  My recipe is simple, mostly
taken from the openembedded 2.0.4 version had stripped down:

Hi JF,

I add the same problem you had with the man page stuff, try this patch.

Marc
diff --git iperf-2.0.5/man/Makefile.am iperf-2.0.5/man/Makefile.am
index ed97bc6..728873f 100644
--- iperf-2.0.5/man/Makefile.am
+++ iperf-2.0.5/man/Makefile.am
@@ -1,2 +1 @@
-man_MANS = iperf.1
-dist_man_MANS = $(man_MANS)
+dist_man_MANS = iperf.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] QtCreator and Yocto SDK

[Marc Ferland]

Hi,

I'm currently looking for instructions on how to integrate a Yocto SDK
with QtCreator.

I've successfully built my application by sourcing the environment file
and simply calling qmake/make, but QtCreator refuses to build the
project.

Any ideas/tips?

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

Re: [yocto] Adding features to a machine

[Marc Ferland]

On Thu, Dec 8, 2011 at 4:02 PM, Darren Hart dvh...@linux.intel.com wrote:



 On 12/08/2011 12:36 PM, Marc Ferland wrote:
  On Thu, Dec 8, 2011 at 2:50 PM, Darren Hart dvh...@linux.intel.com
  mailto:dvh...@linux.intel.com wrote:
 
  On 12/08/2011 11:13 AM, Marc Ferland wrote:
   Hi,
  
   I have a crownbay based machine here and I would like to add the
   bluetooth machine feature to it. Do I have to create a whole new
  BSP for
   this? I haven't seen any examples showing how to _modify_ a machine
   description.
 
 
  Have you tried modifying either MACHINE_FEATURES_crownbay or
  KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this
  myself, but I believe it should work.
 
 
  Tried both.
 
  With MACHINE_FEATURES_crownbay += bluetooth I get:
  NOTE: Resolving any missing task queue dependencies
  ERROR: Nothing RPROVIDES 'modutils-depmod' (but
  /home/marc/dev/poky/poky-src/meta/recipes-kernel/update-modules/
 update-modules_1.0.bb
  http://update-modules_1.0.bb RDEPENDS on or otherwise requires it)
  NOTE: Runtime target 'modutils-depmod' is unbuildable, removing...

 Hrm, yes, I don't see what provides modutils-depmod. I believe you may
 have found a bug. Mind filing one?

  Missing or unbuildable dependency chain was: ['modutils-depmod']
  NOTE: Runtime target 'perf' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['perf', 'update-modules',
  'modutils-depmod']
  NOTE: Runtime target 'task-core-tools-profile' is unbuildable,
 removing...
  Missing or unbuildable dependency chain was: ['task-core-tools-profile',
  'perf', 'update-modules', 'modutils-depmod']
  ERROR: Required build target 'sonatest-test-image' has no buildable
  providers.
  Missing or unbuildable dependency chain was: ['sonatest-test-image',
  'task-core-tools-profile', 'perf', 'update-modules', 'modutils-depmod']
 
  With KERNEL_FEATURES_crownbay += bluetooth, I get the following when
  recompiling the kernel:
  Log data follows:
  | Deleted branch meta-temp (was 620917d).
  | WARNING: addon feature bluetooth was not found
  | ERROR: required features were not found. aborting
 
  BTW, I did not find any precise kernel feature for bluetooth when
  looking in
 
 builddir/tmp/work/crownbay-poky-linux/linux-yocto/linux/meta/cfg/kernel-cache/

 Right, you would need to add something if you need a driver that isn't
 listed there or in the crownbay BSP.

 Sorry to bring this up again, but since the documentation states that
bluetooth is a valid MACHINE_FEATURE option and no configuration fragment
is present to support this feature does that mean that it cannot really
work by simply adding the option? Could this be a bug/missing feature?

BTW, I got bluetooth working but I add to create a config fragment like you
suggested which is kind of confusing since a MACHINE_FEATURE already exists
for this functionality.

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

[yocto] Adding features to a machine

[Marc Ferland]

Hi,

I have a crownbay based machine here and I would like to add the bluetooth
machine feature to it. Do I have to create a whole new BSP for this? I
haven't seen any examples showing how to _modify_ a machine description.

Regards,

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

[yocto] Native build tools question

[Marc Ferland]

Hi,

I'm currently writing a recipe for the visualization toolkit (vtk).

To compile, this library invokes executables that are generated on-the-fly
by the compilation process (a little bit like Qt and qmake).

The path to these executables can be specified to cmake when building vtk.
So far I was able to make it work by hard-coding this tools directory in
my recipe to a path on my local machine. It works, but it is not very
portable.

What's the official way to handle such libraries?

Should I first do a native build, then use this native build directory when
cross-compiling? If so, is there any examples I should look into?

Regards,

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

[yocto] Adding line to ld.so.conf

[Marc Ferland]

Hi,

What's the proper way to add a line to the ld.so.conf file for a new
library I am adding?

Regards,

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

Re: [yocto] Adding line to ld.so.conf

[Marc Ferland]

On Mon, Nov 21, 2011 at 11:04 AM, Khem Raj raj.k...@gmail.com wrote:

 On Mon, Nov 21, 2011 at 7:35 AM, Marc Ferland marc.ferl...@gmail.com
 wrote:
  Hi,
 
  What's the proper way to add a line to the ld.so.conf file for a new
 library
  I am adding?
 

 if the libraries is in standard paths you dont have to add it but if
 its in a special path
 then just add the absolute path to the library e.g. /opt/lib if your
 library is in /opt/lib
 and then run ldconfig


What I meant was how to do it in a recipe file. I don't want to modify
ld.so.conf and run ldconfig each time I create a new image.

Regards,

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

[yocto] QIconvCodec error

[Marc Ferland]

Hi,

I'm currently testing my application (which uses Qt) on an image which
inherits core-image with a qemux86 target. Everything built without errors
but each time I start my application (or any other Qt application) I get:

QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed
for BOM: Bad file descriptor
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open
failed
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open
failed

Any idea? Would installing libiconv fix this? Shouldn't eglibc provide this?

Regards,

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

[yocto] Change splash screen

[Marc Ferland]

 Hi,

What's the proper way to change the splash screen in Yocto? I have
re-generated the psplash-poky-img.h file but I don't know where to put this
file in my local layer. I guess this question also applies to all recipes
containing references to local files in the SRC_URI.

I could replace the current file with the one I just generated but that
doesn't seem right...!

Regards,

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

[yocto] [PATCH] Add SMP support to crownbay.

[Marc Ferland]

This patch fixes Yocto BUG #1015. It adds support for SMP on the crownbay 
architecture from the meta-intel branch.
---
 .../linux/linux-yocto-stable_git.bbappend  |2 ++
 .../recipes-kernel/linux/linux-yocto_git.bbappend  |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
index 8309478..44f892f 100644
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
@@ -2,6 +2,8 @@ FILESEXTRAPATHS := ${FILESEXTRAPATHS}:${THISDIR}/${PN}
 
 COMPATIBLE_MACHINE_crownbay = crownbay
 KMACHINE_crownbay  = crownbay
+KERNEL_FEATURES_append_crownbay +=  cfg/smp.scc
 
 COMPATIBLE_MACHINE_crownbay-noemgd = crownbay-noemgd
 KMACHINE_crownbay-noemgd  = crownbay
+KERNEL_FEATURES_append_crownbay-noemgd +=  cfg/smp.scc
diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
index 176acd3..387c207 100644
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
@@ -2,6 +2,8 @@ FILESEXTRAPATHS := ${FILESEXTRAPATHS}:${THISDIR}/${PN}
 
 COMPATIBLE_MACHINE_crownbay = crownbay
 KMACHINE_crownbay  = yocto/standard/crownbay
+KERNEL_FEATURES_append_crownbay +=  cfg/smp.scc
 
 COMPATIBLE_MACHINE_crownbay-noemgd = crownbay-noemgd
 KMACHINE_crownbay-noemgd  = yocto/standard/crownbay
+KERNEL_FEATURES_append_crownbay-noemgd +=  cfg/smp.scc
-- 
1.7.1

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

Re: [yocto] [PATCH] Add SMP support to crownbay.

[Marc Ferland]

Signed-off-by: Marc Ferland ferla...@sonatest.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] libboost has wrong architecture

[Marc Ferland]

Hi,

I'm trying to build an image for the meta-intel/meta-crownbay machine
on ubuntu 10.10 (x86_64) and I'm getting a QA error with libboost:


wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_filesystem.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_graph.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_date_time.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_iostreams.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_unit_test_framework.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_regex.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_signals.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_prg_exec_monitor.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_program_options.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_system.so.1.44.0
wrong architecture,
boost-dbg,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-dbg/usr/lib/.debug/libboost_thread.so.1.44.0
wrong architecture,
boost-date-time,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-date-time/usr/lib/libboost_date_time.so.1.44.0
wrong architecture,
boost-filesystem,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-filesystem/usr/lib/libboost_filesystem.so.1.44.0
wrong architecture,
boost-graph,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-graph/usr/lib/libboost_graph.so.1.44.0
wrong architecture,
boost-iostreams,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-iostreams/usr/lib/libboost_iostreams.so.1.44.0
wrong architecture,
boost-program-options,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-program-options/usr/lib/libboost_program_options.so.1.44.0
wrong architecture,
boost-regex,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-regex/usr/lib/libboost_regex.so.1.44.0
wrong architecture,
boost-signals,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-signals/usr/lib/libboost_signals.so.1.44.0
wrong architecture,
boost-system,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-system/usr/lib/libboost_system.so.1.44.0
wrong architecture,
boost-test,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-test/usr/lib/libboost_unit_test_framework.so.1.44.0
wrong architecture,
boost-test,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-test/usr/lib/libboost_prg_exec_monitor.so.1.44.0
wrong architecture,
boost-thread,/work/atom-poky-linux/boost-1.44.0-r0/packages-split/boost-thread/usr/lib/libboost_thread.so.1.44.0

The build then continues and fails when libzypp tries to link with this library:

/home/marc/g3/yocto/buildo/tmp/sysroots/x86_64-linux/usr/libexec/atom-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
skipping incompatible
/home/marc/g3/yocto/buildo/tmp/sysroots/crownbay/usr/lib/libboost_signals-mt.so
when searching for -lboost_signals-mt
/home/marc/g3/yocto/buildo/tmp/sysroots/x86_64-linux/usr/libexec/atom-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
skipping incompatible
/home/marc/g3/yocto/buildo/tmp/sysroots/crownbay/usr/lib/libboost_signals-mt.a
when searching for -lboost_signals-mt
/home/marc/g3/yocto/buildo/tmp/sysroots/x86_64-linux/usr/libexec/atom-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
skipping incompatible
/home/marc/g3/yocto/buildo/tmp/sysroots/crownbay/usr/lib/libboost_signals-mt.so
when searching for -lboost_signals-mt
/home/marc/g3/yocto/buildo/tmp/sysroots/x86_64-linux/usr/libexec/atom-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
skipping incompatible
/home/marc/g3/yocto/buildo/tmp/sysroots/crownbay/usr/lib/libboost_signals-mt.a
when searching for -lboost_signals-mt
/home/marc/g3/yocto/buildo/tmp/sysroots/x86_64-linux/usr/libexec/atom-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
cannot find -lboost_signals-mt collect2: ld returned 1 exit status
make[2]: *** [zypp/libzypp.so.810.1.0] Error 1
make[2]: Leaving directory
`/home/marc/g3/yocto/buildo/tmp/work/crownbay-poky-linux/libzypp-0.0-git1+15b6c52260bbc52b3d8e585e271b67e10cc7c433-r9/git'
make[1]: *** [zypp/CMakeFiles/zypp.dir/all] Error 2
make[1]: Leaving directory
`/home/marc/g3/yocto/buildo/tmp/work/crownbay-poky-linux/libzypp-0.0-git1+15b6c52260bbc52b3d8e585e271b67e10cc7c433-r9/git'
make: *** [all] Error 2
FATAL: oe_runmake failed

Any idea how to resolve this?

Regards,

Marc