Today I have two announcements to make.

First, the version 0.9.1 of the Ixion library is now available. You can download the 0.9.1 source package from the project’s main page.

This is purely a maintenance release to address portability problems in the python bindings as well as other minor build and packaging issues. Many thanks to David Tardon for single-handedly addressing these issues.

Now, here is the second announcement. We are officially moving the project’s home from the previous Gitorious one to the GitLab’s, following the announcement of the acquisition of Gitorious by GitLab and the imminent shutdown of the Gitorious hosting site resulted from the acquisition. The new official URL for the Ixion project will be https://gitlab.com/ixion/ixion. If you need to include an URL to the project, please use the new one from this point forward.

Thank you, ladies and gentlemen.

A lot has been happening on the KDE side of openSUSE… this post summarizes what’s been going on so far.

Live media for Plasma 5

One of the most-often requested ways to test Plasma 5, given it can’t be coinstalled with the 4.x Workspace, is the availability of live images to test either in VM or bare metal without touching existing systems.

Given that other distributions started doing so since a while, naturally openSUSE couldn’t stay still. ;) Thanks to the efforts of Hrvoje “shumski” Senjan, we have now live media available for testing out Plasma 5!

• Download location: the ISO file you’re looking for is called openSUSE-Plasma5 (currently x86_64 only)

The image is based on the current Tumbleweed and takes the latest code from git. If you test this in a virtual machine, bear in mind that there are some issues with VirtualBox and Plasma 5, and that QtQuick’s reliance on openGL can cause problems in general with virtual machines.

And if you find a bug… if it’s in the core distribution, or in the KDE packaging, head over to openSUSE’s Bugzilla. If it’s instead in the software, the KDE bug tracker is your friend.

Questions? Head over to the opensuse-kde ML, or the #opensuse-kde channel on Freenode.

Plasma 5 as default in openSUSE

You may have read on a recent Softpedia article that Plasma 5 is going to become the default in openSUSE. That’s correct (what did you expect, a retraction? ;): I and the others of the team (Raymond and Hrvoje) have been using Plasma 5 for a long time, not only because we like to stay on the bleeding edge ;) but also to see how it would fare for openSUSE. In the mean time, we reported bugs, sometimes fixed them, and occasionally landed one or two features in.

With the upcoming Plasma 5.3, we feel that it is of the level of quality expected from the default openSUSE desktop, and therefore we have set up preparations for the switch. As Rome wasn’t built in a day, it won’t happen straight away ;) but it will involve changes in the repositories and in the packaging, which are summarized below:

• We will start the migration around the end of April, as long as the basic openQA tests are ready;

• We will release KDE Applications 15.04 in Tumbleweed at the same time;

• The KF5 ports of the applications present in KDE Applications 15.04 will obsolete their existing counterparts (hence the KF5 version will replace the 4.x version).  The same will happen for the kdebase4-workspace and Workspace 4.x packages;

• Afterwards, the 4.x Workspace will not be supported or maintained for Tumbleweed. Help from the community is welcome in case anyone wants to step up and maintain the packages.

• The default menu applet will be Kicker (as opposed to Kickoff used in the 4.x tiems;

• The default theme for Plasma 5 will be Breeze (the upstream default), and we will use the menu structure provided by upstream KDE (as opposed to the custom structure we use today);

• The repository layout will change. We will have three repositories holding KDE software:

  • KDE:Frameworks - the KF5 libraries and Plasma 5;
  • KDE:Applications - KDE Applications releases
  • KDE:Extra - Other KDE/Qt related community packages.

• For each of these repositories, there will be also an “unstable” variant, tracking the current git master state.

(The full IRC log of the last meeting outlines these points in detail)

There are still some points open for discussion, in particularly for the update applet: should we keep Apper? Would Muon be a drop-in replacement? Or are we better off without an applet at all?

Of course, input  and help from the community is welcome. Hop on IRC or on the ML (see above for where to look)  if you want to help and participate in this large transition.

Heute habe ich Kraft Version 0.58 freigegeben. Download.

0.58 ist ein weiteres Release, das Fehler in der Kraft 0.5x Reihe behebt. Es wurde ein Fehler bei der Berechnung der Mehrwertsteuer auf den PDF-gerenderten Dokumenten behoben. Ausserdem kann jetzt der Schrägstrich (‚/‘) in Nummernkreis-Vorlagen verwendet werden, was vorher zu einem Fehler geführt hat.

Ausserdem habe ich den Build-Prozess etwas aufgeräumt und die kraftcat Bibliothek entfernt. Die Dateeien werden jetzt auch direkt mit Kraft gebaut.

Die Bibliothek hatte nie eine öffentliche API und war nie stabil, so dass sie auch nicht ausserhalb von Kraft verwendet wurde. Paketieren von Kraft ist damit einfacher und standardkonformer.

Ein Update auf Version 0.58 wird für Produktionssysteme empfohlen.

Orthogonal or hierarchical?

Time

Screenshot from contourproject

Space

Conclusion

General

Official Install Documentation

Repositories

1. use the repositories from devel:languages:ruby and home:darix:apps
2. zypper in –from home:darix:apps redis gitlab-ce gitlab-shell

config redis:

See also: /usr/share/doc/packages/redis/README.SUSE

$ cd /etc/redis
$ cp default.conf.example gitlab.conf
$ vi gitlab.conf

* daemonize no
* pidfile /var/run/redis/gitlab.pid
* logfile /var/log/redis/gitlab.log
* dir /var/lib/redis/gitlab/

$ install -d -m 0750 -o redis -g redis /var/lib/redis/gitlab/
$ chown root:redis gitlab.conf
$ sc start redis@gitlab
$ sc enable redis@gitlab

GitLab Shell

1. cd /usr/share/gitlab/shell/; cp config.yml{.example,}
2. set up redis socket matching /etc/redis/gitlab.conf
3. maybe enable audit_usernames (but see warning)

config rails app

1. cd /srv/www/vhosts/gitlab-ce/
2. configure database.yml (based on postgresql example)
3. cp config/gitlab.yml.{example,}

• host, port, https, email_from in gitlab section
• optionally ldap settings

4. cp config/resque.yml.{example,}

• adapt socket for redis. should match /etc/redis/gitlab.conf

5. export RAILS_ENV="${RAILS_ENV:=production}"
6. gitlab-ce-update
7. rake db:seed_fu
8. check for new files which are now owned by root:root (e.g. .gitlab_shell_secret) they should be owned by root:gitlab with permissions u=rw,g=r,o=
9. make sure you have the symlink .gitlab_shell_secret /srv/www/vhosts/gitlab-ce/.gitlab_shell_secret
10. Configure git for gitlab user as seen in official docs
11. sc start gitlab-ce-unicorn gitlab-ce-sidekiq gitlab-workhorse
12. sc enable gitlab-ce-unicorn gitlab-ce-sidekiq gitlab-workhorse

Testing things

1. ssh access

ssh -T gitlab@gitlab.suse.de
Welcome to GitLab, $yourusername!

My opinion is Simple Direct Layer 2  library is awesome piece of code. SDL2 delivers 99.9% what it promises. When SDL2 works it makes good habit to stay away your mind but now I want to talk about when SDL2 doesn’t work and when you want to deliver closed source application.

It seems that there is some problems with  OpenGL/DirectX and other accelerations APIs that they don’t play together without tweaking and researching ways to make them work. Okay this ain’t SDL2 fault completely this manufacturer problem again but.. you use SDL2 to get rid of hardware problems.

All those problems are solvable with current SDL2 version but again they takes lots of time and someone who is willing to debug application in non-working machine and remember this is normal stuff in development and not a big thing. But it’s big thing when you are about to releasing your new bling bling game with megalomanic blitting and your surfaces starts to blink every time you blit with some random machines. Even in not so bling bling UnReal Wolrd RPG you have problem with that but they are solved now but I builded many many Mac OS X and Linux builds before problem was traced to SDL2 related. If you are Apple people I point my finger to you. What the heck you are doing to openGL in Mac OS X??

SDL2 is what open source library but their biggest problems (in my opinion) are these: Hey Wiki is nice but have proper Doxygen or something documentation (which should be official), You have Bugzilla but there is no connection (or I just didn’t noticed) how bugs and Mercurial repository communicate each other and where/how you communicate with you users (mailinglists are so 90′ how about posting some news)?

What this leads is people post patches to Bugzilla where they get to nowhere and other one are using them because they solve their problem. This leads in situation where there is unofficial SDL2 libraries that are not compatible with each other. This is normal situation in open source world and SDL2 is under ZLib license so you can do it but what happens when they fix something that was broken to official SDL2 library and you using older one in development that is patched to work?

This is not SDL2 specific thing it’s very common situation with many open source projects (and yes they tend to have limited man power if you like to fix them you can! Learn to communicate with those people like I should with SDL2 people) but in a way SDL2 have deep connection with Valve (They use it in Linux steam client at least) and Steam ain’t small company they should but power behind this or let it go.

At the end remember this ain’t rant against SDL2 or SDL2 developers. They are doing hard work for you getting mostly nothing out of it. Because Eastern is all about pain and unhappiness so this was my contribution to that or no not really people!! Life is too short for sadness so have a lot’s of fun all eastern!

And once again, it’s time for another Limba blogpost

Limba is a solution to install 3rd-party software on Linux, without interfering with the distribution’s native package manager. It can be useful to try out different software versions, use newer software on a stable OS release or simply to obtain software which does not yet exist for your distribution.

Limba works distribution-independent, so software authors only need to publish their software once for all Linux distributions.

I recently released version 0.4, with which all most important features you would expect from a software manager are complete. This includes installing & removing packages, GPG-signing of packages, package repositories, package updates etc. Using Limba is still a bit rough, but most things work pretty well already.

So, it’s time for another progress report. Since a FAQ-like list is easier to digest. compared to a long blogpost, I go with this again. So, let’s address one important general question first:

How does Limba relate to the GNOME Sandboxing approach?

(If you don’t know about GNOMEs sandboxes, take a look at the GNOME Wiki – Alexander Larsson also blogged about it recently)

First of all: There is no rivalry here and no NIH syndrome involved. Limba and GNOMEs Sandboxes (XdgApp) are different concepts, which both have their place.

The main difference between both projects is the handling of runtimes. A runtime is the shared libraries and other shared ressources applications use. This includes libraries like GTK+/Qt5/SDL/libpulse etc. XdgApp applications have one big runtime they can use, built with OSTree. This runtime is static and will not change, it will only receive critical security updates. A runtime in XdgApp is provided by a vendor like GNOME as a compilation of multiple single libraries.

Limba, on the other hand, generates runtimes on the target system on-the-fly out of several subcomponents with dependency-relations between them. Each component can be updated independently, as long as the dependencies are satisfied. The individual components are intended to be provided by the respective upstream projects.

Both projects have their individual up and downsides: While the static runtime of XdgApp projects makes testing simple, it is also harder to extend and more difficult to update. If something you need is not provided by the mega-runtime, you will have to provide it by yourself (e.g. we will have some applications ship smaller shared libraries with their binaries, as they are not part of the big runtime).

Limba does not have this issue, but instead, with its dynamic runtimes, relies on upstreams behaving nice and not breaking ABIs in security updates, so existing applications continue to be working even with newer software components.

Obviously, I like the Limba approach more, since it is incredibly flexible, and even allows to mimic the behaviour of GNOMEs XdgApp by using absolute dependencies on components.

Do you have an example of a Limba-distributed application?

Yes! I recently created a set of package for Neverball – Alexander Larsson also created a XdgApp bundle for it, and due to the low amount of stuff Neverball depends on, it was a perfect test subject.

One of the main things I want to achieve with Limba is to integrate it well with continuous integration systems, so you can automatically get a Limba package built for your application and have it tested with the current set of dependencies. Also, building packages should be very easy, and as failsafe as possible.

You can find the current Neverball test in the Limba-Neverball repository on Github. All you need (after installing Limba and the build dependencies of all components) is to run the make_all.sh script.

Later, I also want to provide helper tools to automatically build the software in a chroot environment, and to allow building against the exact version depended on in the Limba package.

Creating a Limba package is trivial, it boils down to creating a simple “control” file describing the dependencies of the package, and to write an AppStream metadata file. If you feel adventurous, you can also add automatic build instructions as a YAML file (which uses a subset of the Travis build config schema)

This is the Neverball Limba package, built on Tanglu 3, run on Fedora 21:

Which kernel do I need to run Limba?

The Limba build tools run on any Linux version, but to run applications installed with Limba, you need at least Linux 3.18 (for Limba 0.4.2). I plan to bump the minimum version requirement to Linux 4.0+ very soon, since this release contains some improvements in OverlayFS and a few other kernel features I am thinking about making use of.

Linux 3.18 is included in most Linux distributions released in 2015 (and of course any rolling release distribution and Fedora have it).

Building all these little Limba packages and keeping them up-to-date is annoying…

Yes indeed. I expect that we will see some “bigger” Limba packages bundling a few dependencies, but in general this is a pretty annoying property of Limba currently, since there are so few packages available you can reuse. But I plan to address this. Behind the scenes, I am working on a webservice, which will allow developers to upload Limba packages.

This central ressource can then be used by other developers to obtain dependencies. We can also perform some QA on the received packages, map the available software with CVE databases to see if a component is vulnerable and publish that information, etc.

All of this is currently planned, and I can’t say a lot more yet. Stay tuned! (As always: If you want to help, please contact me)

Are the Limba interfaces stable? Can I use it already?

The Limba package format should be stable by now – since Limba is still Alpha software, I will however, make breaking changes in case there is a huge flaw which makes it reasonable to break the IPK package format. I don’t think that this will happen though, as the Limba packages are designed to be easily backward- and forward compatible.

For the Limba repository format, I might make some more changes though (less invasive, but you might need to rebuilt the repository).

tl;dr: Yes! Plase use Limba and report bugs, but keep in mind that Limba is still in an early stage of development, and we need bug reports!

Will there be integration into GNOME-Software and Muon?

From the GNOME-Software side, there were positive signals about that, but some technical obstancles need to be resolved first. I did not yet get in contact with the Muon crew – they are just implementing AppStream, which is a prerequisite for having any support for Limba[1].

Since PackageKit dropped the support for plugins, every software manager needs to implement support for Limba.

So, thanks for reading this (again too long) blogpost There are some more exciting things coming soon, especially regarding AppStream on Debian/Ubuntu!

[1]: And I should actually help with the AppStream support, but currently I can not allocate enough time to take that additional project as well – this might change in a few weeks. Also, Muon does pretty well already!

One of the major visual updates of the 3.16 release is the high contrast accessible theme. Both the shell and the toolkit have received attention in the HC department. One noteworthy aspect of the theme is the icons. To guarantee some decent amount of contrast of an icon against any background, back in GNOME 2 days, we solved it by "double stroking" every shape. The term double stroke comes from a special case, when a shape that was open, having only an outline, would get an additional inverted color outline. Most of the time it was a white outline of a black silhouette though.

In the new world, we actually treat icons the same way we treat text. We can adjust the best contrast by controlling the color at runtime. We do this the same way we've done it for symbolic icons, using an embedded CSS stylesheet inside SVG icons. And in fact we are using the very same symbolic icons for the HC variant. You would be right arguing that there are specific needs for high contrast, but in reality majority of the double stroked icons in HC have already been direct conversions of their symbolic counterparts.

While centralized theme that overrides all application never seemed like a good idea, as the application icon is part of its identity and should be distributed and maintained alongside the actual app, the process to create a high contrast variant of an icon was extremely cumbersome and required quite a bit of effort. With the changes in place for both the toolkit and the shell, it's far more reasonable to mandate applications to include a symbolic/high contrast variant of its app icon now. I'll be spending my time transforming the existing double stroke assets into symbolic, but if you are an application author, please look into providing a scalable stencil variant of your app icon as well. Thank you!

• GNOME icon design guidelines
• High Contrast App Icon Initiative