The complete weekly report for the Linaro Kernel Consolidation team
may be found at:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-08-…
Summary of the minutes:
Device tree support
- ARM specific patches in Grant's test tree - probably will be
included in the 2.6.38 kernel release
- Patches making good progress, just takes time
Richard discussed device trees at the TI OMAP open source meeting.
- Most maintainers were receptive and would like to see patches merged.
- Russell King had reservations. Concern was the lack of
standardization within the ARM community could cause messy
implementations.
Device tree support for OMAP. Jeremy could use some hardware to speed testing.
Arnd asked about QEMU support for the Versatile Express.
- Needs to be added to a specification for this platform and scheduled.
- Richard pointed out there there was a QEMU branch(qemu-maemo)
with OMAP support, but the necessary PCI support wasn't implemented.
- Device trees may help in situations like this.
Versatile Express device tree support is coming.
Arnd reviewing ST Ericsson, out of town next week
- Waiting for the BSP, but has hardware
Boot architecture WG
- Grant to kick-off this team after the kernel merge window
No alpha3 testing done within the group
Please let me know if you have any questions.
--Matt
On Tue, Aug 3, 2010 at 11:16 PM, Loïc Minier <loic.minier(a)linaro.org> wrote:
> On Mon, Aug 02, 2010, Amit Kucheria wrote:
>> arm-linux-gnueabi-objdump: /lib/libm.so.6: File format not recognized
>> dpkg-shlibdeps: error: arm-linux-gnueabi-objdump gave error exit status 1
>
> This is a very recent new bug, which appeared between my testing and
> yours in the form of a new dpkg-dev! 1.15.8 and later introduce this
> issue, see Debian #591522.
>
> There would be some ugly workarounds, but these aren't practical right
> now.
So I guess, native compilation is the only way out now, until this
problem is solved?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591522
The weekly report for the Linaro Infrastructure team may be found at:-
https://wiki.linaro.org/Releases/InfrastructureStatus for a release status and
https://wiki.linaro.org/Platform/Infrastructure/Status/2010-08-05 for a task oriented report.
Summary:
According to the Blueprints, some tasks are behind schedule.
Steady progress being made on tasks, including bug resolution.
Progress:
Some tasks listed for the alpha-3 release are awaiting completion.
Many tasks are outstanding for the beta release.
Please let me know if you have any questions.
Kind Regards,
Ian
The weekly report for the Linaro Infrastructure team may be found at:-
https://wiki.linaro.org/Releases/InfrastructureStatus
Summary:
According to the Blueprints, some tasks are behind schedule.
Steady progress being made on tasks, including bug resolution.
Progress:
Some tasks listed for the alpha-3 release are awaiting completion.
Many tasks are outstanding for the beta release.
hello,
i am trying to cross compile our packages using xdeb. I am following the
steps from the wiki (e.g. I am using a maverick chroot where I install
xdeb and cross compiler).
I can cross compile the 'grep' example fine. However when I try to cross
compile our packages, it seems that xdeb is not able to handle the
dependencies well.
I am building new packages, e.g. that do not exist in maverick archive,
instead they are stored on a private archive within the company. I have
the following packages titiler-memmgr, tisyslink-lib and
tisyslink-d2cmap. I cannot share all sources for now, but here is the
package information for these 3 (extracted from the archive Sources file)
Format: 1.0
Package: titiler-memmgr
Binary: titiler-memmgr, titiler-memmgr-dev, titiler-memmgr-tests
Architecture: armel
Version: 0.24.8-0ubuntu1
Standards-Version: 3.9.0
Build-Depends: cdbs, debhelper (>= 7), quilt, libtool
Format: 1.0
Package: tisyslink-lib
Binary: tisyslink-lib, tisyslink-lib-dev, tisyslink-lib-tests
Architecture: armel
Version: 0.24.8.1-0ubuntu2
Standards-Version: 3.9.0
Build-Depends: cdbs, debhelper (>= 7), libtool, titiler-memmgr-dev (>=
0.24.8)
Format: 1.0
Package: tisyslink-d2cmap
Binary: tisyslink-d2cmap, tisyslink-d2cmap-dev, tisyslink-d2cmap-tests
Architecture: armel
Version: 0.24.8.1-0ubuntu1
Standards-Version: 3.9.0
Build-Depends: cdbs, debhelper (>= 7), libtool, titiler-memmgr-dev (>=
0.24.7), tisyslink-lib-dev (>= 0.24.7)
So, now I am using xdeb with --sequence, here is the output:
$ xdeb -a armel --apt-source --sequence titiler-memmgr
Build sequence: titiler-memmgr
$ xdeb -a armel --apt-source --sequence tisyslink-lib
Build sequence: tisyslink-lib*
$ xdeb -a armel --apt-source --sequence tisyslink-d2cmap
Build sequence: tisyslink-lib* tisyslink-d2cmap*
What is quite disturbing is that xdeb is able to figure out that
tisyslink-d2cmap depends on tisyslink-lib, but it does not get that
tisyslink-lib depends on titiler-memmgr. As such the build fails.
Can something be wrong with my packages? How does xdeb figure out
dependencies? I would expect that it would use the Build-Depends from
the control file, but I am not sure.
Let me know if you need additional data to debug further.
cheers, nicolas
On Fri, Jul 30, 2010 at 4:45 PM, Vishwanath Sripathy
<vishwanath.sripathy(a)linaro.org> wrote:
> Amit,
> I tried to compile it for OMAP, but it failed to compile. Little digging
> showed that Make file does not seem to have entries for ARM tool chains. So
> I think you need to have a config file kind of thing to get powertop cross
> compiled for arm based platforms.
Yes, but it may not be as simple. PowerTOP uses libncursesw library to
link with. Hence for cross compilation we need to make sure that this
(or a non-wide char ncurses library, i.e. libncurses) should also be
cross compiled for target ARM. And then we should have some option in
Makefile (LIBPATH & INCPATH) to point to it.
Will it make sense to have a "readme.ARM" or some other file in
powertop which describes this step ? Any suggestions on how best to do
this ?
Thanks!
--
Regards,
Amit Arora
> Vishwa
Hi there,
I worked on a few patches to the help the userspace perf tools do
better at loading debug symbols -- this is particularly of interest on
Ubuntu and Linaro where separated debug symbols in .ddebs are
typically not loaded even when present. Note that even with the
patches, the contents of .ddebs are still not cached by perf along
with the other profiled binaries, so you will still lose the symbols
if you uninstall/upgrade your ddebs in the meantime. This should get
fixed in the future.
Due to mailserver issues, Arnaldo kindly helped merge these patches
for me. The patches are now merged to the linux-2.6-tip master
branch.
You can find details of the commits here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608775
[ Nico: WIll says he's going to pull these patches into his linaro
branch, if it's more convenient for you to pull from there. ]
Covering notes explaining the changes follow.
Cheers
---Dave
>From c1cb454cc818d367e6b679600bbe7c2fc6d75c2c Mon Sep 17 00:00:00 2001
From: Dave Martin <dave.martin(a)linaro.org>
Date: Tue, 27 Jul 2010 16:44:36 +0100
Subject: [PATCH 0/2] tools/perf: Fix debug symbol lookup issues for some OSes
On Ubuntu (and some other OSes) debug symbols for most of the binaries are
split out into separately-installable files under /usr/lib/debug or elsewhere.
perf already supports this setup, but as a side-effect of abbreviating the
prefix of paths beneath the current directory to './' for display purposes,
the paths constructed to search for the separate debug images are incorrect.
As a result, symbols may not be found even if they are available.
The simplest fix seems to be just to remove the cwd abbreviation feature; this
makes all displayed paths absolute in e.g., perf report -v, but otherwise
appears harmless.
Dave Martin (2):
tools/perf: Don't abbreviate file paths relative to the cwd
tools/perf: Remove unneeded code for tracking the cwd in perf
sessions
tools/perf/util/event.c | 2 +-
tools/perf/util/map.c | 22 +---------------------
tools/perf/util/map.h | 2 +-
tools/perf/util/session.c | 22 +---------------------
4 files changed, 4 insertions(+), 44 deletions(-)
>From fa6c691b767bfcdf9a704aeab58ddc6f618b9be8 Mon Sep 17 00:00:00 2001
From: Dave Martin <dave.martin(a)linaro.org>
Date: Fri, 30 Jul 2010 12:31:46 +0100
Subject: [PATCH 0/3] perf tools: Better image search for separated debug images
The perf tools' buildid cache functionality currently interferes with
loading the correct symbols in environments which use separated debug
images (Ubuntu, Fedora, ...)
This patch set modifies the image search behaviour to perform 2 passes:
no image without a full symtab is considered for loading unless no
image with a symtab is available at all. This avoids loading images
from the buildid cache if a better image is available elsewhere. As a
consequence, perf report and friends should now load the correct
symbols on Ubuntu and friends, at the cost of an extra image loading
pass.
This patch set does not change the way files get cached, but ought to
be OK as the basis for further refactoring to replicate the same search
behaviour in the caching code so all relevant images get cached.
The extra image loading pass should not need to occur on the common path
once the caching behaviour modifications are done.
Dave Martin (3):
perf tools: Factor out buildid reading and make it implicit in
dso__load
perf tools: remove extra build-id check factored into dso__load
perf tools: improve debug image search when loading symbols
tools/perf/util/symbol.c | 206 +++++++++++++++++++++++++--------------------
1 files changed, 114 insertions(+), 92 deletions(-)
Hi,
Hot on the heals of Ubuntu's main archive frozen announcement [1] this email is to inform you that Linaro development is under the same restriction. We are in the process of testing the daily images which will in turn become the Alpha-3 release on Thursday.
Please read the Ubuntu announcement for more information on the restrictions.
Regards,
Jamie.
--
Linaro Release Manager
[1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-August/000741.…
