moiji-mobile

Before I stop blogging once again here is a small status update.

BitBake now features a ‘-g’ option. bitbake -g world will generate a couple of directed graphs. Currently only depends.dot is complete. The above command will generate a complete dependency (build-time as in DEPENDS) graph for the world target. I have no image linked here as the dot is still generating the graph. In the future we will also generate a rdepends.dot and alldepends.dot graph. Both are pretty straight forward now that we can generate one sort of dependency graph. Sadly this feature is not too useful ATM due the OpenEmbedded base.bbclass as each package will depend on quilt-native, virtual/libc and the dependecies of them. This means we will have a lot of edges from nodes to the base dependencies. The solution currently in my mind is to add another option to inform BitBake to stop at a list of dependencies to avoid this situation.
The next step could involve tuning the output to hint dot to generate better graphs. Well we will see how this is evolving.

On the OpenEmbedded front, I won’t comment on the familiar split-up, I have added the NetworkBlockDevice (nbd) package. I deploy a nbd-server on my NSLu2 and have a nbd-client on my SHARK to add swap to the machine. I have finally cleaned up my desk a bit and moved the SHARK, NSLu2 and the PowerPC board, thanks again, away. They are now all plugged together and the NSlu2 will serve NFS to them. Obviously all these machines use OpenEmbedded to some degree or will use it in the future. They are all part of my secret QA plan.

On a private note I’m planning on getting a new desktop machine as mine is getting slower and slower. My currently preferred system is an Athlon X2 based one but I’m still considering if I ask for donations once again…

I invested my spare time in working with that crappy proprietary wink. I think it should be relabled to hog to make it obvious it is a memory hog. And like with any proprietary software you have not been granted the right to fix it for them. Anyway besides the memory issue wink feels really nice but if you can not generate the flash movie in the end this all doesn’t count. I’m currently waiting for the killall -9 wink to be executed so I can use my desktop again… fun.

My gcc patch works nicely with versions 3.4.4, 4.0.0, 4.0.2, 4.1.0 and 4.2.0 snapshot. This will greatly help finding issues with gcc when cross-compiling. A really bad error is when you compile for another endian and another libc and include headers of the host system. It is even worse if you run configure tests you are basicly configuring for your host system and not for your target. A lot of can go wrong if that happens, and since people use AMD64 to compile OpenEmbedded we see bugs coming up.

Oh and my favorite gcc option for now is -isystem, I will probably hack a -lsystem together to help OpenEmbedded. I have now at least two gcc hacks I should consider bringing into a submitable state as they are making gcc a better cross compiler.

Current Impressions:

• Will FSF leave the Google Summer of Code? Or will they trade Freedom for Money?
• Easily installing software into an ARM qemu image to test software quickly

One of the weak points of OpenEmbedded is the documentation, or to be accurate the lack of any documentation. OpenEmbedded is by the far the most flexible system out there but documentation has really suffered. This means you can use OpenEmbedded for many many days but are still unaware of certain features. To overcome this situation Koen and me have started creating a documentation. This documentation is written using DocBook and will be task orientated. It will illustrate how to achieve the common use-cases easily. Typical for OpenEmbedded everything is already available in our SCM system, once it features some more text I will point you to the xhtml,pdf and html versions of it.

Part of the documentation is also to provide some kind of tutorials. These tutorial are getting more and more popular. After having looked at istanbul, I have decided to give wink a try. Wink features editing capabilities, this means I can show and hide balloons with some information, and make the user interact with the demonstration. The only issue with wink is, it is a memory hog and I made it go Out Of Memory twice already. This means after you have recorded your screencast and hit the Finish button it will just freeze your machine and you will have to start over again. Obviously this pretty much sucks. As a workaround you can record steps of your tutorial seperately and copy them into one big tutorial afterwards, I hope this approach will work out right.

To use wink I have used Xephyr to start on DISPLAY=:1 in 800×640 and started a gnome session in there. This is quite nice but I have already fallen victim of Xephyr. First it has issues with my keymap, I’m unable to use curly braces in Xephyr and the second issue was hitting CapsLock and it didn’t go away… pretty bad.

Hacking the Gnu Compiler Collection. I have hacked cpp to error out when including host includes from. This can hopefully uncover certain issues in the future. While hacking gcc I’m in between wow that is neat and the feeling that gcc is really really old software. I think I like it though, well it is using a sort of lambda calculus which makes it sexy.

Once again I try to regulary blog about my experiences… welcome once more

Tinderbox issues and possible workarounds:

Error: Permission Errors
Solution: Yeah tinderbox needs to be owned by one user. This can put one into troubles but looks like the right thing to do.

Error: Spaces, Slashes(/) and others
Solution: Do not put these signs in the VC_Tree, buildtree, buildname. If you do not follow this rules you will recieve weird errors about not being able to move files or not able to process mails.

Error: startime: 0 and tinder.cgi
Solution: sending tinderbox: starttime: 0 to a tinderbox looks like a denial of service attack. tinder.cgi sees the invalid starttime and stops processing. This means all reports after the one will not be processed and status.html will not be updatet…

The OpenEmbedd project kindly hosted at handeld.org is slowly gaining a Quality Assurance architecture. The key part of this infrastructure is a Tinderbox – probably known from the Mozilla project.
Koen and me spent and still spend time on setting the tinderbox up. Tinderbox is written in perl and specially for me this is hard to understand but I could not find anything else that promises the same features as tinderbox.

A Tinderbox links multiple sources of data together and relates them so we can interpret the results. Possible sources are checkins into our SCM (monotone or subversion), our Bug Databases, builds on different systems with different configurations and additional checks.

Tinderclients provide build results and progress by mail, thanks to the flexibility of OpenEmbedded every oe build can function as a tinderclient with just six lines in your local.conf. The tinderclient functionality is implemented as bbclass and monitors the build.
Once our basic setup is done we will ask for you functioning as tinderclients. Your duty will be to run regular builds with a configuration you are interested in.

For example could the familiar people run bootstrap-image for h3900 regulary and monitor regressions.

Besides the buildtests we will do, we plan to run the bittest module as well. Bittest features tests to see if upstream sourcecode still exists, patches apply… These tests are more memory and bandwidth invasive and we need people to run these for us.

First results can be found here and we’re extending the infrastructure. What we did already

• install two tinderbox2 from mozilla/webtools/tinderbox2
• write a VC_svn.pm to track svn using the SVN perl bindings
• fight with ownership of the files until tinder.cgi worked right
• setup a dummy mail account create fetchmail and procmailrc rules to process mails and bug-reports
• make tinderclient.bbclass work with INHERIT += “tinderclient” you can be a tinderclient already. So every build can be part of our infrastructure

But we have much more things todo… but this will be covered tomorrow. I hope koen progresses on his blog better and mails oe AT handhelds.org

Drop us a note if you need help setting a tinderbox, are interested in our configuration or in our VC_svn.pm.

I was so excited about finally being able to attend a KDE developer conference and applied for holding a talk. I’m in the position of requiring subsidies so I made a deal with myself I would only attend if I would be able to do something that would enrich KDE in some way.

With KDE 4.0 development about to start and my background on Mobile Computing through www.handhelds.org and opie.handhelds.org and an internship at www.road-gmbh.de I wanted to make my fellow developers aware where Smartphone/PDA development is going and what KDE should and could do to integrate such devices.

I predict the following development in the market:
The physical formfactor will not change much, it might grow first and then shrink again, it will be touched screen based, its’ display will have at least a VGA resolution, it will have sensors for determining movement of the device and to things like autorotation or generate ‘Left, Right, Up, Down, Page Up, Page Down’ like events. The Itsy was a prototype at Compaqs’ CRL that already featured such sensors.
It will be a beast network wise, it will feature UMTS, Bluetooth, WiMax, Wireless USB with these technologies integrated you will be able to be always connected to the Internet. And that is the key. With technologies like Citrix, Tarantella or NoMachine’s NX you will be able to reach applications too heavy to run on your Gadget/Mobile Client.

I’m confident we will carry such devices in the near future but one thing is for sure it will be a client. The devices will get more powerful and gain new input methods (shaking…) but your Desktop PC will remain more poweful, more comfortable and will be controlled by Mouse instead of a touchscreen.
But in contrast to your Desktop PC you will be able to carry such a device day in, day out. While going to the office, while flying to the Mars, while driving qanu, while sitting in the jacuzzi.

So currently integration of such devices look the following:
(1) You wake up, synchronize your device and download news, go to the office/uni, take notes, finish agenda, take new dates and you go home and synchronize again. If you’re lucky and not a Palm user you can synchronize in your office as well (risking taking confidential data).

How integration can look in the future (remember you’re always connected):
(1) still the same
(2) you will be able to communicate with your Groupware solution from wherever you want. You can partially synchronize data, for example only four pages out of a 1200 pages big PDF document. At some sort of demonstration you take notes on top of these four pages and the next time you synchronize these notes get transferred to your groupware/desktop again.
(3) Your phone is just like your desktop a client to the Groupware/Storage solution but simply with less resources.

Currently KDE has even issues with point (1). Applications, APIs and Frameworks were not designed to implement synchronization. For example KDE PIMs KResource framework renders synchronization solutions impossible to reliable synchronize. In contrast the GNOME Evolution DataCenter solution is more easy to write synchronization solutions for.
KitchenSync did not find acceptance instead synchronization algorithms and features were reinvented for each Groupware Solution support leading.
Solutions like Kolab – often explained as the dumb server – is not suited for mobile applications. The disconnected imap approach works wonderfully for the desktop where disk space is no issue any more but nor for mobile devices with limited space and resources. For integrating mobile clients one currently would need server side query possibilities.

So what can KDE4 do (Part1):
-Support resolutions 640×480 (VGA) to allow Mobile Clients to run KDE (over NX or such)
-Maybe try to support touchscreen input (mouse over effects are useless, no right button…)
-Integrate synchronization support in the core of KDE:
-Allow converting documents to subsets and supersets on the fly
-Allow KDE apps to expose information in a compact way
-For example if you view a page in konqueror be able to safe it in the plucker format
and schedule it for synchronization
-Rewrite KResource with locking/unlocking and query possibilities
-Lock to operate on a fixed point of data
-Query to see all changes since last sync

Imagine the day all company desktops’ are switched to KDE. Imagine the reasons for such a switch, more cost effective, more secure, no vendor lock in… But which client will we support? The marketshare of Microsoft is growing in the Smartphone market and it looks like one more market to be controlled by Microsoft only. Isn’t it funny that we will need to support Microsoft Based Phones in a free desktop that just konquered the market? Why isn’t it important that your Phone is secure, you will be able to customize it, open, you’re not locked in?
I do not see any reason why your phone should be less free than your desktop and with all means we should try to prevent Microsoft controlling the market.

I also believe you can not switch huge amounts of Desktops without integrating Mobile Clients and as I said I do not see a reason why we should support proprietary infrastructure for the same reason libkdecore is not proprietary.

So what can KDE4 do (Part 2)?

• Provide smaller and fine tunable libs usable on Mobile Clients
• Share implementations for freedesktop.org standards with a free Mobile Client
• Make use of ModelView to provide different user interfaces for different clients
• Build Mobile and Desktop Edition out of the same source tree
• Just two different GUIs

• Make Free Mobile Clients perfectly integrated in KDE

Q&A:
Q: I do not see the people using PDAs in my company?
A: They carry Mobile Phones but probably do not recognize they can use the builtin Calendar, Todolist and Addressbook, or find these applications not usable, or can not utilize synchronization. All these will change when devices are getting more powerful and KDE evolves

Q: Why are the decies always connected?
A: More and more WLAN Hot-Spots are accessible prices for GPRS/EDGE and UMTS will fall as well.

This weekend I decided rewriting the parser of bitbake to be token based. A natural choice for this was flex and bison, I used the work of Marc Singer. He produced fantastic lexical analyzer rules (flex) and used lemon for describing the grammar.

I started with pybison as it promised reaching the goal rapidly. I reworked the lexer and the grammar to be bison and pybison compatible but the issues were just too big to continue using pybison.

• No distribution is shipping pybison
• The lexer may not be reentrant which is a huge problem for bitbake as most files inherit or include other files.
• pybison produced syntax errors when exporting the verbatim of the lexer script
• bison2py can not handle comments in the bison files and produce syntactical wrong python modules
• errors are hard to debug

I reiterated over the possibilities and looked at lemon more closely and my conclusion is lemon simply rocks. I find it more natural that the scanner/lexer feeds the parser, the produced parser is reentrant and thread-safe. As I’ve not done anything with bison before I can not judge if lemon’s syntax is less error prone but I’m confident I’ll never ever use bison again.

So the new and optional parser is heavily based on flex and lemon but it will use the bb.data module to store the data and implement the bb.parse interface. For this to work I will need to make Python call C++ code and the C++ code python. Besides never having implemented a python module in C my biggest obstacle is how I will call flex and lemon from the distutils package when creating the module. If all goes wrong I will put the generated files into the distribution and will compile them.

I hope the parser will be a lot faster than the regexp based python implementation we currently have.

The IBM POWER eSeries Truck is blocking the street near our faculty the recent days. I some how really like the big irons of IBM… specially after seing lpar(t) in full glory when being used as a NX server…

I somehow feel sorry for my fellow students (specially the Biology CS Students) they seem to be reducable to the following algorithm:

for( float i = 0.3234f; i != 3.12435f; i = i)
if( annoy_not_enough() ) // tautology
for_each_way_to_ignore_more()
try_to_annoy_more() // recursive call

And they’re not dumb they block the print queue with their huges printouts, block our beloved Linux Computers with their notebooks, randomly block the corridor, speak during lectures… they definately know how to annoy me… and they keep being innovative in exploring new ways…

Yesterday after a long struggle I’ve finally – with the help of a lecturer at my University – got my MAX232 Level Converter working. Now I can communicate with the gadget over a serial link (STUART on the Axim side). Sadly WinCE prevented me from booting because it decided to invalidate the mapped pages containing the initrd and kernel. But doing the initial Software port is the easy task. Once the kernel boots getting PCMCIA, Keys (matrice keyboard), Bluetooth, SD, Touchscreen, Sound working as well will not be too hard thanks to the work of others. The PXA 270 is a highly integrated mobile processor and most of the named functionality is directly provided by this device.
I’m a bit worried the Power Enable controls (GPIOs) are located in an ASIC but we will find that out pretty fast…