Hi,
The Linaro team is pleased to announce the availability of the 11.05
Alpha-2 images. These are still very early developer images but we
encourage all with supported hardware to use and test them by
downloading from:
http://releases.linaro.org/platform/linaro-n/
Highlights of this release include:
* Added Gumstix Overo support.
* New Developer image including console base developer tools.
* Complete rewrite of the installation tools (linaro-image-tools)
to improve the user experience.
* A staggering 141 out of 160 packages have been upgraded since
Alpha-1.
The images consist of two parts. A hardware pack which can be found
under the ./hwpacks directory which contains hardware specific packages
such as the kernel and bootloader. The second part is the roofs which
is combined with the hardware pack to create a complete image. For
For information on how to create an image please see:
http://wiki.linaro.org/Releases/MilestoneBuilds
More information on Linaro in general and the 11.05 plans can be
found at:
* Homepage: http://www.linaro.org
* Wiki: http://wiki.linaro.org
* 11.05: http://wiki.linaro.org/Releases/1105
Also subscribe to the important Linaro mailing lists and join our IRC
channels to stay on top of Linaro developments:
* Announcements:
http://lists.linaro.org/mailman/listinfo/linaro-announce
* Development:
http://lists.linaro.org/mailman/listinfo/linaro-dev
* IRC:
#linaro on irc.linaro.org or irc.freenode.net
For any errata issues please see:
http://wiki.linaro.org/Releases/1105/Alpha2#Issues
Bug reports for this release should be filed in Launchpad against the
individual packages that are affected, if a suitable package cannot be
identified, feel free to assign them to:
http://www.launchpad.net/linaro
Regards,
Jamie.
--
Linaro Release Manager
tcl8.5-dev contains /usr/lib/tcl8.5/tclConfig.sh
which is a symlink pointing to /usr/share/tcltk/tcl8.5/tclConfig.sh
Currently dpkg-cross only copies symlinks across when crossing a
package if the symlink points to somewhere within /lib. symlinks
outside /lib are ignored because they are not arch-dependent so
shouldn't need to be crossed.
The file /usr/lib/tcl8.5/tclConfig.sh is used by packages which build
extensions to tcl (such as sqlite), so that files does need to be
present.
The file is essentially a cache of the config options TCL was built
with so that extensions can make sure they match up. However it is not
arch-independent. e.g. Line 22 of that file is
TCL_CC='x86_64-linux-gnu-gcc' on the x86_64
version and TCL_CC='arm-linux-gnueabi-gcc' on the armel version.
Other options also differ between 32-bit and 64-bit arches for example.
So this file is arch-dependent in that it's different for each arch it
is built-on but arch-independent in that it's just a shell file.
Debian policy (8.2) says:
---------------
It is recommended that supporting files and run-time support programs
that do not need to be invoked manually by users, but are nevertheless
required for the package to function, be placed (if they are binary)
in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
If the program or file is architecture independent, the recommendation
is for it to be placed in a subdirectory of /usr/share instead,
preferably under /usr/share/package-name. Following the package-name
naming convention ensures that the file names change when the shared
object version changes.
Files and support programs only useful when compiling software against
the library should be included in the development package for the
library
---------------
A maintainer reading the above could reasonably decide that /usr/share
was the right place for this file, because the file itself (being just
shell) is arch-independent. The problem is that the contents are
arch-dependent. Policy is not at all clear on this distinction (It's
been making my head hurt all day). For multiarch, or existing
dpkg-cross cross-compiling, to work, arch-dependent needs to mean
either form _or_ content (see below for elaboration).
The original tcl build puts both tclConfig.sh and tcl.m4 in /usr/lib
but the debian packaging moves them to
/usr/share/tcltk/tcl8.5 and /usr/share/aclocal/ respectively
Currently the sqlite build fails because it looks for tclConfig.sh in
/usr/<triplet>/lib/tcl8.5/ and doesn't find it there, because
dpkg-cross didn't copy the symlink (or original) there.
So, the questions is - which of these is the correct fix:
1) make dpkg-cross copy over symlinks even when they point into
/usr/share
2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
/usr/share/tcltk/tcl8.5
3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
instead of /usr/lib/tcl8.5 when building
I note that the supplied tcl8.5.m4 file actually lists a whole pile of
possible locations for the file:
for i in `ls -d ${libdir} 2>/dev/null` \
`ls -d ${exec_prefix}/lib 2>/dev/null` \
`ls -d ${prefix}/lib 2>/dev/null` \
`ls -d /usr/local/lib 2>/dev/null` \
`ls -d /usr/contrib/lib 2>/dev/null` \
`ls -d /usr/share/tcltk/tk8.5 2>/dev/null` \
`ls -d /usr/lib 2>/dev/null` \
`ls -d /usr/lib64 2>/dev/null` \
However that list doesn't include anything ending in tcl8.5
(i.e /usr/<triplet>/lib/tcl8.5 or /usr/share/tcltk/tcl8.5) and perhaps
should by way of 'back-up plan', although I haven't actually looked
into the detals of how that is used.
Consideration when deciding how to fix this include:
Squeeze will be released in a few days with this broken so we will be
stuck with the /usr/share/ file location for some time there. Any fix
going into Ubuntu should make Natty easily enough.
For Multiarch tcl-dev will be a Multiarch:same package (i.e a
'library' package) (despite the name, it contains nothing but headers,
libraries and the above config.sh and m4 files), so the two different
tclConfig.sh files supplied by the DEB_BUILD_ARCH and DEB_HOST_ARCH
packages (when cross-building) will clash and the 2nd package will not
be installable. This, it seems to me, is the clinching argument that
the correct fix is to change the tcl build to put these files in
/usr/lib.
This also implies that policy 8.2 needs to be clarified to explain
what 'arch-independent' means.
Are there other situations which expect to find the tclConfig.sh file
in /usr/share? Is so those need considering.
Does anyone disgree with the above conclusions? And do people agree
that policy 8.2 could be clearer on this point?
I've filed a bug containing some of the above discussion and a patch
for tcl8.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611650
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
On Mon, Jan 24, 2011 at 12:27:16PM -0000, Pawel Moll wrote:
> So - we'll try to enlarge FIFO. For the moment - playing with interrupts
> affinity seem to be a viable workaround.
I don't think enlarging the FIFO will help too much. The issue is
whether the CPU can keep up with the data rate coming off the card.
If it can't, then no matter how large the FIFO is, it will eventually
overflow.
The real answer is to avoid PIO mode, and use DMA support. However,
I've had problems using DMA on the ARM development boards. You can
find details my DMA issues internally within ARM by talking to Catalin.
The alternative answer, I believe implemented by some of ARMs silicon
partners, is to turn the card clock off when the FIFO becomes full/empty
to stop it sending more data. I think this violates some of the MMC/SD
requirements, but it seems to work for the silicon partners just fine.
Hi,
I am struggling to run perf tool on u8500 as hwpacks for 2.6.35 kernel are
still not out. Can someone help me know if anyone is using perf on arm-based
board such as panda, beagle etc.
Ideally, I would like to start a firefox application, and run command
'perf stat -p <pid_of_firefox> -e cycles sleep 1'
Regards,
Sudip
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on February 2nd
in #linaro-meeting on irc.freenode.net at 16:00 UTC.
https://wiki.linaro.org/Platform/Foundations/2011-02-02
Actions from the meeting where as follows:
* JamieBennett to come up with test assignments for the new developer image
* jcrigby to write up landing team u-boot, kernel workflows and send
for review after first draft is done
* slangasek to review
https://wiki.linaro.org/Platform/DevPlatform/Specs/MemoryFootprintMethodolo…
for dmart
* ppearse to figure out what version number we want for 'helios' to
be in natty
* dmart to send a beagle kernel config to aviksil1
* aviksil1 to send pointer to lttng-enabled tree to slangasek
Regards,
Tom (tgall_foo)
Developer Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com