using openembedded (feeds) on e680/i

[rpconnect]

Has anyone tried to use any of the packages from an openembedded feed for an ipaq (h3600)? I cannot seem to unpack ipk files. I have tried tar, gz, unzip, etc, and although I have been able to unpack other .ipk files (to get the .data.tar.gz, .control.tar.gz, etc), I cannot seem to get .ipk files from feeds to unpack (for example, I am trying http://familiar.handhelds.org/feeds/...-r12_h3600.ipk w/o success)

Generally though this openembedded stuff is pretty cool, I am hoping to set up the right confiugration to bitbake build a openzaurus-like environment by compiling w/against the e680 source code that pascal has so gratciously shared. This could generate not just opie and qt as one package, but other potentially useful apps as well (e.g. x11, GPE (a GNU-based version of qpe based on x11 rather than qt), kaffe (an alternative java VM), bluez libs and utils, etc, as these are already generated by part of an openembedded image build process)

Anybody interested?

[yantz]

have you tried ar?

[rpconnect]

have you tried ar?

damn, forgot about that. it works, THANKS!!!

If I have any luck using anything precompiled from an ipaq feed I will post it here....

[leopardus2]

have you tried ar?

damn, forgot about that. it works, THANKS!!!

If I have any luck using anything precompiled from an ipaq feed I will post it here....

If I'm not wrong, we still miss the sources to the Qt stuff...

Rick

[rpconnect]

If I'm not wrong, we still miss the sources to the Qt stuff...

This is true with the .ipk files, although 1) to get opie to run currently we are simply compiling the qt libs using an ipaq setting so compatibility with hp3600 ipaq settings should be pretty darn close, and

2) doing a full imag build (e.g. of openzaurus, or a similar option for ipaq) using openembedded/bitbake will download the sources and compile them as part of the build process. We can then include any mods we want as patches during the bitbake build operation. For example, because of the opie dependencies on the qt libs, building an opie-image would include the qt sources.

I am trying both in parallel (.ipk's from pre-compiled feeds and full build methods), right now I keep getting stuck on "ERROR 404" when bitbake tries to download the sources; it can make the connection to the mirror but its not finding the files....

[leopardus2]

If I'm not wrong, we still miss the sources to the Qt stuff...

This is true with the .ipk files, although 1) to get opie to run currently we are simply compiling the qt libs using an ipaq setting so compatibility with hp3600 ipaq settings should be pretty darn close, and

2) doing a full imag build (e.g. of openzaurus, or a similar option for ipaq) using openembedded/bitbake will download the sources and compile them as part of the build process. We can then include any mods we want as patches during the bitbake build operation. For example, because of the opie dependencies on the qt libs, building an opie-image would include the qt sources.

I am trying both in parallel (.ipk's from pre-compiled feeds and full build methods), right now I keep getting stuck on "ERROR 404" when bitbake tries to download the sources; it can make the connection to the mirror but its not finding the files....

I tried running the .ipk packages from familiar Linux on the E680, but they don't. I tried xmame.SDL, it runs then gets stuck in some input reading routine without displaying anything (under native windowsserver).

The strange thing about these .ipk packages is that they seem to look for various .conf and .qm files when you run them, yet there is no such files in the packages! Try to strace one of them and you will understand what I mean.

Rick

[rpconnect]

Do you know from what type of image the ipk file was for? It seems like the openzaurus/ipaq images generally come in two varieties, one w/ opie (based on qt) and one w/ GPE (based on X) so there is a chance that the ipk file you are using won't communicate w/ the native windowsserver.

do you have a link for the xmame.sdl that you are testing? I would like to give it a try using a full opie (and/or GPE) rootfs image copied to the SD.

[leopardus2]

Do you know from what type of image the ipk file was for? It seems like the openzaurus/ipaq images generally come in two varieties, one w/ opie (based on qt) and one w/ GPE (based on X) so there is a chance that the ipk file you are using won't communicate w/ the native windowsserver.

do you have a link for the xmame.sdl that you are testing? I would like to give it a try using a full opie (and/or GPE) rootfs image copied to the SD.

sure, I got it from ipkgfind.handhelds.org, just search for xmame...
and please report back your findings
I think the xmame.SDL is part of OPIE.
I used some of the libraries from opie.cramfs to run it.

Good luck,

Rick

[rpconnect]

@Rick,

Thanks, I will try to see what happens later today. When I tried to copy over the (a) whole opie rootfs image, a lot worked, but a lot also complained about the ld-linux.so.2 (I think that some of the newer versions of familiar and/or openzaurus are using 2.6 kernels, so I am looking for a feed based on the 2.4 kernel in the meantime to try and resolve this).

One thing I tried that did work is ssh (acutually its linked to dropbearmulti).

i'll let you know what happens regarding the xmame tests.

[leopardus2]

@Rick,

Thanks, I will try to see what happens later today. When I tried to copy over the (a) whole opie rootfs image, a lot worked, but a lot also complained about the ld-linux.so.2 (I think that some of the newer versions of familiar and/or openzaurus are using 2.6 kernels, so I am looking for a feed based on the 2.4 kernel in the meantime to try and resolve this).

One thing I tried that did work is ssh (acutually its linked to dropbearmulti).

i'll let you know what happens regarding the xmame tests.

any progress?

Rick