Well Amazon has just blown ebay out of the water today I sold 2 boxes of 11.4, takes my tally to 24 now.. (10 copies of 11.4 and 14 of 11.3).

Amazon has now sold two copies although i can't figure why the price changes each time!

You know the drill, another week, another release.



Release team decided to do another call for tarballs to fix some bugs across the entire GNOME3 platform, so 2.91.93 was released yesterday.

And today, you can download GNOME Live Image 0.3.0, which contains all the fixes from 2.91.93 tarballs.

Url to download it hasn't changed : http://gnome3.org/tryit.html

Enjoy !

SUSE Studio is  an awesome tool, with a couple of clicks you can create an openSUSE/SUSE based system and deploy to your hard drive, an usb flash,  a live dvd, a VMware/VirtualBox/Xen server and even Amazon EC2 cloud.

Suppose you want to create a tailored SUSE Studio appliance to run a Ruby on Rails app, this is a list of things you have to take care of:

• install all the gems required by the app (this can be a long list).
• install and configure the database used by the app.
• install and configure a webserver.
• ensure all the required services are started at boot time. You can save some time by cloning this appliance shared on SUSE Gallery, but this is still going to be boring.

Dister to the rescue!

Dister is a command line tool similar to the one used by Heroku (one of the coolest ways to run your Rails app into the cloud). Within a few steps you will be able to create a SUSE Studio appliance running your rails application, download it and deploy wherever you want.

Dister is named after SUSE Studio robot. It has been created by  Dominik Mayer and me during the latest hackweek.

How it works

We are going to create a SUSE Studio appliance running a rails application called “SUSE history”. The app uses bundler to handle its dependencies. This is its Gemfile file:

source 'http://rubygems.org'
gem 'rails', '3.0.5'
gem 'pg'
gem "flutie", "~> 1.1"

As you can see the app uses rails3, the flutie gem and PostgreSQL as database.

Appliance creation

Move into the suse_history directory and execute the following command:

dister create suse_history

As you can see dister has already done a couple of things for you:

• created an appliance using latest version of openSUSE supported by SUSE Studio (you can use a different base system of course)
• added the devel:language:ruby:extensions repository to the appliance: this repo contains tons of ruby packages (like _modpassenger)
• installed a couple of things:
  • _devel_CC++ pattern: this will allow you to build native gems.
  • _develruby pattern: provides ruby, rubygems and a couple of development packages needed to build native gems.
  • rubygem-bundler: bundler is required by dister in order to handle the dependencies of your rails application.
  • rubygem-passenger-apache2: dister uses passenger and apache2 to deploy your rails application.
  • postgresql-server: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs it.
  • rubygem-pg: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs the ruby’s library forPostgreSQL.
• uploaded a custom build script which ensures:
  • mod_passenger module is loaded by Apache
  • both Apache and PostgreSQL are always started at boot time.
  • all dependencies are installed: this is done only during the first boot using bundler.
  • the database user required by your rails app is created. This is done only during the first boot using some SQL code.
  • the database used by the appliance is properly initialized (aka rails db:create db:migrate). This is done only during the first boot.
    

Upload your code

It’s time to upload suse_history code. This is done using the following command:

dister push

As you can see dister packaged the application source code and all its dependencies into a single archive. Then uploaded the archive to SUSE Studio as an overlay file. Dister uploaded also the configuration files required by Apache and by PostgreSQL setup.

Build your appliance

It’s build time!

dister build

The appliance has automatically being built using the raw disk. You can use different formats of course.

Testdrive

Testdrive is one of the coolest features of SUSE Studio. Unfortunately dister doesn’t support it yet. Just visit your appliance page and start testdrive from your browser. Just enable testdrive networking and connect to your appliance:

Download

Your appliance is working flawlessly. Download it and deploy it wherever you want.

dister download

Current status

As you can see dister handles pretty fine a simple Rails application, but there’s still room for improvements.

Here’s a small list of the things on my TODO list:

• The dependency management should install gems using rpm packages. This would make the installation of native gems easier, right now the user has to manually add all the development libraries required by the gem. Moreover it would reduce the size of the overlay files uploaded to SUSE Studio.
• SUSE Studio Testdrive should be supported.
• It should be possible to deploy the SUSE Studio directly to EC2.
• Fix bugs!
  

Bugs and enhancements are going to be tracked here.

Contribute

Dister code can be found here on github, fork it and start contributing.

If you are a student you can work on dister during the next Google Summer of code, apply now!

The poll on SurveyMonkey on how to version the openSUSE distribution release is now closed, you can see the results here. The winner is the “old school” (like currently but only counting the right number until 3), followed by “Fedora style” (just integers) and “Ubuntu style” (2 digits year “.” 2 digits month).

The openSUSE members only poll is now live on connect.opensuse.org until April 04, 2011. Please select your favorite option!

A late blog post about the Novell Hack Week a couple of months ago: I worked on making LibreOffice build as x64 (x86_64, amd64) code on Windows. I used the same compiler suite as normally when building the current LibreOffice, i.e. Microsoft's Visual C++ 2008, just the x64 toolchain instead of the x86 one.

My goal was not to produce a complete installer just in one week, but to see how feasible an x64 LibreOffice on Windows is, and to get at least some tests to run successfully, and there I succeeded.

Porting LibreOffice to a new platform consists of

• Some trivial tasks like defining new LibreOffice internal codenames and whatnot for the platform
• The hard bit: Porting the so-called C++–UNO bridge to the platform
• A bunch of unexpected less hard stuff

Porting the C++–UNO bridge requires knowing the platform calling convention and exception handling in minute detail. Dynamic generation of code for short trampolines is involved, so some machine code knowledge is required. Also a small amount of "normal" (non-dynamically-generated) assembly code is typically needed.

The x64 Windows calling convention is luckily quite clean and simple. Compare to the AMD64 System V ABI used on Linux, with its complex rules on how to allocate registers for parameters.

Sure, thanks to the simplicity, it uses much fewer registers for parameter passing than the Linux one. There is always a maximum of four parameters passed in registers, either integer or floating point ones. One parameter always takes one register and parameters larger than 64 bits are always passed through pointers.

The exception handling mechanism used by MSVC on x64 is complex, but luckily it is roughly similar in principle to that on x86 Windows. Except of course that the structured exception handling (SEH) is table-based and not frame-based.

In addition to the trivial tasks and the C++–UNO bridge, a bunch of minor changes were needed here and there to get the code to compile. After all, 64-bit Windows is different from other 64-bit platforms in that the long type is still 32 bits. The LibreOffice codebase is old, and consistent use of sane integral types is not one of its strong points.

For instance, there is an infamous legacy type in LibreOffice's "solar" layer called ULONG which surprisingly isn't typedeffed as unsigned long, as one might suspect from its name, but as (effectively) uintptr_t.

That type is then mostly used as if it was unsigned long anyway, for instance there were a couple of assumptions that literals like 42UL are of ULONG type. Of course, on other 64-bit platforms it doesn't matter, as both unsigned long and uintptr_t are 64 bits anyway, but this broke the compilation in a couple of places. There were a mass of warnings, obviously, as the code converts liberally back and forth between integral types, but then, there are a lot of similar warnings in a 32-bit build, too. It remains to be seen then once the actual LibreOffice application is running as 64-bit Windows code how many of those warnings actually cause run-time issues.

So what did I then achieve, concretely?

• Most (maybe all even, I haven't verified exactly) of LibreOffice compiles as x64 Windows code.
• The extensive C++-UNO bridge test in "testtools" runs fine as long as one comments out the exception handling testing.
  

What remains to be done?

• The exception handling part of the C++–UNO bridge. I think it should be achievable with some week of additional effort. I have found good 3rd-party documentation on how it works, open source code even. It is possible to get an understandig what the existing code for 32-bit Windows is doing, and what the x64 code should do.
• Enabling also Java and the Mozilla bits in the build. I disabled them for now when building, didn't want to get stuck on those parts.
• Verifying that the monster then actually runs.
• Building an actual installer for it. Hopefully the installer-building mechanism doesn't even need to be aware that it is building an installer for 64-bit code, but there might be some details that need changing here.
  

This was a very interesting thing to hack on, but how useful is this work? That is a hard question.

As such, running a 32-bit LibreOffice on Windows "should be enough for everybody". Its hard to imagine a situation where one would need to, or want to, manipulate gigabyte-sized documents in LibreOffice. On Windows there isn't the same concern as on Linux where one wants to avoid needing to have both 32- and 64-bit libraries installed; at least so far all 64-bit Windows editions provide the full set of system libraries in both 64- and 32-bit versions. But who knows, maybe some day Intel or AMD will produce x64 CPUs that don't have 32-bit mode any more, and then there will be corresponding Windows editions that run 64-bit code only.

The code is in the master branch of the LibreOffice repositories. The completely new parts are licensed under the usual MPL 1.1 / GPLv3+ / LGPLv3+ combination.

Just re-posting in my blog an interesting email that was sent to the MonoAddins list, comparing these two Addin frameworks:

> Can you give a short summary on why you replaced MEF with Mono.Addins?

Basically it came down to maturity. Mono.Addins seems far more stable and mature than MEF. The MEF documentation was lacking, inconsistent and out of date in a lot of places. But all that could be worked around, and for the first few internal versions of our app, MEF was servicing us just fine.

Then our addins became a bit more complex. We needed to package them up with multiple files, ideally distribute them as an archive, host them online in a plugin exchange, allow them to be discovered and installed easily. Essentially this page covers features in Mono.Addins that made us switch rather than implementing a lot of the same things using MEF ourselves:

http://monoaddins.codeplex.com/wikipage?title=Creating%20and%20Managing%20Add-in%20Packages&referringTitle=Programming%20Guide

At the time as well MEF had issues on Mono on linux. This might have been a problem with how we were using it, but it just turned out easier to plonk Mono.Addins in instead. Was an easy migration and has a lot more power and features straight out of the box (and it worked on Linux).

Your millage may vary, and your needs are probably different. MEF might be an awesome tool for your requirements. It is a little simpler to get up and running and requires less engineering to support it (which was one of the reasons we used it first off).

Hope that helps,

Michael

I think it is only fair to state publicly what should have been painfully obvious for some time already to anybody following: I have lost inspiration/motivation/interest in working in my spare time on GTK+ on Windows. It isn't likely that I will be producing any more Windows packages (32- and 64-bit) of GTK+ and dependencies to be offered on gtk.org (actually ftp.gnome.org).

Occasionally building such packages is all I have done for quite some time for the stack on Windows, anyway; it's a long time since I attempted any bug fixing for instance.

But the situation is not too bad: Check out the stuff in the openSUSE Build Service, see for instance http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/ . Note that even though I might be listed as a co-admin or something for that stuff, too, I haven't really done much for it. My colleague Fridrich Štrba is the main driving force there. Also note that other people have been fixing bugs and making GTK+ 3 build on Windows, for instance Hans Breuer deserves much thanks.

Another week, another release



This week release is version 0.2.0. It features GNOME 2.91.92, including :

• soon to be released Network Manager 0.9 and new UI integrated in GNOME Shell and GNOME Control Center (be careful, it has still rough edges)
• a11y support should be improved

If you have installed this image or if you use the home:fcrozat:gnome3 openSUSE and want to upgrade to 2.91.92, you can update using zypper up (if you still want to keep Network Manager 0.8) or zypper dup (if you want to switch to NM 0.9). Some packages might be uninstalled in the process.

Image is, as always, available at http://gnome3.org/tryit.html

Enjoy !

I’m happy to announce LibreOffice 3.3.2 bugfix release for openSUSE. The packages are available in the Build Service LibreOffice:Stable project. They fix various crashers, usability and translation problems, see the libreoffice-3.3.2.2 release news for more details. See also some notes about openSUSE LibreOffice build.

The openSUSE LO team hopes that you will be happy with this release. Though, any software contains bugs and we kindly ask you to report bugs. It will help us to fix them in the future releases.

Other information and plans:

The 3.3.2 packages includes KDE3 support again. Thanks Lubos Lunak who fixed all known issues and Ilya Chernykh who helped with packaging.

The 3.3.2 release is in a very good shape, so we decided to slow down the bug fixes release cycle. You might expect the 3.3.3 bug fix release two months from now.

LO-3.4 feature freeze is pretty close and we will start producing test packages in the LibreOffice:Unstable project. Please, be patient because there are many interesting changes in the build framework. They are good for the future but I expect some problems with packaging. I hope that I will manage to provide something by the end of April.