[X2Go-Dev] X2Go module purposes

[Mike]

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