Well, i know that i haven’t be so active in the last months here in lizards or the OWN but that doesn’t mean that i stop my ambassador work, and here is a small story about what i do to integrate the spread of the openSUSE word in my work.

After a really bad month for the economic point of view, i had to refocus all the goals of my company to jump out the hole where i fall thanks to the changes in the economy of my country (Venezuela), so i came out with the idea of give on-line courses about system security, hacking, pen-testing and that kind of stuff, including the usual Web Dev, Sys Admin courses.

I give a lot of conferences of Hacking and System Security around this year in various events, and taking advantage of that give some publicity to the courses, but of course including something: Our Beloved Geeko.

In the courses I teach using openSUSE, and have turned a lot of people that doesn’t even had a clue of what its linux, to be a totally Geeko Lovers, to the point that they speak about “The green side of the force”.

In all my conferences always appear the words: “openSUSE its the best option for newbies and advanced users”, “You wanna try Linux, well the best option i can give its openSUSE”, I am a proudly member/ambassador of the openSUSE Community”.

Subliminal, directly, any way i just point people to use and love the Geeko!

I hope to be more active around here in the next weeks when all the events and congress are done.

Cheers people! There are always some ways to Spread the word of the Geeko!

As I wrote last time, I’ve migrated our documentation to a public SVN server on BerliOS. There you can get the English sources of the official openSUSE documentation and some business products too.

Apart from Russian, I’m very happy that the Hungarian translation of the openSUSE documentation is underway! Thanks to Kálmán Kéménczy, he will publish the Hungarian documentation soon. Currently, some translatation, proofreading, and polishing have to be done, so stay tuned (see https://svn.berlios.de/svnroot/repos/opensuse-doc/trunk/documents/distribution/hu.)
By the way, the Hungarian books from the 11.1 and 11.2 release can be downloaded in the Hungarian portal.

If someone from the Hungarian community wants to help, please support Kálmán and contact him for futher details.

Thanks Kálmán, for your ongoing work! I’m sure, everybody appreciates your work, be it in the past, present, or future.

Yet again I get a dose of the Early Adopter jitters – I tried to hold out but I just couldn’t. I went and got me some shiny robot lovin’ from Korea, and boy do I love this particular droid – the fabulous (IMHO) Samsung GT-P1000 better known as the Galaxy Tab. This is my third dedicated Android device, the first being the Motorola Milestone 11months ago, followed by the Nexus One around Easter time this year.

dbus-dump is a tool to capture D-Bus messages in a libpcap capture file.

It takes an idea from dbus-scrape, which processes a strace output of dbus-monitor, and takes it further by stracing dbus-daemon, thus not relying on any eavesdropping (mis)configuration.

The intended purpose is to establish the libpcap capture format as a base for debugging tools like

• dbus-monitor
• DBusMessageBox
• Bustle
• dbus-spy

Thanks to Will Thompson for mentioning the pcap idea.

Usage

$ sudo strace -p `pgrep -f 'dbus-daemon --system'` \
    -s 3000 -ttt -xx -o foo.strace
$ ./dbus-dump foo.strace foo.pcap
$ ./dbus-pcap-parse foo.pcap
Tue Nov 16 12:56:47 +0100 2010 #<DBus::Message:0xb741f340
 @body_length=0,
 @destination="fi.epitest.hostap.WPASupplicant",
 @error_name=nil,
 @flags=0,
 @interface="fi.epitest.hostap.WPASupplicant.Interface",
 @member="scan",
 @message_type=1,
 @params=[],
 @path="/fi/epitest/hostap/WPASupplicant/Interfaces/180",
 @protocol=1,
 @reply_serial=nil,
 @sender=":1.7132",
 @serial=88639,
 @signature="">
Tue Nov 16 12:56:47 +0100 2010 #<DBus::Message:0xb741b060
 @body_length=4,
 @destination=":1.7132",
[...]>

Dependencies

It is written in Ruby. The pcap format is handled by a small bundled module. dbus-dump has no other dependencies. dbus-pcap-parse uses ruby-dbus.

Bugs

This is an early proof-of-concept release, serving to introduce the libpcap format.

The main problem of dbus-dump is duplicating the messages, seeing them both when the daemon receives them and when it sends them (multiple times, for the signals).

The other tools haven't caught up yet:

$ /usr/sbin/tcpdump -r foo.pcap
reading from file foo.pcap, link-type 231
tcpdump: unknown data link type 231

Moin,

after 7 years with SUSE and Novell I’ve chosen to change something in my life – and decided to accept a new job and will lay down my duties in the openSUSE project. I’ve been with the openSUSE project already prior to its launch in August 2005 and experienced a number of highs and lows. Overall the project  has been shaping up nicely, we reached a lot of our goals and the just passed openSUSE conference reflects this pretty well in my opinion.

Just to stop any rumours – I leave Novell because I found a new job in the trade show management area close to Nuremberg. Trade show management is where my expertise is and where I worked prior to coming to openSUSE. While I enjoyed the work at openSUSE, organizing the openSUSE conference meant doing what I really love and my new job will give me many more conferences and trade shows to plan and organise.  As I will leave Novell before the end of December the project needs a new openSUSE chairman who should serve until the openSUSE foundation is created.

Best wishes to the openSUSE project and the people behind it. I had a lot of fun over the past 7 years, met numerous outstanding people and learned a lot which will help me in my future life.

Best
Michael

I have made a new release of ruby-dbus, a Ruby language binding for the D-Bus IPC system.
The main feature is a better binding of Ruby Exceptions to D-Bus Errors. See below for an excerpt of the documentation.
Perhaps more importantly, the library is now primarily packaged as a RubyGem (Issue#6). Also I converted the tutorial from Webgen to Markdown.
Bug fixes:

• Don't pass file descriptors to subprocesses, they would not let go of the service name.
• Fixed InterfaceElement::validate_name (Ticket#38, by Herwin Weststrate).
• Fixed a typo in InvalidDestinationName description (Ticket#40).

RPMs can be found via openSUSE Build Service Search.

Errors

D-Bus calls can reply with an error instead of a return value. An error is translated to a Ruby exception.

begin
    network_manager.sleep
rescue DBus::Error => e
    puts e unless e.name == "org.freedesktop.NetworkManager.AlreadyAsleepOrAwake"
end

Replying with an error

To reply to a dbus_method with a D-Bus error, raise a DBus::Error, as constructed by the error convenience function:

raise DBus.error("org.example.Error.SeatOccupied"), "Seat #{seat} is occupied"

If the error name is not specified, the generic org.freedesktop.DBus.Error.Failed is used.

raise DBus.error, "Seat #{seat} is occupied"
raise DBus.error

GIMP doesn't have any formal organisation. There is no association that would be able to have a bank account etc. So, since 2004 or thereabouts, any money that the GIMP project receives as donations has been kept by the GNOME Foundation.

Occasionally a consensus of GIMP developers then decides to spend some of these funds on various purposes that benefit the project. Like reimbursing travel expenses to GIMP meetings, which in recent years have been held in conjunction with the Libre Graphics Meeting.

But... it has been very slow getting the reimbursements paid this year. The necessary details (account numbers and amounts) was collected and provided to relevant people in the GNOME Foundation quite quickly after LGM, already during Summer. The information was sent, as requested, in a spreadsheet, with all invoices. But nothing happens. One can't help but wonder, what is going on?

The flight and accommodation expenses represent a significant amount of money to many of us who travelled to Brussels this year. How can we in the future convince people to come to the meeting if we have no idea if getting the travel expenses reimbursed will take months or years? Next year's LGM will be in Montréal, much further away for us Europeans, and thus with more expensive flights.

AJ requested DKMS which is the good news.

What is not so good are some comments that oppose need for DKMS.


Free and Open Source Software (FOSS) ideals are nice, and very special word in that name is Free, like freedom. Creating obstacles that will limit users ability to use what works for them will not help us, nor FOSS. We can recommend opensource software and install it by default, but we can't make sure that it works for everyone, in which case giving that as the only choice is forcing users to give up on Linux, or go elsewhere. Does that help to build user base?

With alternatives that are not very strict in enforcement of ideals (and ironically, bring few times more new users to the free and open source software), those that are not happy with openSUSE have no trouble to find what they need.

DKMS is solution for only one of obstacles, and there is many more. If we can't offer some stuff for legal reasons, there is no need to create other problems for people that want to run openSUSE.

Adding files to a SVN server is usually a task done in seconds. However, having several independent SVN repositories and wanting to “combine” them, this is not trivial—especially if you want to preserve the history.

The doc team had had three different, independent repositories on BerliOS (opensuse-ha-doc, opensuse-docmaker, and opensuse-lfl) all holding separate information. This was a bit silly, so my task was to consolidate them into opensuse-doc by keeping all history.

A SVN history is nice as you can see what you or others have done with the files. Loosing the history is the same as starting from scratch — which can be sometimes a good idea. In that case, the doc team wanted to preserve the history as we use it very often. So I had to think of a solution how to merge different SVN repositories into one. I came up with a solution containing the following steps:

1. Create a test repository
2. Create the dump files
3. Filter the dump files and extract trunk only
4. Rename trunk content
5. Edit the dump files
6. Load dump files into test repository

Several tools are needed: svnadmin and svndumpfilter are already available from the subversion package. Additionally, Darix recommended the svndumptool from devel:tools:scm:svn (thanks Darix!). A very convenient tool when dealing with SVN dumps.

Apart from this, all three SVN repositories consist of the usual trunk, branches, and a tags directories.

Step 1: Creating Test Repository

Before I got my hands dirty, I needed a test repository. Luckily, the subversion package contains everything what I need.  In my case, I’ve used the hotcopy command to create this test repository. I’ve logged in to BerliOS and made a hotcopy of my target SVN repository:

# ssh svn.berlios.de
# svnadmin hotcopy /svnroot/repos/opensuse-doc opensuse-doc

I did the same for my other repositories as well, just for safety reasons:

# svnadmin hotcopy /svnroot/repos/opensuse-lfl opensuse-lfl
# svnadmin hotcopy /svnroot/repos/opensuse-docmaker opensuse-docmaker
# svnadmin hotcopy /svnroot/repos/opensuse-ha-doc opensuse-ha-doc

Later, I will use the opensuse-doc hotcopy to test my modifications before I apply them to the production SVN repository. With this method, I wanted to make sure everything is correct. Of course, you have to be sure that nobody commits to your repositories, otherwise any later commits won’t be incorporated.

Step 2: Creating Dump Files

Dump files contain everything what’s inside a repository including SVN properties. However, they don’t contain the configuration or repository hooks from the repository. If you want to keep them, you’ll have to save them manually.

It’s very easy to create a dump file. In BerliOS, everything lives under /svnroot/repos/PROJECT:

# svnadmin dump /svnroot/repos/opensuse-lfl > opensuse-lfl.dump
# svnadmin dump /svnroot/repos/opensuse-docmaker > opensuse-docmaker.dump
# svnadmin dump /svnroot/repos/opensuse-ha-doc > opensuse-ha-doc.dump

The above lines create a dump file for each of my SVN repositories. As the BerliOS server doesn’t have the svndumptool command, I have to copy them to my own machine:

toms@earth:~ > scp shell.berlios.de:~/opensuse-*.dump .

Step 3: Extracting trunk

In most SVN repositories, tags and branches contain information which were at some point in time copied (for tags) or copied and modified later (for branches). I haven’t found a satisfying solution to use svndumptool and take into account these two directories. Anyway, I’ve decided to just concentrate on trunk and manually adjust tags and branches later. This makes it easier when dealing with dump files.

To extract only parts of a dump file, the svndumpfilter command is the right tool. Combined with the needed options and subcommands, I’ve used:

toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-docmaker.dump > docmaker-trunk.dump
toms@earth:~ > cat dumps/opensuse-ha-doc.dump | \
    svndumpfilter --renumber-revs --drop-empty-revs  include "trunk" | \
    svndumpfilter exclude trunk/package > ha-doc-trunk.dump
toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-lfl.dump > lfl-trunk.dump

The commands are not exactly the same, as the SVN repositories are slightly different. For example, the opensuse-ha-doc repo contained a trunk/package directory which I don’t want. Therefor you see the exclude command in svndumpfilter. The resulting dump files contain only trunk, nothing else.

Step 4: Renaming trunk Directory

The last step created dump files which contain only the trunk directory. The dump files can already be loaded into the target SVN repository. However, this is only partly successful. After loading you have to rename and move subdirectories around which is unconvenient. To avoid this cumbersome task, I’ve used the svndumptool command which does the job directly on the dump file!

For example, the former docmaker repository has to appear under trunk/tools/docmaker, not directly under trunk. This can be done with the merge subcommand of svndumptool:

toms@earth:~ > svndumptool merge -o docmaker-trunk-rename.dump \
   -i docmaker-trunk.dump \
   -s '^trunk' 'trunk/tools/docmaker' \
   -d trunk/tools/docmaker

The -d option creates the trunk/tools/docmaker directory in case it doesn’t exist in your target. The -i and -o options are the input and output stream of the dump files, -s contains a regular expression how to rename the source (^trunk) into the target (trunk/tools/docmaker). The other repositories are similar:

toms@earth:~ > svndumptool merge -o ha-doc-trunk-rename.dump  \
  -i ha-doc-trunk.dump \
  -d trunk/documents/ha/ \
  -s '^trunk/books/en' 'trunk/documents/ha/en' \
  -s '^trunk/books' 'trunk/documents'
toms@earth:~ > svndumptool merge -o lfl-trunk-rename.dump  \
  -i lfl-trunk.dump \
  -d trunk/documents/lfl/ \
  -s '^trunk/books/en' 'trunk/documents/lfl/en' \
  -s '^trunk/books' 'trunk/documents'

After this step I have three files, named *-trunk-rename.dump which contains the renamed directories.

Step 5: Editing Dump File

This step is a bit tricky and I haven’t found a better solution yet. Probably this can also be done with cat and sed magic, but I preferred vi. The task is to list the content of the dump files and decide which directory entries need to be deleted. This step is absolutely necessary to avoid any SVN error (something like “directory/file already exists”) when trying to load the dump file into the repository.

1. Get an overview of the contents:

   toms@earth:~ > svndumptool ls ha-doc-trunk-rename.dump
   /trunk
   ...
   toms@earth:~ > svndumptool ls docmaker-trunk-rename.dump
   /trunk
   /trunk/documents

   Usually this is /trunk and probably some other directories (depending on the structure).

2. Modify the dump file(s) and remove any directories which are available in the target SVN repository.
   The renamed directories from the last step contains a single trunk “node” which has to be removed. The same applies for trunk/documents. Both exist already on the BerliOS server. Manually edit the dump files and remove the following lines:

   Node-path: trunk
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
   PROPS-END
   ...
   Node-path: trunk/documents
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
     [[ Some other content could be available here ]]
   PROPS-END

3. Save the dump file

Be careful! It is very important not to destroy any structure in the dump file!

I’ve checked the result with “svndumptool ls DUMPFILE”. No lonely trunk directory should be shown anymore. To be on the safe side, I’ve checked the two files with svndumptool check -A DUMPFILE, too.

Step 6: Loading Dump Files into Test Repository

The last step created the dump files with the correct structure. As this was done on my own machine, I have to copy the files back to BerliOS (remember to use the shell.berlios.de server):

toms@earth:~ > scp *-rename.dump  shell.berlios.de:

It’s almost done! Logged into BerliOS and loaded the dump files in my hotcopy test repository (see step 1):

# svnadmin load opensuse-doc  < docmaker-trunk-rename.dump
# svnadmin load opensuse-doc  < ha-doc-trunk-rename.dump
# svnadmin load opensuse-doc  < lfl-trunk-rename.dump

After playing around a bit, everything was successful. So I repeated it, but replaced the opensuse-doc hotcopy with the correct path /svnroot/repos/opensuse-doc.

The remaining pieces are the tags and branches directory. As revision numbers have been changed, the revision number in the original repository and the revision number in opensuse-doc are obviously not the same anymore. Creating tags can only be done with a correct date, because dates are preserved. For this reason, it is convenient to still have the original repositories around to look for the exact date and log message:

$ svn copy -r "{2010-10-20T10:00:00}" -m "..." \
   $BERLIOSURL/trunk/tools/docmaker \
   $BERLIOSURL/tags/tools/docmaker/obs

The branches are a bit different. Maybe the history can be preserved with the same method as with trunk, but I haven’t tried it. Our three repositories hadn’t had meaningful information in branch, or it wasn’t worth the effort.

Conclusion

The steps above showed how to merge different SVN repository into one while keeping the history.  Unfortunately, this task could be easier. Although svndumpfilter is very easy, it is also very limited. Especially when you have to modify the dump file itself, svndumpfilter won’t rescue you. It would be very good, if svndumpfilter could be extended to work with dump files in the same way as svndumptool. That would be fun.

One of the features we want to include in the next MonoDevelop release is integrated support of Git. I committed a first version of a git add-in some months ago which works by invoking the git command and parsing the results. This solution satisfied some basic needs (Mono was moving to git at that time), but it was done as a short term solution, since parsing git output is not very reliable, and has portability issues.