OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

Profile
Personal Photo
Options
Options
Personal Statement
Bundabrg doesn't have a personal statement currently.
Personal Info
Bundabrg
Age Unknown
Gender Not Set
Location Unknown
Birthday Unknown
Interests
No Information
Statistics
Joined: 7-September 04
Profile Views: 540*
Last Seen: 19th April 2007 - 11:55 PM
Local Time: Nov 27 2014, 09:35 AM
183 posts (0 per day)
Contact Information
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
* Profile views updated each hour

Bundabrg

Members


Topics
Posts
Comments
Friends
My Content
20 Jul 2006
Hi All,

I'd like to discuss a few things that I think are basically some inherent weaknesses in pdaXrom, or rather its development philosophy. Please don't get me wrong as I actually quite like pdaXrom and I think there’s been an exceptional amount of good work put into it by the developer(s), and I must also applaud those who package and contribute applications. You just need to look at http://mail.pdaxrom.org to see the amount of good work put in.

However my concern is that the design of pdaXrom currently prohibits its expansibility and has some pretty big risks.

What are some of the big questions that are always asked in the forums? They are things like this: -
- Where do I find the feed for (some older version)?
- Please could someone port app from (newer/older) feed to (older/newer) feed?
- Where can I find (appname)? It used to be here, but its not here any more.

Currently, from my perspective, an image of a version of pdaXrom is released periodically through the efforts of sashz and Laze. These may or may not work with existing feeds (including contributed ones), and generally kind developers on the forums scramble to ensure that packages they've released still work and still have the proper dependencies etc..

My worry is that this process has the following flaws: -
- The 'hit by the bus' issue - What if a core developer disappears/gets sick of the project. What happens to the project? Is it capable of surviving? What happens if sashz is burned out and feels that he is obligated now to keep developing since everyone is depending on him? That’s quite a bit of stress!
- Effort to create a package - There seems to be a lot of effort needed to generate packages. Once generated, people are reluctant to necessarily update these packages unless they are actively using them as they need to almost reproduce the effort to create it in the first place unless they're smart enough to keep good logs or have a good make script.
- Effort to create a public package - Due to the above point, it’s possible that people who could package something for the public may decide against doing it as the effort may only work for the current release of the 'rom'.
- Lost Compiling Information/Source code - How someone packaged something (including patches) seems to be lost. This actually breaks GPL. It also means that should this person be 'hit by a bus' etc.. someone else has to re-work out how to package the app.
- Old Version Maintenance - Old versions. Most distributions will 'backport' fixes to old versions for a period of time. Currently as soon as a release is made in pdaXrom, the old feed is 'frozen' and it used to be lost. I'm talking about non-core feeds here as well (i.e. contributed ones that may/may not with other versions of pdaXrom). No back porting is really done.
- Dependancy Change Issue - If a major library changes (IE, say libc, glibc or something everything depends on), too many contributed packages will break! Same old story, who will go through the steps to repackage them (talking about contributed as well as core feeds)? In fact, it may take a while before someone realises the package doesn't work if it’s not too popular a package.


I really don't wish to see a project like this die because of one of these flaws. Something that most distributions have is the following: -
- Version control with full logging and accessible access to the code. All of it!
- A method of generating a new feed (by compiling everything based on rules/recipes) when new versions that may break old feeds come out

The advantages, especially of the latter point are: -
- Rule based packaging - If I want to package something, I create a recipe/rule for it safe in the knowledge that most likely this same rule/recipe will work to recompile the package for future versions. I can submit this somewhere and know that someone else can run the 'rule' and get a package. This takes lots of things out of the equation
- Effort expended only once - Because I only really have to use the effort once to create the rule/recipe I'm more likely to create packages. If I'm bored, I'll just randomly pick one and create it. Then forever more that package (possibly with minor tweaks to the rule/recipe) will be available.


What I'm describing as most of you may already know is already provided in the OpenEmbedded framework. I realise there has also be friendly (and some unfriendly) rivalry between OpenZaurus and pdaXrom, but I think that no one can disagree that OpenEmbedded does a pretty good job and takes a lot of risk away. I'm not saying this is the only way, but a lot of the work is already done here.

I decided the other day to backup my pdaXrom installation, install OZ/GPE and try out OpenEmbedded to compile things. I haven’t before because its scary learning something new and I'd heard that OpenEmbedded was a bit difficult. I took my time tracking app (Gtimer) that I use (and normally use in a debian chroot) as my challenge to package. It’s a bit of a complicated package in that debian provides quite a big patch for it (the author no longer maintains it), it’s still packaged for the older debian system (IE, the original_tar is a tar of a tar.bz2) and uses libgtk1.2. It took me 30 minutes to work out how to use OpenEmbedded (to compile nano as an example...), then 1 hour to muddle my way through to create a recipe that downloads, extracts, patches, compiles and packages gtimer (and the end recipe is only 14 lines long!!). I can submit this and know that gtimer will always be around now (since the whole feed is compiled for each version), and if I get 'hit by a bus', someone else surely can fix a 14 line file. And someone will KNOW it breaks because the WHOLE feed is compiled every version and non-compiling packages will be flagged. I also don't have to figure out how to create a tool-chain or any of the dependency libraries as they are compiled by OE automatically as part of creating my package.

What I would like to ask is if pdaXrom developers please (please!) could seriously consider using this valuable tool (or an equivalent if it exists). You can (and probably should) have a totally separate 'branch' from OpenZaurus dedicated to the pdaXrom style that people could contribute recipes to... and it also means that probably with minimal tweaking, rules can be take from the '.dev' and '.oz354x' branches and vice versa. It means that you're still 'separate' but that everyone can contribute and maintain what is a very good OS.

What do other developers and users think? This is NOT a flame starter and NOT a this-rom is better than that-rom thread! It is simply my concern that I wish to express!


- Bundabrg
17 Jul 2006
Ok, I've searched everywhere and simply can't find documentation on keylaunch. So I've pulled apart the code and worked it out. To save someone else the same frustration, here are my notes.

Firstly, for those who don't know, keylaunch is used to bind 'commands' to hotkeys. For example, pressing 'Calendar' can load Calendar, and pressing 'Fn 3' can lower the brightness.

Keylaunch uses /etc/keylaunchrc, and can also be (overridden? in addition?) by ~/.keylaunchrc.

A typical keylaunchrc may look like this: -
CODE
# Comment

key=....F9:-:command
key=...*1:chvt 1
key=....Released F9:anothercommand



Each line has the following format ([]'s means optional. {} means its a variable):
CODE
key={flag}[{option} ]{keyname}[ {combinekeyname}][:-]:[~]{command}



Lets look at each bit seperately: -
key= - This is always the same.

{flag} - 4 characters, normally ....
- Each character corresponds to a modifier. If the modifier is pressed at the same time, then this key will be triggered. IE, Control + 1 can give a chvt 1.
- If the FIRST character is '?', then all the flags are ignored, and it will trigger on ANY modifier
- OTHERWISE, each character can be '.' (not selected) or '*' (selected), and the modifiers are as follows: -
*... - Control
.*.. - Shift
..*. - Alt
...* - Fn
- I'm pretty sure you can have more than one modifier.

[{option} ] - Optional Option. Note the SPACE afterwards if used!
- This dictates on what event the key must trigger. If you don't specify an option it assumes when the key is pressed.
- The events can be one of the following: -
Pressed - Occurs when the key is pressed
Released - Occurs when the key is released
Held - Occurs if the key is held for a bit
Combine - Occurs when you press TWO keys (IE Calendar+AddressBook} You MUST provide {combinekeyname}.
- Don't forget the space!!!

{keyname} - The name of the key to trigger on
- The names are defined in /etc/keymap-2.6.map

[ {combinekeyname}] - Iff (if and only if) the Combine option is used you specify a second key here.
- Don't forget the space BEFORE this (ie, between key and combinekeyname}

[:-] - Try to raise an existing window
- If this exists then when the key is triggered keylaunch will first see if there is already a running instance of the command, and if so, just bring it into focus.
- If it is omitted, then it will load a new instance every time.

[~] - Disable startup notify
- If this exists (IE, a tilda before the commandname), then startup notify will not be used. I think this means that you won't see the hourglass in the corner.

{command} - Command to run
- What command to run.



Feel free to post your changes you've made to your keylaunchrc files. I'd be interested in getting some ideas.

- Bundabrg
30 Jun 2006
Ok, back to the same old problem I had last time I installed OZ. Every restart my Z resets its time to some abituary time (but not 1970, so its reading some stored time from somewhere)

I installed slutils, which normally fixed the problem, but under the new OZ (3.5.4) I get the following error if I set or read the so called 'hardware' clock: -
CODE
ioctl(MEMWRITELADDR): Inappropriate ioctl for device


I'm assuming the new kernel doesn't allow this anymore. How do I store the time, and how do I read it?

- Bundabrg
28 Jun 2006
Hi All,

(C860, 1Gb SD, Symbol24 Wifi CF)

OK, I'm doing a 'rom' tryout, and have now setup OZ Opie and GPE to run at the same time on VT2 and VT3. Also edited the relevant files so pressing <ctrl><alt>#num on any VT will change VT's fine. Oh, and switched / and ,.
The only thing I needed to do to really get this to work different from the wiki is to chmod u+s /usr/bin/chvt as chvt needs to run with root privs.
Oh, I also did it from the GPE image and then installing the Opie packages. The other way just seemed not to work well for me and indeed its interesting the number of differences the two ways gives (ie, /etc/ipkg/* versus /etc/ipkg.conf is one example).

Now I realise Opie/GPE is not a supported option, fair enough so I'm looking for what people who HAVE got it running did. Maybe some tricks and tips etc. I almost think that bar running qt4 under X instead, having a dual image would be useful, though installing it was fairly easy anyway.

My questions: -
- I've had to disabled ALL idle suspends etc under both GPE and Opie. Is there anyway that the idle checker can determine if there is activity on another VT? Currently if they are enabled, then if say I'm in GPE, and Opie suddenly realises there is no activty on it for 5 minutes, it suspends.

- Feeds. ipkg is really really REALLY slow. I think because of the base feed. However I can live with this. My issue is knowing if a package is opie or GPE when installing. Currently I comment out the opie feed, update then install when wanting to install a GPE app, and vice versa for opie. (IE, kopi is a good example). My question I guess is, are there any collisions of names between the feeds (the official OZ ones, not 3rd party).

- I have set my sd to be default install (after installing most OPIE and GPE apps to root first). However I have one of those annoying SD cards that comes up with Input/Output error frequently if under usage (even mounted sync). I solved this by forcing a sync every 1 second when installing packages and hopefully will get another card one day. When I restart, the SD card is never automatically checked, and I can't unmount it as its always in use now (applets running etc...). Any proper way of getting round this? I've updated the insert scripts so when an SD/CF is inserted, it runs a filesystem check on it, then plays a 'sound' when its done.



Oh and finally, why gpe-bootsplash? I always just remove this because I like to see whats happening. Why cover up nice the really nice main splash screen with the whiteout splash of GPE (though I now see that the boot messages come up through it, which is an improvement).

EDIT: Excuse typos. I've just had a daughter and am very sleep deprived (and hence why I have the time to reflash ;-)

- Bundabrg
20 Dec 2005
Ok, I'd like to check with anyone who is running kopi. I'm running the one that was posted in This thread.

Does your Z lock up if you suspend, then quickly resume again straight away (IE, within about 5 seconds).?

If I close everything but kopi (and its a kopi with events and alarms in it, not a blank one), my Z does this. Does it every time. I just hit suspend button, wait for the screen to go black, then hit the button again... screen comes on, everything is locked up (can't move mouse, can't ctrl-alt-backspace).

If I open LOTS of other apps, but not kopi, then it works fine.

Interestingly, if I run kopi, suspend, then wait at least 60 seconds, then resume, its ok.

This behaviour occurs under both matchbox (openbox) and xfce4

Edit
I have a C860 running RC12
End Edit

- Bundabrg
Last Visitors
Bundabrg has no visitors to display.

Comments
Other users have left no comments for Bundabrg.

Friends
There are no friends to display.
RSS Lo-Fi Version Time is now: 27th November 2014 - 01:35 AM