Canonical Voices

Posts tagged with 'porting'

Michael Hall

Last month I announced a contest to win a new OPPO Find 5 by porting Ubuntu Touch to it.  Today I’m pleased to announce that we have a winner!

Below is a picture tour of what Ubuntu Touch running on the device, along with descriptions of what works and what doesn’t. If you’re impatient, you can find links to download the images and instructions for flashing them here.

First a disclaimer, these aren’t professional pictures.  They were taken with my Nexus 4, also running Ubuntu Touch, and the colors are slightly shifted horizontally for some reason.  I didn’t notice it until I had already gone through and taken 58 pictures and downloaded them to my laptop.  Apologies for that.  But you can still get a feel for it, so let’s carry on!

Edge Swiping

The touch screen and edge swiping worked perfectly, as was neatly demonstrated by going through the new introduction tour.

Dash & Launcher

The Dash also works exactly as expected.  This build has a low enough pixel/grid-unit, and high enough resolution, that it fits 4 icons per row, the same as you get on Asus Nexus 4. The icons on the Launcher felt a little small, but everything there worked perfectly too.

Indicators

The indicators were missing some functionality, which I assume is a result of Ubuntu Touch not working with all of the Find 5′s hardware.  Specifically the WiFi isn’t working, so you don’t see anything for it in the Network indicator, and the screen brightness slider was non-functional in the Battery indicator.  Sound, however, worked perfectly.

Apps

Not having WiFi limited the number of apps I could play with, but most of the ones I could try worked fine.  Sudoku and Dropping letters don’t work for some reason, but the Core Apps (except Weather, which requires network access) worked fine.

 

Hardware

As I already mentioned, WiFi doesn’t work on this build, nor does screen brightness.  The camera, however, is a different story. Both the front and back cameras worked, including the flash on the back.

Final Thoughts

While this build didn’t meet all the criteria I had initially set out, it did so much more than any other image I had received up until now that I am happy to call it the winner.  The developer who built it has also committed to continuing his porting work, and getting the remaining items working.  I hope that having this Find 5 will help him in that work, and so all Find 5 owners will have the chance to run Ubuntu Touch on their device.

Read more
Daniel Holbach

Whether or not Ubuntu Edge will get the green light or not (read Joey’s great 5 Reasons Why You Should Stop What You’re Doing & Pledge to #UbuntuEdge), everybody’s hard at work making Ubuntu Touch, the beautiful mobile OS happen.

The 7

Two weeks ago we had our first Ubuntu Touch Porting Clinic and it went quite well. We found and fixed a number of issues in our tools, our porting guide and many porters turned up to ask their questions and update the images.

There’s also still Michael Hall’s offer to win an OPPO Find 5. If you are interested in winning it, or work on an existing port, create a new one and generally get Ubuntu Touch on devices out there, show up, talk to the Ubuntu Touch engineers, find out what’s happening and how to get involved.

It’s all happening

Or reach us on the ubuntu-phone mailing list.

Read more
Daniel Holbach

We had our first Ubuntu Touch Porting clinic yesterday and we made quite a bit of progress there.

  1. Sergio Schvezov published a branch of phablet-tools, which will allow everyone to flash all kinds of devices (for which we have images) just by running something like phablet-flash community --device i9100
    This should make things a lot lot easier for everyone. The only thing which needs to be done is to follow this process which documents where the images live. (Flipped images are not a requirement for this.)
  2. Lots and lots of questions were answered in order to port Ubuntu Touch images to the new world order of flipped images. Since some weeks the Android bits live on top of Ubuntu, which will make our journey towards convergence over device borders a lot easier. During the process we updated our (work-in-progress) porting guide with everybody’s findings. Thanks a lot everyone for your hard work in debugging, asking and replying to questions!

We want Ubuntu Touch to run on as many devices as possible and we need some help here.

If you have a device on which Ubuntu runs fine (our devices lists is here), you can help out by doing a couple of different things:

  1. Help with the porting effort to flipped images. Check out the new porting guide. Find other folks who are interested in the port on the mailing list or on IRC. Ask questions, make it a team effort.
  2. Document location of the images. Follow this process to document where the images live. Make sure you 1) use a location for the image which can be used by something like wget/curl without user intervention and 2) check if the newest phablet-flash can handle it. 3) PROFIT!
  3. If image information for your device is already up (list here), check out Sergio’s branch and let us know on the mailing list how things work for you!

These are awesome times for Ubuntu and with every new port, we’ll learn and fix more of general Ubuntu to make it work everywhere. Join the team today! :-)

Update: now it’s just
bzr branch lp:phablet-tools; cd phablet-tools
./phablet-flash community --device <vendor>

Read more
Daniel Holbach

The unstoppable Sergio Schvezov is working on bug 1201811 right now. Once it’s fixed this should put is into a position where users of devices for which we have Ubuntu Touch images (and not just the four devices we supported right from the start) can just use phablet-flash. This doesn’t mean that they are “officially supported” or that they’re built daily in the Canonical data centre, but that you can make use of the images much more easily.

Over time we still want to build more images in the data centre in a regular fashion. One of the big blockers there has been information about the redistributability of firwmare, blobs and closed kernel modules. If you have information about the licenses any of these, it’d be great if you could help with updating the Touch device pages.

On Thursday, 1st August we are going to hold a Ubuntu Touch Porting Clinic in #ubuntu-touch on irc.freenode.net where you will be able to ask all the questions you have and our local experts can help you with updating your image(s) to the new world order. We hope to see you there!

Ubuntu Touch

Read more
Daniel Holbach

Yesterday we released Ubuntu Touch Preview images for four devices. This is a huge milestone for Ubuntu. We always wanted Ubuntu to be everywhere and the Preview shows quite nicely how well the vision of a design family across different form factors works.

There is quite a bit of work to be done, we all know that, but it’s a giant opportunity for us, the Ubuntu community. Everybody can contribute to the effort and we can show the world how we believe software should look like.

How you can help? Easy.

  • You can install the Ubuntu Touch preview images on a device and test them.
  • You can help out designing and shaping the Ubuntu Touch Core Apps.
  • If you are a bit more experienced with bringing software up on new devices, you can help us porting Ubuntu Touch to new devices.

Did the last point find your interest? Excellent, because we just took the wraps of our Ubuntu Touch Porting guide. This also marks the start of our Ubuntu Touch Port-a-thon. We want to get Ubuntu Touch up and running on as many devices as possible.

If you don’t mind some tinkering, maybe some kernel building, some configuration meddling and flashing your device repeatedly, you might just the person we’re looking for.

The porting guide should help you understand

  • how Ubuntu Touch works internally,
  • which bits are generally involved and where to find them
  • how to submit patches
  • how images are put together
  • how to test them and
  • where to find help

To get you started and into the mood, you might want to join us today, at Friday 22nd February at 15:00 UTC on http://ubuntuonair.com when two super heroes of the Ubuntu Touch project, namely Ricardo Salveti and Sergio Schvezov, are going to talk to us about the technical aspects of the phone and the tablet.

Reliable sources tell us, there’s going to be a surprise announce during the hangout as well.

This is the opportunity we always wanted. Let’s make it happen. Bring Ubuntu to the world in all its beauty.

Read more
pitti

A few days ago Olav Vitters announced the GNOME 3.8 goal of porting to Python 3.

This has been discussed on desktop-devel-list@ in the past days, and the foundations for this are now ready:

  • pygobject now has a –with-python option. (commit)
  • JHBuild now defaults to building pygobject for Python 3, but introduces a “pygobject-python2″ project for the transition phase which provides pygobject built for Python 2. (commit)
  • All dependencies to “pygobject” were changed to “pygobject-python2″ to avoid breaking modules. (commit).

So in theory your modules should continue to build and work in jhbuild just fine. Once you ported a module to Python 3, please switch the dependency back to “pygobject” in jhbuild. (This is now also mentioned on https://live.gnome.org/GnomeGoals/Python3Porting)

Please don’t hesitate to ask me or any fellow PyGObject maintainer in cases of trouble; I’m “pitti” in #python on irc.gnome.org.

Thanks!

Read more
pitti

GNOME 3.0 and Ubuntu Natty are currently undergoing a major architectural shift from GTK 2.0 to 3.0. Part of this is that the previous set of manually maintained language bindings, such as PyGTK, are being deprecated in favor of GObject Introspection, a really cool technology!

For us this means that we have to port all our PyGTK applications from PyGTK 2 to gobject-introspection and GTK 3.0 at the same time. I started with that for my own projects (Apport and Jockey) a few days ago, and along the way encountered a number of problems. They are being fixed (particular thanks to the quick responsiveness of John Palmieri!), so I guess after a few of those iterations, porting should actually become straight forward and solid.

So now I’m proud to announce Apport 1.16 which is now fully working with GTK 3.0 and pygobject-introspection. I just uploaded it to Ubuntu Natty, where it can get some wider testing. I also have a pygi/GTK3.0 branch for Jockey, which is also mostly working now, but it’s blocked on the availability of a GIR for AppIndicator. Once that lands, I’ll release and upload the Jockey as well.

For other people working on porting, these are the bugs and problems I’ve encountered:

  • [pygobject] GtkMessageDialog constructors did not work at all. This was fixed in pygobject 2.27, so it works fine in Natty, but there is little to no chance of making these work in Ubuntu 10.10.
  • [pygobject] Gtk.init_check() crashes (upstream bug). It’s not strictly necessary, though, just avoids crashes (and crash reports) when calling it without a $DISPLAY. I’ll put that back once that gets fixed.
  • [pygobject] You can’t pass unicode objects as method arguments or property values (upstream bug). Method arguments were recently fixed in upstream git head, and I backported it to the Natty package, so these work now. Property values are still outstanding. The workaround for both is to convert unicode values to bytes with .encode('UTF-8') everywhere.
  • [pygobject] pygi-convert.sh is a great help which automates most of the mechanical rewriting work and thus gets you 90% of the porting done automatically. It’s currently missing MessageDialog constants, and is a bit inconvenient to call. I sent two patches upstream (upstream bug) which improve this.
  • [GIR availability] libnotify did not build a GIR yet (upstream bug). This was fixed in upstream git head with some contributions of mine, and I uploaded it to Natty. This works quite well now, although add_action() crashes on passing the callback. This is still to be investigated.
  • [GIR availability] There is no Application Indicator GIR, as already mentioned. Our DX team and Ken VanDine are working on this, so this should get fixed soon.
  • [GTK] Many dialogs now scale in a very ugly manner: Instead of resizing the contents, the dialog just grows huge outer padding. This is due to a change of the default “fill” property, and apparently is not fully understood yet (upstream bug). As a workaround I explicitly added the fill property to the top-level GTKBox in my GTKBuilder .ui files. (Note that this happens in C as well, it’s not a GI specific bug.)
  • [GTK] Building GtkRadioButton groups is currently a bit inconvenient and requires special-casing for the first group member, due to some missing annotations. I sent a patch upstream which fixes that (upstream bug).
  • [GTK] After initial porting, a lot of my dialogs got way too narrow with wrapped labels and text, because GTK 3 changed the behaviour and handling of widget and window sizes. This is intended, not a bug, but it does require some adaptions in the GtkBuilder files and also in the code. The GTK 2 ? 3 migration guide has a section about it.

Despite those, I’m impressed how well gobject-introspection already works. It was relatively painless for me to generate a GIR from a libnotify (thanks to the annotations already being mostly correct for building the documentation) and use it from Python. In another couple of months this will be rock solid, and porting our bigger pygtk projects like ubiquity and software-center will hopefully become feasible.

Read more