Now that the controversial 3.12 tab design has been validated by Apple, we're ready to tackle new challenges with the widgetry™.

Adwaita has grown into a fairly complex theme. We make sure unfocused windows are less eye-grabbing (flat). We provide a less light-polluting variant for visually-heavy content apps (Adwaita:dark). And last but not least we provide a specific widget style for overlay controls (OSD). All this complexity has made Adwaita quite a challenge to maintain and evolve. Since we were to relocate Adwaita directly into gtk+, we had to bite the bullet and perform quite a surgery on it.

There's a number of improvements we aimed to achieve. Limiting the number of distinct colors and making most colors derived makes it easier to adjust the overall feel of the theme and I'm sure 3rd party themers will enjoy this too. Not relying on image assets for majority of the drawing makes the workflow much more flexible as well. Many of the small graphical elements now make use of the icon theme assets so these remain recolorable based on the context, similar to how text is treated.

Benjamin has been working hard to move the theme closer to the familiar CSS box model, further minimizing the reliance on odd property hacks and engines (Adwaita no longer makes use of any engine drawing).

Anything gtk related never happens without the giant help from Matthias, Cosimo and Benjamin, but I have to give extra credits to Lapo Calamandrei, without whom these dark caverns would be impossible for me to enter. Another major piece that I'm grateful for living right inside the toolkit, ready to be brought up any time, is the awesome inspector. Really happy to see it mature and evolve.

We are happy to announce reviving of electronics OBS project. It contains software for developing electronic circuits and firmware for microcontrollers: EDA, programmers, flashers, simulation tools and other.

Some software will be moved from science project to electronics, at least:

• dinotrace
• gEDA
• gerbv
• gnucap
• gtkwave
• iverilog
• KiCad
• ngspice
• PCB
• Qucs

So this packages can be deleted from science repository in future.

This blog was created by openSUSE Science Project to publish some news for openSUSE community. This project provides software for engineering and natural science.

More info:

• Wiki portal
• OBS page

Hi,

It took a bit but I am happy to report that all openSUSE 13.1 images in Amazon EC2, Google Compute Engine and Microsoft Azure public cloud environments have been refreshed. After the latest round of the GNU-TLS and OpenSSL fixes the security was, as usual, extremely efficient in providing fixed packages and these have been available in all cloud images via zypper up since last Friday. As of today the base images available in the public cloud frameworks contain the fixes by default.

In Amazon the new images are as follows:

• ap-northeast-1: ami-79296078
• ap-southeast-1: ami-84a7fbd6
• ap-southeast-2: ami-41cbae7b
• eu-west-1: ami-b56aa4c2
• sa-east-1: ami-bffb54a2
• us-east-1: ami-5e708d36
• us-west-1: ami-16f2f553
• us-west-2: ami-b7097487

In Google compute engine the image name is: opensuse-13-1-v20140609

The old image (opensuse131-v20140417) has been deprecated. To access the image you will need to add –image=opensuse-cloud/global/images/opensuse-13-1-v20140609 as the openSUSE images are not yet fully integrated into the GCE framework. Still working on that part with Google. This image also has upgrades to the google-cloud-sdk package and enable the bq (big-query) command. The gcloud command is still a bit rough around the edges, but the gcutil command should work as expected. Eventually gcutil is going to be deprecated by Google thus there is work to be done to fix the integration issues with the gcloud command. If anyone has time to work on that please send submit request to the google-cloud-sdk package in the Cloud:Tools project in OBS. Unfortunately Google still hasn’t posted the source anywhere for open collaboration . They’ll get there eventually. I will try and push any changes upstream.

In Azure just search for openSUSE in the Gallery, it’s more of a point an click thing

And that’s a wrap. Not certain we will be able to improve on the speed of such fire drill updates, but we’ll try to keep refreshing images as quickly as time allows when critical vulnerabilities in the core libraries get exposed.

Have a lot of fun….

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.

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!

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.