Canonical Voices

What Timo Jyrinki talks about

Posts tagged with 'software'

Timo Jyrinki

Qt 5.2.1 in Ubuntu

Ubuntu running Qt 5.2.1
Ubuntu running Qt 5.2.1
Qt 5.2.1 landed in Ubuntu 14.04 LTS last Friday, hooray! Making it into a drop-in replacement for Qt 5.0.2 was not trivial. Because of the qreal change, it was decided to rebuild everything against the new Qt, so it was an all at once approach involving roughly 130 source packages while the parts were moving constantly. The landing last week meant pushing to archives around three thousand binary packages - counting all six architectures - with the total size of closer to 10 gigabytes.

The new Qt brings performance and features to base future work on, and is a solid base for the future of Ubuntu. You may be interested in the release notes for Qt 5.2.0 and 5.2.1. The Ubuntu SDK got updated to Qt Creator 3.0.1 + new Ubuntu plugin at the same time, although updates for the older Ubuntu releases is a work in progress by the SDK Team.

How We Got Here

Throughout the last few months before the last joint push, I filed tens of tagged bugs. For most of that time I was interested only in build and unit test results, since even tracking those was quite a task. I offered simple fixes here and there myself, if I found out a fix.

I created automated Launchpad recipe builds for over 80 packages that rely on Qt 5 in Ubuntu. Meanwhile I also kept on updating the Qt packaging for its 20+ source packages and tried to stay on top of Debian's and upstream's changes.

Parallel to this work, some like the Unity 8 and UI Toolkit developers started experimenting with my Qt 5.2 PPA. It turned out the rewritten QML engine in Qt 5.2 - V4 - was not entirely stable when 5.2.0 was released, so they worked together with upstream on fixes. It was only after 5.2.1 release that it could be said that V4 worked well enough for Unity 8. Known issues like these slowed down the start of full-blown testing.

Then everything built, unit tests passed, most integration tests passed and things seemed mostly to work. We had automated autopilot integration testing runs. The apps team tested through all of the app store to find out whether some needed fixes - most were fine without changes. On top of the found autopilot test failures and other app issues, manual testing found a few more bugs

Sudoku
Some critical pieces of software
like Sudoku needed small fixing
Finally last Thursday it was decided to push Qt in, with a belief that the remaining issues had fixes in branches or not blockers. It turned out the real deployment of Qt revealed a couple of more problems, and some new issues were raised to be blockers, and not all of the believed fixes were really fixing the bugs. So it was not a complete success. Considering the complexity of the landing, it was an adequate accomplishment however.

Specific Issues

Throughout this exercise I bumped into more obstacles that I can remember, but those included:
  • Not all of the packages had seen updates for months or for example since last summer, and since I needed to rebuild everything I found out various problems that were not related to Qt 5.2
  • Unrelated changes during 14.04 development broke packages - like one wouldn't immediately think a gtkdoc update would break a package using Qt
  • Syncing packaging with Debian is GOOD, and the fixes from Debian were likewise excellent and needed, but some changes there had effects on our wide-spread Qt 5 usage, like the mkspecs directory move
  • xvfb used to run unit tests needed parameters updated in most packages because of OpenGL changes in Qt
  • arm64 and ppc64el were late to be added to the landing PPA. Fixing those archs up was quite a last minute effort and needed to continue after landing by the porters. On the plus side, with Qt 5.2's V4 working on those archs unlike Qt 5.0's V8 based Qt Declarative, a majority of Unity 8 dependencies are now already available for 64-bit ARM and PowerPC!
  • While Qt was being prepared the 100 other packages kept on changing, and I needed to keep on top of all of it, especially during the final landing phase that lasted for two weeks. During it, there was no total control of "locking" packages into Qt 5.2 transition, so for the 20+ manual uploads I simply needed to keep track of whether something changed in the distribution and accommodate.
One issue related to the last one was that some things needed were in progress at the time. There was no support for automated AP test running using a PPA. There was also no support on building images. If migration to Ubuntu Touch landing process (CI Train, a middle point on the way to CI Airlines) had been completed for all the packages earlier, handling the locking would have been clearer, and the "trunk passes all integration tests too" would have prevented "trunk seemingly got broken" situations I ended up since I was using bzr trunks everywhere.

Qt 5.3?

We are near to having a promoted Ubuntu image for the mobile users using Qt 5.2, if no new issues pop up. Ubuntu 14.04 LTS will be released in a month to the joy of desktop and mobile users alike.

It was discussed during the vUDS that Qt 5.3.x would be likely Qt version for the next cycle, to be on the more conservative side this time. It's not entirely wrong to say we should have migrated to Qt 5.1 in the beginning of this cycle and only consider 5.2. With 5.0 in use with known issues, we almost had to switch to 5.2.

Kubuntu will join the Qt 5 users next cycle, so it's no longer only Ubuntu deciding the version of Qt. Hopefully there can be a joint agreement, but in the worst case Ubuntu will need a separate Qt version packaged.

Read more
Timo Jyrinki

Background

I upgraded from Linux 3.8 to 3.11 among with newer Mesa, X.Org and Intel driver recently and I found a small workaround was needed because of upstream changes.

The upstream change was the Add "Automatic" mode for "Broadcast RGB" property, and defaulting to the Automatic. This is a sensible default, since many (most?) TVs default to the more limited 16-235, and continuing to default to Full from the driver side would mean wrong colors on the TV. I've set my screen to support the full 0-255 range available to not cut the amount of available shades of colors down.

Unfortunately it seems the Automatic setting does not work for my HDMI input, ie blacks become grey since the driver still outputs the more limited range. Maybe there could be something to improve on the driver side, but I'd guess it's more about my 2008 Sony TV actually having a mode that the standard suggests limited range for. I remember the TV did default to limited range, so maybe the EDID data from TV does not change when setting the RGB range to Full.

I hope the Automatic setting works to offer full range on newer screens and the modes they have, but that's probably up to the manufacturers and standards.

Below is an illustration of the correct setting on my Haswell CPU. When the Broadcast RGB is left to its default Automatic setting, the above image is displayed. When set to Full, the image below with deeper blacks is seen instead. I used manual settings on my camera so it's the same exposure.


Workaround

For me the workaround has evolved to the following so far. Create a /etc/X11/Xsession.d/95fullrgb file:
 
if [ "$(/usr/bin/xrandr -q --prop | grep 'Broadcast RGB: Full' | wc -l)" = "0" ] ; then
/usr/bin/xrandr --output HDMI3 --set "Broadcast RGB" "Full"
fi
And since I'm using lightdm, adding the following to /etc/lightdm/lightdm.conf means the flicker only happens once during bootup:

display-setup-script=/etc/X11/Xsession.d/95fullrgb

Important: when using the LightDM setting, enable executable bits (chmod +x) to /etc/X11/Xsession.d/95fullrgb for it to work. Obviously also check your output, for me it was HDMI3.

If there is no situation where it'd set back to "Limited 16:235" setting on its own, the display manager script should be enough and having it in /etc/X11/Xsession.d is redundant and slows login time down. I think for me it maybe went from 2 seconds to 3 seconds since executing xrandr query is not cheap.

Misc

Note that unrelated to Full range usage, the Limited range at the moment behaves incorrectly on Haswell until the patch in bug #71769 is accepted. That means, the blacks are grey in Limited mode even if the screen is also set to Limited.

I'd prefer there would be a kernel parameter for the Broadcast RGB setting, although my Haswell machine does boot so fast I don't get to see too many seconds of wrong colors...

Read more
Timo Jyrinki

A new Compiz window manager performance update reached Ubuntu 12.04 LTS users last week. This completes the earlier [1] [2] enabling of 'unredirected' (compositing disabled) fullscreen gaming and other applications for performance benefits.

The update has two fixes. The first one fixes a compiz CPU usage regression. The second one enables unredirection also for Intel and Nouveau users using the Mesa 9.0.x stack. That means up-to-date installs from 12.04.2 LTS installation media and anyone with original 12.04 LTS installation who has opted in to the 'quantal' package updates of the kernel, X.Org and mesa *)

The new default setting for the unredirection blacklist is shown in the image below (CompizConfig Settings Manager -> General -> OpenGL). It now only blacklists the original Mesa 8.0.x series for nouveau and intel, plus the '9.0' (not a point release).


I did new runs of OpenArena at openbenchmarking.org from a 12.04.2 LTS live USB. For comparison I first had a run with the non-updated Mesa 9.0 from February. I then allowed Ubuntu to upgrade the Mesa to the current 9.0.3, and ran the test with both the previous version of Compiz and the new one released.

12.04.2 LTS    Mesa 9.0   | Mesa 9.0.3 | Mesa 9.0.3
               old Compiz | old Compiz | new Compiz
OpenArena fps    29.63    |   31.90    | 35.03     

Reading into the results, Mesa 9.0.3 seems to have improved the slowdown in the redirected case. That would include normal desktop usage as well. Meanwhile the unredirected performance remains about 10% higher.

*) Packages linux-generic-lts-quantal xserver-xorg-lts-quantal libgl1-mesa-dri-lts-quantal libegl1-mesa-drivers-lts-quantal. 'raring' stack with Mesa 9.1 and kernel 3.8 will be available around the time of 12.04.3 LTS installation media late August.

Read more
Timo Jyrinki

Packages

I quite like the current status of Qt 5 in Debian and Ubuntu (the links are to the qtbase packages, there are ca. 15 other modules as well). Despite Qt 5 being bleeding edge and Ubuntu having had the need to use it before even the first stable release came out in December, the co-operation with Debian has gone well. Debian is now having the first Qt 5 uploads done to experimental and later on to unstable. My work contributed to pkg-kde git on the modules has been welcomed, and even though more work has been done there by others, there haven't been drastic changes that would cause too big transition problems on the Ubuntu side. It has of course helped to ask others what they want, like the whole usage of qtchooser. Now with Qt 5.0.2 I've been able to mostly re-sync all newer changes / fixes to my packaging from Debian to Ubuntu and vice versa.

There will remain some delta, as pkg-kde plans to ask for a complete transition to qtchooser so that all Qt using packages would declare the Qt version either by QT_SELECT environment variable (preferable) or a package dependency (qt5-default or qt4-default). As a temporary change related to that, Debian will have a debhelper modification that defaults QT_SELECT to qt4 for the duration of the transition. Meanwhile, Ubuntu already shipped the 13.04 release with Qt 5, and a shortcut was taken there instead to prevent any Qt 4 package breakage. However, after the transition period in Debian is over, that small delta can again be removed.

I will also need to continue pushing any useful packaging I do to Debian. I pushed qtimageformats and qtdoc last week, but I know I'm still behind with some "possibly interesting" git snapshot modules like qtsensors and qtpim.

Patches

More delta exists in the form of multiple patches related to the recent Ubuntu Touch efforts. I do not think they are of immediate interest to Debian – let's start packaging Qt 5 apps to Debian first. However, about all of those patches have already been upstreamed to be part of Qt 5.1 or Qt 5.2, or will be later on. Some already were for 5.0.2.

A couple of months ago Ubuntu did have some patches hanging around with no clear author information. This was a result of the heated preparation for the Ubuntu Touch launches, and the fact that patches flew (too) quickly in place into various PPA:s. I started hunting down the authors, and the situation turned out to be better than I thought. About half of the patches were already upstreamed, and work on properly upstreaming the other ones was swiftly started after my initial contact. Proper DEP3 fields do help understanding the overall situation. There are now 10 Canonical individuals in the upstream group of contributors, and in the last week's sprint it turned out more people will be joining them to upstream their future patches.

Nowadays about all the requests I get for including patches from developers are stuff that was already upstreamed, like the XEmbed support in qtbase. This is how it should be.

One big patch still being Ubuntu only is the Unity appmenu support. There was a temporary solution for 13.04 that forward-ported the Qt 4 way of doing it. This will be however removed from the first 13.10 ('saucy') upload, as it's not upstreamable (the old way of supporting Unity appmenus was deliberately dropped from Qt 5). A re-implementation via QPA plugin support is on its way, but it may be that the development version users will be without appmenu support for some duration. Another big patch is related to qtwebkit's device pixel ratio, which will need to be fixed. Apart from these two areas of work that need to be followed through, patches situation is quite nice as mentioned.

Conclusion

Free software will do world domination, and I'm happy to be part of it.

Read more
Timo Jyrinki

Whee!! zy

Congrats and thanks to everyone,

Debian 7.0 Wheezy released

Updating my trusty orion5x box as we speak. No better way to spend a (jetlagged) Sunday.

Read more
Timo Jyrinki

I'd like to modify my discussion comment and earlier thoughts into a short blog post touching only some of the technical concerns voiced, and my opinion to those.

Claim (my version): Ubuntu/Canonical is going the "Google route" to become another Android, while Android has not benefited the Linux ecosystem in any way, forking everything

Firstly, Ubuntu is open to development and community for also mobile and tablet - Android has none of that, just code drops that get modded. (yes, some people have a problem with CLA like Canonical's or Qt's, I have no problem with those - let's keep that discussion elsewhere). Ubuntu contributes back to Debian and upstream projects like Qt - those upstream projects it's not upstream of itself. There are not too many free software mobile UIs for example. SHR has some E17 apps, Nemo Mobile a handful of Qt apps and so on.

Secondly, I disagree about Android - even in its current shape and after creating everything from scratch with mobile on mind, Android has done tremendous things for the free software community, kernel development, mobile device driver and making things like Replicant possible. If those aren't directly seen on the desktop side, that's because it's not the desktop and most free software desktop users don't use free software mobile products (usually at most a vendor provided Android).

I feel people get too attached to software projects or even the desktop in general. The money to pay desktop has traditionally largely come from the server. As a discussion-heating example Wayland has been a great promise for 5 years and continues to be, yet no products use it (software products like distributions or hardware+software products). That's not a problem per se for a great and ambitious project, but it means no interested party has taken it to create products. I was very excited about Gallium3D and Wayland in 2008, but somewhat optimistic in believing they would conquer the world in one or two years. In perspective, I've always seen the "version staring" a common habit in enthusiasts me included. I think it extents to "shiny development projects that should be taken into production use immediately".

The Nokia N9 triumphs all other 2011 mobile phones in general and even the current user interfaces like iOS, Android and Windows Phone in general usability ideas (if only it'd run Cortex-A15 instead of OMAP3..). It uses X.org and Qt 4.7. Jolla's plans for their first phone at the end of this year? Qt 4.8, no Wayland. Like N9 which otherwise had unfortunate fate, I hope Jolla will sell millions of free software wielding products to the masses. The biggest problem with X.org is, though, the drivers, generally zero support from vendors so hard to make products. Hooking into Android EGL drivers and building on top of that seems a good compromise at the moment. Note that from product creation point of view it's not the non-shininess of X.org that IMHO is the blocker. Wayland and Mir may help on the driver side.

I want products!

I'd love to see more push to have actual products on the market, since otherwise we don't get free software to the masses. If Mir helps Ubuntu to do that in one year, fine (I don't know how it's going to be). Yes Mir is a new shiny project, but it's a very product/target oriented project one. If Android would be open as a project, it wouldn't hurt - other than feelings attached to the other projects especially by the core developers and fans of those - if it was the superior alternative from product creation perspective making all of X.org, upstart, systemd, Wayland, Pulseaudio, D-Bus, glibc less interesting to product creators while even more interest would go to Android. It's not so now, Android is not an open project in any sense, even though still beneficial for free software. Ubuntu will keep using a lot more of the traditional stack anyway than Android (which also just got rid of BlueZ), but I have zero problem of changing any of the components if it's visioned to be required to get finished, ready to use products out. IMHO the key is to get products out, and I hope all the parties manage to do that.

Of the traditional GNU/Linux desktop distributions only Ubuntu seems to be adapting for the mobile in large steps at the moment. The other distributions in the mobile playing field are: (Android/)Replicant, Mer/Sailfish, Firefox OS, Tizen, added with OpenEmbedded based distributions like SHR. Have you used those on a daily basis on your devices? I believe you should. I think KDE will bring with its Plasma Active - currently focusing on building on top of Mer - mobile power to the traditional GNU/Linux distributions, but otherwise it's all up to the new players - and Ubuntu.

Like many know, I used Debian exclusively on my primary phone for ca. two years before switching mostly to N9. During all that time, I already pondered why people and distributions are so focused on x86 and desktop. And the reason is that that's what their history is, and I stared at the wrong place - desktop distributions. I dismissed Android and some of the small newcomers in the mobile distro playing field, but it seems that big changes are needed to not need completely new players. I think Ubuntu is on the completely right track to both benefit from the history and adapt for the future. I still hope more developers to Debian Mobile, though!! Debian should be the universal operating system after all.

Disclaimer: I'm an Ubuntu community person from 2004, Debian Developer since 2008 and a contractor for Canonical for ca. 1 year. My opinions haven't changed during the 1 year, but I've learned a lot more of how free software is loved at Canonical despite critics.

Read more
Timo Jyrinki

Update January 2013: Both Ubuntu 12.04 LTS and Ubuntu 12.10 now have this new feature enabled by default!

Here's an update to my previous entry. In summary, the Compiz update for Ubuntu 12.10 is now in the quantal-proposed updates, and enables unredirection by default for fullscreen applications like games. Happy gaming holidays! A new Compiz update 0.9.7.12 enabling unredirection by default for Ubuntu 12.04 LTS users is in the SRU PPA.

Several changes have happened since the last update, addressing some potential issues uncovered by the people testing the updates (thanks to all!). Daniel has again done all the hard work with regards to actual development.

Changes affecting both 12.10 & 12.04 LTS:

  • Some drivers do not offer tear-free Xv output without a compositor (or glXSwapBuffers in general). Therefore there is a new option available, for which the default setting enables redirection exception in case of some common video players (eg. Adobe Flash plugin and Totem). The option is Composite -> Undirect Match (unredirect_match) available in the CompizConfig Settings Manager (ccsm). The most notable driver is intel on Intel SB/IVB. Those newer chips don't support the XvPreferOverlay xorg.conf option that would bring tear-free non-composited Xv video on earlier Intels.
  • The default setting for unredirect_match should be fine for existing users. But if you want to enable unredirection also for the common/default video players and risk tearing on some drivers and some applications, change the unredirect_match option to be just '(any)'. This might help with video playback on older/slower integrated graphics which are only barely powerful enough to play HD videos.
12.04 LTS only:
  • 0.9.7.10 will not be uploaded to precise, it was just used for early testing. 0.9.7.12 currently tested in the SRU PPA enables unredirection by default also on the 12.04 LTS release.
  • Intel and nouveau mesa drivers are now blacklisted from unredirection on Mesa 8.0 because of so far unresolved driver problems. The blacklist is however configurable in OpenGL -> unredirect_driver_blacklist. The default blacklist regexp is '(nouveau|Intel).*Mesa 8.0'. This does not affect other drivers or Mesa 9.0, so those intel and nouveau users that install 12.04.2 LTS after the end of January or opt-in into the 'LTS-Q' hardware enablement stack for existing installations around the same time will not be blacklisted anymore. Update January 2013: on 12.04 LTS (only), as a last minute change, also Mesa 9.0 in combination with Intel or Nouveau is blacklisted by default at least until LTS-Q stack is properly testable. You can modify the unredirect_driver_blacklist in CCSM -> OpenGL. It was found out that at least mesa 9.0 _only_ from x-updates is not enough - Intel has graphics display problems. It is probable that the problems go away with the full 12.04.2 stack (kernel, X.org, libdrm, mesa) at which point the Intel/nouveau blacklisting can be removed.
  • The original unredirect_fullscreen_windows option is actually forced on now, because of potential gconf setting migration problems. Disabling unredirection can be done via the unredirect_match option above, by simply blanking the string in there, including removing the '(any)' part - everything will be redirected in that case.

Read more
Timo Jyrinki

Unity, which uses Compiz and Nux for drawing, recently had a regression with full screen gaming speeds (LP: #1024304). While the performance of Compiz itself was improved significantly in Ubuntu 12.10, the big changes like full OpenGL ES support brought in some regressions at least from benchmarking point of view. Unity/Compiz has had a small performance impact also in Ubuntu 12.04 LTS depending on what it's being compared to. Any compositing method will necessarily bring some performance hit, but there's another option...

Many people know already about enabling the setting "Unredirect Fullscreen Windows" in Compiz's Composite plugin, but having to enable it manually meant that most people didn't get to use it. The feature detects when an application is running full screen, and simply takes compositing out of the equation, improving performance. Getting the feature work fluently has required fixes in both Compiz and drivers, which is why it hasn't been enabled by default before (LP: #1063690).

But things are progressing now. The Unity team's SRU PPA now has a test build of the new Compiz 0.9.8.6 for Ubuntu 12.10, which enables this feature by default:

ppa:unity-team/sru

Since Phoronix is a frequent reporter on Linux gaming performance, I (very) quickly run phoronix-test-suite's Open Arena test on my Sandy Bridge machine with the stock Ubuntu 12.10 (quantal) Compiz and with Compiz upgraded from the PPA: 18% increase in fps! (test1_1 has older compiz, test1_2 the newer, no settings touched)

The idea is to get the new Compiz into quantal-proposed after the previous snapshot release 1:0.9.8.4+bzr3412-0ubuntu0.1 gets its bug fixes properly verified via the Stable Release Updates process. Note that also this previous snapshot contains all the needed fixes for unredirecting fullscreen windows, the final tagged 0.9.8.6 version just switches the default to be enabled.

For Ubuntu 12.04 LTS (precise) there will be two steps. First of all, Daniel van Vugt has just backported the required Compiz fixes to the 0.9.7 branch of Compiz that the 12.04 LTS uses and tagged the 0.9.7.10 release. Also in the case of precise, there is an earlier snapshot release in the SRU system, but that one does not yet include the needed backports even though it includes many other fixes. The 0.9.7.10 will be available in the same SRU PPA soon. Secondly, once the fixes are in but the feature is not yet enabled by default, the X.org driver team will need to look at additional fixes for the drivers before enabling the Unredirect Fullscreen Windows by default. But after that, Ubuntu 12.04 LTS should also see a Compiz release with this feature turned on by default.

Read more
Timo Jyrinki

OpenPhoenux GTA04

Postman was on a kind mood yesterday. My OpenPhoenux GTA04 arrived! I had my newer Neo FreeRunner upgraded via the service from Golden Delicious.

First, something rare to behold in phones nowadays - Made in Bavaria:






As a sidenote, also rare now - my Nokia N9 is one of the last phones that had this:

It's sad that's now a thing of the past for both hardware assembly and software! But that's just a hint for new companies to step in.

But back to GTA04 - a quick boot to the pre-installed Debian w/ LXDE:






And then as a shortcut unpacked and booted into QtMoko (well, it's also Debian) instead to test that phone functionality also works - and it does:



Next up: brewing something of my own!

Read more
Timo Jyrinki

I believe I'm not the only one who thinks that use case oriented Grub2 documentation is hard to find, and a lot of the documentation is obsolete or wrong. My main cause for writing this blog post is a currently unanswered question regarding 2.00, but meanwhile it seems months have passed and still most 1.99 documentation is wrong as well, which might be interesting to some.

The aim is to prevent grub entries from being edited, while not restricting actual booting. This protection is meant for computers not having any confidential stuff, but just wanting to do some light weight security with the assumption that the computer isn't physically opened.

Common setup

You will obviously want to disable any automatically generated root access giving entries, by for example uncommenting GRUB_DISABLE_RECOVERY="true" in /etc/default/grub on Debian or Ubuntu. Also you would disable allowing any external boot devices to be used in BIOS/EFI/coreboot, which you would also have protected with a password. And that often means you need to also disable USB legacy support, since some BIOSes tend to offer all USB devices as bootable without password otherwise (note that I guess that could also cause problems accessing setup on desktop computers if your only keyboard is USB).

1.99

So to first fix the false instructions in various places - no, setting the superuser in 00_header as instructed is not enough. It might be, but does not apply if eg. old kernels are put into submenu (Ubuntu bug 718670, Fedora bug 836259). The protection from editing does not apply there. And if you remove all but one kernel so that there is no submenu, a submenu will be automatically created when there is a new kernel installed via security updates. I didn't need the submenu feature anyway, so I used to comment out the following lines in /etc/grub.d/10_linux:

  #if [ "$list" ] && ! $in_submenu; then
    #echo "submenu \"Previous Linux versions\" {"
    #in_submenu=:
  #fi
...
#if $in_submenu; then
#  echo "}"
#fi

I hope that was useful. I can imagine it causing a couple of family battles if the commonly instructed setup was the only protection used and there's for example a case of two computer savvy siblings that are eager to get to each others' computers...

2.00 & The Question

The problem with 2.00 is that the superusers setup yields a non-bootable system, ie. password is required for booting. But Google wasn't smiling at me today! Terrible. Can you help me (and others) with 2.00? The aim would be to have a 1.99-like setup where superuser password protects all entries from editing, but booting is fine without any passwords.

Update: Thanks, problem solved, see comments! Find the following line in /etc/grub.d/10_linux:

      echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"

And add --unrestricted there. Don't mix the line with the another menuentry line two lines earlier. The submenu problem doesn't exist anymore in 2.00.

Read more
Timo Jyrinki

A couple of photos from the Ubuntu release fest in Tampere yesterday.

People gathering up before presentations

Tieto's Markus Mannio

Again, continuing on how Ubuntu is used at Tieto

A cut to the end of presentations, Trine 2 game licenses from Frozenbyte being raffled. A great game available on Linux.

Tablets running KDE Plasma, and Ubuntu for Android being demoed.

Someone else probably has photos of my generic Ubuntu 12.04 LTS presentation (what's new, what's next), and likewise for the other presentations (Ubuntu for Android, uTouch) held. Those will be available as slides and videos later on, although do note the whole event was in the crypto-language called Finnish.

Thanks to the organizers, sponsors and everyone I met, it was a great event with nice little dinner and wine served at the end!

Read more
Timo Jyrinki

Just a quick note that the merry Finnish localization folks are organizing an (extended) localization weekend, starting today. As a nice step towards ease of use, they're utilizing the long developed, maybe even underused Translatewiki.net platform, or to be precise a separate instance of it. Translatewiki.net is used by MediaWiki (Wikimedia Foundation), StatusNet and other high profile projects. Co-incidentally the main developer of Translatewiki.net is Finnish as well.

Anyway enough of the platform, join the translation frenzy at http://l10n.laxstrom.name/wiki/Gnome_3.4, but do make sure to read the notes at http://muistio.tieke.fi/IYZxesy9uc.

I've promised to help in upstreaming those to git.gnome.org on Sunday. There is additionally a new report about Ubuntu 12.04 LTS translations schedule (to which these GNOME contributions will find their way as well) at the ubuntu-l10n-fin mailing list by Jiri.

Ja sama suomeksi.

Read more
Timo Jyrinki

The MeeGo community is frustrated with the news of the MeeGo brand being abandoned. Some are understandably angry or otherwise not happy about how Linux Foundation, Intel handled the Tizen announcement and community in general - or more like how they didn't handle it at all. Last week Openmind 2011 happened to be arranged in Tampere on the very same day as Tizen announcement came alive. It was good in the way that it lead to the fact that Nomovok's CEO Pasi Nieminen was able to initiate the "Reigniting MeeGo" session not just by talking vague things about future, but actually about the process which led to Tizen and the unfortunately brief initial PR about it. Pasi is intense on emphasizing the quality and role of Qt in Tizen as well, even though officially Tizen is all about HTML5 and apparently from Samsung's part at least EFL is provided as a native toolkit. However, the promise of Tizen compared to MeeGo is reportedly that the toolkit is not specified in compliancy documents, so HTML5 with WAC is the main/only "3rd party apps" layer whereas others can be offered case-by-case. This means that unlike before, the underlying system can be built on top of practically any distribution (theoretically) and using whatever toolkits and other techniques wanted. Obviously the "Nordic System Integrators" are probably all very keen of using Qt to produce more of Nokia N9 quality user experiences in various products.

Taking the corporate hat off, I as a community member am also puzzled. The only reason I was not completely blown by the news was that I didn't yet manage to get involved in MeeGo community on a daily basis, since I'm involved with a dozen communities already. Instead I've been more like scratching the surface with MeeGo Network Finland meetings, IRC activity, OBS usage for building a few apps for MeeGo Harmattan and MeeGo proper etc. But I can somewhat understand how people like Jarkko Moilanen from meego-fi feel. They have given a _lot_ to the MeeGo community and brand, all taken away without hearing or pre-notice.

So where to now for MeeGo community? Tizen is one obvious choice. However, for all the talks that even I started this post with, Tizen is still vaporware today, and the dislike of how community is being treated might make it easy to consider other options. Also, if Tizen's reference implementation has lesser meaning, it might also mean less to actually be "in" the Tizen community than in MeeGo. I met Jos Poortvliet at Openmind, and he invited people to openSUSE. There is a lot of common ground with MeeGo and openSUSE - strong OBS usage, RPM packaging, community side focused on KDE and therefore Qt.

I would like to now point similarly to Debian! If one is tired about corporate interests and not listening to community, there is no match for Debian's 15+ years history, purely volunteer based, trust based organization, and first of all scope. While openSUSE has traditionally focused on desktop (even though like Jos pointed out they are open to all new contributions and projects), Debian has always had the "universal" scope, ie. no boundaries besides producing free software operating system for various purposes. There are over 10 architectures maintained at the moment, including the ARM (different ports for ARMv4 and hard-float ARMv7) and x86 from MeeGo world. There are even alternative kernels to Linux, mainly the GNU/kFreeBSD port. There are multiple relevant plans and projects like the Smartphones wiki area, most noticeably Debian on Neo FreeRunner. I have run Debian on my primary mobile phone for over 2.5 years, although now in the recent months I've had dual-SIM in my Nokia N950 as well (Debian not yet running on Nokia N950 or Nokia N9 - but it can and will be done!).

What Debian may lack in both good and bad is corporate funding, if you don't count the still quite respectful contributions from Ubuntu to Debian (it's in Ubuntu's interests to contribute as much possible back to Debian, so that the delta remains small). For each and every aspect, it needs a volunteer - there are a thousand volunteer Debian Developers, and at least a double of that of people without the official DD status but who still maintain a package or two among the 25000+ packages in Debian. That means also that one my find it more lucrative to join a project that has paid people to do some of the "boring parts", more of fancy web tools, including for bug handling and build systems like the OBS (which I do love by the way). On the other hand, there is no other project in my opinion where what you do really matters as much.

To find out more about Debian from MeeGo perspective, please see the recent mailing list post Mobile UXes - From the DebConf11 BoF to the stars where I wrote most of the MeeGo (CE) part when I was asked to and known of my MeeGo involvement.

Last but not certainly least, there is the Mer project - originally "maemo reconstructed", ie. making Nokia's "not really distro" into a real distro by filling in the void places. Now it's obviously MeeGo reconstructed, and they aim to be the MeeGo they always wanted MeeGo to be! Read the post for details from Carsten Munk and other key Mer people. They share the love for Qt, and want the core to be as lean as possible. They also aim to incorporate the most community like aspect from MeeGo - MeeGo CE - as the reference vendor in Mer. They also aim to be Tizen compliant - and when Tizen comes alive, I wouldn't see why the Tizen reference implementation couldn't be used for saving resources. Maybe Nomovok and/or others could offer the Qt maintaining part.

So, it might be that Tizen itself is enough for most people's needs. The key point however in this post is not to fall in agony if one corporate based project takes big turns - it has happened before, it will happen in the future. There are always enough political and business reasons from some points of view to do Big Changes. But the wider community is out there, always, and it's bigger than you think. You should consider where you want to contribute by asking yourself why you are/were part of for example the MeeGo community. Aaron Seigo from KDE asked us all this question in the Openmind MeeGo Reignited session, and I think it's good to repeat.

Read more
Timo Jyrinki

It was good that I didn't hold up my blog post in November until the videos from FSCONS 2010 (Free Society Conference and Nordic Summit) are out, but now they finally are:


Timo Jyrinki - Tuning an old but free phone (pt 1/2)
Timo Jyrinki - Tuning an old but free phone (pt 2/2)

Definitely see also all videos and since Vimeo doesn't work in Gnash, use a script to download.

ps. As a related item to the talk's future oriented aspects, while waiting for GTA04A3 boards to arrive, GTA04A2 has been patched to run Debian/LXDE.

Read more
Timo Jyrinki

MeeGo Summit FI is now nearing completion, with several keynotes and other presentations, Meegathon 24h contest just coming to an end and a lot of interesting discussions had. See full program for details. Yesterday was a hugely energetic day, but today the lack of sleep starts to kick in a bit at least for me.

Some highlights via photos:



Keynote venue was a movie theater




MeeGo status update by Valtteri Halla / Intel - talking among else about tablets, IVI, and the 20 person team at Nokia doing MeeGo(.com) for N900 phone





Mikko Terho / Nokia - "Internet for the next billion => Qt good candidate", "code wins politics and standards"




Carsten Munk / Nomovok - "Hacking your existence: the importance of open-ended devices in the MeeGo world"




In addition to MeeGo tablet demonstrations a Wayland compositor was demoed by a Nomovok employee.



One of the many Qt / QML related talks was held by Tapani Mikola / Nokia



Evening party




Day 2 started with a few more presentations and Finhack event launching in the Protomo room as well

Still remaining for the day are Meegathon demonstrations (well actually I'm right now already following those while finishing this - cool demos!) , Meegathon awards, a panel discussion on "MeeGo, Nokia, Finns - finished? Can MeeGo be important in Finland without being inside Nokia's core?", BoF sessions and finally Intel AppUp Application Lab including some MeeGo table give-outs.

Thanks to organizers, many of whom were volunteers. The event has been running completely smoothly, coming not as a big surprise after the hugely successful last summer's Akademy 2010 also held in Tampere.

Read more
Timo Jyrinki

I'm participating in the MeeGo Summit FI that starts tomorrow, and I'm already in Tampere now, as you can see. The summit is at an interesting time, given that there is a huge amount of stuff happening around MeeGo while at the same time Nokia is balancing on what do both in the far future and what to do to ship the MeeGo device they've already promised. The summit is fully and overly booked for >300 attendees. There is also Finhack free software event happening alongside on Saturday at the same venue.

A view towards the venue(s), Finlayson area in Tampere.
The company I work for, Nomovok's CEO illustrated the MeeGo situation extraordinarily well a little less than two months ago. I think it's one of the best insights you can get from anywhere in public at the moment. Now things are starting to really heat up. Of course the Big thing is the MeeGo Conference in San Francisco in the end of May, but it takes nothing away from this being the major event both in the country formerly known as NokiaLandia, and also globally given the amount of MeeGo related talent here. Nomovok is teasing people with the SteelRat - a launchpad for MeeGo tablet creation and an UX, based on latest MeeGo Core - a beta of which will be available now in Tampere and first version in San Fransisco. Meanwhile we and others are investing in also the MeeGo IVI and MeeGo TV platforms, not forgetting about the handset industry that is more visible to many tech savvy consumers.

Pre-registration and building on-going.
At the same time there is a lot of exciting stuff going on in the Ubuntu project (Ubuntu 11.04 upcoming, I'm already using it and reporting bugs), together with Linaro and other ARM players. As a founder of Ubuntu Finland I'm always eager to see if I can work there also on work time, not only on free time. And regarding ARM, Nomovok is the key player in having ARM on MeeGo as well.

Then on the completely other end of spectrum, I'm eagerly waiting for the GTA04 project to have my Neo FreeRunner(s) bumped up to modern specs. At the end of the day I'm still using over 2,5 year old phone myself, since I want to run the software that is both free and completely selected (and if I want, done) by me. With GTA04, I could choose between MeeGo armv7hl port, Debian armhf port or Ubuntu as the base distribution to use my software.

Read more
Timo Jyrinki

Just a note that the slides are available (non-slideshare link) for my presentation ”Tuning an old but free phone” (description) that I held in the tremendously great event FSCONS 2010. It could be described as a smaller scale FOSDEM, but that would be actually down-playing it since the free software effects on society are something that I've actually never seen elsewhere on such a scale. My talk was among the purely technical ones, though.

I was planning to hold on with this blog post until the recorded videos arrive, but since it seems it might not be during this year I will just post this now that slides are available.

I've shared a few photos as well at Flickr...


Keynote: Karin Kosina, The Inanna Project. A tech + art workshop for female artists in Damascus, Syria. An experiment in art, technology, and the transformative power of Free Hardware and Software.


Erik de Bruijn, The Future of RepRap, a self-replicating open source 3D printer that fabricates arbitrary objects including parts of itself.


Social event at the Berg 211.


Malin Nilsson on Gender, class and global flows. Using free software to fuel a revolution in home based industrial work.



Keynote: Glyn Moody, Ethics of Intellectual Monopolies.


Keynote: Glyn Moody, Ethics of Intellectual Monopolies (audience).

A few summaries available on a Qaiku seminar channel.

Read more
Timo Jyrinki

I'm writing a blog entry instead of just replying to myself on a mailing list, since this subject might be interesting to a largish portion of the community. Most people assume things just magically work out by themselves and then after a release wonder why it wasn't so.

So, I raised a question on ubuntu-devel-discuss mailing list about whether usb-modeswitch should be included in the default Ubuntu 10.04 LTS installation instead of it only being in the universe repository. Reason was simply that firstly, I've read some general wonderings from the community about why it isn't already so. Secondly, without it my 3G modem (Huawei E1552) was first not functional, but right after installing usb-modeswitch package Network Manager worked smoothly with it.

Since I didn't get much discussion going on besides some statements that it doesn't work for everybody and even has caused extra problems for some others (in 9.10), I asked for a small round of comments on the subject on IRC. The channels are logged so I believe I can quote those a bit.

Colin Watson said among else:

"surely we just want the kernel to DTRT [do the right thing] by default ... this is the upstream trend ... it already DTRT for quite a few devices"
"I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel"
"I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work ... I'm just not very convinced it's a real properly supportable option"
"but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)"
Later on Paul Sladen continued a bit, among else:
"usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile"
"grep -hr MessageContent usb_modeswitch.d/ | sort -n | uniq -c | sort -rn shows the level of duplication in the configuration files"
"...I do like that it is done in userspace though, as so easy to disable if you wanted something else".
Meanwhile I also IM:d a bit with Antti Kaijanmäki from whom I probably originally coined the idea of following whether usb-modeswitch is integrated into Ubuntu or not. He mainly said that he doubts the feasibility of updating kernel's USB storage quirks in a stable release, compared to having stable release upgrades about the usb-modeswitch-data udev rules. He also proposed discussing maintainability and usability by distros with the Debian maintainer and upstream, although it sounds like Colin might have had some talks already.

So there we are now. Apparently at this point it is hoped that as many quirks as possible are inserted in the kernel, see for example drivers/usb/storage/unusual_devs.h in the kernel. But if you have concerns about if 10.04 LTS will be kept up-to-date regarding 3G modems and want to somehow participate in bringing usb-modeswitch into Ubuntu default installation or simply discuss how to handle the kernel SRUs properly, it's time to stand up and do something.

Should there perhaps be a process with which the usb-modeswitch developers would get the information they are gathering more easily to the upstream kernel _and_ (older) distribution kernels? Is this simply a case of being easier to address an issue with a "hackish" approach, or is the usb-modeswitch actually the right way to go?

Note that I'm no expert in this area, I simply become interested in various subject from time to time :)

-Timo, going to figure out a kernel quirk for his 3G modem

Read more