Re: [yocto] [meta-raspberrypi] Issue with 8250/16550 UART1 access in raspberrypi (meta-raspberrypi)

[Andreas Enbacka]

Hello Andrei,

I attempted to compile the driver as a module, and ismod it after using
wiringPi to configure the pins for uart1 (bcm pins 32/33), however the
system still freeze (freeze occurs when attempting to close Minicom, and
when attempting to switch off hardware flow control which of some reason is
enabled by default when connecting to /dev/ttyS0). I am using kernel
3.18.5+, could this have some impact? Or could some addresses for uart1
require modifications in the driver?

Best regards,
Andreas Enbacka

-Original Message-
From: Andrei Gherzan [mailto:and...@gherzan.ro] 
Sent: 5. kesäkuuta 2015 18:11
To: Andreas Enbacka
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [meta-raspberrypi] Issue with 8250/16550 UART1 access
in raspberrypi (meta-raspberrypi)

Hello Andreas,

I don't have a Compute module to test anything so I'll just say some hints
that might help.

On Thu, Jun 04, 2015 at 03:01:26PM +0300, Andreas Enbacka wrote:
>Hello,
>
>
>After a long break, I have returned to the Yocto project, and generally
>very pleased. A lot of progress has been done since I last used the
>project (two years ago), and now in my opinion everything works very
>smoothly.
>
>
>I have used yocto to build a custom image for the RaspberryPi Compute
>Module. Generally everything works ok, however I am experiencing
>problem with accessing the UART1 port on the raspberryPi. I am using a
>library called wiringPi to put the appropriate GPIO pins in the correct
>mode (alt5) for RXD1/TXD1 (pins 32/33). Also I have used menuconfig to
>enable the 8250/16550 serial port support in the kernel (3.18.5+).
>After booting the image I examined the dmesg output, and it shows
>following information related to 8250/16550:
>
>..
>
>[   1.010958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>
>[   1.013920] serial8250.0: ttyS0 at MMIO 0x20215040 (irq = 29,
>base_baud = 7812500) is a 8250

You will need to configure the pins before starting the driver. And this can
be done either by messing with the DTS or my compiling the driver as module
and insmod it after you configure the pins.

>Then I put the pins 32/33 into alternative mode alt5, and try to
>connect to the port /dev/ttyS0 using minicom (baud 115200). Trying to
>enter something into the Mincom terminal does not give any indications
>on our connected oscilloscope (connected to the relevant pins), however
>change of the alt mode earlier was observed correctly. The serial port
>should not be using any flow control, but when trying to disable the
>flow control using Minicom (it was on by default) freezes the complete
>RaspberryPi system (requiring to disconnect and reconnect power).

I'm not sure about the pin configuration of UART1 function but the
documentation seems to be covering this topic:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM28
35-ARM-Peripherals.pdf

Hope this helps,

--
Andrei Gherzan

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

[yocto] Python3 failure using ctypes

[Peter Bergin]

Hi,

we are currently migrating from daisy to fido and I have experienced trouble 
with the package python3-ctypes. When I try to import the ctypes library on 
target I get the following output:

root@petber2:~# python3
Python 3.3.3 (default, Jun  8 2015, 11:21:29)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.3/ctypes/__init__.py", line 7, in 
from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'

The root cause of this is an error during the build of Python3. From 
tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/temp/log.do_configure:

DEBUG: Executing shell function do_configure
autoreconf: 'configure.ac' or 'configure.in' is required
NOTE: _ctypes failed to autoreconf

The targeted machine for us is i.Mx6 built with the Freescale community BSP but 
I have also been able to reproduce the same thing with just building 
core-image-base for qemux86 only appending python3-ctypes.

Anyone having an idea around this error?

Regards,
/Peter






Peter Bergin



peter.ber...@tritech.se
+46 733 35 21 05


www.tritech.se
+46 31 763 38 00
Nordstadstorget 6
SE-411 05 G?teborg, Sweden
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python3 failure using ctypes

[Burton, Ross]

On 9 June 2015 at 09:27, Peter Bergin  wrote:

> The root cause of this is an error during the build of Python3. From
> tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/temp/log.do_configure:
>
> DEBUG: Executing shell function do_configure
> autoreconf: 'configure.ac' or 'configure.in' is required
> NOTE: _ctypes failed to autoreconf
>
> The targeted machine for us is i.Mx6 built with the Freescale community
> BSP but I have also been able to reproduce the same thing with just
> building core-image-base for qemux86 only appending python3-ctypes.
>

That's odd.  My local builds of python3 appear to be working fine, there's
a python3-ctypes package with a _ctype.so inside, and configure works:

autoreconf: Entering directory `../Python-3.4.3/Modules/_ctypes/libffi'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running:
/data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/autoconf --force
autoreconf: running:
/data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:34: installing './compile'
configure.ac:22: installing './missing'
Makefile.am: installing './depcomp'
autoreconf: running: gnu-configize
autoreconf: Leaving directory `../Python-3.4.3/Modules/_ctypes/libffi'

Can you share the full do_configure log?

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

Re: [yocto] smart 1.4.1 unsolved problem

[George Nita]

On 05/22/2015 12:35 PM, George Nita wrote:

On 05/22/2015 11:43 AM, Paul Eggleton wrote:

Hi George,

On Thursday 21 May 2015 11:44:54 George Nita wrote:

I've reproduced the https://bugs.launchpad.net/smart/+bug/1238492 issue

branch: dizzy
target: p2041rdb

Did any one hit this too?


Did you enable runtime package management (i.e., is
"package-management" in
IMAGE_FEATURES (or indirectly via EXTRA_IMAGE_FEATURES)?) If you're
not sure,
you can use bitbake -e to check.

If it isn't enabled, that would explain the behaviour because
smart/rpm think
that no packages are installed because there is no package database in
the
image.

Cheers,
Paul



Hello Paul,

IMAGE_FEATURES="debug-tweaks ssh-server-dropbear package-management"


When committing the computed changeset smart attempts to install
packages that are in the dependency list but are already installed, and
fails because of it:

root@p2041rdb:~# smart install -y bc
Loading cache...
Updating cache...   
[100%]

Computing transaction...

Installing packages (7):
   bc-1.06-r2.0@ppce500mc
   busybox-1.22.1-r32.0@ppce500mc
   busybox-syslog-1.22.1-r32.0@ppce500mc
   busybox-udhcpc-1.22.1-r32.0@ppce500mc
   libc6-2.20-r0.0@ppce500mc
   update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0@ppce500mc
   update-rc.d-0.7-r5.0@all

2.2MB of package files are needed. 4.4MB will be used.

Fetching packages...
->
http://172.21.3.25/.../update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0.ppce500mc.rpm

update-alternatives-opkg-0.1... 
[ 14%]
-> http://.../rpm/all/update-rc.d-0.7-r5.0.all.rpm
->
http://172.21.3.25/~geni/rpm/.../busybox-udhcpc-1.22.1-r32.0.ppce500mc.rpm
busybox-udhcpc-1.22.1-r32.0.p.. 
[ 28%]
-> http://.../rpm/ppce500mc/bc-1.06-r2.0.ppce500mc.rpm
bc-1.06-r2.0.ppce500mc.rpm  
[ 42%]
-> http://.../rpm/.../busybox-syslog-1.22.1-r32.0.ppce500mc.rpm
busybox-syslog-1.22.1-r32.0.p.. 
[ 57%]
update-rc.d-0.7-r5.0.all.rpm
[ 71%]
-> http://.../rpm/ppce500mc/busybox-1.22.1-r32.0.ppce500mc.rpm
busybox-1.22.1-r32.0.ppce500m.. 
[ 85%]
-> http://.../rpm/ppce500mc/libc6-2.20-r0.0.ppce500mc.rpm
libc6-2.20-r0.0.ppce500mc.rpm   
[100%]



Committing transaction...
Preparing...
[  0%]
error: package
update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0.ppce500mc is already
installed
error: package busybox-1.22.1-r32.0.ppce500mc is already installed
error: package update-rc.d-0.7-r5.0.all is already installed
...


This seems consistent with the reported issue
https://bugs.launchpad.net/smart/+bug/1238492



Thanks,


Hello,

Sorry, my error: I've removed the rpm-sys type channel, the one hosting 
installed packages. After recreating the rpm-sys type channel everything 
worked as expected.


--
Best regards,
George Nita
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] smart 1.4.1 unsolved problem

[Paul Eggleton]

On Tuesday 09 June 2015 12:47:31 George Nita wrote:
> On 05/22/2015 12:35 PM, George Nita wrote:
> > On 05/22/2015 11:43 AM, Paul Eggleton wrote:
> >> Hi George,
> >> 
> >> On Thursday 21 May 2015 11:44:54 George Nita wrote:
> >>> I've reproduced the https://bugs.launchpad.net/smart/+bug/1238492 issue
> >>> 
> >>> branch: dizzy
> >>> target: p2041rdb
> >>> 
> >>> Did any one hit this too?
> >> 
> >> Did you enable runtime package management (i.e., is
> >> "package-management" in
> >> IMAGE_FEATURES (or indirectly via EXTRA_IMAGE_FEATURES)?) If you're
> >> not sure,
> >> you can use bitbake -e to check.
> >> 
> >> If it isn't enabled, that would explain the behaviour because
> >> smart/rpm think
> >> that no packages are installed because there is no package database in
> >> the
> >> image.
> >> 
> >> Cheers,
> >> Paul
> > 
> > Hello Paul,
> > 
> > IMAGE_FEATURES="debug-tweaks ssh-server-dropbear package-management"
> > 
> > 
> > When committing the computed changeset smart attempts to install
> > packages that are in the dependency list but are already installed, and
> > fails because of it:
> > 
> > root@p2041rdb:~# smart install -y bc
> > Loading cache...
> > Updating cache...   
> > [100%]
> > 
> > Computing transaction...
> > 
> > Installing packages (7):
> >bc-1.06-r2.0@ppce500mc
> >busybox-1.22.1-r32.0@ppce500mc
> >busybox-syslog-1.22.1-r32.0@ppce500mc
> >busybox-udhcpc-1.22.1-r32.0@ppce500mc
> >libc6-2.20-r0.0@ppce500mc
> >update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0@ppce500mc
> >update-rc.d-0.7-r5.0@all
> > 
> > 2.2MB of package files are needed. 4.4MB will be used.
> > 
> > Fetching packages...
> > ->
> > http://172.21.3.25/.../update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0
> > .ppce500mc.rpm
> > 
> > update-alternatives-opkg-0.1... 
> > [ 14%]
> > -> http://.../rpm/all/update-rc.d-0.7-r5.0.all.rpm
> > ->
> > http://172.21.3.25/~geni/rpm/.../busybox-udhcpc-1.22.1-r32.0.ppce500mc.rpm
> > busybox-udhcpc-1.22.1-r32.0.p.. 
> > [ 28%]
> > -> http://.../rpm/ppce500mc/bc-1.06-r2.0.ppce500mc.rpm
> > bc-1.06-r2.0.ppce500mc.rpm  
> > [ 42%]
> > -> http://.../rpm/.../busybox-syslog-1.22.1-r32.0.ppce500mc.rpm
> > busybox-syslog-1.22.1-r32.0.p.. 
> > [ 57%]
> > update-rc.d-0.7-r5.0.all.rpm
> > [ 71%]
> > -> http://.../rpm/ppce500mc/busybox-1.22.1-r32.0.ppce500mc.rpm
> > busybox-1.22.1-r32.0.ppce500m.. 
> > [ 85%]
> > -> http://.../rpm/ppce500mc/libc6-2.20-r0.0.ppce500mc.rpm
> > libc6-2.20-r0.0.ppce500mc.rpm   
> > [100%]
> > 
> > 
> > 
> > Committing transaction...
> > Preparing...
> > [  0%]
> > error: package
> > update-alternatives-opkg-0.1.8+git0+eae0d8fa44-r0.0.ppce500mc is already
> > installed
> > error: package busybox-1.22.1-r32.0.ppce500mc is already installed
> > error: package update-rc.d-0.7-r5.0.all is already installed
> > ...
> > 
> > 
> > This seems consistent with the reported issue
> > https://bugs.launchpad.net/smart/+bug/1238492
> > 
> 
> Sorry, my error: I've removed the rpm-sys type channel, the one hosting
> installed packages. After recreating the rpm-sys type channel everything
> worked as expected.

Ah yes, that would do it... glad you managed to resolve the issue, I'll 
remember to ask about that in future :)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python3 failure using ctypes

[Peter Bergin]

Hi,

On 06/09/2015 11:28 AM, Burton, Ross wrote:

On 9 June 2015 at 09:27, Peter Bergin 
mailto:peter.ber...@tritech.se>> wrote:
The root cause of this is an error during the build of Python3. From 
tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/temp/log.do_configure:

DEBUG: Executing shell function do_configure
autoreconf: 'configure.ac' or 
'configure.in' is required
NOTE: _ctypes failed to autoreconf

The targeted machine for us is i.Mx6 built with the Freescale community BSP but 
I have also been able to reproduce the same thing with just building 
core-image-base for qemux86 only appending python3-ctypes.

That's odd.  My local builds of python3 appear to be working fine, there's a 
python3-ctypes package with a _ctype.so inside, and configure works:


It seems that you are building Python 3.4.3. Recipes included in fido is 
version 3.3.3.

autoreconf: Entering directory `../Python-3.4.3/Modules/_ctypes/libffi'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: 
/data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/autoconf --force
autoreconf: running: 
/data/poky-master/tmp/sysroots/x86_64-linux/usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:34: installing './compile'
configure.ac:22: installing './missing'
Makefile.am: installing './depcomp'
autoreconf: running: gnu-configize
autoreconf: Leaving directory `../Python-3.4.3/Modules/_ctypes/libffi'

Can you share the full do_configure log?

Ross

I attach the log.do_configure files from a build. See if you can find something 
odd in it.

Thanks,
/Peter

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_copy_aclocals
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Python function autotools_copy_aclocals finished
DEBUG: Executing shell function do_configure
autoreconf: 'configure.ac' or 'configure.in' is required
NOTE: _ctypes failed to autoreconf
NOTE: Using icecc
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey 
   and Alexandre Duret-Lutz .
AUTOV is 1
NOTE: Executing ACLOCAL="aclocal 
--system-acdir=/work/yocto/fido/qep/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/build/aclocal-copy/"
 autoreconf --verbose --install --force --exclude=autopoint
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
--system-acdir=/work/yocto/fido/qep/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/build/aclocal-copy/
 --force 
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: 
/work/yocto/fido/qep/tmp/sysroots/x86_64-linux/usr/bin/autoconf --force
autoreconf: running: 
/work/yocto/fido/qep/tmp/sysroots/x86_64-linux/usr/bin/autoheader --force
autoreconf: configure.ac: not using Automake
autoreconf: running: gnu-configize
autoreconf: Leaving directory `.'
NOTE: Running 
/work/yocto/fido/qep/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/python3/3.3.3-r1.0/Python-3.3.3/configure
  --build=x86_64-linux--host=arm-poky-linux-gnueabi 
  --target=arm-poky-linux-gnueabi --prefix=/usr 
  --exec_prefix=/usr  --bindir=/usr/bin   
--sbindir=/usr/sbin --libexecdir=/usr/lib/python3   
--datadir=/usr/share--sysconfdir=/etc   
--sharedstatedir=/com   --localstatedir=/var
--libdir=/usr/lib   --includedir=/usr/include   
--oldincludedir=/usr/include--infodir=/usr/share/info   
--mandir=/usr/share/man --disable-silent-rule

Re: [yocto] Limit RAM for Linux

[Edward Wingate]

Thanks, Nathan, for your help. It worked, with a little oddity I don't
understand.

In my uEnv.txt, I set both fdt_high and initrd_high to 0x1000 and
fdt/initrd are now loaded to 1st 256 MB:
   Loading Kernel Image ... OK
   Loading Ramdisk to 0f44c000, end 02f2 ... OK
   Loading Device Tree to 0f443000, end 0f44bf40 ... OK

However, with bootarg "mem=256MB", the kernel doesn't boot.
With "mem=257M", it does:

/proc/iomem:
-100f : System RAM
   8000-00584b03 : Kernel code
   005b6000-0061d5df : Kernel data

I'd be OK with this, but just want to understand why I can't specify
mem=256M?  I could probably also lower initrd_high and fdt_high a bit
more to make mem=256M work, but why would that be necessary?

Also, in the device tree entry for memory, should I leave "reg = <0x0
0x2000>" or change that to reflect 256MB?  Changing it to "reg =
<0x0 0x1000>" didn't seem to have any effect.  The mem bootarg
seems to be the thing that actually works to limit the amount of
memory Linux sees.


On Mon, Jun 8, 2015 at 9:45 PM, Nathan Rossi  wrote:
> On Tue, Jun 9, 2015 at 4:06 AM, Edward Wingate  wrote:
>
> Those values are generated via u-boot based on the value of fdt_high
> and initrd_high which are set in the u-boot environment. (At least for
> Zynq)
>
> If you have a look at the default environment you will see them set to
> 0x2000:
> http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/zynq-common.h;h=1a52e7d538261a9d36b078d61e00e60bf8918227;hb=HEAD#l217
>
> You can override those environment variables with your uEnv.txt file,
> setting it to 0x1000 will make sure they fdt/initrd is loaded into
> the first 256M.
>
> Regards,
> Nathan
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Limit RAM for Linux

[Edward Wingate]

Typo in last email, I used "mem=256M", not "mem=256MB"

On Tue, Jun 9, 2015 at 9:03 AM, Edward Wingate  wrote:
> Thanks, Nathan, for your help. It worked, with a little oddity I don't
> understand.
>
> In my uEnv.txt, I set both fdt_high and initrd_high to 0x1000 and
> fdt/initrd are now loaded to 1st 256 MB:
>Loading Kernel Image ... OK
>Loading Ramdisk to 0f44c000, end 02f2 ... OK
>Loading Device Tree to 0f443000, end 0f44bf40 ... OK
>
> However, with bootarg "mem=256MB", the kernel doesn't boot.
> With "mem=257M", it does:
>
> /proc/iomem:
> -100f : System RAM
>8000-00584b03 : Kernel code
>005b6000-0061d5df : Kernel data
>
> I'd be OK with this, but just want to understand why I can't specify
> mem=256M?  I could probably also lower initrd_high and fdt_high a bit
> more to make mem=256M work, but why would that be necessary?
>
> Also, in the device tree entry for memory, should I leave "reg = <0x0
> 0x2000>" or change that to reflect 256MB?  Changing it to "reg =
> <0x0 0x1000>" didn't seem to have any effect.  The mem bootarg
> seems to be the thing that actually works to limit the amount of
> memory Linux sees.
>
>
> On Mon, Jun 8, 2015 at 9:45 PM, Nathan Rossi  wrote:
>> On Tue, Jun 9, 2015 at 4:06 AM, Edward Wingate  wrote:
>>
>> Those values are generated via u-boot based on the value of fdt_high
>> and initrd_high which are set in the u-boot environment. (At least for
>> Zynq)
>>
>> If you have a look at the default environment you will see them set to
>> 0x2000:
>> http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/zynq-common.h;h=1a52e7d538261a9d36b078d61e00e60bf8918227;hb=HEAD#l217
>>
>> You can override those environment variables with your uEnv.txt file,
>> setting it to 0x1000 will make sure they fdt/initrd is loaded into
>> the first 256M.
>>
>> Regards,
>> Nathan
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFC] error-report-web error matching

[Michael Wood]

I've recently added a feature which was requested for the 
error-report-web project[1] to add some kind of error matching 
mechanism, this is now live on http://errors.yoctoproject.org


I'd be interested to hear If anyone has feedback regarding the similar 
errors matching, whether it's useful or has too many false positives etc.


The matching threshold value can be tweaked, I've currently just set it 
to a threshold that seemed OK to me, but would be good if those with 
more experienced eyes could have a glance over.


Thanks,

Michael

[1] http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Build available for QA

[Poky Build User]

-e 
A build identified as needing QA has finished on the autobuilder. This
build is located at:

 
http://autobuilder.yoctoproject.org/pub/nightly/20150609-1


Build hash information: 
meta-intel : b92a0b5c7f6befda61466ad491ff90079bfc95c4 
meta-fsl-arm : 9c0e329fa02673a990630f6e400157ca30e3447f 
meta-minnow : 00a39ed5a5f7037965ff674efe11277bd73416a5 
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 
meta-fsl-ppc : 36bd6ce8c63b8876c96fc1cd50e43863cdc2e44e 
poky : 926de56da9469e3d4ea8349d8e7c9777ae6f93c1 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe question

[Darren Breeze]

Hi

I have sorted this out.

I had assumed the ${D} contained a trailing slash when it didn't

I changed do_install to

do_install() {
install -d ${D}/opt/web_remote
cp -r ${S}/* ${D}/opt/web_remote/.
}

And it worked.

Thanks for all the responses.

Darren B.




On 8/06/2015 3:36 PM, Anders Darander wrote:

* Darren Breeze  [150606 02:52]:

the recipe file is :
-
DESCRIPTION = "Web Remote"
SECTION = "utils"
SRC_URI =
"git://192.168.192.46/mygroup/web_remote.git;protocol=http;branch=master;"
S = "${WORKDIR}/git"
do_install() {
 install -d ${D}opt/web_remote
 cp -r ${S}/* ${D}opt/web_remote/.
}
--
but I keep getting this error
"error: Can't install packagegroup-core-boot-1.0-r17@rk3188: no package
provides web-remote"

You have installed the files under /opt, though there's nothing that
tells the system in which package these files should be installed.

Add a line:

FILES_${PN} += "/opt/we_remote"

to your recipe. This should tell the packaging step that all files under
/opt/web_root should be included in the ${PN}-package.

Cheers,
Anders



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

Re: [yocto] [meta-intel] "Crazy" Xorg memory usage after upgrading from Daisy to Fido

[Chang, Rebecca Swee Fun]

Hi Vincent,

Can you help to comment on this issue mentioned by Chris?
Thanks.

Regards,
Rebecca

> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: 09 June, 2015 12:15 AM
> To: Chang, Rebecca Swee Fun
> Cc: meta-in...@yoctoproject.org; Chris Tapp; Yocto Project; Wold, Saul
> Subject: Re: [meta-intel] "Crazy" Xorg memory usage after upgrading from
> Daisy to Fido
> 
> Rebecca, is this something you or one of your colleagues would be able to
> help with?
> 
> Thanks,
> Paul
> 
> On Friday 05 June 2015 08:29:00 Chris Tapp wrote:
> > I’ve got an application that I’ve had running nicely under Daisy for
> > some time. As Daisy is now a bit old, I decided to move the application to
> Fido.
> > I’m using the meta-intel/isg/valleyisland BSP and also switched to
> > using its Fido branch.
> >
> > The move only required a few minor changes and allowed me to drop a
> > Daisy “updates” layer that I had been using for things like gstreamer-1.0.
> >
> > However, there is one behaviour which is killing me - I keep getting
> > oom-killer events!
> >
> > The application is basically an OpenGL-ES 2.0 application that renders
> > various bits of text, images and streams captured from a gstreamer
> > pipeline at 60 Hz to a 1080 screen.
> >
> > Under Daisy this generally took just under 50% CPU and used a modest
> > percentage of the 4 GB system memory - i.e. no where near running out
> > and usage was just about static.
> >
> > Under Fido the CPU usage is about the same and the memory used by the
> > application itself looks reasonable when compared to Daisy (and usage
> > is static). However, the memory used by XOrg is far from constant or
> > stable - it basically has a VSZ value cycling from about 630m to 2989m
> > with the cycle period being in the order of 5 to 10 seconds. Peaks in
> > XOrg memory usage coincide with stutters in video playback within my
> > app (audio is unaffected).
> >
> > Monitoring /proc/meminfo when this is going on shows that “Shmem”
> > usage is following the same pattern as the memory used by XOrg (i.e.
> > Shmem usage is high at the same time). If the values are plotted on a
> > graph they appear to show that Shmem usage grows linearly and then
> > falls rapidly when nearly all the free memory has been exhausted,
> > perhaps in response to a delayed garbage collection run.
> >
> > Does anyone have any ideas as to what I should be looking at to work
> > out what’s going on?
> >
> > Are there any significant changes between XOrg under Daisy and Fido
> > that could be causing this?
> >
> > Could this be related to the meta-intel video drivers?
> >
> > Any feedback / comments would be really appreciated.
> >
> > Thanks :-)
> >
> > --
> >
> > Chris Tapp
> > opensou...@keylevel.com
> > www.keylevel.com
> >
> > 
> > You can tell you're getting older when your car insurance gets real cheap!
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Brian Hutchinson]

On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson  wrote:
> On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield
>  wrote:
>> On 2015-05-19 07:39 AM, Bruce Ashfield wrote:
>>>
>>> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson 
>>> wrote:

 On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson 
 wrote:
>
> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson 
> wrote:
>>
>> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson
>>  wrote:
>>>
>>>
>>> On May 14, 2015 6:08 PM, "Denys Dmytriyenko"  wrote:


 On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:
>
> On 2015-05-12 10:20 AM, Brian Hutchinson wrote:
>>
>> On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
>>  wrote:
>>>
>>> On 2015-05-11 02:10 PM, Brian Hutchinson wrote:


 On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
  wrote:
>
>
> It is plausible. But in theory, linux-dummy should still provide
> what you need (but since it doesn't build anything, there is
> no abi .. and no modules can be built against it) .. so the
> error isn't graceful.
>
> Bruce



 I can confirm this same problem is happening to me.  I just
 updated
 one of my builds from 1.7 to 1.8 and am also getting my rootfs to
 fail
 due to no abi kernel version:
>>>
>>>
>>>
>>> We still have a race condition in the 1.8 branch for the
>>> population
>>> of the build-artifacts directory.
>>>
>>> If modules start building, they'll race against the population of
>>> the
>>> abiversion, and you may see that message.
>>>
>>> There's a proposed patch for master, but I don't think it is in
>>> fido yet.
>>>
>>> Bruce
>>
>>
>> Hi Bruce,
>>
>> I did some searches and looks like there are a number of 'race'
>> condition fixes but it wasn't obvious which one I may need.  Is it
>> this one:
>
>
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98
>>
>>
>
> That's the one that should make sure that the shared workdir
> (Which has the abiversion) is in place before building any modules.
>
> I can't say that it is exactly your issue, but it is the change
> I was thinking of.


 Brian,

 Were you able to try the above mentioned commit against am180x in
 meta-ti?
 Did
 it solve the missing abi kernel version? Thanks.

 --
 Denys
>>>
>>>
>>> Hi Denys,
>>>
>>> No, I got caught up in something else ... I'll try it tomorrow and
>>> report
>>> back after I cherry pick that commit Bruce mentioned.
>>>
>>> Regards,
>>>
>>> Brian
>>
>>
>> Update.  Not sure if I did this right but this is what I did.  I added
>> master as a remote and cherry picked
>> 02d0a003d603266114512160b209876199241e98.  Next I just went for it and
>> tried to bitbake my image again and got the same result as before.
>> Next I did a bitbake cleanall on virtual/kernel and tried to make my
>> image again and still got the same result.
>>
>> I'm going to leave this build as is and setup a new one using 1.8
>> master and see if I get the same thing again.  I'll leave this broken
>> build alone for a while in case someone wants me to try something with
>> it to fix it.
>>
>> Regards,
>>
>> Brian
>
>
> Yet another update ... I did a fresh checkout of master and tried to
> build and had the same kernelabiversion error:
>
> WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for
> now###
>| ETA:
> 00:00:28
> WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now
> WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for
> now
>
>   | ETA:  00:00:26
> Parsing recipes: 100%
>
> |##|
> Time: 00:01:02
> Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303
> targets, 182 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> NOTE: multiple providers are available for u-boot (u-boot,
> u-boot-glsdk, u-boot-ti-staging)
> NOTE: c

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 2015-06-09 9:12 PM, Brian Hutchinson wrote:

On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson  wrote:

On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield
 wrote:

On 2015-05-19 07:39 AM, Bruce Ashfield wrote:


On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson 
wrote:


On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson 
wrote:


On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson 
wrote:


On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson
 wrote:



On May 14, 2015 6:08 PM, "Denys Dmytriyenko"  wrote:



On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:


On 2015-05-12 10:20 AM, Brian Hutchinson wrote:


On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
 wrote:


On 2015-05-11 02:10 PM, Brian Hutchinson wrote:



On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
 wrote:



It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.

Bruce




I can confirm this same problem is happening to me.  I just
updated
one of my builds from 1.7 to 1.8 and am also getting my rootfs to
fail
due to no abi kernel version:




We still have a race condition in the 1.8 branch for the
population
of the build-artifacts directory.

If modules start building, they'll race against the population of
the
abiversion, and you may see that message.

There's a proposed patch for master, but I don't think it is in
fido yet.

Bruce



Hi Bruce,

I did some searches and looks like there are a number of 'race'
condition fixes but it wasn't obvious which one I may need.  Is it
this one:





http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98





That's the one that should make sure that the shared workdir
(Which has the abiversion) is in place before building any modules.

I can't say that it is exactly your issue, but it is the change
I was thinking of.



Brian,

Were you able to try the above mentioned commit against am180x in
meta-ti?
Did
it solve the missing abi kernel version? Thanks.

--
Denys



Hi Denys,

No, I got caught up in something else ... I'll try it tomorrow and
report
back after I cherry pick that commit Bruce mentioned.

Regards,

Brian



Update.  Not sure if I did this right but this is what I did.  I added
master as a remote and cherry picked
02d0a003d603266114512160b209876199241e98.  Next I just went for it and
tried to bitbake my image again and got the same result as before.
Next I did a bitbake cleanall on virtual/kernel and tried to make my
image again and still got the same result.

I'm going to leave this build as is and setup a new one using 1.8
master and see if I get the same thing again.  I'll leave this broken
build alone for a while in case someone wants me to try something with
it to fix it.

Regards,

Brian



Yet another update ... I did a fresh checkout of master and tried to
build and had the same kernelabiversion error:

WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for
now###
| ETA:
00:00:28
WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now
WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for
now

   | ETA:  00:00:26
Parsing recipes: 100%

|##|
Time: 00:01:02
Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303
targets, 182 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for u-boot (u-boot,
u-boot-glsdk, u-boot-ti-staging)
NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot
NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg

Build Configuration:
BB_VERSION= "1.27.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-7.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "am180x-evm"
DISTRO= "poky"
DISTRO_VERSION= "1.8+snapshot-20150515"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f"
meta-ti   = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e"
meta-oe
meta-python
meta-networking
meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package
apache2-dev requires /usr/bin/perl, but no providers found in its
RDEPENDS [file-rdeps]
ERROR: No kernel-abiversion file found

(/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Brian Hutchinson]

On Tue, Jun 9, 2015 at 9:14 PM, Bruce Ashfield
 wrote:
> On 2015-06-09 9:12 PM, Brian Hutchinson wrote:
>>
>> On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson 
>> wrote:
>>>
>>> On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield
>>>  wrote:

 On 2015-05-19 07:39 AM, Bruce Ashfield wrote:
>
>
> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson
> 
> wrote:
>>
>>
>> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson
>> 
>> wrote:
>>>
>>>
>>> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson
>>> 
>>> wrote:


 On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson
  wrote:
>
>
>
> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" 
> wrote:
>>
>>
>>
>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:
>>>
>>>
>>> On 2015-05-12 10:20 AM, Brian Hutchinson wrote:


 On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
  wrote:
>
>
> On 2015-05-11 02:10 PM, Brian Hutchinson wrote:
>>
>>
>>
>> On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
>>  wrote:
>>>
>>>
>>>
>>> It is plausible. But in theory, linux-dummy should still
>>> provide
>>> what you need (but since it doesn't build anything, there is
>>> no abi .. and no modules can be built against it) .. so the
>>> error isn't graceful.
>>>
>>> Bruce
>>
>>
>>
>>
>> I can confirm this same problem is happening to me.  I just
>> updated
>> one of my builds from 1.7 to 1.8 and am also getting my rootfs
>> to
>> fail
>> due to no abi kernel version:
>
>
>
>
> We still have a race condition in the 1.8 branch for the
> population
> of the build-artifacts directory.
>
> If modules start building, they'll race against the population
> of
> the
> abiversion, and you may see that message.
>
> There's a proposed patch for master, but I don't think it is in
> fido yet.
>
> Bruce



 Hi Bruce,

 I did some searches and looks like there are a number of 'race'
 condition fixes but it wasn't obvious which one I may need.  Is
 it
 this one:
>>>
>>>
>>>
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98



>>>
>>> That's the one that should make sure that the shared workdir
>>> (Which has the abiversion) is in place before building any
>>> modules.
>>>
>>> I can't say that it is exactly your issue, but it is the change
>>> I was thinking of.
>>
>>
>>
>> Brian,
>>
>> Were you able to try the above mentioned commit against am180x in
>> meta-ti?
>> Did
>> it solve the missing abi kernel version? Thanks.
>>
>> --
>> Denys
>
>
>
> Hi Denys,
>
> No, I got caught up in something else ... I'll try it tomorrow and
> report
> back after I cherry pick that commit Bruce mentioned.
>
> Regards,
>
> Brian



 Update.  Not sure if I did this right but this is what I did.  I
 added
 master as a remote and cherry picked
 02d0a003d603266114512160b209876199241e98.  Next I just went for it
 and
 tried to bitbake my image again and got the same result as before.
 Next I did a bitbake cleanall on virtual/kernel and tried to make my
 image again and still got the same result.

 I'm going to leave this build as is and setup a new one using 1.8
 master and see if I get the same thing again.  I'll leave this
 broken
 build alone for a while in case someone wants me to try something
 with
 it to fix it.

 Regards,

 Brian
>>>
>>>
>>>
>>> Yet another update ... I did a fresh checkout of master and tried to
>>> build and had the same kernelabiversion error:
>>>
>>> WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for
>>> now###
>>> | ETA:
>>> 

Re: [yocto] [meta-selinux][RFC 10/10] e2fsprogs: Add patch to implement simple linked list as cache for existing xattr blocks.

[Philip Tricca]

It looks like I screwed up this patch when I was rewriting some git
history. I'm working up a fix.

Philip

On 06/06/2015 05:37 PM, Philip Tricca wrote:
> Signed-off-by: Philip Tricca 
> ---
>  .../e2fsprogs/misc-xattr-create-xattr-cache.patch  | 217 
> +
>  .../e2fsprogs/e2fsprogs_1.42.9.bbappend|   1 +
>  2 files changed, 218 insertions(+)
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-cache.patch
> 
> diff --git 
> a/recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-cache.patch 
> b/recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-cache.patch
> new file mode 100644
> index 000..ba09e2b
> --- /dev/null
> +++ b/recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-cache.patch
> @@ -0,0 +1,217 @@
> +Implement the xattr block cache as a sorted linked list. This requires the 
> add
> +and rm functions be able to compare xattr blocks. This is implemented as two
> +functions. The first compares individual entries and the second compares the
> +whole xattr block by iterating over and comparing individual entries.
> +
> +The xattr block cache keeps memory allocated on the heap around across
> +invocations of the set_inode_xattr function. To free this memory we implement
> +an xattr_cleanup function that iterates over the cache freeing resources
> +associated with each node.
> +
> +Signed-off-by: Philip Tricca 
> +
> +Index: e2fsprogs-1.42.9/misc/xattr.c
> +===
> +--- e2fsprogs-1.42.9.orig/misc/xattr.c
>  e2fsprogs-1.42.9/misc/xattr.c
> +@@ -76,7 +76,16 @@ xattr_free_node (xattr_node_t *node)
> + void
> + xattr_cleanup ()
> + {
> ++xattr_node_t *curr = NULL, *tmp = NULL;
> ++size_t count = 0;
> ++
> + XATTR_STDERR ("Cleaning up resources from xattrs.\n");
> ++for (curr = xattr_list_head; curr != NULL; ++count) {
> ++tmp = curr;
> ++curr = curr->next;
> ++xattr_free_node (tmp);
> ++}
> ++XATTR_STDERR ("Freed %d xattr_node_ts.\n", count);
> + }
> + 
> + /* Get value for named xattr from file at path.
> +@@ -284,6 +293,77 @@ out:
> + return ret;
> + }
> + 
> ++/* Compre two extended attribute entries. This includes the entry and the 
> value.
> ++ * if a < b return -1
> ++ * if a == b return 0
> ++ * if a > b return 1
> ++ */
> ++static int
> ++xattr_compare_entry (struct ext2_ext_attr_header *header_a,
> ++struct ext2_ext_attr_entry *entry_a,
> ++struct ext2_ext_attr_header *header_b,
> ++struct ext2_ext_attr_entry *entry_b)
> ++{
> ++int ret = 0;
> ++
> ++if (entry_a->e_hash != entry_b->e_hash ||
> ++entry_a->e_name_index != entry_b->e_name_index ||
> ++entry_a->e_name_len != entry_b->e_name_len ||
> ++entry_a->e_value_size != entry_b->e_value_size)
> ++{
> ++if (ret = memcmp (EXT2_EXT_ATTR_NAME(entry_a),
> ++EXT2_EXT_ATTR_NAME(entry_b),
> ++MIN (entry_a->e_name_len, entry_b->e_name_len)))
> ++return ret;
> ++if (entry_a->e_value_block != 0 || entry_b->e_value_block != 0)
> ++return -EIO;
> ++return memcmp (VALUE(header_a, entry_a),
> ++VALUE(header_b, entry_b),
> ++MIN(entry_a->e_value_size, 
> entry_b->e_value_size));
> ++}
> ++}
> ++
> ++/* Compare two extended attribute blocks. This includes the header as well 
> as
> ++ *   all entries and values.
> ++ * Algorithm is almost straight from the ext2 kernel drive with the 
> exception
> ++ *   of adding lt and gt behavior to get sorting.
> ++ * If a < b return < 0
> ++ * If a == b return 0
> ++ * If a > b return > 0
> ++ */
> ++static int
> ++xattr_compare_block (struct ext2_ext_attr_header *header_a,
> ++ struct ext2_ext_attr_header *header_b)
> ++{
> ++struct ext2_ext_attr_entry *entry_a = NULL, *entry_b = NULL;
> ++int ret = 0;
> ++
> ++XATTR_STDERR ("comparing xattr blocks at 0x%x and 0x%x\n", header_a, 
> header_b);
> ++for (entry_a = FIRST_ENTRY(header_a), entry_b = FIRST_ENTRY(header_b);
> ++!EXT2_EXT_IS_LAST_ENTRY(entry_a) && 
> !EXT2_EXT_IS_LAST_ENTRY(entry_b);
> ++entry_a = EXT2_EXT_ATTR_NEXT(entry_a), entry_b = 
> EXT2_EXT_ATTR_NEXT(entry_b))
> ++{
> ++xattr_pp_value (VALUE(header_a, entry_a), 
> entry_a->e_value_size);
> ++xattr_pp_value (VALUE(header_b, entry_b), 
> entry_b->e_value_size);
> ++if (ret = xattr_compare_entry (header_a, entry_a, header_b, 
> entry_b)) {
> ++XATTR_STDERR ("entries do not match: %d\n", ret);
> ++return ret;
> ++} else {
> ++XATTR_STDERR ("entries match!\n");
> ++}
> ++}
> ++/* All entries checked were e