European Wafaa

It's been almost a month since the last ARM porting update so here's a little christmas present to you all.

Dirk Müller sent out a status update to the mailing list, but I thought it would be a good idea post here for you scoundrels that aren't subscribed :-)

Thanks to some great work by loads of people including (but not limited to) Alex Graf, Adrian Schröter, Dirk Müller, Marcus Schäfer, Joop Boonen openSUSE's ARM port has come along nicely.  We are now at about 4200 successful packages out of a total of around 4700 for a complete distro, an increase of roughly 700 packages.

There are some localised issues for ARM but they are much much fewer than before. As we are building against Factory we naturally are affected by Factory's occaisional desire to break for the sake of breaking, but again those breakages are realtively few.

Marcus has managed to get Kiwi support to build ARM images (with a patch or two from Joop); Kiwi can run on Pandaboards, and also generate suitable images for for Pandaboards – the other boards and devices will come later. Alex, Dirk and Adrian have been busy beavering away as usual with package fixes, improvements to qemu and general OBS tweaks; they have also got the internal ARM OBS instance into a great shape, this is distributed between the Nürnberg and Prague offices and the nodes comprise of EfikaMX, Pandaboard & Beagleboard. It basically builds factory in parrelel to the public OBS but generally is more successful due to running on native hardware, whereas the public instance uses qemu which sometimes doesn't want to play nicely in the playground; we (well OK Alex) can then look at getting a fix for qemu or we import the succesful package into the OBS can move on. I'm still battling with kernels for the Snowball, but I think I'm almost there.

One of the bigger issues we have is that there is no graphics support, if you think graphics issues on x86 based systems is a pain wait till you look at it on ARM! ;-) This is being worked on so it's just a matter of time, there are ways and means around it but they are far from elegant.

As everyone likes videos, Joop has created another great video showing openSUSE running on a Pandaboard (Joop uses one of those aforementioned ways & means to get graphics working) and Michal Hrušecký has a video showing openSUSE on his Asus Transformer Tablet (yes it's still in a chroot but look at that ncurses yummyness :-) )

Just to remind you that you will be able to see first hand some of the ARM porting goodness at FOSDEM in Febuary so make sure you come along ;-) Till the next update, have a fun and Geeko filled time

Sorry that no news has been dished out with regards to the openSUSE ARM porting effort, but that's mostly because things have been busy (honest!)

For starters we have now successfully built around 3500 packages out of a total of about 4700 for the full openSUSE ditribution. So we are well on our way. It hasn't been easy going though, and we still have lots of hurdles, hoops and obstacles to overcome.

Alex Graf has been beavering away into the small wee hours getting among things lots of fixes into qemu to help with builds, fixing kernel builds that I and Adrian Schroeter created, and generally being an engineering machine.

As I mentioned Adrian Schroeter has been busy with creating as generic a kernel as possible to be used in the OBS with qemu. He has also been busy fixing packages in association with Dirk Mueller, Reinhard Max and others.

Joop Boonen built u-boot and submitted it into the relevant devel project. So we now have the means to properly boot an ARM based system.

I've been busy building hardware specific kernels, which I'm still learning how to do properly. As it stands we have kernels built for Freescale powered EfikaMXs, Texas Instruments powered Pandboards & Beagleboards, Nvidia powered Tegra2 devices (mainly Trimslice) and soon ST-Ericsson powered NovaThor devices like the Snowball.

Work is still on going, one really good thing is Kiwi support for ARM is being worked on. Marcus Schaefer has rolled his sleeves up and is attacking it with gusto, and making good progress. It is by no means a done deal, yet. It does show though how versatile openSUSE's toolsets are. Hopefully it won't be too long until we can get things working, and hey maybe even get those fine folks in SUSE Studio to add ARM as an architecture so that we can have highly customised ARM builds :-)

As I also mentioned, the kernels aren't perfect yet. So we still need to do more testing and fine tuning. One item that was identified (by Alex of course) was that we have an issue with unwinding. There is a "hack" identified to get things working but a proper fix is still being sought.

We also have some exception handling issues which prevents us from builing Java and Java related apps which in turn are preventing us from building a lot of the remaining 1200 or so packages. We do still have some packages that need fixing which don't require any of the exception crippled packages, so feel free to jump in ;-)

There are some areas that still need some love on ARM, like hwinfo and also our darling YaST. X drivers are also a bit of a grey area, actually they're more likely to be missing.

All in all we still have our work cut out for us, but we are making good progress.  I can't say when we will have working images for people to try, so don't ask; but trust me, I will make sure to let you all know when we do. I am hoping to have something working in time for FOSDEM and hopefully show it off there.

Just to give you an idea of what we are using the hardware that has been donated so far: EfikaMXs are currently employed natively building packages, one of the issues we have with qemu is that it can be tempremental at times and isn't suited really as a long term solution as it stands. So the EfikaMXs build all the the failed packages to make sure that qemu isn't at fault - we found a load of packages built, and as such were imported into the OBS to get things rolling on. They are also being used to help out with Kiwi support. Pandaboards are being used for testing and bug hunting mostly, but also for packaging. There is also one device of each type for kernel testing/tuning.

So if you're interested and aren't afraid of getting your hands dirty (or occaisionally burnt) do join in. Jump on IRC (#opensuse-arm on freenode) and let's have fun together.  Oh and don't forget this is a community effort and as such we still need a bit more funding to get some more devices.

Some people may have noticed that I've been fairly quiet on the Geeko front, this has been mainly down to an insane amount of work but also some other bits and bobs.

Some of those bits and bobs are a result of my mind running away with me, I like to believe that I'm a good thinker, some people say I'm a daydreamer, others say I have an over active imagination. Personally I reckon they're all correct :-D 

This has a downside though of loosing focus.  If I was a business I would be bust or very close to going bust, as I no longer have sight of my core product and am trying to enter new markets with half hearted products that aren't of any use to anybody. So something has to change, and as such I'm looking at trying to calm down and regain focus.

Previously focus wasn't that difficult – after all I was charging around getting dear old Smeegol out. That was no simple task and was hugely enjoyable even though many things would really tick me off.  My pet project that I intended on doing was that little bit too crazy even for me, mainly because my C++ and Android knowledge isn't up to the task, no development experience of LibreOffice and not a huge amount f spare time.  As such I'm not going to be going forward with this.  Luckily thanks to those kind folk at Google, LibreOffice has been accepted into GSOC and I believe this is one of the projects that will be mentored.

I was also looking at getting MeeGo's new Tablet UI built on openSUSE, unfortunately I don't really have the heart at the moment for this for some reason, and I'm not entirely sure I'm prepared for the massive amounts of pain involved.  Oh, and as a minor item I don't have any hardware to dogfood with. So I'm shelving this idea too.

I'm going to try and go back to roots, which means chipping in and helping out with the GNOME team, after all we can't have it dominated by the French and Swiss now can we?  I am also lucky enough to be a co-mentor for GSOC in getting Entomologist better.  So this is something that I'm looking forward to – hopefully I get to slowly and comfortably get better with Android and C++ ;-) I also want to try and blog a bit more. I was hoping to be able to do some items as part of my job around Spacewalk and other bits, but unfortunately this hasn't materialised :-(  

So I'm going to try and focus any spare time on these two items, if anyone sees me do otherwise please slap me and remind me what it is I'm supposed to be doing.

I previously enlightened people to entomologist and also showed an image or two of it running on Android. Well now's the time to get your funk on and help test, file bugs and generally make it better.

You can download entomologist from the Android Market, or if you don't have access to the Market you can grab the .apk. When you launch it for the first time it checks to see if you have the required Qt libraries, if not it will ask you to install Ministro (if not already installed) from the Market (grab the .apk if you don't have the Market), once installed it then grabs the required libraries - probably best to be on a wifi connection rather than cellular just in case.

I know the UI isn't the best for mobiles - it works fairly well on my GalaxyTab thanks to the large screen & higher resolution. Reason for releasing now is so people can contribute ideas/code/bugs/etc.

If there are any UI designers bored and fancy a little piece of fun, then please join in - I'm not looking at anyone in particular, Mr LeSage & Mr Fitzsomon ;-P

So as I mentioned earlier I managed to port entimologist to Android. This post will hopefully explain how I did this.

The shopping list for this task is relatively straight forward:

• Android SDK
• Android NDK
• Java development files (on openSUSE I use java-1_6_0-sun-devel)
• ant (on openSUSE ant is too old, I use the binary tarball from the Apache site)
• Qt Creator for Android SDK a.k.a Necessitas
• Not necessary but could be helpful – Eclipse (on openSUSE don't use the packages available as there are things missing that prevent building for android, use the binary tarball from the Eclipse site)
• Ministro

First thing I had done was install and setup Eclipse, I then setup the Android SDK & Android NDK – that was done months ago. See the Android Developer site for good, clear instructions.

For setting up Necessitas, I used Alessandro's post & video as a guide, but there are also details on Necessitas' site.  After following the steps, I couldnt quite get things working, and I was starting to think that GNOME3 and Qt, were being children and bickering. No, they weren't. It was me being a dufus! I hadn't read the bit about ant needing to be >=1.8.0 :-) Download Ministro to somewhere safe (I popped mine in /opt/necessitas)

So to get things to work, I un-installed the ant rpm, extracted the bibnary tarball into ~/bin, and did a sudo ln -s ~/bin/apache-ant-1.8.2/bin/ant /usr/bin/ant

Now I wont pretend to know WTF I'm doing with Qt, as far as I'm concerned it's another alien language. Problem is I needed to tell Necessitas what Qt libraries entomologist needed, I had no real idea. I had a look at the source and the spec file and got some clues, so I added the ones I thought were needed. I tried a build and got further than previously (now that I had the correct version of ant!). I was now getting some weird missing library error, but I couldn't work it out. Along comes our new Boosters member Ismail Dönmez to the rescue.  There will be a lib$APPNAME.so that is created to work out which Qt libraries you need just do a readelf -d  lib$APPNAME.so.

In my case I did readelf -d libentomologist.so and got:

~/workspace/Entomologist-build-android> readelf -d libentomologist.so

Dynamic section at offset 0x4bda8 contains 29 entries:

It may seem obvious, but look at the ones that have (NEEDED) in them ;-) I was missing libQtXml.so. Simply add the missing Qt library either by adding it manually in $PROJECT_LOCATION > Other files > android > res > values > libs.xml, or simply tick the required one in Qt Creator by going to the Projects button on the left > Run > Package Configurations > Libraries tab

When testing your app, make sure you select “Install Ministro system wide qt shared libraries installer” from the Projects button on the left > Run > Deploy configurations, then select the .apk in the “Choose apk” button.

Once that's done, hit the “Play” button on the bottom left of Qt Creator and off you go :-)  I appreciate it may seem like a lot of work, but honestly it isn't that much. I buggered around for ages cursing, mainly because I hadn't checked my version of ant and didnt read the error message being spat out. I also didn't know about readelf -d.  All I need to work out and try now is publishing to the Market https://market.android.com/. So all in all have fun and keep being cute Qt :-D 

I like to think of myself as being fairly consistent, and I've had one request for a long time, a desktop bug tracker client. I even asked  if someone more adept in the ways of The Code could help. Unfortunately my call for help wasn't heard :-(

That was until HackWeek VI  came along! Luckily Matt Barringer (from those crazy cooks in the SUSE Studio team) heard my call. He picked up his code machine gun and blasted away \o/ 

A few days after HackWeek VI ended he enlightened me to his new masterpiece – Entomologist.  So what is it? As you may have guessed, it is a desktop bug tracker client.  It's cutely written in Qt, isn't final yet (is any software?) but works fairly well.  Why only fairly well? Simples, it only supports Bugzilla at the minute, but there are plans afoot to add others (please see the ToDo list). Once more bug backends are added it will be great (yes, this is a subtle hint for you to contribute code ;-) ). It is being put forward as one of the GSOC projects so fingers crossed ;-)

Of course you need some obligatory screenshots, so feast your eyes :-)

Seeing your bugs on the desktop

Seeing your bugs on the move.

Yes that's right, entomologist works on Android!! Sure the UI is a bit butt ugly on the platform, but the app works ;-)

I'll do a post on how I ported entomologist to Android shortly, it wasn't too difficult.

So if you want to give it a whirl, then head over to the homepage and choose your flavour of openSUSE, Fedora, Mandriva, Ubuntu or Debian (thanks OBS)

UPDATE:

For those that want to minimise the number of clicks the list of repos are:

• openSUSE 11.4
• openSUSE 11.3
• openSUSE 11.2
• openSUSE Factory
• SLED 11 SP1
• Fedora 14 (untested)
• Fedora 13 (untested)
• Fedora 12 (untested)
• Mandriva 2010 (untested)
• Mandriva 2010.1 (untested)

.deb packages are also provided:

• (K)Ubuntu 10.10
• (K)Ubuntu 10.04 (untested)
• Debian 6.0 (untested)

Yes, you read that correct - I am going to try and port LibreOffice to Android! :-)

Why? Simples, there are no ODF compatible products on Android for reading & writing. There is OpenOffice Document Reader which as the name suggests is just a reader, and also OOo is so 2009 ;-)

Now if I was a half decent hacker, this may not have been such a big deal.  Problem is I'm an absolutley crap hacker, with almost no experience or knowledge of Android or LibreOffice development. So why on earth would I try and do such a monumentally painful task? Two reasons - 1. I was challenged by an engineer that I respect to do it. 2. I've got an itch that needs scratching (actually I'm riddled with itches, and the Doc confirms it isn't a medical condition ;-) ).

So how to go about it? I'm still working that one out. As it stands openSUSE doesn't provide the necessary tools for the job - no decent ARM port :( So I'm going to have a play with Debian - after all 6.0 Squeeze is just out the oven so now's as good a time as any. If that doesn't work out I'll give Ubuntu a whirl.  Never fear oh mighty Geeko lovers - these alien installations will be going on my test machine. My primary machine is still running openSUSE, with GNOME3.

I'll try and document my trip through pain and fun, if for nothing else humour for those more seasoned than me at doing cooky stuff like this.

Just as a little side note - my primary machine, a Dell D820 decided to die just before FOSDEM. This has left me using my Netbook as my main machine. It took me ~15.5hrs to build LibreOffice on it.

As many know, I have a few Android devices, and I know a lot of other openSUSE fans out there also have robot powered devices.  I decided the other day to try something during my lunch break - create a widget to show how many days left till 11.4's release.

Yeah I know it isn't an earth shattering application, but I'm not a code monkey, so any working code I generate is a serious plus for me ;-)

So my lunchtime project was inspired by the efforts of someone at Ubuntu who was doing the same for their Natty release.  I used this tutorial to help get me going.  I now present to you oSRCD - the openSUSE Release CountDown. 

It isn't perfect, but it is a start, so if there is anyone that is a bit more able in the ways of Android programming or artwork then please join in :-)

You can grab the source code from github or the .apk for manual install. And as it's a mobile app here's the QR code:

Personally I find that in Linux or any OS for that matter, keeping track of and dealing with bugs can be a real PITA.  This may be in part that I'm not a power user of the services available (they don't make it obvious how to fully utilise their service); also there are so many different types of bug trackers out there - bugzilla, trac, mantis, etc; it is also down to so many different projects use their own tracker; one advantage is that code/project hosting sites have their own - SourceForge, Gna!, launchpad, BerliOS, etc.  So all projects under these use the same tool/interface.  Yes bugzilla is probably the most common, but it is also one of the most modified - no two projects using it are the same and the work flow differs as much as the visuals.

As an illustration, I am active or have a keen interest in openSUSE & Bongo.  One uses a customised version of Bugzilla and the other uses GNA!'s Savane.  As a result, I am also in contact with a multitude of other projects (GNOME, KDE, Freedesktop.org, Moblin, Gwibber to name a few).  These all have their own bug trackers on different services, so to add them to the original two means I have at least seven different tracking services to deal with.  My dealings range from filing bugs, to monitoring a bug for information and even the odd occaison where I am assigned a bug to resolve.

Now I know they all pump out emails when something changes to the bug, but having to hunt through my email to get bug ids or whatever is annoying to say the least, not to mention filling up my inbox.  One big gripe is with people adding themselves to the CC list; do I really care if Chief Umbuzweiluh has added himself to the CC list for a particular bug? No!

Now what I would like is:

• An application that can either sit on my desktop or in the notification panel that can help me manage all my bugs.
• The app would need to be cross desktop friendly, so that it doesn't look out of place on whichever DE I'm using - yes I do use more than one :-)
• Ideally offer some form of offline functionality - caching/storing the information locally.
• I don't care what language it is written in, something that anyone can understand would be handy, heck I may even contribute some code if it is easy enough ;-)
• Support multiple backends, as I said I use lots of different trackers so getting the bulk of them supported would be ideal.

When I mention "offline" I would ideally like to have read+write access so that I can then update a bug say if I'm on the move and then the app syncs with the backend next time I'm online.  I appreciate this may be harder to implement so I'd be happy with read only access.  Basically the sort of information I'd like to see is something along the lines of:

|Tracker(1)|BugID(2)|Summary(3)|Status(4)|Role(5)|Product(6)Priority(7)|Severity(8)|+(9)|-(10)|

1. Which bug tracker is it on - Novell, GNOME, Launchpad, KDE, etc. Ideally show the logo of the tracker but if not a short text - BNC, BGO, LP, BKO, etc.
2. The bug number, ideally as a hyperlink so that it can be pasted into and email or IM conversation.
3. The bug summary. Basically whatever is put into the summary field of the bug.
4. The status of the bug - New, Assigned, Re-Opened, Unconfirmed, NeedInfo, Closed.
5. What is your role with the bug - Reporter, Asignee, CC.
6. What product is the bug against.
7. What is the bug's priority - Urgent, High, Normal, Low.
8. What is the bug's severuty - Critical, Major, Normal, Minor, Trivial
9. Add a bug by either ID or url.  In an ideal world one would even be able to generate the whole thing from scratch and when you add it it create the ticket on the service and fills in the bug id for you.
10. Remove a bug. If one is on the CC list it would unsubscribe you from it.

As I'm no code monkey I have no real idea on how to implement my idea, but what I do know is what I would like.  I would be more than happy for an app that just provided the above mentioned table, but in an ideal world the app would also provide the full conversation of the bug showing all comments and any attachments.  Baby steps first, get the basic information available then add features as things progress.

Now I would love for the app to do the notifying of bug changes for me so I can disable all the email notifications I get.  So having some form of notification area presence would be great, and even providing a bubble when something does change:

---------------------------------------------------
| N / BNC(1)|12345(2)|Foo Bar Noob(3) |
---------------------------------------------------

1. Logo or ID of bug tracker
2. Bug ID - clickable
3. What has changed - this could be Status, Role, Product, Priority, Severity

Now depending on how the app works will depend on what happens when one clicks on the bug id. Is there functionality for full context (fat app) or will it just open up in a browser.  The intial services I would like to see are (in priority) - Bugzilla, Savane, Launchpad, Trac, Sourceforge, and then anyting else.

So does anyone fancy being my hero and coding this for me?  It would be great if we could get this as part of GSoC - I'll add it to openFate and the wiki ;-)

If anyone knows of something that exists that provides this functionality please let me know.  Chris Lamb did create a GNOME Applet for the Debian BTS tracker that kind of did this so if it helps have a look here for the code.