Guylhem Rom: First Qtopia 1.5 Release

[adf]

Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]

I was thinking along the lines of a future "idiot-proof" release.

[adf]

Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]

I was thinking along the lines of a future "idiot-proof" release.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79782\"][{POST_SNAPBACK}][/a][/div]

btw. I think maybe a vnc client should be included..or at least in the feed?  the only one I can find that works with the qtopia 1.5 setup is opie-keypeble 1.0.

[ken]

I fixed /tmp ipkg problems using /home/tmp in /etc/ipkg.conf

Regarding the log files however, I'm not sure what I should do. Ideally they should be capped to 100ko each. Maybe I'll just cut them clean at each suspend ?

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]

If there's a newsyslog.conf, it's supposed to trim/rotate logs

Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]

I'd prefer not having it in /mnt/cf, as the cf usually has to be removed to put in cards, like network, bluetooth, modem, etc

[hbo]

Please do ! That's the purpose of the wiki

I suggest the following pages:
 - installation notes
 - bugs
 - features suggestions

Maybe a sum up of this thread would be good

Guylhem
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Great!

I created a guylhem ROM development section at [a href=\"http://externe.net/zaurus/faq]http://externe.net/zaurus/faq[/url] with links to the three pages you suggested above. I created the InstallationNotes page with a description of my hack to make /tmp on CF work. The other two pages still haven't been created. I'll look at them later today.

I think that I will "cherry pick" items from this thread to include. If anyone would like to add to, subtract from or reformat what's there, or create more content, please do!

Edited to correct broken link pointed out in the third following post.

[hbo]

I fixed /tmp ipkg problems using /home/tmp in /etc/ipkg.conf

Regarding the log files however, I'm not sure what I should do. Ideally they should be capped to 100ko each. Maybe I'll just cut them clean at each suspend ?

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]

If there's a newsyslog.conf, it's supposed to trim/rotate logs

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79809\"][{POST_SNAPBACK}][/a][/div]

That functionality is provided by various packages on the various distros. On RHEL[34] and SuSE, it's the logrotate package, and the file is /etc/logrotate.conf with a /etc/logrotate.d subdirectory. I know LSB defines how packages provide log rotation scripts. Anyhow, it doesn't happen automatically. We'd need to provide something to get the functionality.

[hbo]

I'm thinking about a flexible base system on top of which people could layer many different type of GUIs and/or application suites, as has been discussed here.The guylhem ROM project could provide a standard load, similar to the current 0.9 load, but also provide a bare-bones system and supporting software to roll your own environment. I'd be interested in contributing to such an effort. What do you all think?

[ken]

I created a guylhem ROM development section at http://externe.net/faq with links to the three pages you suggested above. I created

[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

I'm sure you mean [a href=\"http://externe.net/zaurus/faq]http://externe.net/zaurus/faq[/url]

[hbo]

I'm sure you mean http://externe.net/zaurus/faq
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79835\"][{POST_SNAPBACK}][/a][/div]

Yup.    

Thanks for catching the broken link!

[adf]

ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.

as a personal bit of madness, though i really like using the ram w/ qt onboard anpocketworkstaion on my sd, I could see shrinking my qt setup some and making a "huge" base install sytem with a ton o moduls and libs.

[hbo]

ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.

as a personal bit of madness, though i really like using the ram w/ qt onboard anpocketworkstaion on my sd, I could see shrinking my qt setup some and making a "huge" base install sytem with a ton o moduls and libs.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]

My tastes run that way too.  

But, the point is, those are my tastes, which aren't identical to yours, which..

If we put some thought now into what it would take to layer a personality on top of a minimal core, I think it would lead to a more flexible and useful system later. Since Gutylhem has been doing a lot of the work on this project, (it is named after him I think we should start with his choice of apps as the "standard" install. As things stand, I think you can rip and replace just about anything in the system, since you can write to all the (visible) filesystems. But wouldn't it be nice to define a set of tasks to make it a QT/X-Qt/PW/GPE/Whatever system or all of the above? We don't have to write this all at once. We just have to avoid dependencies between the layers so that such a system is possible.  And to do that, we need to define the layers, at least to some level of detail, if not fully specify them.

Thoughts? Are we reinventing part of the OE wheel?

[ken]

ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]

I've tried OZ and it's flavors.  To be honest with you, gpe is a bit sterile, but stable.  Opie is nice but a bit buggy at the edges.  If you want a choice of GUIs, then wouldn't that be what OZ is about?  I can pretty much live with how he has things set up.   He has a point about certain apps can always be updated with later versions (as long as this keeps moving).

What I think is more important, is making sure the most used of apps is there.  Which means things like a good media player of some sort that can play tons of things. zbedic is nice of course - I was surprised that OE is still on 0.9.4 rather than 0.9.5.   And so forth - cover the basics of what people need and would use.

The image program would be a problem though - photostorage does large images, which I haven't seen others do.

As for however he wants it released is fine by me --- using nand restore is fine.  That certainly simplifies things.  Maybe later that could be tuned to whatever.

For me, I'm hoping at some point we could have a cvs type of system, so we can participate in the debugging of things.

[adf]

nah...

Guylhem is doing great stuff with the default rom setup.

what the gui replacement system would consist of are a few scripts to mount images, and maybe make links.

The pain will be loading tarring and untarring and troubleshooting the additional guis.

Guylhem's next bit will be opie, I think.

Other than help testing that, maybe we can figure out how to do stuff on qtopia 2.1, then rip and move it around?

I think the X roms should probably be the last thing we  touch (though I really like x) just because they will be different and are eveolving fastest.

My first issue is the &*(&*$%^#!!   keymap issue with fbvnc 1.71 (latest).  apparently what is needed is to use loadkeys and maybe guylhem's tosa.map to fix it up. I can't seem to make it go..nor an i seem to figure out why.  It is probably child's play too...
Anyone have an idea?

I also should setup oe this weekend.

and load and tar Qtopia 2.1. (which so far, I can't seem to install opera on).

I probably should sort out the irk issues too... but I chickened out there and ordered a roll-up usb kbd  


so.. the agenda for the sideshow (while Guylhem is putting on the main event) should be what? 2.1?  pocketworkstation issues? getting ready for opie?  ( I need to make some kernel modules too, I think.. though the old ones I made seem to work ok)

opie--when it gets done-- is going to be sweet on this rom btw

edit:  this is assuming the stuff we try works with the curent guylhem kernel. I know that doing a kernel update in qtopi2.1 did not work. the mobile QtPalmtop obver g-rom might?

[hbo]

ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]

I've tried OZ and it's flavors.  To be honest with you, gpe is a bit sterile, but stable.  Opie is nice but a bit buggy at the edges.  If you want a choice of GUIs, then wouldn't that be what OZ is about?  I can pretty much live with how he has things set up.   He has a point about certain apps can always be updated with later versions (as long as this keeps moving).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]

That was the sense of my question about reinventing the wheel. OE builds Familiar and OZ already, so they should have the business of integrating different systems from parts down cold. I agree with your assessment of OZ/Opie.

What I think is more important, is making sure the most used of apps is there.  Which means things like a good media player of some sort that can play tons of things. zbedic is nice of course - I was surprised that OE is still on 0.9.4 rather than 0.9.5.   And so forth - cover the basics of what people need and would use.

The image program would be a problem though - photostorage does large images, which I haven't seen others do.

 [div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]

All well and good. But what if you're tone deaf? A media player might not fit what you want to do with the Z. What about an X server running alongside a QT environment? Most people wouldn't want that, but I do.

The list is actually endless. I have no use for Portabase or several others of the apps in 0.9.  I can't live without Perl on the Qtopia side. (If that were in the base, I could write some killer integration software! Other people will have a completely different list. I can hear all the Python devotees yelping with alarm at the mention of Perl, for instance.    

I'm not suggesting that there shouldn't be a default set of apps that reflect someone's idea of what the perfect mix is. I'd just like to see some thought given to decoupling the base OS from the GUI and applications layer. That would make it easier to rip and replace, at the very least.

As for however he wants it released is fine by me --- using nand restore is fine.  That certainly simplifies things.  Maybe later that could be tuned to whatever.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]

The only objection I can see is that the entire flash gets written to, and there are a limited (though large) number of writes the flash can take. It occurs to me that this may not be a real big concern for the average user, however. I'm not positive, but I'll bet most Z users don't reflash that often. OTOH, there's a high proportion of hackers and tinkerers in the Z community, so maybe it is an issue.

For me, I'm hoping at some point we could have a cvs type of system, so we can participate in the debugging of things.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]

That would be nice. If I had access to Guylhem's keyboard patch, then I could patch fbvncserver to match it.

[hbo]

...

My first issue is the &*(&*$%^#!!   keymap issue with fbvnc 1.71 (latest).  apparently what is needed is to use loadkeys and maybe guylhem's tosa.map to fix it up. I can't seem to make it go..nor an i seem to figure out why.  It is probably child's play too...
Anyone have an idea?

...

so.. the agenda for the sideshow (while Guylhem is putting on the main event) should be what? 2.1?  pocketworkstation issues? getting ready for opie?  ( I need to make some kernel modules too, I think.. though the old ones I made seem to work ok)

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79854\"][{POST_SNAPBACK}][/a][/div]

The keyboard issues also impact the fbvncserver from SDG Systems. Personally, I think that's one I might be able to tackle. Surely its just a matter of modifying the VNC server's map (in the driver for clients local to the server) to match what the kernel is expecting? The other high priority bug for me is that the package manager won't let you install to CF or SD. Since the ipkg command won't do the links when you do a '-d cf' that's a real pain.

I have a cross compile environment, but I'm not set up to build the kernel for testing. Are you doing anything special? (Other than "make oldconfig; make depend; make bzImage"?)

[adf]

actually, i tend to do 600l configs a bit differently than guylhem does his configs.

He has gone to compiling more stuff in, so that difference is less...

But I compile in all the basic usb stuff, do usb bluetooth comiplied in, and ignore the rest of bluetooth (since I have an "L")... compile in wireless and ipv6 and tunneling support, that sort of thing.

The new kernel has changed a bit.. so I am having to feel my way around to get a good "L" version-centric kernel. ATM I'm having something in "tools" die on me... likely something I thought looked like fun but didn't really need too

Other than that.. I use his source when I compile.... It's right there on externe for download

If you can get the fbvnc keyboard issues sorted out, I expect that will help a lot of people... I know I'd like the option on PW..and (though I didn't know of the problem yet)  I do occasionally use fbvncserver to work on my Z

As for the great gui debate    

A). A basic gui that is compatible with the largest number of packages and has the most useable interface is obviously the highest priority. ATM that is indeed Qtopia 1.5.  I think, Ultimately that Gutlhem's roadmap is correct, and that Qtopia 2.1 will make the best solution.

. As to reinventing OZ.  Guylhem is planning (you read his roadmap?) to implement fast floating point and gcc 3.x stuff eventually. This will surely mean dabbling with stuff OZ has done.But using opie does not necessarily mean it will wind up the same as OZ/6k.. which is merely the product of a much bigger project.  I think it would be more like tuning OE to build something very specifiacally tweaked for the 6k/G-rom. this is not the same.. though it is a huge project. The roadmap.. says it is heading for a softfloat enabled qtopia 2.1.

OK. Softfloat 2.1 then is the goal. Opie is a likely by product.

By version 1.5 of this Rom QTopia 1.5 and Opie will be available options, I think. right there is an argument for making gui changes easy. when Qtopia 2 is added as default, there will be 3 possible guis-- 1 default.   If one of us loonies wants an X gui there will be 4. and why not? I think we should pitch in to help make this work.. but I don't think that precludes stuff like making multiple gui options easier to have.

Right now, I suppose troubleshooting the existing stuff is something the 6kers should be working on...  but obviously we can do that stuf and branch out a little too

and having multiple gui options is not reinventing oz. there will be only one official one.. and all of them are derivate of other projects. A very different proposition, I think.