On Thu, 15 Jan 2009 17:01:34 +0100
"Martin Fuzzey" <mfuzzey@gmail.com> wrote:
> Hi,
> I'm trying to run gpe on emdebian crush on a ARM iMX21 based board.
> After a few minor problems due to busybox differences in some script
> files (should I file bug reports for these?)
Yes - against the pseudo-package buildd.emdebian.org, not against
busybox itself.
Also, take a look at balloon3-config which includes a set of fixes
developed for the balloon3 board - you may find some of those useful.
http://www.emdebian.org/packages/search.php?package=balloon3-config&distro=unstable
Use deb-gview to inspect the contents. ('apt-get install deb-gview' on
your desktop/laptop machine). Alternatively, simply wget it and use
dpkg -I and/or dpkg -c etc.
> I have startx working.
Congratulations. However, some of your questions indicate that you are
expecting Emdebian Crush to do things that it simply cannot do -
debugging for one, building packages on the board for another. For
that, you will need Grip.
> However none of the gpe stuff works. Virtually all gpe applications
> (gpe-clock, gpe-edit,...) have trouble loading PNGs :
> GPE-ERROR: Couldn't recognize the image file format for file
> '/usr/share/gpe/pixmaps/default/save_as.png'
It's a configuration file that you need. Unfortunately, both Gtk and
Pango generate this configuration file during the build by compiling a
parser routine and executing it. Naturally, this fails in a
cross-build. There are good reasons for this practice within Debian but
the issues that arise within Emdebian Crush are unresolved currently.
These are not typical configuration files as far as dpkg is concerned,
these are internal library lists of files that are needed to load PNG
and load text glyphs.
The simplest fix is to copy the files from Debian. As Grip develops, I
hope to be able to use that to provide suitable files. AFAICT these
files are not *machine* specific configuration, they are *library
version* specific - i.e. transferable between machines as long as the
versions match.
Please follow up to the existing bug for Gtk (480722) and report a
bug against buildd.emdebian.org for pango (text).
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/126-State-of-play-in-Emdebian-ARM.html
Running:
/usr/lib/libgtk2.0-0/update-gdkpixbuf-loaders
Copying:
/usr/lib/pango/1.6.0/module-files.d/libpango1.0-0.modules
The GPE apps are a little picky on this issue and fail completely if
the icons cannot be found. This is unfortunate because there is no
problem in the actual binaries, it is all due to the inability to load
the icons.
> My normal next step would be to use strace,ltrace,objdump and ldd to
> try and figure out what is going on but the first three don't appear
> to be in emdebian and ldd is a shell script that requires bash (i've
> tried dash but to no avail).
That path would have led you into a blind alley. This is not a problem
in the binaries, it is a problem of a lack of data for the binaries.
> Are there any good reasons for not including these tools? Should I try
> to build emdebian packages locally for them?
Good reasons for not including these tools:
1. the source packages for the tools do not currently cross-build.
2. the binary packages tend to be v.large.
3. iirc the Debian versions won't install on Crush
4. dependencies get unmanageable on Crush - not least perl - making
enormous demands on the available space required on the device.
> Indeed I have no pango.modules file (just an empty /etc/pango directory)
The modules file is generated by a compiled executable during the
Debian build, then the tools to update it are packaged in the -dev.
What you actually need is the file that would have been generated
within the build. The file currently installed in the Debian lib
package does the job but this issue needs to be fixed properly -
sometime after the Lenny release.
> I don't have pango-query modules and the libpango1.0-dev package which
> normally provides it is not installable due to an unresolved
> dependency on pkg-config:
Emdebian Crush does not provide -dev packages, generally. It certainly
does not contain build tools for native builds, nor does it provide
dependencies of -dev packages. There is no real expectation that
machines running Crush would be capable of installing the compiler and
build tools, let alone running them or building packages.
All debugging of Crush will end up being done on your desktop / laptop
machine. It's a situation familiar to most embedded people.
Emdebian Grip is the flavour to use if you need to be able to build
packages on the device actually running Emdebian.
> # apt-get install libpango1.0-dev
Something to sort out in Crush is that these packages are not installed
into the archive. Developments in Grip will help in this area.
There are valid reasons why Emdebian Crush is aimed at developers only
and will be given the 1.0 tag in the manner of Slackware 1.0 or RedHat
1.0 or Debian 1.1. The first releases of any distribution tend to be
hard to install, hard to configure and hard to maintain. However, the
benefits of getting a set of packages into a stable platform outweigh
the problems of actually using the final system at runtime as opposed
to using it for ongoing development and testing.
All of the fixes required to make Crush easy to install, easy to
configure and easy to maintain are waiting for the release of Debian
Lenny and will take time to develop and merge into the relevant
packages in Debian and Emdebian. For now, Emdebian can provide a lot of
what you need but, in return, expects quite a lot in return. Sorry
about that.
Please be verbose in your bug reports and comments to bug reports when
using the buildd.emdebian.org pseudo-package. I need real input, real
complaints, real issues and real fixes in order to collate the results
into a useful FAQ based on the contents of the bug reports generated by
these initial stages.
One major drawback with Emdebian right now is that 99.9% of all the
documentation was written by me - alone. Getting this release out and
encouraging lots and lots of feedback is one way of making the
documentation more relevant and more useful. Please do what you can to
document everything that goes wrong, everything you find to fix it and
details of the machines used etc. That is why the buildd.emdebian.org
pseudo-package was created in the Debian Bug Tracking System:
http://bugs.debian.org/buildd.emdebian.org
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpfbe42yB977.pgp
Description: PGP signature