Home Home > 2014 > 08 > 25
Sign up | Login

Archive for August 25th, 2014

LSB Best Effort

August 25th, 2014 by

As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.

Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.

At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.

Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.

Randa meetings – August 2014 – report from a Geeko’s point of view

August 25th, 2014 by
randa-mascot

Konqi Randa Mascot

2 Weeks ago myself and Françoise had joined the [http://www.randa-meetings.ch/ Randa Meeting] in Switzerland.

This event is a full hack-week where between around fifty people, that help to change the world, met together and hack around [http://www.kde.org KDE Community] related stuff. More on
KDE sprint page

I’ve heard about Randa from years, and had seen numerous reports about how Randa hack-week has allowed lots of changes : Plasma, Software collection, etc…

This year, we decided not only to financially sponsor the event, but also be part of as simple helper, with the status of newcomers in the KDE community contributors. Just to check how it goes.
Mario Fux (the organizer) didn’t fake his involvement to make this week a success, in a full open source spirit.



We’re reporting below a number of blog post that have been made during the hackweek.
And as the icing on the cake, you could just watch the video realized during the week.

videomaker
(more…)