Resending to list not Stefan!
On 01/26/2015 06:20 PM, Mike wrote:
On 01/26/2015 05:02 PM, Stefan Baur wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 26.01.2015 um 22:44 schrieb Short, Kermit:
It's certainly something I'd like to try, but if I recall
correctly, the firmware is only loosely based on LTS. The actual
OS on the thin client is heavily customized.
Well, I hope I'm not talking out of my lower back here, but it can't
be much more complicated than grabbing our packages, unpacking them,
and checking for any dependencies that they need to have met.
Possibly apply some ldd and strace to see where things are going wrong.
Yes, excellent advice! Although I'm a lazy admin and don't see the
need for ldd or strace here. The .deb package info is able to give us
all the reverse dependency information. Many ways to obtain it I'm
sure, apt-cache showpkg or using the package search on the Debian
website should revel all the needed information. Surely Ubuntu has a
similar webpage available.
Working with debian packages is not something I've done much, and
then only to build them rather than deconstruct them.
It's actually not that hard. If you have a copy of midnight commander
(mc) installed, you can usually go inside them like any other virtual
file system (like when you "open" a *.tar.gz file with mc).
There are also command line tools available to unpack Debian/Ubuntu
packages without installing them.
ar x some-package_0.1.2.deb .
dpkg --extract some-package_0.1.2.deb .
dpkg -x some-package_0.1.2.deb .
Certainly there are other ways...
I do really like the idea of a chroot shell, though. I'm currently
using AIDE to look at changes pre and post build, and then I go
through interactive error messages on the IGEL to determine what
additional libraries are necessary.
The last time I did this, there were several libraries provided by
the LTS footprint that were not provided on the IGEL, so it's a
little easier for me to do the scratch build, since I have to do
some by hand tracing anyway.
That sounds really painful. In a first step, I'd try to parse the
output of ldd for every executable I want to copy, then make sure I
have those files either available on the IGEL, or know I have copy
them over along with the executable.
for example (this is on Debian Wheezy, not Ubuntu, but the process
should be the same):
dpkg -L libnx-x11
gives
/.
<chopped some dpkg output>
and just grabbing one sample from here,
/usr/lib/nx/X11/libNX_Xrender.so.1,
ldd /usr/lib/nx/X11/libNX_Xrender.so.1 gives
linux-gate.so.1 => (0xb7702000)
libNX_Xext.so.6 => not found
libNX_X11.so.6 => not found
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6
(0xb7583000)
/lib/ld-linux.so.2 (0xb7703000)
As this is from a working system, I would assume the two "not found"s
are harmless, but I need to make sure I have the other files on my
target system in some way - either from the original OS image, or by
copying them over.
If memory serves X2Go is setting LD_LIBRARY_PATH to where the libNX*
and probably other NX specific libs live. The dependency information
of the .deb file(s) should point these out without having to use ldd.
Being able to do this from a debian package in a root shell would
be very handy, though!!
Well, I can't do more than suggest you try it and see if it turns out
to be the easier way. :-)
How large is that extra partition you can access, anyway?
Large enough to untar a complete non-IGEL linux distribution there and
chroot or possibly even kexec into it?
Another option would be to offer one or more of your IGELs to
interested developers so they can do the grunt work for you.
- -Stefan
Hopefully some of this can be of some help. If I can get away without
building things from scratch I'm all for it. Like I said I'm a lazy
admin, building software isn't one of my favorite things in life.
Mike
_______________________________________________
x2go-dev mailing list
[email protected]
http://lists.x2go.org/listinfo/x2go-dev
