'start-stop-daemon' is a link to busybox on OZ 3.5.3. I think it would be safe to write a shell script replacement to just run the damned first argument in the background, possibly redirecting stdin/stdout to useful places.

We may have quick success with this, which would be really cool. But I still think porting the KNX client would be better for the long term.

I'll have to look again,lmy last "solution" was to enable the whole thing i n drivers/inputand then Not compile hid in usb i( i think there was something about usb hid in /usb.. I'll have to look) but just raw keyboard. i dunno. will get to it this weekend.

as to the qui option thing, yeah.. for a general purpose gui Qt is probably the way to do it. I was thinkin more along the lines of interesting alternatives.

have you poked at the latest Qtopia 2.1? It might be useable in this Rom with not too much agony. (though i didn't have a lot of luck with opera, lpotter seems to think that the problem was not qtopia 2.1 itself might be worth double checking)

Did you see the qemu oe thread this morning? there is, link and all, a disk image from a debian system with OE installed. you might grab that, since it is up right now, and don't see having a tarrball ready to go for 2 or 3 more days

I reflashed this evening with the 0.9 release. Aside from the microdrive not getting mounted, I noticed something else that happened the first time around. I was getting ready to install X-Qt, so I remade the link from /tmp to point at the microdrive. I also put the Z in its cradle for the first time since I'd flashed it this time around. The screen on the Z switched back to the "Gator" photo! It's as if the runqpe command had exited on an error, and the qpe.sh script had done a chvt back to the splash screen. How do you do switch virtual terminals using the keyboard or buttons in this ROM?

I just realized that pulling the temp files out from under qtopia is probably not a great idea. 8) But it's the only way to get installations of large ipks to work.

Is there a Wiki/Twiki where we could centralize bug reports and development info for this ROM?

maybe you should put /tmp on sd till you get your microdrive reliably automounting?

I fixed it by moving /etc/rc.d/init.d/pcmcia, which sets up the cf drivers on the Z, to /etc/rc.d/rc.pcmcia and removing the symlink /etc/rc.d/rc5.d/S05pcmcia. Then in /etc/rc.d/rc.sysinit, I put a call to rc.pcmcia right before local file systems are mounted like so:

Since I have an entry in /etc/fstab for my microdrive, it gets mounted by the second line above, and this allows me to maintain the link /tmp -> /mnt/cf/tmp. /var is another matter. The pcmcia script makes heavy use of /var, and I was unwilling to study the problem of removing the dependency, or risk just mounting on top of it. But now the logs have the full 1MB to play with.

It's cool that syslog is running on this ROM. It's very helpful for debugging problems and learning about the details of the startup. However it won't do to keep that in production, since it would fill up quickly.

Next up, why doesn't the qpe package manager work for non root targets?

I'm willing to host a Wiki, BTW. It would be a complement to these forums, not a replacement.

there will be people who want to have access to logs. maybe a 1st run? setup the image with a marker set to 0, on boot check the maker, if it is 0 run the script? (have the script write 1, of course) ask "Do you want /tmp on sd or cf?" Do you want to use system logs warning this can use lots of space y/N?" if y then ask about var the same a /tmp. you copuld probably use the same thing to assign acceptable targets for ipkg.

this would also make a nice (if slow way) to set up the qtpalmtop.rom at whatevet target is wanted -- copy to/mount from(cd sf, internal...nfs?-- having an nfs or samba option might be nice for some offices?)

and on boot ask for gui target location. this would make either purpose specific setups, or different guis (I think at the very least there will be those that want opie and those that want qtopia2) easy to manage on a handful of diferent cards, or with a handful of different images.

and this would lead to the last (if feaseable) script--that does not go on the rom.one that rips guis to an installable useable tarball (obviously tis would go somewhere down the road.)