The openSIS team is proud to announce that the conversion from Postgres to MySQL is nearly complete. Check it out at http://opensis.sourceforge.net  We have a few small bugs in the SQL left in some of the less used features. For the most part the project is on track and we have started to divide the team in two with one half working on bugs, the other working on Moodle integration. By mid fall we hope to have a “push” mode of integration with Moodle version 1.9.5 and hope to have work begun using Moodles new 2.0 version with SIS API.

We have IMHO created what will be the next “killer” , “must have” application  in the education administration venue.  Paired with the offerings produced by my good friends and teammates of the opensuse-education team. I think we will be producing a wonderful tool for all humanity.  A free education software suite.  Much has been done with the ideals founded here, Linkat, and the Edubuntu add-on are just a few. I hope it keeps going , for the children’s sake “let’s make a difference”!

So far it was only possible to have upto 16 device nodes for a single disks. This restricted the number of usable partitions. As a workaround kpartx could be used to create device mapper mappings for further partitions but that was never fully integrated in openSUSE.

With version 2.6.28 the kernel supports upto 256 device nodes per disk, much more than the partition table allows. But since the implementation is not straightforward, the additional device nodes are assigned dynamically, user-space programs may need to be adapted.

For openSUSE 11.2 Milestone 5 YaST was extended to support this new kernel feature.

Some quick tests showed only problems with LVM. If you are interested in this feature and have the possibility please give it a try so that we find remaining bugs.

When talking about live systems on USB sticks people reported many problems with bootloaders like grub to boot the stick. Even though this is most often a problem with the stick hardware or the PC BIOS it’s an annoying situation which should have a better solution. There are also many people who wants to use the stick as a data container in combination with a live system to work with

With the ISO hybrid technology and the integration into kiwi there is a way to create such a stick very easily. A hybrid ISO is an iso filesystem which contains a MBR and thus it’s seen as a disk to the PC BIOS. As it’s an ISO the isolinux bootloader is used instead of grub which works better on many systems. Additionally the hybrid ISO can be used as a live system on CD/DVD as well as on a USB stick

What’s required to use this

• kiwi v3.68 or later
• syslinux-3.82-2.1 or later

How do I setup a hybrid ISO in kiwi

In order to activate the creation of a hybrid iso in kiwi you only have to add the hybrid=”true” attribute as part of your iso image type in config.xml:


<type boot="isoboot/suse-11.2" flags="clic" hybrid="true">iso

You can use the suse-11.2-JeOS from the kiwi-templates package as example image description for your hybrid testing. The generated .iso file can be dumped via a simple dd call onto the USB stick. The same file also can be used to be burned on a CD/DVD


dd if=LimeJeOS-openSUSE-11.2.i686-1.11.2.iso of=/dev/... bs=32k

After that the stick can be tested. By default all attempts to write data will go into the RAM of the system. As a stick allows storing data persistently you can create a write partition on the stick using fdisk:


fdisk /dev/...

kiwi will prevent using a vfat partition for the operating system. So make sure you create a 0x83 (linux) type partition and not a vfat partition for the write support. If you additionally create a vfat partition you can use it as a container for any kind of data independently from the live system. We choose vfat here to stay compatible with Windows systems.

Known bugs

• when using the clicfs filesystem (flags=”clic”) the persistently write feature into a single partition will fail because clicfs currently can’t deal with raw block specials as cow device. Will be fixed as soon as possible

Have fun

Just incase you’ve been living under a rock on Mars there is a certain feature request in openFate. Both Michael and Zonker have posted on the matter but as they are both Internal (as in they get paid by the Big N) I thought I’d throw my external views (these views are not solicited by anyone other than me, yadayadayada) into the pot.  Now I know I was asked to put my thoughts down and send them into the mailing list, but to be honest the whole discussion has turned into a childish “My dad’s got bigger knuckles than your dad” style flamewar and there are multiple threads on the one topic.  Personally I have now switched off of the discussion on the lists as it’s hard to follow and frankly going nowhere.

Firstly I’d like to think that Frank had no malice in filing the feature and only had the best intentions for KDE and openSUSE at heart.  The problem is there doesn’t seem to have been enough background checks and verification of facts prior to unleashing this handgrenade of annoying pointlessness.  If you default on a loan/mortgage/credit card you are in jeopardy of loosing assets.  The same can be carried over to this discussion.

openSUSE did indeed start out as a very KDE centric distro, I don’t actually recall seeing GNOME available in 6.2 but it was that long ago (I can just about remember yesterday).  Prior to Novell buying SUSE they bought Ximian who were big players in the GNOME sphere and had a lot of expertise, so sure enough GNOME starts to make an appearance.  Then we had the first iteration of this silly and pointless dingdong GNOME gets made the default DE much to many people’s anger.  Novell did actually listen and came up with a reasonable solution – no default and list the environments alphabetically.  Now some folk think the alphabet is rigged but then again they probably reckon electrons are unfairly viewed as negative – deal with it! Ubuntu was created solely as a GNOME distibution and is the only real commercially supported varient by Canonical, that’s why they have derivatives like Kubuntu and Xubuntu – Canonical are slowly employing more and more people for other DEs to ensure they can keep abreast of what;s going on in the wider world.  Fedora/RedHat were always a GNOME focused distro but offered KDE as an option, if my memory serves me right it was very much a stock upstream version with almost no enhancements (I believe that is changing in the right direction).  Now I’m not trying to give a histroy lesson or educate people on what the competition is doing, just trying to provide more information.

So the aim of the feature is to make KDE the default DE for openSUSE, why? Frank lists the following and I put my response to them underneath:

– It is confusing for new Linux users if they have to decide between KDE and GNOME during the installation. New users don´t know either of them. So it is easier for beginners if there is a default. openSUSE has more KDE users than GNOME users so it is logical to make KDE the default.

Nope.  It’s easier for beginners if they are educated and informed.  Having a default will only give them a first impression, nothing more.  Yes you are quite correct openSUSE does have more KDE users than GNOME users which is a vestige from the good old S.u.S.E. days and before, but how does that make it logical?  I challenge this point’s validity.

– Unique Selling Point. It is important for openSUSE to provide something that Ubuntu and Fedora don´t provide. It would be beneficial for openSUSE to be the only big KDE distribution.

openSUSE has several USPs.  The major one is that openSUSE has one the largest pools of upstream developers for both GNOME and KDE.  It is a distribution that gives equal weight to both DEs with a large amount of cross DE work.  We already provide something that no other distro does – open, supported and enhanced choice.  Another USP is that openSUSE is already renowned for it’s KDE implementation regardless of which event I go to and the whole distro discussion comes up people acknowledge and that openSUSE has one of the best KDE builds going.  I challenge this point’s validity.

– This could attract more developers because KDE developers need a nice distribution to develop on.

Now this I think is just ill advised.  Having KDE as the default DE will only mean that the KDE zealots will be more likely to use openSUSE and to be honest we don’t want or need any zealots.  What we want and need is responsible contributions.  Having a good implementation of what ever DE and the correct tools is the way to get more developers NOT a default.  I challenge this points validity.

– This would increase the popularity of openSUSE in the KDE user community. The negative impact on the GNOME community is not that bad because Ubuntu is the most popular GNOME distribution.

Again it would only really be popular amongst the KDE fanboys/girls, if you don’t agree just look at some of the comments in the feature and on the threads .  Sensible developers/users would actually take the time to see what KDE related artifacts are on offer – Beineri’s roll outs of the latest KDE releases is a good example, as is Cornelius’ KDE SDK appliance.  It is innovations like this that will make openSUSE popular not having a default desktop.  Now for the second part of this comment.  Really, do you really honestly think that the impact on the openSUSE GNOME community would be “not that bad”? As Marco once advised us – ZONK!  This is probably the worst thoughtout aspect to your idea.  Any negative impact to any of our community would be bad.  If Ubuntu is “the most popular GNOME distibution” don’t you think it would be better if we tried to address that and make openSUSE the best all round distribution?  I challenge this point’s validity.

Frank, you asked for people’s thoughts here’s mine.  I would have thought the best way to approach this idea would be to first put forward the question at one of the Project meetings on IRC and then follow it up on the -project mailinglist.  Filing the feature and then advertising it solely on your KDE syndicated blog wasn’t the most intelligent course.  It affects openSUSE and KDE so giving a bit of notice to the openSUSE project would have been at the very least curtious.  Oh and to put the record straight – I class myslef as desktop agnostic and use GNOME, KDE, XFCE and Moblin if anything I use Moblin more than the others at the moment

Patch Contributors Julien Rebetez, Igor Vatavuk Features

• Insert external documents via menu/toolbar
• Drag pages between open documents
• Export images (jpg/png) working
• Beautiful new icon from Kalle Persson
• UI translated into 10 languages: da de es fr hr lt pl pt_BR sv ta
• User docs translated into 5 langauges: de es hr pl sv

Bugs Fixed

• No longer jumps to top on zoom or delete
• Error messages are shown to user in popup
• Scroll when dragging near the top or bottom
• Clicking on select matching button works

See the wiki for information on the mailing list, IRC, downloading, git, filing bugs, etc.

I added a new document to the MonoDevelop developers documentation page: API Overview.

The public MonoDevelop API is really extensive, and it is not easy for add-in developers to find out which part of the API they have to use to do certain operations. This document is basically a high level description of all functionality provided by the API, with information about which classes and objects provide that functionality. The document doesn't give much detail about how to use the API, this will come in separate feature-specific documents.

I hope you find it useful.

Some hours ago I have worked on fix of eclipse build. But two parallel builds of eclipse (there are eclipse.spec and eclipse-archdep.spec) eats almost all resources of my computer, which was unusable. Fortunately vim needs a little of CPU time, so I decided to improve smarter osc commit, I implemented on Friday.

If you work with osc and packaging, you probably forgot to add a new patch, or source and commits sources with missing file, so build in OBS fails. Our internal script, which we used before BuildService has a check, which warns about files not specified in Patch or Source in a spec file, so it was a great feature for forgetful developers (as myself, for example). The problem is how to get a list of sources and patches for a current spec file? The internal script uses some “magic” shell code which calls a rpmbuild, because it’s rather impossible to parse a specfile correctly. Fortunately there is a simplest approach.

In build service package directory each file has a state – added, modified, removed, …. So my idea is simple – check state of all files in the directory and if there is any file with ‘?’ (file exists, but not in metadata) or ‘!’ (file is in metadata, but not in directory) state, ask user what to do. The initial implementation allows to continue or abort and was not user friendly as it could be. So during rebuild of (two) eclipse I wrote a better implementation.

Lets have a package (for example called xdoclet) and we want commit our changes to OBS. So

$ osc status
?    xdoclet-modules-objectweb-4.6.tar.bz2
?    xdoclet-src-1.2.3.tar.bz2
!    xdoclet-modules-objectweb-4.6.tgz
!    xdoclet-src-1.2.3.tgz
M    xdoclet.changes
M    xdoclet.spec

You see, that we used bznew to repack tgz files to tar.bz2, which is recommended in openSUSE. Then we commit our changes

osc commit
File `xdoclet-modules-objectweb-4.6.tar.bz2' is not in package meta. Would you like skip/remove/edit file lists/commit/abort? (s/r/e/c/A)

I suppose that all options are clear – skip will skip check for this file, remove will remove it, commit forced commit and abort breaks it. But I don’t like this message, so if you have some better proposal, please contact me.

The most important command is edit file list. I thought how to easily add and remove files using this smarter commit. The final implementation has been inspired by one of the coolest git feature – interactive rebase.

So after selecting e, the list of files is opened in your EDITOR

  1 leave   xdoclet-AbstractProgramElementTagsHandler.patch
  2 leave   xdoclet-WebLogicSubTask.patch
  3 leave   xdoclet-XDocletModulesEjbMessages.patch
  4 leave   xdoclet-ant.not-required.patch
  5 leave   xdoclet-build_docs_xml.patch
  6 leave   xdoclet-build_xml.patch
  7 leave   xdoclet-component-info.xml
  8 leave   xdoclet-maven-plugin-project.patch
  9 leave   xdoclet-maven-plugin-template.patch
 10 leave ? xdoclet-modules-objectweb-4.6.tar.bz2
 11 remove ! xdoclet-modules-objectweb-4.6.tgz
 12 leave   xdoclet-project_xml.patch
 13 leave ? xdoclet-src-1.2.3.tar.bz2
 14 remove ! xdoclet-src-1.2.3.tgz
 15 leave M xdoclet.changes
 16 leave M xdoclet.spec
 17
 18 # Edit a filelist for package %s
 19 # Commands:
 20 # l, leave = leave a file as is
 21 # r, remove = remove a file
 22 # a, add   = add a file
 23 #
 24 # If you remove file from a list, it will be unchanged
 25 # If you remove all, commit will be aborted

and a manipulation is obvious. Just replace a command listed in a first column by another one, then save a file and instructions will be processed and package will be commited.

BTW: Of course this feature can be suppressed by new -f/–force option.

Smolt got changes that makes it more user friendly, ie. GUI is improved and it's on a way to be enhanced with more very useful features. Carlos, openSUSE member, rewrote the Smolt GUI in Qt, and removed serious usability bug - not reporting user password that allows user to access his report web page on http://www.smolts.org/. Password was available only trough command line client.

More in his blog .

There are pretty many pros and cons and even more people with their opinion about the feature. I’d like to summarize what has been said in the discussion in the feature itself and during yesterday’s openSUSE project meeting. Unfortunately the only sure thing is whatever decision is taken – it will be wrong for some. This is why, at this time, we have no default – because openSUSE has strong GNOME and KDE implementations, we offer them side-by-side as equals.  And we made 2 years ago on opensuse-project the decision that we stay with “no default” desktop.

So what do we have so far?

• a feature request from one of the KDE e.V. board members
• the feature asks to make KDE default. Reason for that, is to make openSUSE more simple for newbies and to make openSUSE the best KDE distribution around
• Through the discussion in the feature I’d translate that feature into put the radio button as default to KDE on the desktop selection screen during installation instead of today’s status where everybody needs to make a choice between
• the highest rated feature in openFATE until today
• a majority of people supporting this feature (currently approx. 90% pro, 1% neutral, 9% against)

What I clearly see as pro is:

• listening to our KDE community we may gain more KDE contributors. But don’t forget this feature is also about making openSUSE an outstanding KDE distribution. And for that just voting for a feature is not enough. For becoming an outstanding KDE distribution we need you to contribute
• we simplify the installation by one click for 2/3 of our users, according to question no. 11 in our  last openSUSE survey made in 11.0 time frame
• the GNOME users keep status quo and need to set the radio button as before

What I clearly see as con is:

• our pretty active GNOME community won’t be very happy about it
• our strength is to support choice and two major desktops
• with the CD you always get a default desktop

What might stay doubtful?

• Would changing a radio button really drive lots of users and contributors to us?
• Would already KDE as a default make us to an outstanding KDE distribution?
• Does openSUSE need a default desktop?

What I suggest?
Due to upcoming feature freeze for openSUSE 11.2 we have now only the possibility to default the radio button to KDE. But this is IMO more a diplomatic solution which doesn’t help much anybody. We should give the feature one or two more weeks to evolve and need to do the decision for openSUSE 11.2 by mid of August.

Some other observations I have with respect about this feature:

• inviting people through blogs, web pages, mailing lists or twitter to vote has potential to set the credibility of the voting system at risk as people not involved with openSUSE or not using openSUSE express their thoughts
• the feature shows the success of opening up the openSUSE project. Few years ago decisions were made by Novell and nowadays decisions are challenged by our community.
• I’m pretty happy about the way the discussion is handled (impartial, no bashing etc.)

May wisdom be with us – and may we get in openSUSE the best GNOME and the best KDE desktops!

I committed today very basic support for building projects using MSBuild / XBuild instead of MonoDevelop's own build system. Ankit has been doing a lot of progress in XBuild, and it is mature enough to build complex projects. XBuild support is for now disabled by default. To try it, you'll have to enable it in the Edit / Preferences / Build options panel.

The integration right now is simple because all it does is to launch the xbuild command in a separate process. That's not the best way of doing it, but the most straightforward. A more optimal option is to use the MSBuild API to load the project and launch the build. That's my next step, but there are some issues with it.

The main problem is that MonoDevelop now supports multiple target runtimes and frameworks. Multiple frameworks are not a problem because MSBuild already has support for that, but it doesn't have support for multiple runtimes.

Multiple runtimes means that for example when running MD on Windows, I can select either Mono or MS.NET as target runtime, and MD will build the project using the selected runtime. Each runtime has its own GAC and set of installed packages, even its own MSBuild version, so I can't use the MSBuild API to load and build the project. The only option in this case is to launch in an external process.

There is however and additional and more hard to fix problem. To get the list of assemblies referenced by a project (for example to do code completion), MonoDevelop right now just enumerates the reference elements defined in the project. When using MSBuild that's not fully correct anymore, since custom targets and tasks may inject references which are not explicitly set in the project. So the only way of getting the real list of references is by loading the MSBuild project and evaluating it, and that won't work when targeting a runtime other that then one running MD.

Anyway, this basic support we have now is good enough for many projects. I'll go step by step.