During the X-mas holidays Kolab, the groupware server got a stable repository for 11.1 and 11.2 on the openSUSE build service (OBS). All packages that are not provided by the openSUSE base distribution have been copied (using osc copypac) to the STABLE repository. Another possiblity to achieve the same result could be by making a fixed link to the unstable package using osc linkpac -r <rev>. Once the unstable package works again the link could be updated with osc setlinkrev -r <newrev> to point to the working revision or updated revision.

The stable repository already shows its benefits, as cyrus-imapd was updated from version 2.3.14 to 2.3.16 in the server:mail, being the cyrus-imapd development repository for Factory. As the cyrus-imapd package in kolab:UNSTABLE links to the server:mail one, it no longer builds as the kolab patches no longer apply. Unfortunately my computer went South, and real package development is at the moment not possible. A good thing to mention here is, that cyrus-imapd-2.3.16 includes patches that are needed for Kolab and which have been in the review queue for multiple years!

Just before X-mas Kolab-2.2.3 was announced. This version is not used in the openSUSE packages, as we package the version from trunk. After the 2.2.3 release the kolab development, moved back to trunk and the next version will be from trunk.

During the 8th annual KDE PIM meeting in Osnabrück, Northern Germany Kolab got some attention as well, with the following exciting announcement: KDAB and Intevation will be working on making a functional PIM suite and Kolab Groupware client based on Kontact for mobile platforms.

The facts:

Processing time using gdk_pixbuf: 431ms
Same method ported to Mono.Simd: 66ms
That means roughly 6.5 times faster !

Some explanations:

• The gdk-pixbuf is an unoptimized standard gdk operation (gtk+ 2.18.1), but I don't think a lot of them are optimized either using mmx or SSEx for this platform (x86-64). Feel free to prove me wrong here.
• Times are averaged.
• Loading and saving times aren't taken into account here, but both are using gdk_pixbuf operations.
• The Mono.Simd method acts on vanilla pixbufs, and results are plain old usable pixbufs, not some kind of memory buffer or whatnot.
  
• The image attached to this post is not the result of the processing.

This is only a teaser for the short talk I'll be giving at FOSDEM on Sunday Feb 7. Be there if you want to learn more, see the code, or question my sanity for doing this in Mono and not directly as a gdk-pixbuf patch.

At the last minute I'm getting away from the snow and ice to visit Camp KDE in San Diego this weekend. I'll be there waving the openSUSE flag, giving a talk about using the Build Service to package and distribute your KDE applications for many Linux distributions, generally enthusing people about openSUSE and thinking about ways for KDE to be better as distributed. So if you see a guy with an SUSE t-shirt on staggering under a huge pile of DVDs, say hi! I hear San Diego has a very good zoo, perhaps they'll lend me a chameleon for even better recognisability...

All I really need know I learned in kindergarten ... Come on, say you're sorry when you mess things up. Allright, we released a YaST (ncurses) update. It broke ncurses packager in openSUSE 11.1 and 11.2 for everyone. One could still use GUI (qt/gtk) packager or zypper CLI - instead, or to fix things up (e.g. to downgrade), but this is not exactly the thing that boosts user's trust in the distribution, is it? Many thanks to Marcus  for prompt response - a new update has  been released swiftly  and it can be downloaded by now. It was enough to rebuild ncurses packager against updated YaST ncurses UI lib ...

Logically, one could now ask "How comes you guys released such a crappy update? Hasn't it been tested at all?". Well, as Marcus already stated in bzilla, openSUSE update testing largely depends on those community members who use Update:Test repo and apply patches (almost) ready for the release before they hit official update repositories.
To improve the quality of updates (and to prevent buggy updates from hitting many users), we need more hero testers. What does it mean? Go subscribe Update:Test repo and/or look here how you can help maintenance team otherwise. Oh, and you may also talk your neighbour (sister, cousin, ... ) into doing the same :)

Moreover, in this particular case, it was few other little things that summed up and resulted in failure.

• The original bug ("paging bug") this update was about to fix was reported against Package1 (yast2-backup), fixed in Package2 (yast2-ncurses) and the resulting patch crashed Package3 (yast2-ncurses-pkg). Package3 is one of approx. 80 YaST packages. Taking also update description into account, even a seasoned tester would probably pick the original module (yast2-backup) for testing here.
• With dramatic increase in the popularity of zypper and "mainstreamness" of GUI tools, I wouldn't be surprised to find out that very few of our update testers actively use ncurses packager
• This was the first yast2-ncurses update introducing ABI incompatibility since its split (package manager used to be integral part of the library in the past). We didn't have the experience "a dependent pack must be also included in the update"  yet

Wanted: plugin lib versioning know-how

When sh** hit the fan, my thoughts followed along this line: "Now, if we introduce some system of tracking ABI changes in YaST libs .. " (shared library versioning it is called, now I know it) "... and have dependent packages require the correct version of shared library, we can avoid breakages like this in the future." But alas, my visit to YaST core wizard made me pretty pessimistic. Not only YaST core doesn't encourage shared lib writers to version their libs correctly, it makes (in its current form) the versioning impossible. 

YaST core doesn't link against shared libs, it loads ( dlopen()s ) them on demand as plugins and the existence of different versions of plugins would complicate the situation ... So, my dear readers, if you happen to know some (preferably) open-source project that is already proficient in this i.e. it loads its components as plugins AND applies solid library versioning policy at the same time, let us (include MVidner the Wizard in the loop, too) know. Kingdom for know-how !

And now .... winter hibernation again.

I had been working for a while on improving the imap support in evolution. Took the imapx provider which was written by Michael Zuchhi (aka Notzed) and getting it ready for replacing the existing IMAP provider. To summarize what is present,

* Fetch messages in batches
* Fetch messages with large attachments in multiple pieces
* IDLE support (push mail for imap)
* All operations on messages
* Cancel operations

A small screen cast demo of the same

The items which am working on are,

* Store operations (folder delete/create etc.)
* Preference options
* Connection manager to allow concurrent folder access (configurable one)
* Smart background message caching
* Mutliple namespace support

This design follows most of the aspects which are recommended for an IMAP client. Since we now parse all the unsolicited (aka untagged) responses from the server, syncing the changes is just instant when comparing with the existing imap provider even without the IDLE support. Users who live in inbox are going to love this

I would be working agressively to provide a wonderful imap experience with evolution for all evo fans   With akhils’s help we are setting up a server with multiple namespaces to test shared, public folders. If anyone can provide me an account with servers configured with multiple namespaces, it would be of great help.

If you need anything more get in touch Also send ur kudos to Michael Zuchhi!!

After getting asked daily why package X or project Y is in a certain state, why it is not yet published or if a “trigger rebuild” button click is needed, I finally got around and implemented the last planned feature for OBS 1.7.

Each repository has a scheduler state now for each architecture. This state tells you in which state the scheduler saw it the last time he looked at it. In addition to that, there is also a “dirty” flag. This gets set, when something happened what requires a re-calculation by the scheduler, but he has not done this yet. So no need to hit the “trigger rebuild” button in this case, it won’t help

A typical state round trip is the following, it can stop at any point and restart from a higher listed state again if this is needed:

unknown: a repo has just been created for this architecture. The scheduler has not seen this yet. This is currently the case also in most repos, just because the scheduler with this new code has not looked at all existing repos yet. But you will see this only in very rare cases in future.
scheduling: the scheduler is looking at this repo right now. The package states will get updated soon (from 1 second up to 2 minutes, depending on the project complexity)

blocked: packages from other repos need to build first until any of the packages from this repo can get build.
building: packages are scheduled for building, this means they are in “build”, “scheduled” or “finished” state.

unpublished: all packages got built, publishing is disabled, so nothing is to do here anymore.
or
finished: all packages which require a build have been built. This repo is enabled for publishing, but this has not yet happened.
publishing: The publisher is currently processing this repository.
published: the latest built packages have been uploaded to the stage server and are available via download.opensuse.org

Future plans for this are to add this state list in the web interface somehow, so everybody gets an explanation in the context.

Another thing what I want to add is a button beside the “unpublished” state, to force a publishing. So by default nothing gets published, but the project owner can force it when he things it makes sense. However, this is now also possible to achieve by swithing the publish flag and revert it after some time. The OBS is now even publishing when the build has already finished (unlike before).

Hello openSUSE Project! If you follow me on Twitter, you’ll know that since October, I’ve been a Windows 7 user instead of an openSUSE user. Well, late last night, I got a visit at home from this character:

So, I am now an openSUSE user again…

OK. Just kidding. Actually I left the project because I needed to concentrate my time on my work in the liberty movement and school, and when push comes to shove, the little green lizard got shoved. In the process, I had purchased a copy of Windows 7 when Microsoft was selling it for $50, and so I essentially switched over to using Windows 7 for a few months. In the end, I moved back to openSUSE because it’s, quite frankly, a better experience in many ways. I’ll probably write up an article or two in my comparisons between the two OSs… but I’m back now, using openSUSE 11.2.

In the course of these three months, I have to say I missed working with the openSUSE Project, especially the people. So… I’m back! I re-uped my mailinglist subscriptions and have been reading back articles of openSUSE News to try and catch up with what’s been going on in the project. I’m excited to be back and I look forward to working with you all again!

– Kevin

Hello community!

As agreed at the meeting – Russian commutiny needs a forum.

Also… Fixed… I would like to introduce a new Russian openSUSE forum %)

Right now we have a small problem with encoding and want to add Russian buttons, but it’s trifle and we will fix it in next days.

In the past Russian community meet on another linux_universal forums like linuxforum.ru or linux.org.ru, but these forums are not related to openSUSE project. And now I hope our community gradually will start to join the global.

In this forum we are closer to the draft openSUSE: in the same domain is located and Wiki, and the openSUSE Build Service, and much more.

So… you are welcome %)

Now that Moonlight supports DeepZoom for more than a year, it's about time to fill the blanks and allow one to create deepzoom images, even on linux.

DeepzoomIt does just that.

At least for the simple cases, i.e. no collection support and no selective resolution. But it generate files just right, as shown below (might not work on some planets) .

DeepzoomIt uses gdk_pixbuf for image cropping, scaling, composing. And it shouldn't be sensible to the inability of gdk_pixbuf to scale images bigger than 65536px.

The code is available on gitorious, use it if you like it: http://gitorious.org/deepzoomit.


[3159x2591 sized to viewport via DeepZoom. (shift-)Click to (un-)zoom. Drag to Pan]

[Update 2010.01.11: replaced the pure xaml viewer by a managed one. Pan+Zoom works.]