In the spirit of releasing early and often, here is PDF Mod 0.5, a quick three days after 0.4. Contributors Bertrand Lorentz, Michael McKinley Features

• Password-protected PDFs can be opened
• Page labels shown in tooltip, eg A-10, or iii
• Undo/redo have descriptions, eg "Undo Move 5 Pages"

Bugs Fixed

• Loading document doesn't block GUI thread
• Desktop file validates
• Process name set to pdfmod
• Parallel make (-jN) works
• make distcheck passes
• icon-theme-installer included in tarball

See the website for links to tarballs, git, packages, the mailing list, irc, bugzilla, and more.

On our way to F-Spot 1.0, we slowed our well oiled machine to change the tires, fill the tank and do a complete check against the various regressions we might have added while packing tons of new features and changes since the 0.5.x releases.

The truck is now ok and ready to ride to the next milestone. Check 0.6.0 in order to make your own opinion.

Neither this short post nor the NEWS file reflects the really hard work pushed by our contributors, translators and designers, but rescanning the git log this evening reminded me how hard we all worked for this. Thanks guys.

Get it here.

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.