Home Home
Sign up | Login

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
Read the rest of this entry »

Going Factorial

August 22nd, 2014 by

After the unclear status of openSUSE direction, the news about creating a rolling distro was a surprise, but a good one. The revised development model of Factory looks better and though it’s too early to make conclusions, works for me. The transition was straightforward, following the wiki recommendations and simply pointing all repository URLs from 13.1, verifying the proposed changes.

I’m not using a clean 13.1 installation, but a mixture of base distro packages, Tumbleweed, Kernel:stable, packman, and a few devel projects. This requires careful setting of repository prorities and reviewing each zypper dup round, I’m certainly not recommending this to inexperienced users.

Besides the OBS-provided projects, I’ve been maintaining a few packages in my home project. I admit that the right way is to submit the packages to the distro, but laziness and lack of time to the rescue.

The release cycle of openSUSE suits better users that do not tweak their systems too often and expect it to just work. But there are developers who need newer version, or users who simply want to install newer versions. This is where Tumbleweed fills the gap.

One of the visible differences between Tumbleweed and the rolling Factory is number of packages. Due to a small number of packages maintained in my home project, I did not bother submitting them to Tumbleweed. Also because they do not fit very well to its intended package selection. This comprises benchmarking tools or some tweaks and experiments with random packages.

With the announcement of rolling Factory, I’ve decided to clean up all my local changes and forward them to Factory projects. This also ended the period where openSUSE was did not have a clear direction, based on my observations. And I like the new direction, I do want to use a rolling distro, and I’m going to spend more time on updating packages I use. Let’s get rolling!

Javascript tools in openSUSE round 2: js-beautify

August 18th, 2014 by

I’ve been talking about how code construction is necessary to your coding project. With Javascript obfuscation or making code shine is more important than ever. There will be many many eyes looking at your code and see if it’s worth of nothing. After getting friend with js-beautify there ain’t no excuse to keep you ugly looking code laying around. Read the rest of this entry »

BETA Proprietary AMD/ATI Catalyst fglrx 14.20 BETA v1.0 July 11 2014 rpm are released for several openSUSE version

August 17th, 2014 by

Back on line after several weeks in late, I’ve tried from my best to resolve the case of Factory rolling releases.

After some hacks on the latest Sebastian Siebert beta version (Made in June), I’ve been able to build now BETA fglrx rpm for several openSUSE version.

one day AMD will release or not a stable version. (On my side I prefer to see more efforts made on the free radeon driver.)

Notice

This release concern only owners of radeon HD5xxx or above. All owner of HD2xx and HD4xx are really encouraged to use the free radeon driver (which received a lot of improvement in 3.11+ kernels)

This is experimental & BETA software, it could fix issues you encountered (FGLRX not working for openSUSE 13.1),

What happen to Sebastian

I would like to have some news about Sebastian Siebert, he’s a essential key for future updates.
This time I was able (even with several weeks in late) to adjust the script to create a build for openSUSE Factory.
But one day something will broke in kernel or somewhere else, and we all need to find a way to fix it.

So if you’re in touch with Sebastian, could you drop me a comment or a private mail?

I would like to continue the good support we created 3.5 years ago, or at least knowning if I’m orphan :-(

Beta Repository

To make things clear about the status of the drivers, it will not be published under the normal stable repository http://geeko.ioda.net/mirror/amd-fglrx.
I’ve created some times ago a beta repository located at http://geeko.ioda.net/mirror/amd-fglrx-beta.
The FGLRX 14.20 beta1 rpm are released for openSUSE version 12.3, 13.1 (+Tumbleweed), Factory

Signer of package my generic builder gpg key at Ioda-Net. (gpg key id 65BE584C)

For those interested by contributing or patches done to last Sebastian version, the raw-src on the server contain all the material used
http://geeko.ioda.net/mirror/amd-fglrx-beta/raw-src.

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly when new stable version will be published. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta.

Read the rest of this entry »

Fosdem proposals for main track presentations and developer rooms

August 3rd, 2014 by

Fosdem now invite proposals for main track presentations and developer rooms.

FOSDEM offers open source developers a place to meet, share ideas and collaborate. Renowned for being highly developer-oriented, the event brings together some 5000+ geeks from all over the world.

The fifteenth edition will take place on Saturday 31 January and Sunday 1 February 2015 at the usual location: ULB Campus Solbosch in Brussels.

We now invite proposals for main track presentations and developer rooms.

Previous editions have featured tracks centered around security, operating system development, community building, and many other topics. Presentations are expected to be 50 minutes long and should cater to a varied technical audience. The conference covers travel expenses and arranges accommodation for accepted main track speakers.

Developer rooms are assigned to self-organizing groups to work together on open source projects, to discuss topics relevant to a broader subset of the community, etc. Content may be scheduled in any format, subject to approval. Popular formats include presentation tracks, hacking sessions and panel discussions. Proposals involving collaboration across project or domain boundaries are strongly encouraged.

Proposals for main track presentations should be submitted using Pentabarf:

https://penta.fosdem.org/submission/

Developer room proposals should be emailed to devrooms@fosdem.org and be as detailed as possible. In particular, coordinators should indicate their affinity with the topic being proposed and provide a rough idea of the content they plan to schedule.

Key dates:

15 September
deadline for developer room proposals

1 October
deadline for main track proposals
accepted developer rooms announced

https://fosdem.org/2015/news/2014-07-01-call-for-participation/

OpenStack Infra/QA Meetup

July 23rd, 2014 by

Last week, around 30 people from around the world met in Darmstadt, Germany to discuss various things about OpenStack and its automatic testing mechanisms (CI).
The meeting was well-organized by Marc Koderer from Deutsche Telekom.
We were shown plans of what the Telekom intends to do with virtualization in general and OpenStack in particular and the most interesting one to me was to run clouds in dozens of datacenters across Germany, but have a single API for users to access.
There were some introductory sessions about the use of git review and gerrit, that mostly had things I (and I guess the majority of the others) already learned over the years. It included some new parts such as tracking “specs” – specifications (.rst files) in gerrit with proper review by the core reviewers, so that proper processes could already be applied in the design phase to ensure the project is moving in the right direction.

On the second day we learned that the infra team manages servers with puppet, about jenkins-job-builder (jjb) that creates around 4000 jobs from yaml templates. We learned about nodepool that keeps some VMs ready so that jobs in need will not have to wait for them to boot. 180-800 instances is quite an impressive number.
And then we spent three days on discussing and hacking things, the topics and outcomes of which you can find in the etherpad linked from the wiki page.
I got my first infra patch merged, and a SUSE Cloud CI account setup, so that in the future we can test devstack+tempest on openSUSE and have it comment in Gerrit. And maybe some day we can even have a test to deploy crowbar+openstack from git (including the patch from an open review) to provide useful feedback, but for that we might first want to move crowbar (which is consisting of dozens of repos – one for each module) to stackforge – which is the openstack-provided Gerrit hosting.

see also: pleia2′s post

Overall for me it was a nice experience to work together with all these smart people and we certainly had a lot of fun

Updated openSUSE-Edu-li-f-e-gnome-classic

July 20th, 2014 by

Here is updated openSUSE-Edu-li-f-e-gnome-classic iso, this update include GNOME 3.12, official openSUSE updates till date, and it brings back Sugar.

Download ISO | MD5 | Alternate download and mirrors

Previous release announcement.

Fosdem 2015 – 31st January / 1st February – Brussel : call

July 6th, 2014 by

I’m relaying an important information about Fosdem. So people can start to organize a big openSUSE presence next year.

FOSDEM offers open source developers a place to meet, share ideas and
collaborate. Renowned for being highly developer-oriented, the event
brings together some 5000+ geeks from all over the world.

The fifteenth edition will take place on Saturday 31 January and Sunday
1 February 2015 at the usual location: ULB Campus Solbosch in Brussels.

We now invite proposals for main track presentations and developer rooms.

Previous editions have featured tracks centered around security,
operating system development, community building, and many other topics.
Presentations are expected to be 50 minutes long and should cater to a
varied technical audience. The conference covers travel expenses and
arranges accommodation for accepted main track speakers.

Developer rooms are assigned to self-organising groups to work together
on open source projects, to discuss topics relevant to a broader subset
of the community, etc. Content may be scheduled in any format, subject
to approval. Popular formats include presentation tracks, hacking
sessions and panel discussions. Proposals involving collaboration
across project or domain boundaries are strongly encouraged.

Proposals for main track presentations should be submitted using
Pentabarf:

https://penta.fosdem.org/submission/

Developer room proposals should be emailed to and
be as detailed as possible. In particular, coordinators should indicate
their affinity with the topic being proposed and provide a rough idea of
the content they plan to schedule.

Key dates:

15 September
– deadline for developer room proposals
1 October
– deadline for main track proposals
– accepted developer rooms announced


Philip Paeps

Javascript tools in openSUSE round 1: JSHint

July 2nd, 2014 by

Node.js is not getting as much attention in openSUSE community as it’s gaining foot in development world.  Node.js is not just fancy buzz word that I just to be couple years back. There is plethora of libraries and tools that you can use for Node.js development or web-coding. I have been in this Nnode.js dependency hell (ok you can use npm if you like but if you like to make RPM-files you are in trouble) for a while but now I figured out most troubles and start using new tools! I copied most Node.js packaging stuff from Fedora as like Java Javascript is first class citizen of their ecosystem. I also added packages that were missing and updated and added and updated. Read the rest of this entry »