Back in March, Christian Stankowic analysed Spacewalk 2.1 and its new user interface look and feel. He asked himself how SUSE Manager would look like:

I really appreciate this update! The new interface looks more clean and well-designed than the elderly look. I’m really interested to see what the implementation in SUSE Manager will look like and whether Red Hat Satellite will also get a new design.

Well, now you can see it yourself, as SUSE Manager 2.1 is out!

New features include, among others:

• A slick setup wizard to guide administrators through the basic steps needed to configure a fully operational SUSE Manager: Proxy, Novell Mirror Credentials, SUSE Products.

• Action chaining that lets administrators bundle and execute related management actions in one step
• Unattended bare-metal provisioning that allows customers to power on and off and reboot bare-metal systems via the IPMI (Intelligent Platform Management Interface) protocol.
• OpenScap (the open source implementation of SCAP – Security Content Automation Protocol), a standardized approach to maintaining enterprise system security.

• CVE Auditing. This feature goes beyond telling you pending patches but instead assisting you to assign the right content to your systems: what vulnerabilities affect you where you haven’t yet assigned the right channels. For example, you may have an affected system in production. CVE Auditing may tell you that you can fix the security issue by assigning the stage channel to a system.

• Locks packages on the server which are then enforced on the client side (eg. if you login via ssh to the client).

And of course, most of the work is already merged upstream.

Recently, Saurabh Sood suggested me to blog more often, and this an attempt yet again to write more often. Off course, what I may write may or may not be appealing to others, but then its my area

Anyway, the past few weeks, I have written a bit of code, a bit actually means a teeny weeny bit, but hey, the good news is SaX3 is completely localized / internationalized now and this will be shown in the next openSUSE release.

Offcourse, if you are a translator, you can help me out by translating the files at https://github.com/openSUSE/sax3/tree/master/src/translation and by sending an email with translated files, I will include it in the upcoming repos, I will also try to get it to the openSUSE translation repository, so that lives become easier for all of us.

Other than that, we have a new contributor at openSUSE and who is already writing great articles for the news team, thanks a lot Nenad
There are plenty of things down the line and I hope I will update the same in the coming weeks,  till then cya people..

Hello openSUSE translators everywhere,

You love gtranslator and want to use it to localize openSUSE to your native language, but hey! there is a slight problem when you try to create a local translation memory to ease your task. It crashes!

Well, I don’t know if it really happens in Gnome, but in XFCE, when it is the only desktop environment in a default openSUSE installation (of which I am a very happy user), it definitely happens.

So, there is nothing wrong with the program itself. It is more of a packaging issue and a missing runtime dependency. A fix should be on the run (let’s see if I did it correctly on the OBS).

However, until the fix is accepted you can just sudo zypper install libgda-5_0-sqlite and it should crash no more. This fix should work in openSUSE 12.3. Please, drop me a note if it doesn’t work for you.

Have fun translating,
efagra

I have written quite some Ruby code recently which worked with files in a file system somehow. Reading, writing, manipulating data stored in a file, or in a set of files in a directory, or in a set of directories, or one of the countless variations of this. There is a lot of code like this, and one question always is: How do I write unit tests for this code?

You need test files as input for tests. You need space to write files, which is cleaned up after the test. You often have series of tests which use similar but not quite identical sets of files. Doing all this in unit tests is inconvenient, as you usually can't just do it in the test code, but have to interface with some actual file system.

One approach is to stub all the interfaces dealing with the file system and fake them with test code, which mirrors the desired environment without ever hitting a real file system. FakeFS is one low-level way of doing this. You can also often do something similar on a higher level stubbing functions of your own code, when interaction with the file system is well encapsulated.

But this approach often is too limited. When you are using external libraries or calling external tools, you don't have access to the code interacting with the file system, so you can't stub it. You also limit your test coverage, as the actual interaction with the file system usually is an essential part. Finally it can be quite some work to isolate, separate, and fake the code, which interacts with files.

So we do want to have a better solution, right?

My solution is GivenFilesystem. It is a set of helpers for use in RSpec-based tests. It also provides a basic class, if you prefer more direct access or want to integrate it with some other test framework.


GivenFilesystem provides a simple and convenient way to create test files and directories. These can be structures as complex as needed. They are built up from test data you store as part of your tests. But you only need to store the data once, and create different scenarios using this data in your unit test code. GivenFilesystem also provides an easy way to create temporary locations in the file system for writing files. These are automatically cleaned up after the tests.

Here is an example of some code creating test files (see the details in the docs):

path = given_directory "mydir" do
  given_directory "one" do
    given_file "myfile"
    given_file "myotherfile"
  end
  given_directory "two" do
    given_file "myfile2", :from => "myfile"
  end
end

The only assumption is that you have a way to specify the path your code uses to read and write files. There is no magic behind the scenes, which replaces internal code accessing the file system, but your code has to be structured in a way that you can tell it where files are. Usually this is something you want to have anyway, and which gives nicely structured code.

So if you come to the point, where you need to set up files for unit tests, or worry about cleaning up files written by your tests, consider giving GivenFilesystem a try. It has made my life a little bit more simple and convenient, maybe it can do the same for you.

I put some effort into polishing GivenFilesystem. It comes with tests, has full test coverage, and clean code. This turned out quite nicely, also thanks to the magic of code review.

Get the gem, read the docs, get started.

Feedback and other contributions are always welcome. Or if you just want to talk about it, simply drop me an email.

Imagino que por mi tipo de hardware, pulseaudio no detecta cuando enchufo el microfono, ni tampoco detecta en donde lo enchufo, si en el panel frontal y posterior. Entonces siempre al reniciar me aparece como «Dispositivo de entrada» el Line-in, y no el front-mic que siempre uso. He aquí la magia para que siempre mantenga…Más

Herewith I announce the availability of the new Kraft release 0.55.

It was finished today and fixes two issues that came up after the release of the previous version: A compile fix for compiling Kraft against the latest version of ctemplate, which did not work out of the box with Kraft 0.54. The other fix is a fail in generating PDF documents which is a pretty severe problem for Kraft. Both is now working well with the new version 0.55 which can be downloaded here.

Thanks a lot to the Kraft community for testing!

If you find other problems, want to give feedback or seek help, please see here how to proceed. Thanks!

AMD Catalyst 14.6 Beta V1.0 (fglrx 14.20) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-14.6-betav1.0.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.13. Zum Packaging Skript wurde ein Patch hinzugefügt und unterstützt bis Kernel 3.15

Nachfolgende Release Notes von AMD zum AMD Catalyst 14.6 Beta V1.0:

Neue Features:

• Ubuntu 14.04 support
• Install improvements
• Package and distribution generation options; recommend options set by default
• Help user install generated distribution package once created
• Pop-up messages to help guide users through the install process
• Identifying and installation of pre-requisites

Folgende Probleme sind im Treiber behoben worden:

• [399454] : Witcher 2 – Resolves random lock-up seen when launching the application
• [398826] : Screen corruption when connect external monitor to some PowerXpress A+I platform
• [396719] : X crash when do rotation with Tear Free Desktop enabled
• [397810] : Failure on exit of OpenGL programs
• [398424] : Error message when run clinfo in console mode
• [396098] : Blank screen when hotplug HDMI monitor from MST hub
• [396795] : System hang after resume from S3/S4 in High Performance mode on PowerXpress A+I platform
• [396870] : Garbage on the bottom right corner of screen before boot into login UI during restart
• [394504] : Segmentation fault when run ETQW

Offene Probleme:

• DOTA 2 may hang while playing on the AMD Radeon 7900 or AMD Radeon R9 280X
• Witcher 2 exhibits intermittent corruption when swinging sword in the Arena

Link: AMD Catalyst 14.6 Beta for Linux Release Notes

Folgende Steam-Spiele habe ich getestet und laufen mit diesem Treiber:

• Amnesia: The Dark Descent
• Breach & Clear
• Cities in Motion 2
• Creeper World III: Arc Eternal
• Crusader Kings II
• Darwinia
• Defcon
• Duke Nukem 3D: Megaton Edition
• Euro Trucker Simulator
• Europa Universalis IV
• Game Dev Tycoon
• Galcon Fusion
• Galcon Legends
• Half-Life 2: Deathmatch
• Half-Life 2: Lost Coast
• Hotel Miami
• Kerbal Space Program
• Kinetic Void
• Painkiller Hell & Damnation
• Prison Architect
• Project Zomboid
• Symphony (Hinweis: Das Spiel ist etwas instabil)
• Shadow Warrior Classic Redux
• Skulls of the Shogun
• Strike Suit Zero
• Survivor Squad
• Wargame: AirLand Battle
• Wargame: European Escalation

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön.

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. openSUSE bringt bereits für ältere Grafikkarten den freien Radeon-Treiber mit. Um regelmäßig Verbesserungen am freien Radeon-Treiber zu erhalten, ist die Installation eines neuen Kernel unumgänglich.

Downloads:

• Skript: makerpm-amd-14.6-betav1.0.sh
• SHA1: makerpm-amd-14.6-betav1.0.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

Über das makerpm-amd-Skript

Das Skript makerpm-amd-14.6-betav1.0.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b	Nur das RPM-Package bauen (Standard)
-c <type>	Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d	Nur den AMD-Installer downloaden
-i	Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no>	Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw	Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no>	den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report	erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall	entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport	wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück.
-h	Die Hilfe anzeigen lassen
-V	Version des Skript anzeigen

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-14.6-betav1.0.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-14.6-betav1.0.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

Fosscomm is the annual conference of the Greek Free Software communities. This year the event took place on May 3 & 4 at the Technological Educational Institute(TEI) of Lamia. This time we organized the road trip with Pavlos Ratis (dastergon) from Thessaloniki.

##openSUSE-el

Most of the greek community was recuperating from the long and tedious journey to Dubrovnik, Croatia for the Annual openSUSE conference where some had a series of presentations while the rest helped as volunteers there. That left me practically alone at Fosscomm to have a talk and man a booth which we co-hosted with dastergon as a multi-community booth (openSUSE/Gentoo).

The booth had a wide assortment of stickers, flyers, CDs and DVDs for both openSUSE and Gentoo.
My talk, entitled “Enlightening Lizards: Getting the Enlightenment experience & Being part of the effort”, was about the effort we put for packaging the environment and associated libraries and the current status in recent openSUSE versions.
I started the talk with a brief historical overview about the Enlightenment project, then moved on to an introduction of the Enlightenment Foundation Libraries (EFL) and the Enlightenment window manager to conclude with a briefing of the team members and plans for the future.

Finally, I talked about how we coordinate the work in distribution level and how to work with upstream so that we can provide a full and enjoyable environment for openSUSE users.

##Gentoo-el

The Gentoo community had 2 presentations one by dastergon, entitled “Btrfs: A next generation filesystem”, in 35’ Pavlos managed to get us up to date with the current developments regarding btrfs, the ecosystem that has developed around it, its users the architecture and workings of the filesystem.

The second presentation was one that is more upstream in character and also one I personally consider far more important. This one Pavlos co-presented with Panayiotis Christopoulos (pchrist) they talked about package maintainership and the distinction between distribution and upstream level packaging. In quite an effective and coherent manner they switched places each talking about a specific environment and its tooling and packaging tactics.
Finally after having switched quite a few distros before they both ended up as Gentoo users (later Gentoo developers) they gave a handful of tips about packaging and working with upstreams gathered from their experience with said distros and packaging schemes.

##The rest

I spent the rest of the conference at our booth helping people, answering questions and generally socializing and talking with old friends.

Congratulations to the people from the TEI of Lamia for the organization! :)

Here is their photostream on flickr

• Update: Fixed Gentoo-el photos.

It is not without emotion that the Document Liberation Project announces today the first release of the new framework library, librevenge-0.0.0. This release means that the API of librevenge is now set into a stone (at least until the 0.1.x series) and thus the library can be used by willing filter-writers.

You might be familiar with some aspects of the librevenge framework from this blog or from this FOSDEM 2014 presentation. David Tardon started a nice serie of articles explaining how to use the framework. So, there are no valid excuses remaining not to use it and not to contribute to the world domination that is the ultimate destiny of the Document Liberation Project.

Standing on the shoulders of giants

But the first release of a new framework would be empty without mentioning those on shoulder of whom we stand. First we would love to thank Will Lachance and Mark Maurer for having started more then 10 years ago the development of libwpd. It is this library and its wise interface design that allowed us to move incrementally to the current framework. Thank you guys, you know that without you we would be nowhere!

Besides your servant, David Tardon, and Valek Filipov, we would love to single out a discrete person, who speaks little but codes a lot. It is Laurent Alonso, without whom we would never be able to recover a huge amount of old MacIntosh documents. We thank equally to all our past and present Google Summer of Code students, without whom the road would be much more thorny.

LibreOffice and The Document Foundation

It would be a very big mistake if we did not thank the project from which we all originate, the LibreOffice project. The community gravitating around LibreOffice creates is caring, encouraging and creates the right environment to foster innovation.

Last but not least, our thanks go to The Document Foundation that did not hesitate to take us under its umbrella and provide all the necessary institutional support.

How to contribute

Now a new phase starts and you can be part of it! There are many ways to contribute. You drop by at the #documentliberation-dev channel at irc.freenode.net. There will always be someone to help you to join this exciting journey.

For more information about our activities, follow @DocLiberation on twitter, Join our Google plus community or like us on Facebook.

Here we are, at the beginning of a great summer!

This time, Google has given plenty of slots to the GNOME project, so we could accept many participants, including 3 brilliant students to work on the Banshee project. In case they haven't blogged about it, or didn't give much detail, I'll elaborate a bit about what they will be aiming to do these months:

• Nicholas Little will be working on creating a new extension for Bluetooth synchronization, and if time permits, refactoring our MTP support. In regards to the latter, if you have an Android phone you might have experienced some bugs getting it to work with Banshee lately (our MassStorage synchronization support is great, but the latest versions of Android have been deprecating this mode in favour of MTP, which we never supported very well); we have been working hard on fixing them, but Nicholas is going to try to give it that extra push at the end of the summer, which I'm confident he will do very well (he was the developer who brought Symbian support for the masses -or rather, for his Nokia N95 ;) -, on Banshee 2.9.0). And you may be wondering, why do we need Bluetooth sync? Well, we understand that it's much slower than USB or Wifi, but:

1. USB can work for the first sync, but whenever you update your library, I never remember to connect my phone again with my cable, or I'm too lazy to do it. Now imagine that whenever your phone is near your computer (and of course if you have Banshee running), they could negotiate together to update the sync without the need of moving a finger!
2. Wifi could work also for the use case I just explained, but getting Wifi to work, compared to Bluetooth, would involve creating an app for the phone that could talk with Banshee. And we all know what are the problems associated with that: we would need to be cross-platform for at least the 3 main mobile platforms out there (well, iOS wouldn't even work neither with this nor with Bluetooth, because there are no public APIs to integrate with the music database of the OS, sigh iTunes...), and that means a lot of maintenance burden (even if we choose a same-language native platform like Xamarin), and a user experience that is not so seamless (as it would require the user to install an app first).

• Marcin Kolny, which has convinced us that he will do a great job given his great patches and the fact that he's already very involved in opensource (maintainer of C++ bindings to GStreamer if I recall correctly), will be working on integration with AcoustID. To summarize it very bluntly, AcoustID is the open-source alternative to Shazam, so thanks to this, if you have many tracks in your library which didn't get ripped properly with tags, or you got from some friend which is not very metadata-driven ;) then you will be able to fix this situation! We will be likely reusing the MetadataFixer extension that we already have in Banshee, to not reinvent the UI wheel.

• Dmitriy Petukhov, a very motivated Russian student, will be helping us get two extensions in shape, which were developed in the last GSoC (more details about this in my previous blog post), but were not ready for mainstream yet. The FanArt.TV extension, which retrieves artist logos and shows them next to your album icons, needs some caching (we could even violate FanArt.TV service's ToS if we don't do this) and UI polish (our ListView widget doesn't play well with differently-sized images, so we need to modify this custom GTK widget to allow rendering rows with different heights). The SongKick extension works great, but also needs caching, and it especially needs GeoLocation to maybe even work autonomously (imagine, you don't even know what SongKick is, and because you installed the banshee-community-extensions package of your distro, you suddenly get told that one of your favorite bands is soon playing a gig near your city!).

As you can see, most things are work under-the-hood this year, with little UI work. That's good for me because I'm no design expert. However, there is one area which we could do with some help: the new backgound tasks that will be implemented will need a way to notify the user (i.e. SongKick: when a new gig is discovered; AcoustID: when new/better metadata is found). In this respect, maybe Hylke Bons (our chief designer for the last Gnome .NET hackfest) and Garrett LeSage (assistance that Hylke proposed now to avoid getting himself swamped!) will be able to help! (BTW, if you're interested in participating in this year's Gnome .NET hackfest, message David Nielsen, which started to plan it recently.)

I'm very happy about starting the mentoring of these projects this year. And I'm specially jealous about my students... I became mentor of GSoC myself without being GSoC student first! (Maybe I should switch roles in the future?)

Wish them good luck! It was actually just yesterday when GSoC really started! (gotta love mondays)

UPDATE: Fixed embarrassing typo: I meant AcoustID, not OpenID!