thx for spotting that typo - fixed.

If you are using your core to cross compile it will be fine as long as you don't have another Qt dev environment set up. If you just want to have some Pi then this is fine. If you are trying to compile qOrbiter for other platforms then they won't co-exist. At least not yet, it is their plan to allow it in future.

-Coley.

Not specifically no, the two unofficial raspbian images, pisces and hexxeh, both aim to boot to graphical environments.
I'm trying to keep the image as trimmed as possible.
Having said that, assuming this works there should be nothing stopping you running qOrbiter on either of those images.

-Coley.

parked work on QtonPi 0.2 image. 0.3 when it is released will have what we need.
Going to focus on a different image with later qt5 install and see how we go.
An Arm hardfp port of debian wheezy has mouse and working qtwayland under qt5 - may give us something interesting.
I just need to get image and toolchain set up

-Coley.

Doesn't look like I'll get much further tonight
https://bugreports.qt-project.org/browse/QTONPI-13 Mouse support has only recently been added  

If I get a chance I'll try a nightly qt5 snapshot or try the debian image.

-Coley.

either way I'll need the qt50-snapshot, actual debian image has older qt5 installed.

qOrbiter now loads the familiar home screen after getting its config from the router.
I didn't have a spare usb mouse to test, will try to pick one up tomorrow and see how much further I can get.

-Coley.

yep, I know. There is always NanoX, I've used it before on arm devices.
Rolling our own window manager can remove X. As I see it X is kinda in the way on one of these devices.
Also up and coming QtWayland could be a nice fit, its an addon I might try getting going once q0rbiter behaves on the Pi.
Actually if you check out the QtonPi SD image it has no X installed, and thats what I've started with.
-Coley.

I've had the same issues with multiple detection of non existant gamepads on a headless core install. I hadn't worried too much about it as I was in a VM and thought it might have been as a result of that.
-Coley.

I've been trying to get qOrbiter ported to the Raspberry Pi.
I've made some progress and you can follow it on the wiki: http://wiki.linuxmce.org/index.php/RaspberryPi
If you have comment, suggestions or advice please post.

Be aware this is prototyping so progress could be forwards as well as backwards

-Coley.

I don't understand why the diskless setup failed coley.

I understand why cores can't get to desktop, I had just hoped I fixed it, clearly needs more work.

I can try again with a re-install if you want and see if the first boot of the MD fails.
I wasn't looking to get desktop on my core as it was a headless install, just reporting it worked on MD.

-Coley.

Came across this https://github.com/nemein/Qt_AirCursor not a lot there yet but might be a nice fit with qOrbiter if/when it is released....

-Coley.

Installed LMCE-1004-20120519090525976.iso headless and added a MD, both VMs.
Initial boot of MD ended with Diskless Setup failed, rebooted router and tried MD again.
All went ok this time and sarah appeared, completed avwizard.
ssh from core to moon OK and from moon back to core.

do you want any logs/info from this install?

-Coley.

and fwiw kde desktop works on the MD 

Yep I had similar problems but poked about and managed a zsync download, needed a bit more intervention but works.
The zsync control file has a header containing the URL this needs to be adjusted to suit the final destination of the iso.

Code:

- wget the relevant <snapshot>.iso.zsync file
 - open this in a proper editor and edit the URL: line, shorten it down to /snapshots/<snapshot>.iso and save.
 - now feed this to zsync
 - zsync LMCE-1004-<snapshot>.iso.zsync -u http://linuxmce.iptp.org/

This has worked successfully for me.

-Coley.

maybe someone with access to the script generating the iso snapshots could change the zsyncmake command and feed the final destination URL to it?

These instructions can now safely be ignored
After Possy's change the zsync file now has the correct url and the download happens as per l3mce's previous instructions.
Around 1Gig as opposed to > 3Gig to download per snapshot.

-Coley.

I've changed the script. It now reads:

zsyncmake http://linuxmce.iptp.org/snapshots/LMCE-1004-20120515132925970.iso LMCE-1004-20120515132925970.iso

I've manually ran it just now, so if you find a zsync file which is as old as the iso file, it is NOT the right one. The zsync file should be an hour or so younger. In the future, they should have the same time (+/- a minute or so)

Thx for the quick response .

-Coley

Zsync is failing for me... anyone else had success with zsync?

Yep I had similar problems but poked about and managed a zsync download, needed a bit more intervention but works.
The zsync control file has a header containing the URL this needs to be adjusted to suit the final destination of the iso.

Code:

- wget the relevant <snapshot>.iso.zsync file
 - open this in a proper editor and edit the URL: line, shorten it down to /snapshots/<snapshot>.iso and save.
 - now feed this to zsync
 - zsync LMCE-1004-<snapshot>.iso.zsync -u http://linuxmce.iptp.org/

This has worked successfully for me.

-Coley.

maybe someone with access to the script generating the iso snapshots could change the zsyncmake command and feed the final destination URL to it?

Figured it was a space issue.
I didn't realise you could use any older snapshot to sync with to generate a new iso.

thanks
-Coley.