Home Home
Sign up | Login

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 »

Workshop on Open Source for Embedded System Development

July 1st, 2014 by

GUJARAT TECHNOLOGICAL UNIVERSITY
Open Source Technologies Club organizes One Day workshop on Open Source for Embedded System Development

On 5th July 2014

At Bhaskaracharya Institute for Space Applications and Geo-informatics, ,Gandhinagar

Faculty Members from GTU Affiliated Colleges are invited to participate in this workshop.

More information here

Report of the event and pictures

 

osc: speedup update of a project working copy

June 26th, 2014 by

Hi,

recently, I pushed a commit that speeds up the update of an osc project
working copy, if most of the packages in the working copy are already up to
date (that is no update has to be performed).
The following table shows the improvements of the new code (in terms of
wall-clock time). Both project working copies were already up to date
and the packages in the home:Marcus_H project were unexpanded.

project       # number of packages  #    old code # new code
home:Marcus_H                   66        51.135s    10.653s
d:l:r:e                       1245     7:07.07min    17.804s

(the numbers for the devel:languages:ruby:extensions (d:l:r:e) project
were kindly provided by darix – thanks!).

Technically, we just reduced the number of http requests for packages
that are already up to date by using the backend’s getprojectsourceinfo
call (/source/project?view=info&package=pkg_1…&package=pkg_n).
Note: currently, such a reduction is not possible for packages that have
a _service file, because a small change in the backend is needed (see [1]).
Consequently, there are no time improvements for such packages.

If you want to test the new code, use the osc package from the
devel:tools:scm repo (http://download.opensuse.org/repositories/devel:/tools:/scm/).
Feedback is always welcome! :)

Next, my plan is to improve the speed of an update of a single package
working copy (again by reducing the number of http requests).

[1] http://lists.opensuse.org/opensuse-buildservice/2014-06/msg00067.html