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

Okay, so you've gotten the "Engage" hand-gesture from your Captain to deploy your MonoTouch app to the rest of the crew of the Enterprise. Now all you need to know is which buttons to press on your helm...


Step 1.

First, you'll need to make sure that you've created and installed your "In-House" Distribution Certificate via Apple's iOS Provisioning Portal.


Step 2.

Open your Project Options in MonoDevelop and navigate to the iPhone Bundle Signing section.

If you've got MonoDevelop 3.1.0 or later, you'll be able to set your configuration to:


Otherwise you'll simply have to select your Provisioning Profile manually.

Once you've selected your signing certificate and provisioning profile, click the OK button to dismiss the Project Options dialog.


Step 3.

In MonoDevelop, click on the Build menu and select Archive. This will build your project and archive it in a location that Xcode will be able to see it in its Organizer window.


Step 4.

Launch Xcode and then click on the Window menu and select Organizer. At the top of Xcode's Organizer window, you will see an array of icons. Click on the one labeled Archives.

Find your application in the list of archives and select it.


Step 5.

Now click on the Distribute... button in the top-right area of the window and select Save for Enterprise or Ad-Hoc Deployment.

The next screen will prompt you for your code-signing certificate, providing you with a drop-down menu listing your available options.

Clicking Next will cause an action sheet to slide into view, prompting you for the location to save the AppName.ipa package and the AppName.plist file.

Important: Make sure to toggle the Save for Enterprise Distribution checkbox.

Once you've finished filling out all of the fields, click on the Save button.


Step 6.

You'll need to upload the saved AppName.ipa and AppName.plist files to your corporate web server in the location that you specified in the previous step. You'll also need a web page that will link to your app using a hyperlink similar to the one below:

<a href="itms-services://?action=download-manifest&url=http://internal.mycompany.com/Applications/AppName.plist">Install AppName!</a>

That's it! You're done!

I have blogged about how to get Linux on the Chromebook in the past; and whilst the process works, it isn’t the easiest or most friendly way. Thanks to the tireless work of the openSUSE ARM Team (especially Alex Graf and Marcus Schäfer) we now have a simpler way to get openSUSE on the Chromebook. We now have an installable image that can be dd’ed directly to either an SD card or USB drive (I’ve not tried the internal eMMC) just like any other ARM device.