I’m going to be holding a Bof at the openSUSE Conference all about the 5 Ws of contributing to openSUSE. WTF is it about? Well I’m glad you asked (I don’t care if you didn’t ask, because I’m going to tell you anyway ;-) ) My intention is to have as interactive a session possible, I will take on the role of compère and with audience participation I will try and highlight where we have issues both as a project and as a contributor and try and get to some form of resolution even if it is just a plan not an actual fix.

I've just released GMime 2.5.10 which I hope to be the last of the 2.5 releases before I release 2.6.0. I feel that I've stretched the development of 2.6.0 out for far too long (2.5 development began at the end of April, 2009) and even though I didn't get around to doing everything I had hoped to do, I feel that the latest 2.5.x releases are such an improvement over 2.4.x that I just want to get it out there for developers to start using. But before I make a 2.6.0 release, I'm hoping to get some feedback and some testing.

What's new?

New for the release of 2.5.10 is GMimePartIter which replaces the need for g_mime_object_foreach()and its awkward callback requirement, instead allowing you to take the far nicer iterator approach that is popular in the C# and Java worlds (known as IEnumerator in C#). This new iterator, like the foreach function it replaces, iterates over the MIME tree structure in depth-first order.

Inspired by IMAP's FETCH body part-specifier syntax, I've implemented a method allowing you to jump to a part based on a part-specifier string (aka a path): g_mime_part_iter_jump_to(). Also implemented is a function called g_mime_part_iter_get_path(), which can be used to tell you the current part-specifier path of the iterator.

For example, if you had the following MIME message structure:

multipart/related
  multipart/alternative
    text/plain
    text/html
  image/jpeg

The body part-specifier paths would be:

1    multipart/alternative
1.1  text/plain
1.2  text/html
2    image/jpeg

This means that g_mime_part_iter_jump_to(iter, "1.2") would jump to the part specified by the path "1.2" which, as we can see above, would be the text/html part. Calling g_mime_part_iter_next(iter) would iterate to the next part, being the image/jpeg, while calling g_mime_part_iter_prev(iter) would iterate backwards to the text/plain part and calling it again would iterate backwards to the multipart/alternative.

What I Need From Testers

My feeling is that developers will want to use this cool new body part-specifier path functionality for aiding them in implementing IMAP servers and/or clients. Because of this, it would be great if GMime's implementation matched IMAP's specification exactly. The problem is that I don't have the time or energy to verify that the paths work out to be identical in all cases. So... if you are one of those developers who is interested in using this functionality and need it to be identical to IMAP's syntax (or would really like it to be), I'm hoping that you could test it out and make sure that it matches. Especially worthwhile of testing, I'd imagine, is having message/rfc822 parts in the tree. I suspect that, if anywhere, this is where differences may be.

If body part-specifier paths aren't something you care about, don't fret; the rest of the iterator API needs testing as well and if you have no interest in the iterator API at all, perhaps you'd be willing to test the S/MIME functionality (especially since I haven't figured out how to test it myself, given that I don't have an S/MIME cert nor have I figured out how to generate one or add one to my gpgsm keyring).

Your help will be greatly appreciated.

Well, it's been a long while since my last news ... but I've got some nice news to report - my submissions of redshift and backintime were accepted into openSUSE Factory. So these useful programs will be part of the next openSUSE release, hooray!

Redshift is a little command-line (and GTK) utility which reduces screen brightness at night (via colour temperature, so your screen becomes more red). Given your location in the world, it automatically calculates sunset and sunrise and gradually ramps up/down the brightness at the right times. I find it makes working at night easier on the eyes, and wrote a little plasmoid to control it easily from the desktop, which I will also release when I get some time.
For previous openSUSE versions one can download and install redshift from its OBS devel project, X11:Utilities.

Backintime is a backup program, effectively a rsync frontend, with GUIs for KDE and GNOME. Once configured with which folders you want to back up, and where you want to back up to, it can automatically take backups based on a schedule. Also a very nice feature is that on filesystems that support it (not FAT), it uses hardlinks to the previous backup, so each backup is a full backup but only changed files take up space on the backup disk. Each backup is just a normal copy of all the folders, so no special software is needed for recovery, but backintime offers a GUI that allows you to easily navigate through all your backed up versions of a folder. IMO it's the best userfriendly but complete backup software for Linux desktops. backintime used to be packaged by packman and now lives on the OBS in Archiving:Backup.


Enjoy! If you have other interesting programs that aren't in openSUSE remember that anyone can contribute to Factory now, so if you are willing to maintain them, go ahead and submit them on the OBS! My next target is byobu, a set of preconfigured GNU screen profiles (I never figured out how to write hardstatus lines!)

This week in three short achievements:

- personal OBS project (playing around, tutored by DimStar), work in progress

- code tide-up, ready for merging into master

- features, usage and testing documentation, work in progress

I’m now focusing on the gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release.

And done

(Bicycle-) Wheel building is an art. An art perfectly suited for a geek; it requires technical insight, knowledge, feeling and some experience. For those interested, here are some tips and pointers from my own experience.

1) Buy "Professional guide to Wheel Building" by Roger Musson, it is going to be the best 9GBP you have spent in a long long while. [HINT1]
2) Read it, twice!
3) Buy the rims and hubs before you buy the spokes (and get the necessary tools too if you haven't already).
4) Measure the ERD (Effective Rim Diameter) using the old-spokes with glued-on nipple method that Roger describes [HINT2].
5) Buy the spokes that spocalc.xls then calculates for you.
5) Lace your wheel like Roger describes, to the letter.
6) Tension your wheel like Roger describes, to the letter [HINT3].

HINT1: Do not read any other sources, Gerd Schraner's book is just pure nostalgia and does not help you much. Especially his explanation for tensioning your spokes should be ignored: while it might get you a straight wheel, your spokes might have wildly varying tension, and are therefor likely to either break due to fatigue or have the wheel go out of true quickly.

HINT2: For creating the cut-off spokes for measuring the ERD as Musson describes; screw your nipples onto your spokes so that your spoke only _just_ comes out of the nipple into the groove for the nipple-driver. This is the measuring length you should use. If you use the absolute top of the nipple for measuring the length, then you will have no room for error, and you will very likely use up all of the thread on the spoke while bringing the wheel up to full tension (this is the experience bit right here). If it is still inside the nipple, then you most likely will end up with too short a spokes, with thread still showing, this too is a nightmare for wheel-building (your nipple-driver will not disengage). Once you bring your wheel up to its final tension, the spoke (especially double butted spokes) will come slightly further out of the nipple as with the measurement-spokes.

HINT3: For the final stage of tensioning, where the spokes tend to turn with the spoke-key, I marked the rim-sides of the spokes with different colour alcohol markers. This gave me the ability to view the turning of the spokes, and to undo it, close to the rim and nipple, without hampering the spoke-key. Since this is an alcohol based marker on stainless steel, you can rub it off afterwards, or you could just take some alcohol to wipe it off. I just kept it on now, knowing full well that most of it will disappear soon enough in the rain and mud.

I am using Extreme Airline 3s, which i got from Rose. These are rather deep rims that are very stable and sturdy, and they have a wear-indicator still. The joint is not done well, and you will always have a third or so of a mm difference in diameter there, but for trekking or mtb tires, this is no issue, it is just annoying when working on the wheels in the stand. Because these rims are so sturdy, the Schraner method becomes quite unreliable, you can much more easily get away with differently tensioned spokes, as the rim is much more likely to even differences out for you instead of showing where the differences are. You actually need to pluck the spokes instead, like Musson describes, early on in the tensioning process, to get rid of the differences in tone and therefor tension.

I ordered a pre-built set of Airline 3s (28" with LX hub and 3N72 dynamo) from Rose more than a year ago, and they seem quite sturdy and have served me well so far. But, sadly, these pre-built wheels were not up to tension, which I could hear on steep climbs as the spokes were rubbing against eachother with heavy and changing load. They were subsequently very hard to tension further, my guess is because of badly oiled nipples before assembly.

Recently I built a first set according to the Schraner method, and while this went well, and the wheels feel good, I am not sure how good they really are as I haven't used them yet. It could be that they go out of true quickly, especially after pumping quite a bit of heat in them going down some slope in the Fränkische Schweiss. The spoke lengths I used for the 28" Extreme Airline 3 rims, triple crossed (of course!) and with 12mm nipples are 276mm for the front, 281/283 for the back.

For the 26" version of the same rim, with the same hubs, same lacing, same nipples, I used 246mm for the front, and 251/253 for the back. This was calculated with spocalc after measuring the rim, according to Musson, and the ERD is 523mm (after correcting for my mistake). These wheels are for a velotraum cross crmo frame that I am just now building up, so there are no kms on them either, but I have a very very good feeling about them, as I did use Mussons book for them, and the wheels came together as good or even better than described. So while my own handiwork is still untested in real-life conditions, at least I can tell the difference between Schraner and Musson, and the spoke lengths are (now) correct too ;)

In any case, if you are into cycling, have done all other jobs around the bicycle, and mastered them, already, then try your hand at wheel-building to complete the skill-set. It is not black magic, it is actually highly logical, but you should not use sentences like "How hard can it be?" or "Right, I'll get my hammer!" when doing so. Read the right book, get the right tools and the correct spokes, and then take your time; it is really very rewarding.

openSUSE 12.1 is on its way, and recently LXDE got some major updates.

I’m personally always been really satisfied of how LXDE works and is integrated into the openSUSE user experience, one defect though , that I’m really sorry about, is that i was never able to provide a very nice look&feel.

Since I’m not a graphic, and i realized I’m failing, i decide to ask your help now.

Here is what we need:

1) A gtk2 + openbox theme (including lxpanel background and icon theme)

2) A theme for lxdm (you can use /usr/share/lxdm/themes/Industrial as template), and eventually a background too

Also, i would like to open a contest. Your goal is create a logo for openSUSE-LXDE project.

You’ll have more information as soon as possible about this contest on the opensuse-lxde@o.o mailing list and here on lizards, please keep in mind that we want to print the winning logo on t-shirts too.

Up to date info about the contest will be available in the wiki here

I hope lot’s of you will help.

Andrea

We at SUSE needed to know whether we had some severe regressions regarding graphics performance during enablement of intel SandyBridge graphics - and it turned out that it was not commonly understood what graphics performance is actually composed of. Some were only interested in core X commands (xterm users :-) , some only in render performance (office users :-) , some in low-core 3D graphics (compiz users :-) , some in hardcore 3D graphics (gamers :-) .

So finally I put together a standardized graphical benchmark with aspects for all users. And no, it won't output a single number, because that would be meaningless for everybody. But it makes it easy to compare different aspects between different graphics cards and drivers, and there are some surprising results. But more about the results later.

The sources for the benchmark are now on gitorious, and the Wiki entry describes its usage. It's currently somewhat tailored to SLE11SP1, so you might run into minor issues when running it on a different OS version. And of course, it's not very polished yet .

Advances in the layout engine

I started implementing "Shape" support in my layout engine. What's so special about Shapes is the fact that the text needs to flow around them when wrapping is enabled. Shapes are used a lot e.g. to construct letterheads etc. Good Shape support is absolutely crucial for business documents.
Here is my sample document I used for testing wrap03.docx:

It shows Shape objects with "tight" wrapping and the different wrapping modes as defined in 20.4.3.7 ST_WrapText (Text Wrapping Location) of the OOXML specification:

• both (Both Sides) Specifies that text shall wrap around both sides of the object.


• left (Left Side Only) Specifies that text shall only wrap around the left side of the object.


• right (Right Side Only) Specifies that text shall only wrap around the right side of the object.

I'm really happy to have this key feature in the layout engine. Just to show how difficult this is to implement take a look at what Google Docs makes out of it: wrap03.docx.

Played with Package view a little bit today. This would probably look more like what I’m heading toward:

The biggest change was adding embedded collapsible buttons.

I tried serializing Files and loading the list alphabetically sorted, like this:

<script type="text/javascript">

 // build up a javascript array from the file list
 var filelist = [
<% @files.each do |file|
 fl = file.submit if file.has_element? :submit
 fl = file.action if file.has_element? :action
 pkg = ""
 if fl.has_element?(:pkg)
 pkg = elide(ae.pkg.package, 20)
 if fl.pkg.has_attribute?(:package)
 pkg += "/ #{elide(fl.target.package, 12)}"
 end
 end
 -%>
 {"name": "<%= elide(file.name, 12) %>", "pkg": "<%= pkg %>"
<% end -%>
 ];

 // renders the file list
 function render_list(criteria) {
 console.debug("rendering list, ordered by: " + criteria);
 var list = $("#file_list");
 $(list).empty();

 var files = filelist.sort(function(a, b) {
 switch (criteria) {
 case 'name':
 return a.name > b.name;
 }
 });

 list.append("<li data-role=\"list-divider\">Files contained in this package</li>");
 $.each(files, function() {
 list.append("<a href='<%= url_for :project => @project, :package => @package, :action => :files %>/" + this.name + "'></a>");
 });
 }

 // initial render after page load
$(document).ready(function(){
 render_list("name");
});

</script>

In the mobile view, I would like to have the Files loaded as a pre-sorted list:

<% @files.each do |file| %>
 <div data-role="collapsible" data-collapsed="true">
 <h3><%= h file %> </h3>

 <ul data-role=”listview”>
 <% if @package.linkinfo %>
 <% if @expand && @expand.to_s == "1" %>
 <%= link_to '(show unmerged sources)', :project => @project, :package => @package, :action => :files, :rev => params[:rev], :expand => "0" %>
 <% else %>
 <%= link_to '(show merged sources derived from linked package)', :project => @project, :package => @package, :action => :files, :rev => params[:rev], :expand => "1" %>
 <% end %>
 <% end %>
 </ul>
</div>
<% end %>

But when I compile, I get this error:

[FATAL|# 8894] ActionView::TemplateError (You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each) on line #5 of app/mobile_views/package/_files.html.erb:
2: 
3: // build up a javascript array from the file list
4: var filelist = [
5: <% @files.each do |file|
6: fl = file.submit if file.has_element? :submit
7: fl = file.action if file.has_element? :action
8: pkg = ""

 app/mobile_views/package/_files.html.erb:5
 app/mobile_views/package/show.html.erb:21
 /server:3

[ERROR|# 8894] rescue_action: caught ActionView::TemplateError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each
[DEBUG|# 8894] ERROR: unknown; You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while e

In desktop views, Files are implemented as a table and sorted with jquery.tablesorter.js. In mobile view, Files would have to be converted to an Array. I can’t quite tell what went wrong here, or how else to do it.

Hello,

A bit late this week’s report. But not without a reason, the last weeks i have been working hard in order to fulfill the initial goals of this project. After lot’s of coding / compiling / testing this week and of course mind storming i can now share with you very good and exciting news.

What is done this week:

-> aug_process_trees is finally done!! That means we can now proceed to the final goal that of implementing the merging functions.
->moved whole code to Augeas version 0.9. Added necessary code and fixed already existing.
->tree_get_children (fixed)
->tree_compare_children (re worked)
->tree_match_combine (added)
->tree_match_lower_level(added)
->tree_child_sort_label(fixed)
->debug_print_treeArray(added)
->debug_print_treeMatchArray(added)

What is to be done:
-> Finish Merging Functions
-> Create First Beta Packages

That is all in a few lines, as GSoC is getting closer to the end, the time available for completing the project is getting less. So I better get back to coding…

Till next week,
Christos Bountalis