TinderBox Issues and Workaround

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...

QA using TinderBox

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.

Akademy2005

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 640x480 (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.

Weekend hacking

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.

POWER to the students

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...

Serial cable for Dell Axim x50v

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...

Late LinuxTag impressions

A delayed writing up on my one day visit at LinuxTag:

I took the train to Karlsruhe in the morning, sadly it had no power plug in the whole train so I was not able to do the scheduled bitbake hacking.
I arrived at 10 o'clock in Karlsruhe and went straight to KDE booth, it was way smaller compared to LinuxTag 2002. I waited for Tobias König, Cornelius Schumacher and Michael Lauer to arrive...

Cornelius, Tobias and me met with Armin Bauer of OpenSync to discuss its possible usage in KDE: Basicallyy OpenSync is 1:1 copy of the core architecture of KitchenSync but written in C and using glib. Its strong points are it is actively developed and looks like it will be maintained as well and it does not use KResource and libkcal natively for transporting its data. Almost all crashes I've seen with KitchenSync are due issues with KResource so OpenSync promises to be more stable. OpenSync promises that people only need to write one plugin for each gadget and this is where OpenSync can help both GPE and Opie.
Both projects will only need to provide one plugin, written in there favorite language and it will work with KDE, Evolution, Mozilla... that is probably the most promising aspect of OpenSync and makes the usage of glib acceptable.

Sadly I did not get OpenSync to do anything useful yet (using file and evolution plugin) the multisync gui simply hangs...