Yesterday Alex Fiestas showed on his blog a video of a recent development version of the KScreen library, created to handle easily multiple monitor setups in KDE, almost in an “automagic” way. As this is a project where configurations and setups are highly heterogeneous, a lot of testing is required to ensure things work reliably.

Of course, you cannot ask a developer to have all sorts of screen combinations, but remember one of the strengths of FOSS: “many eyes make bugs shallow”. And that’s why the KDE team prepared testing packages for KScreen for openSUSE users.

Before you jump to the repository, bear in mind that these packages are for testing and bug reporting purposes. They can potentially cause unwanted effects, connect your displays to some random alien homeland, make your house blow up, and so on.

If you are still daring, you can find them in the KDE:Unstable:Playground repository. Install both the libkscreen and kscreen packages, and you’ll see a new entry in System Settings when you go to the monitor configuration control panel.

Make sure you report all bugs (along with detailed information on monitor setups etc) to bugs.kde.org.

Let the testing commence!

One of the first things I did when I joined the Cloud team at SUSE was to start porting DevStack to openSUSE. DevStack is a set of shell scripts to build complete OpenStack development environments. It is useful to create a small OpenStack environment that will be used for hacking, testing, etc. and is therefore primarily used for upstream development. Getting this to work on openSUSE seemed like a logical first step before doing more OpenStack work. I got things working pretty quickly, but for various reasons, this all stayed in a personal branch of mine (except for a few preliminary patches).

A few weeks ago, I got time for DevStack again. So I rebased my branch, cleaned up everything, and started submitting the patches. After reviews from Sean Dague and Dean Troyer (and some patch rewriting to address the issues that were raised), the openSUSE support landed in master. A few other people tested it, and nobody has been hitting any major issue, so yesterday, I finally submitted the patch to make openSUSE 12.2 a supported distribution. Now you can play with DevStack on openSUSE!

I wrote some documentation for DevStack on openSUSE if you want to get more details on how to use it. But I guess it wouldn't hurt to show how easy it is to setup your own OpenStack environment this way...

I'm shamelessly stealing instructions from the single VM DevStack guide to show you the very short version. Just run the following in an openSUSE virtual machine (do not run this on your main system unless you're 100% sure it's what you want: DevStack is a little bit too invasive right now; see Daniel's analysis on this topic):

zypper in git-core
git clone https://github.com/openstack-dev/devstack.git
cd devstack
echo ADMIN_PASSWORD=password > localrc
echo MYSQL_PASSWORD=password >> localrc
echo RABBIT_PASSWORD=password >> localrc
echo SERVICE_PASSWORD=password >> localrc
echo SERVICE_TOKEN=tokentoken >> localrc
echo FLAT_INTERFACE=br100 >> localrc
./stack.sh

(You'll actually need to call FORCE=yes ./stack.sh until the patch mentioned above gets in.)

And there you go, you have OpenStack running! That was quite easy, right? :-) You can connect to the web dashboard (horizon) or use the command line tools (hint: source openrc will setup the proper environment variables for you). Here's a few commands you can use to get started:

source openrc
glance image-list # find out which image is available
nova boot --image cirros-0.3.0-x86_64-uec --flavor m1.tiny cirros-test # start an instance of one specific image
nova list # see what instances are in the cloud

So go ahead, read the documentation, play with all this, and enjoy DevStack on openSUSE!

2012 is slowly coming to an end and we all are looking forward to a few silent days around Christmas. But we did not want to leave to holidays without adding another thing to your vacation experience: I am happy to announce the first beta of the upcoming ownCloud Client release 1.2.0, ready now for you to test and enjoy under the tree.

This is the first build with the new things we did in Berlin a couple of weeks ago, you will

• discover that there is much better error reporting if something goes wrong.
• probably feel like it syncs faster, yes faster.
• see that there are less HTTP requests to the server for a single sync run.
• don’t see any issues with MacOSX and funny characters in filenames any more.
• recognize a new icon set, which is not finalized yet (actually not all sizes are there, thats why the status dialog looks a bit funny) but we thought its nice to already add it to the beta. It should fit nicely into your operating system environment.
• realize that this client comes with a cross platform file system watcher on clientside, so no polling any more.
• have your password stored in a secure keychain on all platforms since we added qtkeychain to the client.

Maybe there is more, but we thought that’s already a nice beta release.

Please find packages for MacOSX, Windows and Linuxes. Note, not all packages are finished yet. If the one for your distro is missing, please come back later, or even better - speak up at packaging@owncloud.org and help fixing :)

Of course you also should note that this is an early beta and you would not want to use it without a good backup of your data and only on your test account without important data.

We would appreciate if you let us know your experience on the mailinglist. If you find problems, please report it to the client’s bugtracker mentioning client- and server versions and at best with useful logs.

With that we are happily vanishing to spend some time away from the computer, looking back on a very exciting and very busy year, working on an interesting topic with a lot of nice people.

Thanks and best Season’s Greetings!

The release of KDE SC 4.10 is approaching and RC1 packages are now available for openSUSE 12.2 and Factory users from the KDE:Distro:Factory repo aka KDF. You can test them and report packaging and openSUSE-specific bugs on IRC (#opensuse-kde) or the mailinglist (opensuse-kde). Everything else should be filed upstream at bugs.kde.org.

Big thanks to everybody involved!

KDE:Release:410 aka KR410 will be set-up shortly and published as soon as KDE officially releases the final packages for KDE SC 4.10.

Those using KR49 will have noticed that KDE SC 4.9.4 got already published and 4.9.5 will follow at the end of this month.

The KDE team is also proud to congratulate Raymond Wooninck on his election to the openSUSE board! Given his constant commitment to packaging KDE SC and other apps for openSUSE over the last years, I am sure the openSUSE community will profit from his work as member of the board. Congratulations also to Robert Schweikert, the second candidate who got elected to the openSUSE board.

Short before Christmas here is another present for you: After more than one year without release I am happy to announce the availability of Kraft 0.50, the latest version of the KDE software for easy quote and invoice management.

The most important change is that now multiple tax rates are supported within one document. That means that within e.g. one invoice items without tax, with reduced and full tax rate are supported. The sum calculation takes that in consideration properly. That enables Kraft for even more usecases.

Apart from that, a lot of bug fixes and improvements happened, read more details on the Kraft Homepage.

Sources and binary packages for various Linux distributions are available from the Download Page or will appear there soon.

This release is nice progress for Kraft and I hope you have fun and success with the new release. Thanks all who contributed to Kraft! I am looking forward to getting your feedback!

Hi,

as of late each line in the buildlog is prefixed with a “timestamp”. If you do not need
this information just run “osc bl –strip-time …” (this will remove the leading timestamp).
Additionally there’s a new config option to permanently enable the stripping:
osc config general buildlog_strip_time 1
(by default “buildlog_strip_time” is set to False).
The “–strip-time” option is also supported by the “localbuildlog” and “remotebuildlog”
commands.

Marcus

openSUSE is migrating to the use of systemd for the upcoming 12.3 version, given the difficulties that emerged in trying to co-maintain two different init systems (SysV + systemd). While I am not going into the details of this choice (I leave this to more informed people), this has some consequences for software higher in the stack.

As ConsoleKit is deprecated, systemd offers its own daemon to keep track of sessions and assigned seats in a system. However, the KDE Workspaces rely on ConsoleKit to handle user switching, reboot, shutdown and a lot of ther things. Removing ConsoleKit would mean that users would suffer feature loss. On the other hand, with something that’s been deprecated and no longer actively worked on, you have issues with maintenance.

The solution the openSUSE KDE team took was to introduce support for systemd in the KDE Workspaces (this was mainly done by Raymond “tittiatcoke” Wooninck). The task was much easier than it seemed at first, because Red Hat people have already made patches to support systemd in Fedora. The part from the KDE team was to take these patches, test them for a few months (I’ve been running them smoothly for quite a while, along with others in the group), then apply them to the packages for the next version of the distribution. We’re currently testing a patch from Fedora that allows either ConsoleKit or systemd support runtime, without needing a compile-time dependency. Once sufficient data are available, it will be pushed to the distro packages.

Other patches were directly pushed upstream by Red Hat engineers, and include a better interaction between the workspaces’ power management infrastructure and systemd itself.

In short, the next version of openSUSE (12.3) should be fully capable of handling systemd. Of course, to ensure it’s as bug free as possible it requires testing, so why don’t you jump into the fray and share your experience with us?

In a recent developer vote, the php project decided to deprecate the mysql extension in PHP 5.5 and finally remove it from the main PHP project. It may or may not be available for a longer period as a PECL extension.

The mysql extension has long been superseded by two more powerful extensions, PDO/Mysql and mysqli (improved). For years, the older extension has not received any new features and the developers kept it around just to keep compatibility with old code. Framework and application developers are now urged to update their code to use one of the alternative mysql APIs. There are a lot of old code snippets and tutorials around which describe the old API. Eventually, this code will begin to throw warnings and finally stop to work.

Developers discussed the impact of this move on end users. While it might be shocking to see hordes of old installations break just because the hoster updates his PHP version, there is no need to panic. Most hosters have not clenbuterol hydroklorid clen kjope even upgraded to the recent PHP 5.4 release and it might be years to go until PHP 5.6 finally hits enterprise distributions like SLES or RHEL. Additionally, distributors and hosters might opt to provide the PECL version of the mysql extension for backward compatibility. There is enough time left for developers and end users to react on the coming change.

More on the deprecation vote