September 20, 2014

Fedora 20 + Netflix

I’ve finally got native Netflix working in Fedora 20, this is what I had do to get it working.

  • Make sure you’re running Chrome Version 37 at least
  • Make sure you’re running NSS version 3.17
paulmellors@localhost ~]$ rpm -q nss 
  • Make sure you have the chrome user agent switcher installed
  • Think you can get it from here –

Installing this will place new icon in the right of the Chrome toolbar. Right-click on this item and select ‘Options’. We’ll now add the required HTTP agent with the following string (thanks to Mat Enders for these steps):

Name: Netflix Linux
String: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2114.2 Safari/537.36
Group: (is filled in automatically)
Append?: Select ‘Replace’
Flag: IE
If you fill this in correctly you should have something like this:


Click the ‘Add’ button at the far end to save your UA.

Now, load ‘‘ in a new tab, and click the User-Agent Switcher toolbar icon, click ‘Chrome’ and select the ‘Netflix Linux’ entry. This will reload the page.

Optionally, you can set a permanent spoof rule to force this user-agent to take effect when loading Netflix:


You should now be able to watch netflix on Fedora :)

Thanks to info and images from this page.

The post Fedora 20 + Netflix appeared first on Paul Mellors [dot] NET.

flattr this!

MACLUG Inauguration at New Delhi

Today I attend the inauguration ceremony of MACLUGMaharaja Agrasen College, GNU/Linux Users Group. I was honoured to have been invited among many esteemed guests to light the lamp of this wonderful new beginning. This reminded me how nine years ago I along with a bunch of enthusiasts started JMILUG.

I shared my thoughts on “Freedom – Community – Science – Innovation”

Four Freedoms

Let me begin with the Four Freedoms. A program is free software if the program’s users have the four essential freedoms:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Why are these freedoms important?

It won’t take much to realize how these Four Freedoms are. For example, lets take parallel between Four Freedoms and other things that affect our lives daily. Take note that these freedoms are applicable for more things than just software programs:

  • Science – standing on the shoulder of the giants
  • Literature and entertainment – Comics books turned into Super Hero TV Series and Movies
  • Internet – wouldn’t be possible if Tim Bernes Lee didn’t share his idea and the technology

What if Newton or Einstein and many other scientists didn’t share their theories? There wouldn’t be modern science. What if all the literature was kept secret? There wouldn’t be no entertainment. And list would go on and on.

We must be aware of the freedoms we carry with chores of daily life.

How do we take these freedoms forward?

We can spread the awareness of the Four Freedoms only through a Community. Community is a social unit of any size that shares common values. The people invest with shared capital ( such as belongingness ) and people communicate ( via words, art, emotions etc ) to share their views. Community consists of creators ( or contributors ) and consumers. All of the people have different roles and it better be organic, so that it can thrive based on these parameters:

  • Motivation
  • Passion
  • Goals

We need to ensure a thriving community keeps everyone aware of these freedoms. I am confident that MACLUG students have these qualities, and I wish them good luck.

Welcome to the world of Free and Open Source Software :-).

For references:

Emacs Modules

I’ve been working on an odd Emacs package recently — not ready for release — which has turned into more than the usual morass of prefixed names and double hyphens.

So, I took another look at Nic Ferrier’s namespace proposal.

Suddenly it didn’t seem all that hard to implement something along these lines, and after a bit of poking around I wrote emacs-module.

The basic idea is to continue to follow the Emacs approach of prefixing symbol names — but not to require you to actually write out the full names of everything.  Instead, the module system intercepts load and friends to rewrite symbol names as lisp is loaded.

The symbol renaming is done in a simple way, following existing Emacs conventions.  This gives the nice result that existing code doesn’t need to be updated to use the module system directly.  That is, the module system recognizes name prefixes as “implicit” modules, based purely on the module name.

I’d say this is still a proof-of-concept.  I haven’t tried hairier cases, like defclass, and at least declare-function does not work but should.

Here’s the example from the docs:

(define-module testmodule :export (somevar))
(defvar somevar nil)
(defvar private nil)
(provide 'testmodule)

This defines the public variable testmodule-somevar and the “private” function testmodule--private.

Inkscape-Weekend Oktober 2014

Ich habe von verschiedenen Seiten Anfragen erhalten, ob ich denn nicht noch einen Inkscape-Wochenendworkshop anbieten könnte. Momentan ist meine Zeit allerdings begrenzt und es gibt nur eine Möglichkeit und zwar am Wochende vom 24.-26. Oktober 2014

Der Workshop beginnt am Freitag Abend mit einigen Dingen rund um SVG, der Oberfläche von Inkscape, den Verzeichnissen, Zooming und Panning und setzt sich dann am Samstag morgen fort mit den Zeichenwerkzeugen. Nach meinen Erfahrungen schaffen wir in bestimmte Themen, wie Live Pfadeffekte, Gekachelte Klone und vor allem Filter nur Einblicke aber die reichen aus, um im Selbststudium sich damit beschäftigen zu können. Wann immer es geht schieben wir auch praktische Teile ein, bist Sonntag Abend sollten wir auf diese Art und Weise alle Funktionen von Inkscape kennengelernt haben.

Neu dieses Mal ist, das wir verstärkt auf die neuen Funktionen von Inkscape eingehen, denn unter Umständen ist die Version 0.91 von Inkscape dann bereits erschienen. Diese bringt eine große Anzahl Neuerungen mit.

Wie bei allen anderen Workshops vorher auch gibt es wieder ein Formular zur Anmeldung, auch dieses Mal gilt ich mach mir nur die Mühe, wenn mindestens 3 Leute zusammen kommen. Ich gebe spätestens eine Woche vor Veranstaltung per Mail Bescheid, ob die Veranstaltung stattfindet.

Ansonsten bleibt alles beim alten Teilnahme frei, es sei denn ihr wollt mir etwas zustecken aber das bleibt euch überlassen.

September 19, 2014

What the GNOME release team is doing


At the release team BoF at this years Guadec, I said I would write a blog post about the whats and hows and ifs of release team work. I’m a little late with this, but here it is: a glimpse into the life of a GNOME release team member.

We are in the end phase of the development cycle, when the release team work is really kicking into high gear.

Blocker bugs

Since the .90 release, we’ve been tracking blocker bugs.  The way this works is that we are setting the GNOME Target field to the next release. During the cause of the development cycle, we’ve had 50 bugs that were marked with

GNOME Target=3.14

at some point . Today, we’re down to a single one, which will hopefully be gone before the weekend is over.

In order to draw our developers attention to these bugs, we’re sending out regular reports to desktop-devel-list (see them here, here and here). Andre has taken over this task this cycle.

We don’t have formal criteria for what bugs to mark as blockers, we are mostly going by the instinct and experience of bug zapping veterans like Andre Klapper. My own criteria for setting this flag mostly come down to these questions:

Is it a crash in a core component ?
Is it very visible or annoying ?
Will it affect many users ?

For finding bugs that should be blockers, I am regularly scanning all incoming bugs in bugzilla. On an average day this query finds between 100 and 200 bugs – with some practice, one can get through that list in 15 minutes.

We also get ‘nominations’ for blockers from maintainers and developers, which is very helpful.

Development Releases

The duty of ‘doing’ releases is distributed among all of the current, active release team members.

Our development schedule has a pretty well-established cadence of development  releases: We do a number of early development snapshots which are roughly a month apart (3.13.1, 3.13.2, 3.13.3 and 3.13.4 this cycle), followed by the beta releases which are 2 weeks apart (3.13.90, 3.13.91, 3.13.92, this cycle).

The end product of each development release is a set of jhbuild modulesets and a forest of symlinks to the tarballs for individual modules that are included in the release.

Most of the mechanics of creating the modulesets by rewriting our regular modulesets (which point at git repositories, not tarballs), and creating those symlinks on the server are handled by scripts that have been passed down through the generations.

The time-consuming aspect of creating a release is that it usually takes several attempts to create candidate modulesets, hunt down missing releases (or doing them ourselves – which is sadly necessary for a number of ‘weakly maintained’ modules), and do a full jhbuild using the final modulesets. As a consequence, while our official release day is always Monday, the release typically happens on Wednesday or Thursday of the same week.


Towards the end of a development cycle, the release team also starts to plan for the next cycle.

This includes creating the schedule, taking a look at annoying bugs that we should tackle in the next cycle, figuring out if there are project-wide goals that we should push, and collecting input on new modules and features that people want to work on for the next release.

Since we are at this point right now, let me end with this request:

Please let us know what features are on your modules roadmap for the next cycle!
How to work with CentOS-5 in a CentOS-7 mock shell
So I have been spending a lot of time lately working on Extra Packages for Enterprise Linux (EPEL) as I know it is one of the undersold success stories of Fedora.

In doing so I have been focusing on EPEL-5 as it is the oldest release and something that most packagers do not actually think about (as they are usually focusing on the latest and greatest in Fedora or maybe Enterprise Linux-7). This has been a trip down memory lane as I have had to deal with things like ancient Python and a yum without the same command set or tools as 'current' ones.

One of the big things I have to remember is that EL-5 is based off Fedora 6 (<blink>zod</blink>) and so its RPM database is a different format than what is in any Fedora after version 8 (I believe). I rediscovered this format change when I was trying to see what packages in EPEL might replace 'core' packages in a bare bones CentOS-5 install. I was using mock to do this which uses the host system (in my case a EL-7 box) to populate the buildroot with packages from EL-5 tree.

I ran into this when I did a
[smooget@junk02 rpm]$ mock -r local-5-i386 --init
[smooget@junk02 rpm]$ mock -r local-5-i386 --shell
<mock-chroot>[root@junk02 /]# rpm -qa


I got an error telling me that the database type(9) was unknown. After spending some time working through various people running into this on google, I was able to piece together the following on how to work with the rpm inside the mock shell appropriately.
  1. Before entering into the shell, dump the databases with the system db_dump
    [smooget@junk02 rpm]$ mock -r local-5-i386 --install db4-utils
    [smooget@junk02 rpm]$ sudo -i
    [root@junk02 rpm]# cd /srv/mock/tree/local-5-i386/root/var/lib/rpm # this is not DEFAULT location
    [root@junk02 rpm]# for i in Basenames Conflictname Dirnames Group Installtid Name Obsoletename Packages Providename Requirename Sha1header Sigmd5 Triggername ; do echo $i; db_dump $i > $i.x; done
  2. Now we can load all those db (really on Packages is needed but I like to be a completist)
    [smooget@junk02 rpm]$  mock -r local-5-i386 --shell
    <mock-chroot>[root@junk02 /]# cd /var/lib/rpm
    <mock-chroot>[root@junk02 /]# for i in Basenames Conflictname Dirnames Group Installtid Name Obsoletename Packages Providename Requirename Sha1header Sigmd5 Triggername; do echo $i; rm -v $i; cat $i.x | db_load $i; done
    <mock-chroot>[root@junk02 /]# rpm --rebuilddb
    <mock-chroot>[root@junk02 /]# rpm -qa
    should give you a list of packages.
Note once you have done this you can not use mock to install packages anymore. If you need to install more packages make sure you have installed yum before you do this.

So what does this give you if you have completed this and installed EVERY possible package (choosing one set in case of conflicts like samba/samba3)

Package Arch Version Repository Size
agg i386 2.5-9.el5 extras 147 k
agg-devel i386 2.5-9.el5 extras 368 k
fribidi i386 0.19.2-2.el5 extras 53 k
fribidi-devel i386 0.19.2-2.el5 extras 53 k

Transaction Summary
Install 0 Package(s)
Upgrade 4 Package(s)

Total size: 620 k
Is this ok [y/N]:

So it looks like my next step will be to a) see if RHEL-5.10 updated those packages and if not have them 'removed' or something else. Also I need to figure out a better way of doing this so we can have a koji test to make sure the EPEL package doesn't ever get in the first place.
News: audible website come with Trial Membership .
The audible website come now with this great deal.

  • 30-day Trial Membership 
  • 1 book per month Free for the first 30 days and $14.95/month thereafter 
  • Membership continues until you cancel (by visiting your account or contacting customer service) Price - $0.00 .

You can login also with your amazon account.
Tools update


Recently I pushed these packages to various Fedora repositories. Some of them were not in EPEL, some were missing from EPEL-7, one was not built since long time.

  • GNU Pem:- GNU Personal Expenses Manager
  • Is an extremely simple, yet powerful tool to help you track your income and expenses for next 100 years.

  • LZ4:- Extremely fast compression algorithm
  • Is a widely used fast compression algorithm providing compression speed at 400 MB/s per core and is scalable with multi-cores CPU.

  • PDFCrack:- PDF password recovery tool
  • Is a lightweight tool to recover password and content from PDF files. It comes with no dependencies.

  • Ptrash:- move file(s) to ~/.trash directory
  • Is a handy and competent replacement for ‘rm(1)’ command. I wrote it after accidentally deleting few important files.

  • Python-Unidecode:- ASCII transliterations of Unicode text
  • Is a simple Python module used to transliterate Unicode characters to their ASCII representation.

  • Whereami:- display work location
  • Is a handy tool to know your current work location like host name, working directory, IP address etc.

Please let me know if you face any difficulties. Hope you find them useful. :)

Licensing morality

I’ve written in the past about what a mistake it is to add behavioral incentives or morality clauses to the licenses for open-source projects. Briefly, these clauses are bad:

  • philosophically because they infringe the on basic software freedom to use a freely-available project for any purpose1;
  • legally because they generally rely on vague and subjective terms and (paradoxically) thus rendering your license both radioactive and unenforceable; and
  • practically because instead of preventing people from doing things that you don’t like, they just prevent people — even those who wouldn’t be inclined to do things you don’t like! — from using your work.

One software domain in which licenses with usage restrictions are commonplace (and, unfortunately, widely accepted) is digital fonts. This has historically been a problem for Fedora, since many “free” fonts are not open-source (in that they do not permit modification) or have usage restrictions (in particular, against “commercial” use). Furthermore, much like novel one-off open-source software licenses, most partially-free licenses authored by font creators are unlikely to be unambiguous or legally sensical.2

The problem gets far worse when we look at commercial fonts, for which the type of application and type of output are often incorporated in usage restrictions. Last year, I licensed a font whose EULA was self-contradictory; you can click the link for the whole story, but the main problem was that it claimed to broadly allow rasterization, including use to “create images on computer screens, paper, web pages, photographs, movie credits, printed material, T-shirts, and other applications,” but that I couldn’t use the font “as part of broadcasting video or film […] the use of the font software in titling, credits or other text for any onscreen broadcast via television, video, or motion picture.”

Since one of my creative endeavors is editing home and bicycling videos, the combination of being allowed to “create … movie credits” but not to “use the font software in titling, credits or other text for … motion picture” was pretty frustrating, especially since the EULA hadn’t been obviously available for review until after I licensed the face. (There were numerous other problems, ambiguities, and contradictions with the license, and when I asked the foundry for for a clarification, they curtly denied that there was anything to be confused about.)

For more than a year and a half, this inconsistent license has been my benchmark to evaluate whether or not a font is more trouble than it’s worth, and I’ve at least learned to be more careful reading font EULAs.3 However, I recently came across an example4 that so completely outclasses the contradictory license that I can’t imagine it will be replaced as the new standard for terrible usage clauses in licenses. Here’s an excerpt; the author’s name is redacted:

Fonts by [redacted] may NOT be used for pornographic, derogatory, defamatory or racist material (in any form, printed or virtual); fonts by [redacted] may NOT be used by individuals or companies involved in child abuse, child pornography or child labour; fonts by [redacted] may NOT be used by individuals or companies involved in destruction of natural resources and/or habitat, logging (even legal), palm oil exploitation/harvesting, tuna fishing, whaling, animal trafficking, oil and/or gas drilling or transporting and mining. Fonts by [redacted] may NOT be used by individuals or companies promoting an unhealthy lifestyle (fast food, energy drinks, foods containing GM ingredients). Fonts by [redacted] may NOT be used by companies or individuals involved in Genetic Modification / Genetic Alteration of organisms. Fonts by [redacted] may NOT be used by individuals or companies involved in fur trade, or making use of fur. Fonts by [redacted] may NOT be used by missionaries, individuals or institutions of any creed or faith for the purpose of converting others to their creed or faith. Fonts by [redacted] may NOT be used to instigate terror, hate, intolerance, fear or racism.

I almost don’t know where to begin with this one, since it raises so many questions for the licensor:

  • When do we cross the line from light-hearted ribbing to “derogatory material”? Are satire and parody proscribed?
  • Say I use this font to title a bicycling video; would the licensor need to see what sort of chain lubricant I used or whether or not I was a regular inner-tube recycler before determining that I wasn’t involved in “destruction of natural resources”? (What about people who eat animal protein? Or plants?)
  • Are we mostly worried about the Indonesian orangutan, or is (relatively-low-impact) West African palm oil OK? Is the palm oil industry full of typophiles? How many jars of palm oil bore the licensor’s glyphs before he added this clause?
  • How are we defining “unhealthy” or “genetic modification”? It seems like consensus regularly changes on the former and the latter is — like much of the language in this clause — actually kind of vague despite being deployed in an absolute manner. Can I replant seeds from my best tomatoes or must I toss them? (In a related question, since I have the suspicion that it might come up in a future revision of this license: is it OK to use this font to promote vaccination?)
  • What about people of faith whose creed includes a concept of vocation, or the notion that they serve God through their creative and professional work?

Hopefully, these kinds of questions — along with many more like them that you may be asking yourself — underscore why this kind of license is a problem: the licensor probably hoped to make a clear statement of principles, condemn what he saw as social ills, and avoid assisting people and groups he’d find objectionable. Instead, the license restrictions are so broad as to exclude use by anyone except the font’s creator (who is unlikely to sue himself for breach of contract). No matter who you are or what you do, if the licensor wanted to sue you, he probably could.

I’m inclined to excuse that last sentence, though, since the licensor seems to know a thing or two about instigating “hate, intolerance, [and] fear.”

  1. The GNU Project calls this “Freedom 0.”

  2. If you’re releasing open-source software, you should use a well-known license. If you want to release a font freely, you should have a very good reason for using anything except the Open Font License or the LPPL.

  3. This may be surprising to people used to regular software licensing, but I’ve seen fonts for sale in different places with different licenses! It seems like some sellers have standard EULAs and require font creators to allow distribution under these, while others maintain the creators’ EULAs.

  4. Alas, I came across this example after paying for a license.

3.14 On Its Way

I recently put the finishing touches to the GNOME 3.14 release notes, which means that the next GNOME release is getting pretty close now. I never cease to be excited by new GNOME releases, nor to be amazed by our community’s ability to discernibly improve the GNOME 3 user experience release on release. I’m definitely at the point where I want to be running 3.14 all the time – it’s obviously a lot better than the previous version.

You’ll have to wait for the release notes to get all the details about what’s in the new release. Nevertheless, I thought I’d give a sneak peek at some of my personal favourite features.

Often with new releases we focus on the big new features – obvious bits of new UI that do cool stuff. One of the interesting things about this release, though, is that many of the most significant changes are also the most subtle. There’s a lot of polish in 3.14, and it makes a big different to the overall user experience.

New Animations

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="465" src="" width="620"></iframe>

It’s quite a while since Jakub first posted his motion mockups for the applications view. Since then we’ve been steadily and progressively iterating towards those mockups. With 3.14 we’ve finally got there, and it was worth the wait. The most noticeable effect is the new “swarm” animation, but also a lot of other subtle touches, such as when you browse application folders, or when you launch applications. We’ve also reworked the animations for when windows are opened and closed.

Animations might seem like unimportant window dressing, but it’s surprising how significant they can be for the user experience. They are the glue which binds the different parts of the UX together. By smoothing the transition between views, windows and applications, they make the entire experience feel responsive, fluid and more pleasurable to use. (And they actually make everything feel a lot faster, too. But don’t tell anyone.)

Google Images in Photos

Photos 3.14

GNOME’s Photos app has been steadily maturing over the past couple of releases, and it is turning into the dependable core app that we want it to be. The big news for 3.14 is that Photos will now pick up your Google photos, so any images you’ve uploaded with Picasa, Android, or posted on Google+ will be immediately available there. This is obviously incredibly convenient for users of Google services, and I know I’m looking forward to being able to quickly browse my online photos from within GNOME 3.

Rewritten Adwaita

GTK+ 3 Widget Factory 3.14

Jakub and Lapo have been tireless during the 3.14 cycle, and have completely rewritten Adwaita (the GNOME 3 GTK+ theme). This was a huge undertaking – around 8,000 lines of CSS have been reduced to about 3,300 lines of SASS. This was primarily intended to improve the maintainability of the theme. As such, there hasn’t been a dramatic change in the theme. What has happened, though, is that every aspect of the theme has been gone over with a fine-toothed comb.

There are some more noticeable changes. Progress bars have got thinner. Spinners look different (so much better). Switches are a bit different. However, the more exciting thing for me is that pretty much every part of the theme has changed in a subtle way. Everything feels crisper, sharper, and a bit lighter. There’s also a lot of subtle animations now (thanks to CSS animation support in GTK+), adding to the feeling of polish.

Search More Things

System search has been one of the most successful parts of GNOME 3, in my opinion. The number of applications that are feeding results to system search has continued to increase with 3.14, with two really useful new additions. The first is Clocks, which will return search results for world cities. Search is all you need to do to find the time in a place throughout the world.


The second new search provider in 3.14 comes from the Calculator. As you might expect, this allows you to perform simple calculations straight from the search box. It’s pretty exciting to see system search in GNOME 3 become so versatile, and the great thing about it is that it’s always a single keystroke away.


Go Go GTK+ Inspector

GTK+ Inspector 3.14

I don’t usually write about developer-focused features when I preview GNOME releases, but I can’t talk about 3.14 without mentioning GTK+ Inspector. If you work with GNOME technologies – as I do – this tool is something of a revelation. It’s amazing how quickly it becomes a core part of how you work. I’m already wondering how I ever lived without it.

The inspector isn’t just useful. It is also a lot of fun, and makes it easy to experiment. if you’re not a developer, or you don’t regularly work on GTK+ apps, I’d still recommend trying it out. Just hit Ctrl+Shift+I and have a play around.

Waiting Time

This is just a small selection of the features that are coming in the new release. To learn about everything else that’s coming, you’ll have to wait for the release notes. 3.14 should be out next week.

Smittix’s Top 5 GNOME Shell Extensions

GNOME Shell’s ability to have extensions is pretty brilliant in my eyes. Some developers have come up with some great extensions to make life easier within GNOME-Shell.


To install these extensions easily just open the links up within firefox, you will get a message bar asking if you would like to allow to install them.  You need to allow this for them to work.


When you load one of the extension links you will be presented with a page like below, it has a nice easy “On/Off” toggle switch.


Screenshot from 2014-09-19 14:20:49


Hit the toggle to turn the extension on. You will be then asked if you want to install said extension. Click Install!

Screenshot from 2014-09-19 14:21:11




by gcampax


This system monitor extensions shows your CPU and memory usage in the message tray, I think it’s pretty handy too.



Screenshot from 2014-09-19 14:25:29


Installation Link



by Jens


This weather extension sits in your top panel and displays the weather in your location. More information is displayed by clicking on the weather icon.

I know a few people that use a different weather extension but sadly it didn’t have my city and relied on libgweathers locations.xml·

This extension uses for its data.


Screenshot from 2014-09-19 14:19:50


Installation Link



by eon


At the click of a button you can turn this extension on which disables the screensaver and auto suspend.



Screenshot from 2014-09-19 14:23:10

Shown as the small coffee cup in the above screenshot.


Installation Link


Drop Down Terminal

by zzrough


A handy drop down terminal that’s activated by pressing a single keystroke (The key directly above the TAB key by default).

Useful when you’re in the middle of something and you forget that you need a piece of software, hit the activation key insert your command and hit the key again. It will scroll back up and carry on with the command.



Screenshot from 2014-09-19 14:21:54


Installation Link 



by hedayaty


Simply put, it displays your network activity from either your ethernet or wifi devices nicely in the top panel. (customizable)



Screenshot from 2014-09-19 14:19:57


Installation Link


Development of GNOME extensions

If you would like to try your hand at creating a GNOME shell extension the GNOME website has lots of useful information and even quick start scripts to get you going.  The possibilities are endless!


GNOME Extension Information



<script async="async" src=""></script> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
Fedora 20: Games That Will Have You Addicted In Minutes

Everyone has to have some fun after a busy day of working on a computer, I normally post about applications and security and such but I thought we’d have a change for once.

Some of us retire to our Xbox’s and Play Stations but I just throw a few yum commands into a terminal and get some classic gaming action.

First on my list has to be my all time favourite.


Chromium-BSU -

A fast paced top scrolling shooter which reminds me of the classic Deluxe Galaga on the Amiga 1200

Screenshot from 2014-09-19 12:32:45


It’s quite tricky in parts and you need to make sure you don’t let any of the bad guys get past! Oh and be careful of how much you fire,

your ammo is limited until the next ammo drop :)

Screenshot from 2014-09-19 12:32:10

Want to give it a try?

To Install –  

Please su into root or use sudo

user@computer:$ yum install chromium-bsu


Frozen-Bubble –

Frozen-Bubble is a classic arcade game clone, simple really shoot your bubbles to a matching colour group and watch them drop!

Be careful though there’s a big platform that pushes all of the colours down if it reaches the bottom it’s game over!

Screenshot from 2014-09-19 12:33:14


Install it –

To Install –  

Please su into root or use sudo

user@computer:$ yum install frozen-bubble


Hedgewars –

Screenshot from 2014-09-19 12:45:02

Who can remember the great Worms series? Well hedgewars is just that but instead of Worms you’re Hedgehogs! blow the opposite team to smithereens using a plethora of deadly weapons.

Oh and it also has the silly voices which is nice to hear heh.


Screenshot from 2014-09-19 12:45:16


Look like fun? Install it!

To Install –  

Please su into root or use sudo

user@computer:$ yum install hedgewars


Minetest –

I could go on and on in this post as there are quite a few gems in the repositories such as Tux Racer and Tux Kart and the like, but I thought I would add Minetest as the last one.

Unless you have been living in a cave with no connections to the outside world for the past 3 years you should know what Minecraft is, well Minetest is an open source clone of it.

Recently with Microsoft’s take over of Mojang I think some of you will want to give it a try.


I was really impressed with it, yeah it’s not as full featured as Minecraft but it’s new and can only get better plus it’s in the Repositories!


Screenshot from 2014-09-19 12:25:28

Screenshot from 2014-09-19 12:29:20


Go on, you know you want to!

To Install –  

Please su into root or use sudo

user@computer:$ yum install minetest


How about letting me know what your favourite games are? Do you want me to review any or share with fellow Fedorians? Give me a shout over at Smittix AT




<script async="async" src=""></script> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
Must-have GNOME extension: gTile

Tiling window managers have always interested me, but spending a lot of time tinkering with config files or learning how to wrangle them? Not so much. What I really want is a dead simple way to organize my windows and still use a friendly desktop. And I found it, finally: the gTile extension for GNOME.

If you are using GNOME, pop open Firefox and head to the extension page. Click “on” and go ahead and install the extension.

gTile Overlay

gTile Overlay

Once it’s installed, you can click the tile icon in the GNOME menu up top. You’ll see a little overlay with a bunch of squares. The gTile overlay will hover over an open window, and you can click one (or more) of the squares to place the window in that area.

Notice that there’s a row of icons that say “2×2″, “4×4″, etc.? That determines how the screen is tiled – so if you just want to divvy up your screen in four equal chunks, choose that. If you have a lot of screen real estate and want many more windows, choose the 6×6. (I’m using gTile with a 4K monitor, and go with 3×2 for six windows.)

The really nice thing about gTile is you’re not locked into tiling. New windows aren’t automatically put on the grid, and existing windows aren’t “locked” so you can have the best of both worlds.

Note that it also works well with multiple workspaces, and is also said to work well with multiple monitors.

If you’re a GNOME user and want a lightweight solution for tiling windows, give gTile a try. It’s been a great tool for me, and maybe it’ll make you more productive as well.

Samsung Galaxy S4 lockscreen clock lag

I have a Samsung Galaxy S4 (GT-i9506), which is a nice phone, and I’m quite content with it. So content that when we needed another smartphone in the house, we bought a second one.

Now, on the second phone, there is a strange bug. When activating the phone from sleep, checking the lockscreen clock, the time displayed has a time lag, that might be a few seconds or minutes, or even hours, and it may take several seconds for it to get and show the current time. Clicking the power button twice, ie. switching the lockscreen off and on again, forces the phone to show the current time.

Searching for this bug on google gives a lot of hits, so I guess this is a quite common problem, but it does not plague all users, only a few. The most common forum answer is either to ignore it, or just to switch to another lockscreen widget. Samsung, in their Divine wisdom, does not allow changing the clock widget on a lock screen, unless the actual lock (pin, pattern, etc) is removed, and that is not an option for us.

For our phones, the problem is only visible on the second phone, not the first one. The phones are running the same firmware (Android 4.4.2 Kitkat), and roughly the same software and configuration. Both get current time from the network. But they have different carriers, roaming on different networks.

So, I have this theory: When activating the phone from sleep, it shows the lockscreen as it was when it went to sleep including the time, while asking the telephone network for the current time. Some networks use more time to serve current time of day to the phone than others.

To work around the problem, simply switch off using network-provided date and time, and trust the built-in clock.

Settings -> More -> Date and time -> Automatic date and time

If my theory is correct, Samsung should change their lock screen widget to show local time from the internal clock while waiting to get updated time from the network, when activating the phone from sleep.

Irssi – Reducing the noise.

I’ve been using irssi for years, one of the things, which to be honest I’ve been lazy about, that annoys me, is that when people are trying to get hold of me, I’m having to troll through the logs looking for their discussion while ignoring all the PARTS JOINS QUITS etc etc etc.

I decided I had to do something about this, so I’ve just typed this into the irssi window

/ignore #fedora-uk MODES JOINS PARTS QUITS

This will ignore all the JOINS PARTS QUITS from the #fedora-uk channel,  so all I see from now on is the conversation.  Just replace #fedora-uk for what ever channel you don’t want to see all the useless information from.  Yeah that’ll do me for now.

The post Irssi – Reducing the noise. appeared first on Paul Mellors [dot] NET.

flattr this!

[MBaaS] Red Hat aquires FeedHenry


Red Hat, today announced that it has signed a definitive agreement to acquire FeedHenry, a leading enterprise mobile application platform provider.
FeedHenry expands Red Hat’s broad portfolio of application development, integration, and Platform-as-a-Service (PaaS) solutions – Openshift [1] – , enabling Red Hat to support mobile application development in public and private environments.

<iframe allowfullscreen="true" class="youtube-player" frameborder="0" height="289" src=";rel=1&amp;fs=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;wmode=transparent" type="text/html" width="460"></iframe>


reSIProcate migration from SVN to Git completed

This week, the reSIProcate project completed the move from SVN to Git.

With many people using the SIP stack in both open source and commercial projects, the migration was carefully planned and tested over an extended period of time. Hopefully some of the experience from this migration can help other projects too.

Previous SVN committers were tracked down using my script for matching emails to Github accounts. This also allowed us to see their recent commits on other projects and see how they want their name and email address represented when their previous commits in SVN were mapped to Git commits.

For about a year, the sync2git script had been run hourly from cron to maintain an official mirror of the project in Github. This allowed people to test it and it also allowed us to start using some Github features like before officially moving to Git.

At the cut-over, the SVN directories were made read-only, sync2git was run one last time and then people were advised they could commit in Git.

Documentation has also been created to help people get started quickly sharing patches as Github pull requests if they haven't used this facility before.

pointer acceleration in libinput - a userstudy

This post is a summary, the full writeup with data is here (PDF). The texts are quite similar, so if you plan to read the paper you can skip this post.

Following pointer acceleration in libinput - an analysis, we decided to run an actual userstudy to gather some data on how our acceleration behaves, and - more importantly - test if a modified acceleration method is better.

We developed two new pointer acceleration methods (plus the one already in libinput). As explained previously, the pointer acceleration method is a function mapping input speed of a device into cursor speed in pixels. The faster one moves the mouse, the further the cursor moves per "mickey" (a 1-device unit movement). In a simplest example, input deltas of 1 may result in a 1 pixel movement, input deltas of 10 may result in a 30 pixel movement.

The three pointer acceleration methods used in this study were nicknamed:

A shortening of "smooth and simple", this method is used in libinput 0.5 as well as in the X.Org stack since ~2008.
a modification of 'smooth' with roughly the same profile, but the maximum acceleration is applied at a higher speed. This method was developed by Hans de Goede and very promising in personal testing.
a linear acceleration method with a roughly similar speed-to-acceleration profile as the first two. This method was developed to test if a simple function could achieve similar results, as the more complex "smooth" and "stretched" methods.</d>
The input data expected by all three methods is in units/ms. Touchpad devices are normalised to 400 dpi, other devices are left as-is. It is impossible to detect in software what resolution a generic mouse supports, so any acceleration method differs between devices. This is intended by the manufacturer, high-resolution devices are sold as "faster" for this reason.

The three pointer acceleration methods
As the graph shows, the base profile is roughly identical and the main difference is how quickly the maximum acceleration factor is reached.

Study description

Central component was a tool built on libinput that displays a full-screen white window, with a round green target. Participants were prompted by GTK dialog boxes on the steps to take next. Otherwise the study was unsupervised and self-guided.

The task required participants to click on a round target with a radius of 15, 30 and 45 pixels. Targets were grouped, each "set" consisted of 15 targets of the same size. On a successful click within the target, a new target appeared on one out of 12 possible locations, arranged in a grid of 4x3 with grid points 300 pixels apart. The location of the target was randomly selected but was never on the same location twice in a row.

Screenshot of the study tool with the first target (size 45) visible.

Each participant was tested for two acceleration methods, each acceleration method had 6 sets of 15 targets (2 sets per target size, order randomised). The two acceleration methods were randomly selected on startup, throughout the study they were simply referred to as "first" and "second" acceleration method with no further detail provided. Acceleration changed after 6 sets (participants were informed about it), and on completion of all 12 sets participants had to fill out a questionnaire and upload the data.

Statistical concepts

A short foray into statistics to help explain the numbers below. This isn't a full statistics course, I'm just aiming to explain the various definitions used below.

The mean of a dataset is what many people call the average: all values added up divided by the number of values. As a statistical tool, the mean is easy to calculate but is greatly affected by outliers. For skewed datasets the median is be more helpful: the middle value of the data array (array[len/2]). The closer the mean and the median are together, the more symmetrical the distribution is.

The standard deviation (SD) describes how far the data points spread from the median. The smaller the SD, the closer together are the data points. The SD is also used to estimate causality vs randomly induced sampling errors. Generally, if the difference between two items is more than 2 standard deviations, there's a 95% confidence that this is a true effect, not just randomness (95% certainty is a widely accepted standard in this domain). That 95% directly maps to the p-value you may have seen in other studies. A p-value of less than 0.05 equals a less than 5% chance of random factors causing the data differences. That translates into "statistically significant".

The ANOVA method is a standard statistical tool for studies like ours. (we're using one-way ANOVA only here, Wikipedia has an example here). If multiple sets of samples differ in only a single factor (e.g. pointer acceleration method), we start with the so-called Null-Hypothesis of "the factor has no influence, all results are the same on average". Our goal is to reject that hypothesis so we can say that the factor did actually change things. If we cannot reject the Null-Hypothesis, either our factor didn't change anything or the results are caused by random influences. The tools for ANOVA compare the mean value within each sets to the mean value differences across the sets and spit out a p-value. As above, a p-value less than 0.05 means greater than 95% confidence that the Null-Hypothesis can be rejected, i.e. we can say our factor did cause those differences.

One peculiarity of ANOVA is that the sample sets have to be the same size. This affects our samples, more see below.

Study participants

An email was sent to three Red Hat-internal lists with a link to the study description. One list was a specific developer list, the other two list were generic lists. As Red Hat employees, participants are expected to be familiar with Linux-based operating systems and the majority is more technical than the average user. The data collected does not make it possible to identify who took part in the study beyond the information provided in the questionnaire.

44 participants submitted results, 7 left-handed, 37 right-handed (no ambidextrous option was provded in the questionnaire). Gender distribution was 38 male, 6 female. Mean age was 33.3 years (SD 6.7) and participants had an mean 21.2 years of experience with mouse-like input devices (SD 4.9) and used those devices an average 58.1 hours per week (SD 20.0).

As all participants are familiar with Linux systems and thus exposed to the smooth acceleration method on their workstations, we expect a bias towards the smooth acceleration method.

Study data

Data was manually checked and verified, three result files were discarded for bugs or as extreme outliers, leaving us with 41 data files. The distribution of methods in these sets was: 27 for smooth, 25 for stretched and 30 for linear.

The base measurement was the so-called "Index of Difficulty" (ID), the number obtained by distance-to-target/width-of-target. This index gives an indication on how difficult it is to hit the target; a large target very close is easier to hit than a small target that is some distance away.

Illustration of the Index of Difficulty for a target.

In hindsight, the study was not ideally suited for evaluation based on ID. The targets were aligned on a grid and the ID based on the pointer position was very variable. As is visible in the graph below, there are few clear dividing lines to categorise the targets based on their ID. For the evaluation the targets were grouped into specific ID groups: ID < 4.2, ID < 8.4, ID < 12.9, ID < 16.9 < ID < 25 and ID > 25. The numbers were selected simply because there are clear gaps between the ID clusters. This division results in uneven group sizes, (I ran the same calculations with different group numbers, it does not have any real impact on the results.)

ID for each target with the divider lines shown
The top ID was 36.44, corresponding to a 15px radius target 1093 pixels away, the lowest ID was 1.45, corresponding to a 45px radius target 130 pixels away.

Number of targets per ID group
As said above, ANOVA requires equal-sized sample sets. ANOVA was performed separately between the methods (i.e. smooth vs stretched, then smooth vs linear, then stretched vs linear). Before each analysis, the two data arrays were cut to be of equal length. For example, comparing smooth and stretched in the ID max group shortened the smooth dataset to 150 elements. The order of targets was randomised.

Study Results

The following factors were analysed:

  • Time to click on target
  • Movement efficiency
  • Overshoot

Time to click on target

Time to click on a target was measured as the time between displaying the target and clicking on it. This does not take reaction time into account, but there is no reliable way of measuring reaction time in this setup.

Mean time to click on target

As is visible, an increasing ID increases the time-to-click. On a quick glance, we can see that the smooth method is slower than the other two in most ID groups, with linear and stretched being fairly close together. However, the differences are only statistically significant in the following cases:

  • ID 8.4: linear is faster than smooth and stretched
  • ID 12.9: linear and stretched are faster than smooth
  • ID 25: linear and stretched are faster than smooth
In all other combinations, there is no statistically significant difference between the three methods, but overall a slight advantage for the two methods stretched and linear.

Efficiency of movement

The most efficient path from the cursor position to the target is a straight line. However, most movements do not follow that straight line for a number of reasons. One of these reasons is basic anatomy - it is really hard to move a mouse in a straight line due to the rotary action of our wrists. Other reasons may be deficiencies in the pointer acceleration method. To measure the efficiency, we calculated the distance to the target (i.e. the straight line) and compared that to all the deltas added up to the total movement. Note that the distance is to the center of the target, whereas the actual movement may be to any point in the target. So for short distances and large targets, there is a chance that a movement may be less than the distance to the target.

Straight distance to target vs. movement path shows the efficiency of movement.

The efficiency was calculated as movement-path/distance, then normalised to a percent value. A value of 10 thus means the movement path was 10% longer than the straight line to the target centre).

Extra distance covered
Stretched seems to perform better than smooth and linear in all but one ID group and smooth performing worse than linear in all but ID group 4.2. Looking at the actual values however shows that the large standard deviation prevents statistical significance. The differences are only statistically significant in the following cases:
  • ID 4.2: stretched is more efficient than smooth and linear
In all other combinations, there is no statistically significant difference between the three methods.


Somewhat similar to the efficiency of movement, the overshoot is the distance the pointer has moved past the target. It was calculated by drawing a line perpendicular to the direct path from the pointer position to the target's far side. If the pointer moves past this line, the user has overshot the target. The maximum distance between the line and the pointer shows how much the user has overshot the target.

Illustration of pointer overshooting the target.
The red line shows the amount the pointer has overshot the target.
Overshoot was calculated in pixels, as % of the distance and as % of the actual path taken. Unsurprisingly, the graphs look rather the same so I'll only put one up here.

Overshoot in pixels by ID group
As the ID increases, the amount of overshooting increases too. Again the three pointer acceleration methods are largely the same, though linear seems to be slightly less affected by overshoot than smooth and stretched. The differences are only statistically significant in the following cases:
  • ID 4.2: if measured as percentage of distance, stretched has less overshoot than linear.
  • ID 8.4: if measured as percentage of movement path, linear has less overshoot than smooth.
  • ID 16.8: if measured as percentage of distance, stretched and linear have less overshoot than smooth.
  • ID 16.8: if measured as percentage of distance, linear has less overshoot than smooth.
  • ID 16.8: if measured in pixels, linear has less overshoot than smooth.
In all other combinations, there is no statistically significant difference between the three methods.


In summary, there is not a lot of difference between the three methods, though smooth has no significant advantage in any of the measurements. The race between stretched and linear is mostly undecided.

Questionnaire results

The above data was objectively measured. Equally important is the subjective feel of each acceleration method. At the end of the study, the following 14 questions were asked of each participant, with answer ranges in a 5-point Likert scale, ranging from "Strongly Disagree" to "Strongly Agree".

  1. The first acceleration method felt natural
  2. The first acceleration method allowed for precise pointer control
  3. The first acceleration method allowed for fast pointer movement
  4. The first acceleration method made it easy to hit the targets
  5. I would prefer the first acceleration method to be faster
  6. I would prefer the first acceleration method to be slower
  7. The second acceleration method felt natural
  8. The second acceleration method allowed for precise pointer control
  9. The second acceleration method allowed for fast pointer movement
  10. The second acceleration method made it easy to hit the targets
  11. I would prefer the second acceleration method to be faster
  12. I would prefer the second acceleration method to be slower
  13. The two acceleration methods felt different
  14. The first acceleration method was preferable over the second
The figure below shows that comparatively few "strongly agree" and "strongly disagree" answers were given, hinting that the differences between the methods were small.

Distribution of answers in the questionnaire
Looking at statistical significance, the questionnaire didn't really provide anything of value. Not even the question "The two acceleration methods felt different" provided any answers, and the question "The first acceleration method was preferable over the second" was likewise inconclusive. So the summary of the questionnaire is pretty much: on the whole none of the methods stood out as better or worse.

Likert frequencies for the question of which method is preferable


Subjective data was inconclusive, but the objective data goes slightly in favour of linear and stretched over the current smooth method. We didn't have enough sample sets to analyse separately for each device type, so from a maintainer's point of view the vote goes to linear. It allows replacing a rather complicated pointer acceleration method with 3 lines of code.

PHP 5.4.33 and 5.5.17

RPM of PHP version 5.5.17 are available in remi repository for Fedora and in remi-php55 repository for  Enterprise Linux.

RPM of PHP version 5.4.33 are available in remi repository Enterprise Linux (RHEL, CentOS...).

These versions are now also available as Software Collections.

Version announcements:

emblem-important-2-24.png5.4.33 release is the last planned release that contains regular bugfixes. All the consequent releases will contain only security-relevant fixes, for the term of one year.

emblem-notice-24.pngInstallation : read the Repository configuration and choose your version and installation mode.

Replacement of default PHP by version 5.5 installation (simplest):

yum --enablerepo=remi-php55,remi update php\*

Parallel installation of version 5.5 as Software Collection (x86_64 only):

yum --enablerepo=remi install php55

Replacement of default PHP by version 5.4 installation (enterprise only):

yum --enablerepo=remi update php\*

Parallel installation of version 5.4 as Software Collection (x86_64 only):

yum --enablerepo=remi install php54

And soon in the official updates:

Reminder: Fedora 21 will provides PHP 5.6.

emblem-important-2-24.pngTo be noticed :

  • EL7 rpm are build using RHEL-7.0
  • EL6 rpm are build using RHEL-6.5
  • for php 5.5, the zip extension is now provided by the php-pecl-zip package.
  • a lot of new extensions are also available, see the PECL extension RPM status page

emblem-notice-24.pngInformation, read:

Base packages (php)

Software Collections (php54 - php55)

September 18, 2014

F21 Alpha on Tuesday, Fedora UK podcast, Flock bids, Fedora store, and badges!

Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for September 18th, 2014:

Fedora 21 Alpha Coming Tuesday

At today’s Go/No-Go meeting, engineering, release engineering, and QA all agreed that the Fedora 21 alpha release candidate is in sufficiently good shape to ship! So, with a few bits of rel-eng magic, it’ll be going out to mirrors and available to try on Tuesday, September 23.

As Fedora Program Manager Jaroslav Reznik says in announcing the decision to ship: “That’s one small step for mankind but one giant leap for Fedora — the first release on the way towards Fedora.Next!”

Fedora UK Videos

The Fedora UK video has started a video podcast, which will be broadcast every two weeks. Take a look at the first episode, appropriately titled S01EP01.

(No word yet on what the Scotland decision might mean for this podcast….)

Flock Bids Due Saturday!

Proposals for the 2015 edition of Flock, our annual contributor conference, are due Saturday. If you’re working on one, please get send it in. (Remember, of course, that hosting Flock is a lot of work — as Paul Frields notes, writing a bid is the easy part.)

This conference alternates between Europe and North America, and with last year’s very successful event in Prague, we’re back to the NA side of the Atlatic this time.

Fedora Store Coming Soon

I’m excited by the prospect of an official Fedora merch store — something we haven’t ever had before due to various red tape. Heroic tape-cutter Ruth Suehle tells us that we’re getting close. It’s not ready yet, but we’re looking for ideas for what you’d want — what you think would sell, and what you would buy. This won’t be a money-maker for us — it’s about getting Fedora-labeled stuff into the Fedora community’s hands. (It’s not possible to have too much!)

Fedora Badges Update

Fedora Badges are a fun ultimately-meaningless but still wonderful way to show off your contributions in Fedora — and to find new areas where you can help. For example, you can help with contributing to badges itself — there’s a badge for that, of course. On his blog, Fedora hacker Ralph Bean announces a mailing list to coordinate ongoing work (but disappointingly, also tells us that there’s no badge for just subscribing to the list).

Since it’s been quite a few weeks since this ran on a Tuesday, I think I’m going to stop pretending that they always do — but I will keep ‘em coming weekly on some day.



And now for some hardware (Onda v975w)
Prodded by Adam Williamson's fedlet work, and by my inability to getting an Android phone to display anything, I bought an x86 tablet.

At first, I was more interested in buying a brand-name one, such as the Dell Venue 8 Pro Adam has, or the Lenovo Miix 2 that Benjamin Tissoires doesn't seem to get enough time to hack on. But all those tablets are around 300€ at most retailers around, and have a smaller 7 or 8-inch screen.

So I bought a "not exported out of China" tablet, the 10" Onda v975w. The prospect of getting a no-name tablet scared me a little. Would it be as "good" (read bad) as a PadMini or an Action Pad?


Well, the hardware's pretty decent, and feels rather solid. There's a small amount of light leakage on the side of the touchscreen, but not something too noticeable. I wish it had a button on the bezel to mimick the Windows button on some other tablets, but the edge gestures should replace it nicely.

The screen is pretty gorgeous and its high DPI triggers the eponymous mode in GNOME.

With help of various folks (Larry Finger, and the aforementioned Benjamin and Adam), I got the tablet to a state where I could use it to replace my force-obsoleted iPad 1 to read comic books.

I've put up a wiki page with the status of hardware/kernel support. It's doesn't contain all my notes just yet (sound is working, touchscreen will work very very soon, and various "basic" features are being worked on).

I'll be putting up the fixed-up Wi-Fi driver and more instructions about installation on the Wiki page.

And if you want to make the jump, the tablets are available at $150 plus postage from Aliexpress.
Fedora 21 Alpha to release on Tuesday

Today the Fedora Engineering Steering Commitee held a “Go/No Go” meeting regarding the Fedora 21 alpha, and it was agreed that the current release candidates for Fedora 21 met the release criteria. With this decision, this means that Fedora 21 will be released on Tuesday September 23, 2014.

The Fedora 21 Alpha will be the first test release of the new 3 product structure that introduces Fedora Workstation, Fedora Cloud and Fedora Server.


KDE Touchpad configuration ported to Frameworks 5

Fedora 20 with KDE SC 4.14 has been very stable, and after a while it gets…boring – especially when Plasma 5 is already released and you see screenshots everywhere. If you cannot hold the urge and feel sufficiently adventurous, Dan Vratil has built the Fedora 20 and 21 rpms here. If you install i386 versions, beware that baloo-widgets cannot be installed due to unmet dependencies. So, once you install dvratil’s copr repo, just do:

dnf copr enable dvratil/kde-frameworks dvratil/kde-frameworks-unstable dvratil/plasma5
dnf remove kde\* && dnf install kf5\* plasma5\* --exclude=kf5-baloo-widgets\*

I had to manually edit /usr/share/xsessions/plasma.desktop to change "/usr//usr/bin" to "/usr/bin” so that “Plasma 5″ appears in gdm list. After logging in, the desktop runs smooth, but you notice the lack of many applications because they are not yet fully ported to KF5/Plasma5.

KDE Plasma 5 desktop

KDE Plasma 5 desktop

Once I had the Qt5/KF5/Plasma5 based workstation fully operational, I could also develop, build and test KF5 based applications. Most of the KDE apps are ported or being ported to KF5 under 'frameworks' git branch. As the OpenSuSe team already have started building KF5 based apps in an unstable repository, I could leverage the spec files to build rpms.

The first itch I scratched was unavailability of touchpad configuration kcm. Not being able to enable touch-to-tap, vertical and horizontal scrolling is no fun. Looking at the git repo for kcm-touchpad showed that it is not yet ported to KF5. Checked out the git repo and started porting. There are quite some references, blogposts and tools available online to guide and ease the porting effort. As it is a kcm that is being ported, the first place to go is Frameworks Porting Notes. The subtopic of ECM (extended cmake modules) source incompatible changes is also handy updating CMakeLists.txt files. The next thing is reference to Martin Graesslin’s post on porting kcontrol module. And the final tool that is quite useful to port API changes is the kde-dev-scripts. Run the source files through relevant script – like "find -iname "*.cpp" -o -iname "*.h" -o -iname "*.ui" | xargs ~/Programs/Projects/kde-dev-scripts/kf5/<>". When you hit an API change that cannot be automatically converted by the script, check frameworks at Then port away, setup a build directory, compile, note the build failure, fix the build – repeat.

Alexander Mezin and Hrvoje Senjan reviewed the patches and after 6 revisions the patch is committed in kcm-touchpad frameworks branch.

KCM Touchpad on KF5

KCM Touchpad on KF5

RPMs for Fedora 20 and 21 (i386, x86_64) are built and available at my copr repo. It contains builds of kmix and konsole as well. More to build and I’ll make them available in the same repo once build completed. You are welcome to try at your own risk :-)

Tagged: kde, rpm
News: Wing IDE 5.0.9 Released .
At september 10, 2014 the development team released the new version of Wing IDE.
See the details here: 5.0.9 - CHANGELOG.txt , also if you want to purchase licenses then you have this choices:

Wing IDE Pro:

Commercial Use
For companies, paid individuals, organizations, and government
Full-Featured Python IDE
Windows, Linux, and OS X
Includes One Year Support+Upgrades
Extend Support+Upgrades at $89/year
License is Transferable
$245 per user
$1150 5-pack

Non-Commercial Use
For students, educators, academic researchers, hobbyists, and publicly funded charities
Full-Featured Python IDE
Windows, Linux, and OS X
Optional Support+Upgrades at $89/year
$95 per user

Wing IDE Personal:
General Use
A low-cost alternative Python IDE for students and hobbyists
Omits Some Features
Windows, Linux, and OS X
Optional Support+Upgrades at $89/year
$45 per user

Enterprise Linux 5.10 to 5.11 risk report

Red Hat Enterprise Linux 5.11 was released this month (September 2014), eleven months since the release of 5.10 in October 2013. So, as usual, let’s use this opportunity to take a look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Red Hat Enterprise Linux 5 is in Production 3 phase, being over seven years since general availability in March 2007, and will receive security updates until March 31st 2017.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.10, up to and including the 5.11 release, broken down by severity. It’s split into two columns, one for the packages you’d get if you did a default install, and the other if you installed every single package.

Note that during installation there actually isn’t an option to install every package, you’d have to manually select them all, and it’s not a likely scenario. For a given installation, the number of package updates and vulnerabilities that affected your systems will depend on exactly what you selected during installation and which packages you have subsequently installed or removed.

Security errata 5.10 to 5.11 Red Hat Enterprise Linux 5 ServerFor a default install, from release of 5.10 up to and including 5.11, we shipped 41 advisories to address 129 vulnerabilities. 8 advisories were rated critical, 11 were important, and the remaining 22 were moderate and low.

For all packages, from release of 5.10 up to and including 5.11, we shipped 82 advisories to address 298 vulnerabilities. 12 advisories were rated critical, 29 were important, and the remaining 41 were moderate and low.

You can cut down the number of security issues you need to deal with by carefully choosing the right Red Hat Enterprise Linux variant and package set when deploying a new system, and ensuring you install the latest available Update release.

Critical vulnerabilities

Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could be exploited remotely and automatically by a worm. However we also stretch that definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) website in order to be exploited. Most of the critical vulnerabilities we fix fall into that latter category.

The 12 critical advisories addressed 33 critical vulnerabilities across just three different projects:

  • An update to NSS/NSPR: RHSA-2014:0916(July 2014). A race condition was found in the way NSS verified certain certificates which could lead to arbitrary code execution with the privileges of the user running that application.
  • Updates to PHP, PHP53: RHSA-2013:1813, RHSA-2013:1814
    (December 2013). A flaw in the parsing of X.509 certificates could allow scripts using the affected function to potentially execute arbitrary code. An update to PHP: RHSA-2014:0311
    (March 2014). A flaw in the conversion of strings to numbers could allow scripts using the affected function to potentially execute arbitrary code.
  • Updates to Firefox, RHSA-2013:1268 (September 2013), RHSA-2013:1476 (October 2013), RHSA-2013:1812 (December 2013), RHSA-2014:0132 (February 2014), RHSA-2014:0310 (March 2014), RHSA-2014:0448 (Apr 2014), RHSA-2014:0741 (June 2014), RHSA-2014:0919 (July 2014) where a malicious web site could potentially run arbitrary code as the user running Firefox.

Updates to correct 32 of the 33 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.

Overall, for Red Hat Enterprise Linux 5 since release until 5.11, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest are other remote flaws and local privilege escalation flaws:

  • A flaw in glibc, CVE-2014-5119, fixed by RHSA-2014:1110 (August 2014). A local user could use this flaw to escalate their privileges. A public exploit is available which targets the polkit application on 32-bit systems although polkit is not shipped in Red Hat Enterprise Linux 5. It may be possible to create an exploit for Red Hat Enterprise Linux 5 by targeting a different application.
  • Two flaws in squid, CVE-2014-4115, and CVE-2014-3609, fixed by RHSA-2014:1148 (September 2014). A remote attacker could cause Squid to crash.
  • A flaw in procmail, CVE-2014-3618, fixed by RHSA-2014:1172 (September 2014). A remote attacker could send an email with specially crafted headers that, when processed by formail, could cause procmail to crash or, possibly, execute arbitrary code as the user running formail.
  • A flaw in Apache Struts, CVE-2014-0114, fixed by RHSA-2014:0474 (April 2014). A remote attacker could use this flaw to manipulate the ClassLoader used by an application server running Stuts 1 potentially leading to arbitrary code execution under some conditions.
  • A flaw where yum-updatesd did not properly perform RPM signature checks, CVE-2014-0022, fixed by RHSA-2014:1004 (Jan 2014). Where yum-updatesd was configured to automatically install updates, a remote attacker could use this flaw to install a malicious update on the target system using an unsigned RPM or an RPM signed with an untrusted key.
  • A flaw in the kernel floppy driver, CVE-2014-1737, fixed by RHSA-2014:0740 (June 2014). A local user who has write access to /dev/fdX on a system with floppy drive could use this flaw to escalate their privileges. A public exploit is available for this issue. Note that access to /dev/fdX is by default restricted only to members of the floppy group.
  • A flaw in libXfont, CVE-2013-6462, fixed by RHSA-2014:0018 (Jan 2014). A local user could potentially use this flaw to escalate their privileges to root.
  • A flaw in xorg-x11-server, CVE-2013-6424, fixed by RHSA-2013:1868 (Dec 2013). An authorized client could potentially use this flaw to escalate their privileges to root.
  • A flaw in the kernel QETH network device driver, CVE-2013-6381, fixed by RHSA-2014:0285 (March 2014). A local, unprivileged user could potentially use this flaw to escalate their privileges. Note this device is only found on s390x architecture systems.

Note that Red Hat Enterprise Linux 5 was not affected by the OpenSSL issue, CVE-2014-0160, “Heartbleed”.

Previous update releases

We generally measure risk in terms of the number of vulnerabilities, but the actual effort in maintaining a Red Hat Enterprise Linux system is more related to the number of advisories we released: a single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical PHP vulnerability.

To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:

Security Errata per month to 5.10This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn’t really useful for comparisons with other major versions, distributions, or operating systems — for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, time scales, and severity range of interest.

See also:
5.10, 5.9, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, and 5.1 risk reports.

New DNF Project Leader

As I will be moving on to work on other things beyond Linux software management soon, I decided to step down as a leader of the project.

The new leader of the project is Jan Šilhan, the change is effective as of today. Jan is a talented, result-oriented software developer and I am convinced he is just the right type for the job.

It has been exciting and fun three years and a big thanks to all of you who contributed, consulted, supported or generally shared the ride.


Medit – Great text editor, but where is it?

Here is some features

medit is a programming and around-programming text editor.

Started originally as a simple built-in editor component in GGAP, it grew up to a real text editor.


  • Configurable syntax highlighting.
  • Configurable keyboard accelerators.
  • Multiplatform – works on unix and windows.
  • Plugins: can be written in C, Python, or Lua.
  • Configurable tools available from the main and context menus. They can be written in Python or Lua, or it can be a shell script.
  • Regular expression search/replace, grep frontend, builtin file selector, etc.


Searched through the fedora repo, didn’t find it. Started to search on google, but didn’t manage to find latest version for Fedora 20.




So is there someone that knows where you can download rpm files for Fedora 20?

The post Medit – Great text editor, but where is it? appeared first on Fedora Online.

NOTABUG in glibc

The glibc malloc implementation has a number of heap consistency checks in place to ensure that memory corruption bugs in programs are caught as early as possible and the program aborted to prevent misuse of the bug. Memory corruption through buffer overruns (or underruns) are often exploit vectors waiting to be ‘used’, which is why these consistency checks and aborts are necessary.

If the heap of a program has been found to be corrupted, the program is terminated with an error that usually looks something like this:

*** glibc detected *** ./foo: double free or corruption (!prev): 0x0000000001362010 ***
======= Backtrace: =========
======= Memory map: ========

and when one looks at the core dump, the top of the call stack is all inside glibc:

Program terminated with signal 6, Aborted.
#0  0x00007fd0273b6925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64    return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x00007fd0273b6925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fd0273b8105 in abort () at abort.c:92
#2  0x00007fd0273f4837 in __libc_message (do_abort=2, fmt=0x7fd0274dcaa0 "n not possible due to RF-kill") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198
#3  0x00007fd0273fa166 in malloc_printerr (action=3, str=0x7fd0274daa5e "/proc/self/maps", ptr=<value optimized="optimized" out="out">) at malloc.c:6332
#4  0x00007fd0273fdf9a in _int_malloc (av=0x7fd027713e80, bytes=<value optimized="optimized" out="out">) at malloc.c:4673

The common mistake one may make here is to assume that it is a glibc bug because the crash is ‘caused’ by glibc. That is the equivalent of killing the whistleblower. The crash is indeed caused by glibc, but the bug is not in glibc. glibc has only caught the bug after it has happened and halted execution of the program.

And if you think glibc is overstepping its bounds by halting the program, you could tell it to not abort by exporting the MALLOC_CHECK_ environment variable set to either 0 (completely silent) or 1 (prints the message on stderr). Of course, you have to be smoking something very exotic to do that instead of finding and fixing the bug.

Lohit Tami 2.91.0 now available for testing
Done with the release of Lohit Tamil 2.91.0 with the improvements planned under Lohit2 project.

Following are highlights:
  1. Rewritten all Open type tables with supporting taml and tml2 tags.
  2. Renamed all the glyphs by following AGL syntax.
  3. Open type tables are available in .fea file and this time it is compiled with AFDKO.
  4. Reusing glyphs by "COPY REFERENCE"
  5. Added GRID FITTING table and auto-hinting by fontforge. (Need to use ttfautohint but we need Latin support to do that)
  6. Tested with Harfbuzz NG and Uniscribe (W8)  (Need to test on WinXp yet)
  7. Auto test module available with test files. (Please help me to add more test cases.)

This release now support characters required for minority orthographies. For more details visit bugzilla

Stopped using deprecated ligature for SRII. See bugzilla for more information.
Launching the project 'i18nWidgets for Android'
A lot of Android devices, platforms and apps have several issues regarding rendering of non-English text especially that of Indic text. Though many of them claim to support various Indic and other languages, it usually either means that they have a font for that language included or they have some of the native apps supporting all these languages. But this does not mean all the app will be able to render the non-English text properly. This usually happens for one of the following problem being present:

1. No fonts added in the device (or the native android system)
2. Fonts are not accessible by the third party application
3. App has its own Unicode font, but the native android system does not support text layout rendering for the language
4. App has the font and the android system also supports the language, but the sdk for the particular platform does not have widgets integrated with the complex text rendering features.

This problem gave birth to the idea of developing and extending android widgets which will be integrated with text layout and rendering system on their own. So that, the apps that make use of these widgets will have their own independent rendering system free from the underlying bugs and limitations of the base android system.

The good part is, we do not need to rewrite those rendering systems. The two very well known projects that we need to make use of are Harfbuzz and Freetype. Harfbuzz for text layout of the complex scripts, and Freetype for drawing the font glyphs. 

So, this is what the project 'i18nWidgets for Android' is, under which we are developing independent widgets for app development which will have their own complex text rendering support through integration with freetype and harfbuzz libraries.

The project tree is already made suitable for using with eclipse and hence is readily testable from within eclipse. There are three dependencies to take care of while building:
1. Andoroid SDK 14/15: You may have to configure your development environment for Android SDK 14/15 
2. Android NDK 8: Make sure to have NDK 8 support enabled. 
3. Also have the appcompat_v7_2 library added properly to the project dependencies. 

Please make sure to have exact sdk and ndk versions setup, as the project includes working with native C/C++ libraries along with android platform and hence may run into tedious binary incompatibility issues if not built with proper resources. I have made best attempt to keep things simple for working within eclipse, but do go through the documentation of above development environment thoroughly if you are new to developing native android apps, in case you are struck at some compilation issue.

The project tree has following important components:
1. /jni : This contains the complex-script-rendering library that integrates Android Java widget with the C/C++ libraries of Harfbuzz and Freetype. The entire source tree of particular working snapshot of HB and FT are given in the repo to avoid any incompatibilities during the compilation. Also their makefiles are tuned to work with the given setup.
2. /src/gujaratirendering : This package contains a widget IndicTextView, an extension to the TextView widget which can render Gujarati text. Currently 
3. /src/com/example/i18nwidgetdemo: This is a demo package for testing the the IndicTextView widget with sample text on a simple app screen with Lohit-Gujarati font.
4. /assets: It contains the Lohit-Gujarati font to be used in the demo app

The library complex-script-rendering is based on the original work from Shiva Kumar, and is enhanced and made more generic. Indeed the attempt is to make it further generic and extendable. 

As of now, the project supports text rendering on app being developed for ICS platform and Gujarati language, but the language is not a necessarily limitation. Its just that I tried it with one language to start with, and this can be easily extended and made flexible for auto-supporting any language on the fly. Currently, one will have to make a small change in the complex-script-rendering.c to support language other than Gujarati and add the font of the respective language.

The objectives of the project are:
1. To further improve the library and the widgets code (may involve a lot of code cleaning to fit the norms)
2. Add support for all the languages, by detecting the language of the running text
3. Add more extended widgets to support complete android SDK
4. Create and maintain different branches supporting different android platforms

As of now the platform supported is Android 4.0.3 ICS. One would argue why support an older revision, but that's exactly where the problem is relevant. As many of the lower end widely used android devices are still to upgrade to the latest version, there are vast number of users still struggling to use their native languages, where as the developers who wish to maintain compatibility with these devices are also struggling while making apps for those users. 

While the language support on android systems and their sdk is continuously improving, there is no reason why an independent, reliable, native lang support cannot be added to the apps with help of widgets developed in such manner. This would only improve the reach of technology to those who are facing the economical and linguistic barriers. 

September 17, 2014

Fedora 21 Virtualization Test Day is Thursday September 25

virt-v2v preview packages for RHEL and CentOS 7.1 are available

virt-v2v is a small program for converting guests from VMware or Xen, to run on KVM, RHEV-M or OpenStack. For RHEL 7.1, I am rewriting and enhancing virt-v2v, so it’s much faster and easier to use.

To install, follow the instructions here for setting up the yum repository, and then you can do:

yum install virt-v2v

To use it, start with the manual here that has lots of examples and the full reference documentation.

Quick Install Spotify For Linux In Fedora 20

If you love your music whilst hacking away on your computer I am sure you have tried Spotify!

Screenshot from 2014-09-17 20:42:03

Installing it doesn’t have to be a hard task and it’s even easier thanks to Slaanesh over at

He has kindly repackaged the latest Spotify client from the Ubuntu packages to work with Fedora and the like.

Current Supported Distributions

Fedora 19 – x86_64
Fedora 20 – x86_64
Fedora 21 – x86_64
RHEL/CentOS 7 – x86_64


To Install –  

You must be root!

Firstly we need to add the repository that Slaanesh has created for all his packages.

user@computer:$ yum-config-manager --add-repo=

Then install the client

user@computer:$ yum -y install spotify-client

Once it’s installed hit your super key and start typing spotify! Happy Listening!

Screenshot from 2014-09-17 20:37:59

It’s worth also checking our Slaanesh’s other packages as there might be something else you need!


<script async="async" src=""></script> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
A follow up to yesterday's Videos new for 3.14
The more astute (or Wayland testing) amongst you will recognise mutter running a nested Wayland compositor. Yes, it means that Videos will work natively under Wayland.

Got to love indie films

It's not perfect, as I'm still seeing hangs within the Intel driver for a number of operations, but basic playback works, and the playback is actually within the same window and correctly hidden when in the overview ;)
controlando un robot con señales MIDI
El estándar MIDI (Musical Instrument Digital Interface) es un protocolo muy usado en la industria musical para transmitir información entre dispositivos musicales, como teclados, samplers, equipos para sincronizar dispositivos, etc etc. Si bien es un estándar bastante antiguo, sigue siendo valido y aun hoy es una de las formas mas común de controlar distintos equipos musicales.
En los sistemas GNU/LINUX, también implementan una forma de controlar distintos software y hardware a través de señales MIDI, de esa forma, uno puede tener un controlador MIDI o un teclado con salida MIDI  y controlar distintos programas de audio como LMMS, Hydrogen, Ardour o algunos sintes digitales como qsynth.
La forma de trabajar con auido en GNU/LINUX, puede ser un tanto complicadod e entender al principio, hay varios motores de sonido (OSS, ALSA) pero ademas, esta JACK, que se encarga de capturar el hardware y ser un buffer (o proxy si se quiere) que toma las entradas y salidas de los distintos software y los envía a la placa de audio, permitiendo hacer cosas como tomar la salida de LMMS y meterla dentro de un canal de Ardour y la salida maestra de Ardour derivarla a un multi efecto como Rakarrack, y después, todo eso a la salida de la paca de audio.

Ejemplo de Jack con su front-end qjackctl y LMMS

La idea del proyecto siguiente es poder hacer una interface que tome datos MIDI a traves de Jack y las re envié al puerto /dev/ttyACM0 para poder controlar un robot y hacer música. Para eso, use las librerías de pygame para control MIDI, que si bien son unas librerias gigantes, estan empaquetadas en casi todas las distribuciones GNU/LINUX (Y obviamente en FEDORA) y hay mucha documentación. Para el control del robot usao el modulo apicaro, que forma parte del proyecto ICARO y que me permite andar señales a la placa mediante python-serial y un firmware especial del lado del PIC (firmware tortucaro, que se carga desde la pantalla de icaro-bloques).

boton de carga para el firmware Tortucaro 
(para controlar la placa desde puerto /dev/ttyACMx)

<object class="BLOGGER-youtube-video" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase=",0,40,0" data-thumbnail-src="" height="266" width="320"><param name="movie" value=";f=user_uploads&amp;c=google-webdrive-0&amp;app=youtube_gdata"/><param name="bgcolor" value="#FFFFFF"/><param name="allowFullScreen" value="true"/><embed allowfullscreen="true" height="266" src=";f=user_uploads&amp;c=google-webdrive-0&amp;app=youtube_gdata" type="application/x-shockwave-flash" width="320"></embed></object>

Video de un robot que toca el xilofon, 
controlado mediante LMMS y tambien un teclado controlador MIDI.

 Aca el código fuente del robot, no es muy difícil de entender, básicamente son 2 clases que controlan el MIDI y el puerto serie (usando apicaro)
import pygame
import time
import pygame.midi
import apicaro

class ROBOT:
""" clase robot, cotrola mediante apicaro los dos servomotores
de moviento del robot (izquierda/derecha, arriba/abajo """

def __init__ (self):
""" Class initialiser """

def mover(self,tecla):
def golpear(self):

class MIDI:
""" inicia pygame.midi y tiene un diccionario con algunas notas MIDI """
def __init__ (self):
""" Class initialiser """
print "set player"
self.player= pygame.midi.Input(1)
print "set instrument"

# nos fijamos si hay datos en el buffer
flag = midi.player.poll()
if flag == True:
data =
senal = data [0][0]
nota = senal[1]
volumen = senal[2]
#~ print volumen
# si la nota esta dentro del diccionario, muevo el robot
if midi.notas.has_key(nota):
if volumen <>0:

Try Minetest or Voxelands — open source voxel sandbox games for Fedora

In light of recent events it might be worth for fans of Minecraft to try out Minetest or it’s fork Voxelands. Both are open source, infinite voxel sandbox games that are currently available for Fedora.

Minetest is currently being developed on and is fairly simplistic without adding mods, it does have the main game mechanics of gathering resources, crafting and building structures. There are a range of Mods available to add functionality as well as texture packs to customise your experience. Minetest is available now in Fedora from the Software application, or using the command line yum install minetest.


Voxelands is a fork of Minetest that implements a wide range of additional functionalty that is either not available in Minetest, or is only available using Mods. It adds features such as mobs and farming. Voxelands is available for Fedora from this COPR repo.





Compiling Lohit fonts feature file with Adobe Font Development Kit
This first came to notice with issue "OTM error #13". Everything was working perfectly with fontforge, creating feature file and importing feature file back :)

But certainly above issue open up number of issues with this process. Font designers were not able to import .fea file due to this issue.

Thanks to Dave and Frank for pointing to issue and directing me towards Adobe Font Development Kit (AFDKO). Adobe is the one created specification for .fea file and provided nice tools to compile it.  Most of the information already available AT 

 This blog is specifically to update how i am using AFDKO in Lohit project.

1. Write open type tables for Lohit fonts in Fontforge.
2. Export .fea file
3. Generate .ttf by importing .fea file to it using following commands.
4. makeotf -f Lohit-Tamil.ttf -ff Lohit-Tamil.fea

It fails with error but it generates unix Type1 font required for makeotfexe.

What errors :)

  makeotf command pass following arguments to makeotfexe

  "makeotfexe "-f" "Lohit-Tamil.ttf.tmp" "-o" "Lohit-Tamil.ttf.temp_cff" -ff "Lohit-Tamil.fea" -ga -gf "Lohit-Tamil.ttf.temp.GOADB" -mf "FontMenuNameDB" -shw"

In above argument  "-ga -gf "Lohit-Tamil.ttf.temp.GOADB"  are not required but somehow automatically gets added by makeotf.

But makeotf done one good job of converting source font 'Lohit-Tamil.ttf' to temporary Unix Type1 font file 'Lohit-Tamil.ttf.tmp'

5. run makeotfexe removing problem cuasing arguments.
 makeotfexe "-f" "Lohit-Tamil.ttf.tmp" "-o" "Lohit.ttf" -ff "Lohit-Tamil.fea" -mf "FontMenuNameDB" -shw

And here get you Lohit.ttf build by adding .fea file with AFDKO.

Hope so it will help to some others as well.

I specifically found this very useful for finding issues in Lohit-Devanagari.fea files.
Confusing the locale for the language

I wrote a short note on the history/context behind the bn-IN/bn-BD decision and other things here If you’d like to comment/discuss, I’d prefer the G+ post than this blog.

Generar clave publica desde clave privada

Necesito tener esto a mano:

ssh-keygen -y -f ~/.ssh/test-key.pem > ~/.ssh/

Chequear previamente que los permisos en test-key.pem sean 600.

Fedora Notifications, 0.3.0 Release

Just as a heads up, a new release of the Fedora Notifications app (FMN) was deployed today (version 0.3.0).

Frontend Improvements

Negated Rules - Individual rules (associated with a filter) can now be negated. This means that you can now write a rule like: "forward me all messages mentioning my username except for meetbot messages and those secondary arch koji builds."

Disabled Filters - Filters can now be disabled instead of just deleted, thus letting you experiment with removing them before committing to giving them the boot.

Limited Info - The information on the "context" page is now successively revealed. Previously, when you first visited it, you were presented with an overwhelming amount of information and options. It was not at all obvious that you had to 'enable' a context first before you could receive messages. It was furthermore not obvious that even if you had it enabled, you still had to enter an irc nick or an email address in order for things to actually work. It now reveals each section as you complete the preceding ones, hopefully making things more intuitive -- it warns you that you need to be signed on to freenode and identified for the confirmation process to play out.

Truncated Names - Lastly and least, on the "context" page, rule names are no longer truncated with a ..., so you can more easily see the entirety of what each filter does.

Backend Improvements

Group Maintainership - There's a new feature in pkgdb as of this summer: groups can now be maintainers of packages. I.e. the perl-sig group can own a number of core perl packages. FMN didn't know to route messages about such packages to you if you're a member of the perl-sig group, but now it does.

Automatic Accounts - And lastly, with an eye to the future, when new FAS accounts are added to the packager group, FMN notices this and creates them an FMN account turned on by default. (This is in preparation for the upcoming switch of FMN from opt-in to opt-out for packagers.)

Clock Skew - There's a feature where the IRC backend will try to tell you how delayed it was in delivering your message. If your koji build finishes while FMN is busy with other stuff, when it finally gets to your message it will tell you "your koji build finished 2 minutes ago". There was a little cosmetic bug in this where, due to clock skew between servers, FMN would tell you that "your koji build finished 2 seconds in the future".. confusing! This release fixes that.

Cache Locking - The backend keeps an in-memory cache of everyone's notification preferences (which it intelligently invalidates based on fedmsg activity). Some optimization improvements were made on the thread locking around that cache.

Thanks for all the RFEs and bugs filed so far. Happy Hacking!

September 16, 2014

ACPI, kernels and contracts with firmware
ACPI is a complicated specification - the latest version is 980 pages long. But that's because it's trying to define something complicated: an entire interface for abstracting away hardware details and making it easier for an unmodified OS to boot diverse platforms.

Inevitably, though, it can't define the full behaviour of an ACPI system. It doesn't explicitly state what should happen if you violate the spec, for instance. Obviously, in a just and fair world, no systems would violate the spec. But in the grim meathook future that we actually inhabit, systems do. We lack the technology to go back in time and retroactively prevent this, and so we're forced to deal with making these systems work.

This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware.

Back then I was writing from the perspective of the firmware changing its behaviour in response to the OS, but it turns out that it's also relevant from the perspective of the OS changing its behaviour in response to the firmware. Windows 8 handles backlights differently to older versions. Firmware that's intended to support Windows 8 may expect this behaviour. If the OS tells the firmware that it's compatible with Windows 8, the OS has to behave compatibly with Windows 8.

In essence, if the firmware asks for Windows 8 support and the OS says yes, the OS is forming a contract with the firmware that it will behave in a specific way. If Windows 8 allows certain spec violations, the OS must permit those violations. If Windows 8 makes certain ACPI calls in a certain order, the OS must make those calls in the same order. Any firmware bug that is triggered by the OS not behaving identically to Windows 8 must be dealt with by modifying the OS to behave like Windows 8.

This sounds horrifying, but it's actually important. The existence of well-defined[1] OS behaviours means that the industry has something to target. Vendors test their hardware against Windows, and because Windows has consistent behaviour within a version[2] the vendors know that their machines won't suddenly stop working after an update. Linux benefits from this because we know that we can make hardware work as long as we're compatible with the Windows behaviour.

That's fine for x86. But remember when I said it could be worse? What if there were a platform that Microsoft weren't targeting? A platform where Linux was the dominant OS? A platform where vendors all test their hardware against Linux and expect it to have a consistent ACPI implementation?

Our even grimmer meathook future welcomes ARM to the ACPI world.

Software development is hard, and firmware development is software development with worse compilers. Firmware is inevitably going to rely on undefined behaviour. It's going to make assumptions about ordering. It's going to mishandle some cases. And it's the operating system's job to handle that. On x86 we know that systems are tested against Windows, and so we simply implement that behaviour. On ARM, we don't have that convenient reference. We are the reference. And that means that systems will end up accidentally depending on Linux-specific behaviour. Which means that if we ever change that behaviour, those systems will break.

So far we've resisted calls for Linux to provide a contract to the firmware in the way that Windows does, simply because there's been no need to - we can just implement the same contract as Windows. How are we going to manage this on ARM? The worst case scenario is that a system is tested against, say, Linux 3.19 and works fine. We make a change in 3.21 that breaks this system, but nobody notices at the time. Another system is tested against 3.21 and works fine. A few months later somebody finally notices that 3.21 broke their system and the change gets reverted, but oh no! Reverting it breaks the other system. What do we do now? The systems aren't telling us which behaviour they expect, so we're left with the prospect of adding machine-specific quirks. This isn't scalable.

Supporting ACPI on ARM means developing a sense of discipline around ACPI development that we simply haven't had so far. If we want to avoid breaking systems we have two options:

1) Commit to never modifying the ACPI behaviour of Linux.
2) Exposing an interface that indicates which well-defined ACPI behaviour a specific kernel implements, and bumping that whenever an incompatible change is made. Backward compatibility paths will be required if firmware only supports an older interface.

(1) is unlikely to be practical, but (2) isn't a great deal easier. Somebody is going to need to take responsibility for tracking ACPI behaviour and incrementing the exported interface whenever it changes, and we need to know who that's going to be before any of these systems start shipping. The alternative is a sea of ARM devices that only run specific kernel versions, which is exactly the scenario that ACPI was supposed to be fixing.

[1] Defined by implementation, not defined by specification
[2] Windows may change behaviour between versions, but always adds a new _OSI string when it does so. It can then modify its behaviour depending on whether the firmware knows about later versions of Windows.

comment count unavailable comments
Microsoft Scammers Might Get More Than They Bargained For

I have actually had quite a few of these phone calls and I have had fun with them, leading them on and what not.

I even went to the extreme of letting them connect to a Windows XP Virtual Machine just to see what they’d do.

As it happens it wasn’t much, I think I must have gotten one of the dumber ones.

Fortunately none of my family members have had to deal with these goons.

The reason for this post is that Matt Weeks a Professional Security researcher has now released a 0day Exploit for the remote control software that the scammers have been using.

Ammyy Admin is what they are currently using to connect to these poor individuals that actually believe that these cowboys are actually from Microsoft and that they need to pay hundreds of pounds for non existent IT Support and an Anti-Virus you can actually get for free. *Sigh*



Matt Weeks Says…

With this work done, I put together a metasploit module that will generate a plaintext transcript to send to the remote end via the injected DLL into a running Ammyy instance that will exploit the remote end trying to take over your computer. In order to run it, you still need to run Ammyy Admin, save the plaintext transcript in its directory, and inject the DLL into the process which will load up the transcript. So I put together an executable package to automate this. I wrote the exploit for Ammyy Admin 3.4, including both the direct and ROP targets, and I updated for 3.5 when it was released. The vulnerability has been present for as long as I checked, at least back to 3.0, and probably before then.



Image Source Copyright Matt Weeks

You can download the complete package here, including a fully commented metasploit module and detailed README with more information on running it: The one remaining caveat is that Ammyy can connect in two main ways; either by ID, which routes a connection through relay servers run by Ammyy (, or directly by IP. I have only written and used the exploit with a direct IP connection to avoid sending it over the internet, so although the vulnerability should be present either way, I recommend blocking in a hosts file and simply using direct IP connections. Or at this point, feel free to look into making it work over the relays, but I have not. Source

I pretty much agree with Matt, I normally wouldn’t publish any type of exploit that could hurt any innocent end user but in this case I will happily write about this and post it here.

Remember! Microsoft Will Never Call You!

For more InfoSec stuff check out Matts blog over at

<script async="async" src=""></script> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
This week in Fedora QA: Fedora 21 Alpha validation, Cockpit and ARM Test Days

Hi folks! Well, your humble monkey has been spending more time than he strictly ought to pretending he’s a web developer this week, but Fedora 21 QA rolls on regardless. We have had some major headaches with getting Fedora 21 Alpha built, but as of this morning we finally have a release candidate. Network installs still don’t pick up the mirrors properly by default, but the images are now doing the right thing, and the remaining problem is in MirrorManager. This means that once release engineering get MirrorManager pointed in the right direction, the RC1 netinst images will (should…) ‘magically’ start working out of the box.

With that wrinkle noted, we need to run all the usual validation testing on this compose (and any future RCs), so please do help out if you can! It’d be nice to finally sign off on the Alpha release this week.

Aside from Alpha release validation, we have two Test Days this week. Today is Cockpit Test Day. Cockpit is a ‘server user interface’ – it gives you an overview and control panel for a set of server machines, essentially. It’s a key part of the Fedora Server Product that is one of the main components of the Fedora 21 release. It’s a very new and shiny technology, so it needs a lot of testing – it’ll be fun to play with, and we really need to get it into shape. All good reasons to join #fedora-test-day on Freenode IRC and join in. If you don’t know how to use IRC, you can read these instructions, or just use WebIRC.

Thursday (2014-09-18) will be ARM Test Day. Fedora 21 is shaping up to be another awesome release for ARM, with more support for more devices than ever. By now half the world must have one or more ARM devices lying around cluttering up the place, so if you have one that Fedora targets, please do come out and help us check that everything is in order for Fedora 21! Again, you can join #fedora-test-day on Freenode IRC to take part, and again, if you don’t know how to use IRC, you can read these instructions, or just use WebIRC.

Electronic Yellow Sticky of Doom

Instead of writing passwords on a piece of paper, you can save them on the computer. The most obvious way to do this is with a text document or a spreadsheet.

Bad idea!

Your password is now subject to being hacked. Since your computer is almost certainly connected to the network (or you wouldn’t have so many passwords!), you are now threatened by the entire Internet, not just the people around you.

OK, you can save the document or spreadsheet as a password protected document. Less bad, still not good. It is a step in the right direction, but there are better ways to do it. This is a situation where you should use the right tool for the job – in this case a password manager.

A password manager is an application designed to manage your passwords. It will typically have a strong security model, the ability to organize passwords by the application or web site they go to, and the ability to generate passwords. Many password managers are designed to integrate with applications and the Web, where they can automatically provide the username and password and login for you.

Instead of trying to remember multiple passwords, all you have to do is remember a single password to open the password manager. (Yes, you can write down the password to your password manager. In fact, you probably should – and lock it up in a secure location like a safety deposit box. Think of this written copy as a backup, where security is more important than ease of access. You may even want to print out the contents of your password manager and lock them up in the safety deposit box.)

There are many password managers available, so you should do your research before choosing one. Reviews are available from a number of sources such as LWN  or Tech Radar. Be especially careful when choosing a password manager from an application store that has millions of applications – many of these applications are poorly written and may contain malware. For something as important as a password manager you need to do your homework!

An example of a highly regarded password manager is KeePass and the KeePassX version for Linux. This is an open source application, so the code has been widely reviewed. If you are running Linux, KeePassX is probably included in your Linux distribution.

KeePass creates an encrypted database of passwords on your system. In fact, it supports multiple databases, so you can keep personal and work related passwords separated. KeePass also has an internal group structure to organize passwords. This allows you to to have groups like finance, social, sports, email, and work for your various accounts.

A strength of password managers is that most of them have a password generator. Again looking at KeePass as a specific example, you can control the length of the password, uppercase/lower case, numbers, special characters, and even whitespace. You also have the option of specifying “pronounceable” passwords.(For some values of pronounceable…)

Using a password manager makes it feasible to use more secure passwords – specifying 24 characters, uppercase/lowercase/numbers/special characters and generating a unique password for each application or site is easy. It is also easy to change passwords regularly – just have your password manager generate a new password, which it then remembers.

Password managers aren’t perfect, but they are a useful tool for making passwords as good as they can be. Using a good password manager is more secure than re-using an easily guessable password across multiple applications.

Extending the p2 Repository Format in Fedora

We ship a lot of OSGi bundles in Fedora.

$ repoquery --repofrompath=foo, --repoid=foo -q --whatprovides "osgi(*)" | wc -l

We already allow packagers to have requirements based on the OSGi metadata to some extent. We’re supporting Require-Bundle in specfiles through use of the “osgi(…)” provide but even with this, building Eclipse plugins has always seemed like a giant hack, and even more so when compared to the latest Java Maven Packaging Examples. Building with Tycho requires that your OSGi dependencies be in a p2 repository (update site). We obviously can’t just point to the update sites for our Fedora builds since all of our dependencies must be from packages within the Fedora infrastructure that were built from sources. Initially the simplest way to achieve this was to look on the system for all OSGi bundles, publish them to a p2 repository, and then feed this directly into Tycho’s build target platform.

This approach certainly works (and that’s what the copy-platform-all script did) but it still requires performing the same steps every time one needs to feed OSGi bundles to Tycho or some other application that uses p2 repositories. The end-goal is to have tighter integration with tools like XMvn, and to make packaging an easier task. To do this we really need to have our system locations be recognized as p2 repositories so that we could also take advantage of p2 APIs.

When I got back from EclipseCon NA 2014, I started playing around with this idea of having filesystem directories being recognized as a p2 repository.

Imagine :

$ eclipse -application org.eclipse.equinox.p2.director -repository fedora:/usr/share/java/ -installIU org.swtchart

with the result being that ‘org.swtchart’ from somewhere in ‘/usr/share/java’ gets installed into the eclipse instance. This was easy to implement and fairly simple to integrate with Tycho so that we only inject a few system locations and get proper dependency resolution.

I’ve named this fedoraproject-p2 mainly because Fedora’s requirements are the driving force but I could see this being useful in many other cases.

This has been used for some time now on rawhide, and with the addition of things like the xmvn-p2-installer-plugin, it won’t be long until Eclipse plugin packaging will be drastically simpler.

Software Freedom Day Panamá

El próximo sábado 20 de septiembre se estará realizando en la Universidad Interamericana de Panamá el evento Software Freedom Day. Si te gusta la tecnología no te lo puedes perder. Software Freedom Day es un evento bastante similar al Hardware Freedom Day, a diferencia de que éste último trata temas específicamente de hardware.

Estoy participando en el software freedom day.

Para este año sevan a hablar temas relacionados a Firefox OS, Drupal, Node.js, entre otros. Personalmente quiero invitarlos a la exposiciones que voy a presentar: la primera es acerca de cómo puedes realizar tus presentaciones a través del uso de LaTeX y la segunda en conjunto con el equipo Fedora, títulada: “Fedora“. En artículos anteriores dentro de Panama Hitek se ha mostrado información relevante sobre este sistema tipográfico y se ha dado a conocer muchas de sus ventajas. Con este tipo de temas, quisiera impulsar el seguimiento de este paradigma en la creación de textos científicos y que sea especialmente implementado por los estudiantes de las distintas universidad de Panamá. Por otro lado, si también quisiera instalar Fedora en tu ordenador o saber más sobre esta distribución Linux/GNU, puedes venir a la charla de Fedora donde vamos a estar el Team de Fedora Panamá hablando un poco sobre el proyecto, cómo puedes contribuir, y más.

Espero que asistas y nos vemos el sábado 20.

Página web oficial del evento:

Software Freedom Day Flyer

The post Software Freedom Day Panamá appeared first on Panama Hitek.

How to make a Live USB stick using GNOME Disks

Fedora Live ISO images allow you to make bootable CDs and DVDs from scratch. But did you know they can also be used to make bootable USB sticks as well? And did you further know, you can do this directly from the desktop?

This is because these ISO files made by the Fedora crew are hybrid style images. That allows them to be booted from different kinds of devices. Other distributions offer hybrid live images as well. Check with your distribution vendor or support community for details on their ISO images.

This screencast shows how you can use the GNOME Disks tool directly from your desktop to turn a Fedora Live ISO image into a bootable USB stick:

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="375" src="" width="500"></iframe>

Here’s a basic breakdown of the steps:

  1. Open the GNOME DIsks tool.
  2. Insert your USB stick into the computer. If necessary, copy or move any files from the stick you want to keep as backups. This operation will destroy them!
  3. Select the USB stick in Disks, usually called “Generic Flash Disk.”
  4. Unmount the stick using the “Stop” button.
  5. Use the advanced tools at the top of Disks, which looks like a gear icon, to launch “Restore disk image.”
  6. Select your ISO image file, and verify again that you are about to write to your USB stick device (and not your hard disk or some other device!).
  7. Confirm, and if necessary, provide your password.
  8. When the operation is complete, you can eject the stick and then boot a computer from it. Now you can run the Live image without having to install it to your hard disk.
New badge: Blag Dragster (Planet VII) !
Blag Dragster (Planet VII)You posted 160 or more things to the Fedora Planet!
GNOME Wayland development progressing at a steady pace

Last month at flock, we reported on GNOME and Fedora developer Matthias Clasen’s talk on the replacement for the X display server, Wayland. Now on his blog, Matthias has provided a brief update on the status of Wayland support in GNOME 3.14 (the version of GNOME that will ship with Fedora 21).

In this development cycle, the GNOME Developers have added support for keyboard layouts, drag & drop, and support for touch devices. Also there is an impressive number of applications that natively support GNOME Wayland including nautilus, gedit and GNOME Software.


A Wayland status update

It has been a while since I last  wrote about the GNOME Wayland port; time for another status update of GNOME 3.14 on Wayland.


So, what have we achieved this cycle ?

  • Keyboard layouts are supported
  • Drag-and-Drop works (with limitations)
  • Touch is supported

The list of applications that work ‘natively’ (ie with the GTK+ Wayland backend) is looking pretty good, too.  The main straggler here is totem, where we are debugging some issues with the use of subsurfaces in clutter-gtk.

We are homing in on ‘day-to-day usable’.  I would love to say the Wayland session is “rock-solid”, but I just spent an hour trying to track track down an ugly memory leak that ended my session rather quickly. So, we are not quite there yet, and more work is needed.

If you are interested in helping us complete the port and take advantage of Wayland going forward, there is an opening in the desktop team at Red Hat for a Wayland developer.

Update: After a bit of collective head-scratching, Jasper fixed the memory leak here.