Ever since the launch of Argon and Krypton, the openSUSE community KDE team didn’t really stand still: a number of changes (and potentially nice additions) have been brewing this week. This post recapitulates the most important one.

I’d like the most recent Qt, please

As pre-announced by a G+ post, the openSUSE repositories bringing KDE software directly from KDE git (KDE:Unstable:Frameworks and KDE:Unstable:Applications) have switched their Qt libraries from Qt 5.5 to the recently released Qt 5.6. This move was made possible by the heroic work of Christophe “krop” Giboudeaux, who was able to beat QWebEngine into submission and make it build in the OBS.

Qt 5.6 comes with a much improved multiscreen handling and a lot of fixes contributed by people from KDE. A certain number of issues that were plaguing Plasma users should be gone with this version. Be wary however that’s not yet released in stable form, and there may be plenty of bugs. Also, the interaction of KDE software with Qt 5.6 is not completely tested: be sure to try it, and report those bugs!.

For these reasons, Qt 5.6 is not yet in Tumbleweed (the stable release will be submitted once it is out). Therefore you will need an additional repository to be able to update, KDE:Qt56. If you have KDE:Qt55 in your repository list, you must remove it and replace it with KDE:Qt56.

You can add the repository easily like this:

zypper ar -f obs://KDE:Qt56 KDE_Qt56 # Tumbleweed
zypper ar -f obs://KDE:Qt56/openSUSE_Leap_42.1 KDE_Qt56 # for Leap

Then force an update to this repository

zypper ref
zypper dup --from KDE_Qt56

Then update from KDE:Unstable:Frameworks first, then KDE:Unstable:Applications.

A bit of Wayland in my gases, too!

Of course, this change has also trickled down to the Argon and Krypton media, which have been updated to reflect this change. But that’s not all. The KDE team is now proud to offer a Wayland-based Krypton image, which accompanies the standard one. Thanks to KIWI, making this was faster than shouting Ohakonyapachininko! Well, perhaps not, but still quite easy.

If you want to try out the Wayland base image, be aware that it is nowhere near alpha level. There is a lot going on and development is heavy, so it may be broken in may interesting ways before you even notice it. You have been warned!

Where do you find all this goodness? The KDE:Medias directory on download.opensuse.org has all the interesting bits. The three kinds of images residing there are:

• openSUSE_Argon (x86_64 only): Leap based, X11 based KDE git live image;
• openSUSE_Krypton (i586 and x86_64): Tumbleweed based, X11 based KDE git live image;
• openSUSE_Krypton_Wayland (i586 and x86_64): Tumbleweed based, Wayland based KDE git live image.

Let’s not forget about bugs!

Borrowing from my previous entry:

Chances are that you might run into one or more bugs. This is software from git, and code review/continuous integration can only do so much. What should you do in such a case?

1. (NOT recommended) Kick and scream and demand a refund ;)
2. If your bug is in the distribution stack, like drivers or packaging, file a bug on openSUSE’s bugzilla with enough details so that it can be looked at;
3. If your bug is instead in KDE software, turn to KDE’s bugzilla.

As always, “have a lot of fun!”

As KDE software (be it the Frameworks libraries, the Plasma 5 workspace, or the Applications) develops during a normal release cycle, a lot of things happen. New and exciting features emerge, bugs get fixed, and the software becomes better and more useful than it was before. Thanks to code review and continuous integration, the code quality of KDE software has also tremendously improved. Given how things are improving, it is tempting to follow development as it happens. Sounds exciting?

Except that there are some roadblocks that can be problematic:

• If you want to build the full stack from source, there are often many problems if you’re not properly prepared;
• Builds take time (yes, there are tricks to reduce that, but not all people know about them);
• If things break… well, you get to keep the pieces.

But aside personal enjoyment, KDE would really benefit from more people tracking development. It would mean faster bug reporting, uncovering bugs in setups that the developers don’t have, and so on.

What about noble gases?

Recently, an announcement about a gas used in fluorescent lamps generated quite a buzz in the FOSS community. Indeed, such an effort would solve many of the problems highlighted above, because part of the issues would be on the backs of integrators and packagers, which are much better apt for this task.

But what, am I telling a story you already know? Not quite.

A little flashback

For those who don’t know, openSUSE has a certain number of additional repositories with KDE software. Some of these, since many years, have been providing the current state of KDE software as in git for those who wanted to experiment. This hasn’t been done just for being on the bleeding edge: it’s also been used by the openSUSE KDE team itself to identify and fix in advance issues related to packaging, dependencies, and occasionally help testing patches (or submit their own to KDE).

So, in a way, there were already means to test KDE software during development. However, there was a major drawback in adoption, which involves the fact that these packages replace the current ones on the system. For technical reasons, it is not possible to do co-installation (for example, in a separate prefix) in a way that is maintainable long term.

So, what now?

After hearing about the announcement, we (the openSUSE KDE team) realized that we had already the foundation to provide this software to our users. Of course, if you got too much neon, you’d asphyxiate ;), so we had to look at alternative solutions. And the solutions were, like the repositories, already there, provided by openSUSE: the Open Build Service and the KIWI image system which can create images from distribution packages.

But wait, there’s more (TM)!

openSUSE ships two main flavors: the ever-changing (but battle-tested) Tumbleweed, and the rock-solid Leap. So, one user would ever want to experience the latest state of many applications, or just be focused on KDE software while running from a stable base. So, if we could create images using KIWI, why not create two, one for Leap and one for Tumbleweed? And you know what…

Lo and behold, in particular thanks to the heroic efforts of Raymond Wooninck, we had working images! We also like noble gases, so Argon and Krypton were born!

The nitty gritty details

These images work in two ways:

• They work as live images, meaining you can test the latest KDE software without touching your existing system, and like that, not worry about something that breaks;
• You can also install them, and have a fully updated Leap or Tumbleweed system with the KDE:Unstable repositories active. Use this if you know what you’re doing, and want to test and report issues.

Bugs, bugs everywhere!

Chances are that you might run into one or more bugs. This is software from git, and code review/continuous integration can only do so much. What should you do in such a case?

1. (NOT recommended) Kick and scream and demand a refund ;)
2. If your bug is in the distribution stack, like drivers or packaging, file a bug on openSUSE’s bugzilla with enough details so that it can be looked at;
3. If your bug is instead in KDE software, turn to KDE’s bugzilla.

And of course, like the openSUSE login text says, “have a lot of fun!”

Yesterday the Khronos Group with participants from all segments of the graphics industry - including big players like AMD, nVidia, Samsung, Sony, Valve, Intel and many others - has anounced the availability of the first final and open specification of the Vulkan-API. It is comparable with Microsoft's Direct3D and Apple's Metal and planned as the successor to OpenGL.

The Vulkan-API is based on large parts of the AMD exclusive and closed source Mantle-API. Therefore it's no big surprise that A...

Built openSUSE Leap based Sugar test images on SUSE Studio, get it from here.

If you wish to get involved with the project maintaining packages, fixing/reporting bugs, follow the links on the X11:Sugar build service project page.

Version 0.11.0 of the Ixion library has been just released. You can download it from the project’s home page.

Here is the full list of changes since 0.9.1.

• C++11 is a hard requirement.
• implement R1C1 formula name resolver.
• remove boost dependency from the public headers (except for boost::thread).
• fix incorrect life-cycle management of pooled string instances.
• make it buildable on OSX.
• other general code cleanups.
• python
  • correctly catch and translate general_error into python’s, for Document.append_sheet() method.
  • make python module build configurable.
  • add ixion.column_label() to convert numeric column indices into column labels. A1 and R1C1 are supported.

You need to deploy your OpenStack infrastructure with ease and without interruption. Audit your OpenStack environment for known vulnerabilites and quickly remediate them. When your growth creates a necessity to fine tune your storage, compute, and control resources you need to quickly determine your bottlenecks and easily...

https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7837

Manila is the OpenStack shared filesystem service that was announced September 2013. In January 2015 it was labeled as an officially incubated OpenStack program. Now with the current stable release in Liberty, Manila is providing the management of file shares (for example, NFS and CIFS) as a core service to OpenStack. Manila currently works with a variety of vendors, including NetApp, Red Hat Storage (GlusterFS), EMC, IBM GPFS, Hitachi, HPE, and on a base Linux NFS server...

https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7927

https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/8261

I’m pleased to announce the availability of mdds 1.1.0. As always, the source package can be downloaded from the project’s home page.

This release includes the addition of 2 new data structures – trie_map and packed_trie_map, significant performance improvement on sorted_string_map, general bug fixes on some of the existing data structures, enhancement on multi_type_matrix, and support for user-defined event handlers for multi_type_vector.

Huge thanks to Markus Mohrhard for sorted_string_map’s performance improvement as well as the bug fixes and the enhancement on multi_type_matrix’s walk() method.

In addition, thanks to David Tardon, we now use automake as our build system which will simplify the process of package generation and integrity check among other things.

Here is the full list of changes since version 1.0.0:

• all
• switched our build system to using automake.
• packed_trie_map (new)
• new data structure that implements a trie also known as a prefix tree. This implementation requires all key values be known at construction time, after which its content is considered immutable. Internally it packs all its nodes in a single contiguous array for space and lookup efficiencies.
• trie_map (new)
• new data structure that implements a trie. It works similar to packed_trie_map except that this version is mutable.
• multi_type_matrix
• added a variant of walk() that takes the upper-left and lower-right corners to allow walking through a subset of the original matrix.
• multi_type_vector
• fixed incorrect return values of the increment and decrement operators of in-block iterators. They would previously return a value_type pointer which did not conform to the behaviors of STL iterators.
• added support for custom event handlers for element block acquisitions and releases.
• flat_segment_tree
• fixed incorrect return values of the increment and decrement operators of its leaf-node iterators as in multi_type_vector’s fix.
• sorted_string_map
• significantly improved the performance of its find() method by switching from using linear search to using binary search. The improvement is especially visible with a large number of elements.

Documentation

I’ve also added Doxygen documentation for this library for those who are more used to the Doxygen style comprehensive code documentation. The official API documentation has also received some love in the code examples for multi_type_vector. I plan on adding more code examples to the documentation as time permits.

I recently had a discussion on Facebook in the openSUSE users group at Facebook about the reasons why we prefer openSUSE over other distributions like Ubuntu.

An almost complete list of openSUSE's benefits

Installation

One of the first benefits of openSUSE you will recognize is the Installation process. You can easily hit the Next button a few times, give some basic inputs like the username of your account and end up with a fully featured and functional copy of openSUSE on your hard...