Disclaimer: the next paragraphs may sound presumptuous, but they're not. I swear.

It has occurred to me, time and time again, that some people consider others as semi-gods. People who are highly active e.g. in open source projects, and are sometimes even regarded for their work. Well, it sucks.

I know that this has happened to me a few times (being seen as a semi-god, that is), and I hate it. Not only does it not have any ground for being, we're just folks like everyone else, and while hard and good work should be appreciated, and while a simple "thank you" is way too rare and rewarding, taking it to that level is a very-bad-thing (tm)

The main reason for it to be bad is that it breaks communication, it puts artificial barriers between people. Now, I can only speak for myself, but I want people to talk to me, to come to me, say hi, and have a chat about virtually anything, be it on the matter of the openSUSE project or not.

I like hearing about cultural differences, about experiences people make in their life, about funny and not-so-funny moments. I love spending time talking to people, especially "broken" people, who have gone through hard times (haven't we all ?), because they're full of life, full of content, even if it's sorrow. But hey, I like having a good time with happy people too ;).

But culture is often in the way of common sense and the ability to communicate across those artificial differences, specifically when we're talking about the differences in behavior and, well, yes, communication, precisely.

Generalization is always wrong (got it?), but there are a few traits that nevertheless apply in a very fuzzy way. Germans usually don't like physical contact, getting too much in their protective circle. They don't really like people who talk much either, or who behave in an extroverted way. Latins (French, Spaniards, Greeks, Italians, ...) often appear as sloppy, too relaxed, they don't take appointments seriously, they're always late, they're always talking, and loud, etc... Well hell yes. Asian cultures (in the broad geographic sense) are even more mind-boggling (to us Europeans, that is). North Americans are said to be quite vocal and easy to get in touch with, but don't appreciate digging a little deeper. Germans say things pretty straight as they are ("this sucks" is often perfectly acceptable). All those differences, all those barriers to understanding what we say to each other, and how we mean it.

At the openSUSE Conference or wherever we may meet, or even through electronic media, drop those differences, don't bother, say things straight up as they are, but be relaxed, have a good time, be vocal, talk, say what's on your mind. Don't be afraid to hurt feelings, you won't, because we're all a big happy (and sometimes grumpy) bunch of friends. Feel at home, this is your community. I am your friend. Poke me with a stick, give me a hug, talk to me out of the blue, whatever, slice me into pieces and put salt on it (that's a special for Alberto), I don't care. But don't remain silent, intimidated, blocked by your cultural background and, at the same time, be inclusive and accept those differences, to a certain extent (full circle or chicken/egg ?).

See you there, or anywhere else, and give me a hug, or at least a high five ;).

Big mistake, big mistake. At the call for papers deadline, we ended up with not having any sessions about packaging at all except one by Jan Engelhardt.

Now, that would have been quite a ludicrous situation, as our core activity is precisely to build packages, without which it wouldn't be a distribution in the first place.

So I picked up an early email from Lars Vogdt who proposed a few sessions on the topic of packaging. Unfortunately, it was really early in the call for papers phase and we weren't quite organized yet, which caused his proposal to remain unanswered for a few weeks. I tried to contact him by email a few times, but he didn't reply (until now, that is), and I nevertheless took it up on myself to do a few packaging related sessions at the conference.

Introduction to Packaging

One thing that some people in the project have been bugging (me) about on a regular basis is an introductory presentation about packaging for openSUSE. Having been doing that for around 10 years on an almost daily basis, I can indeed understand that it appears as a daunting task and somewhat of a black art (which it is).
So here we go: Introduction to Packaging (Sunday 11 Sept in Brendl, at 11:45). The key here is that I am not assuming any prior knowledge at all. If you're already versed into packaging, this isn't for you. But if you always wanted to know about the main activity of our project, at least in technical terms, you totally have to be there.

Mind you, after that presentation, you will not be able to write your first package, but it will give you an understanding of what packages actually are, the terms, the ecosystem, the process, the toolchains and... well... what the hell it actually takes to create an RPM package for openSUSE. It does sound boring, and too technical, but it isn't. Trust me, we'll have a good time. I'm looking forward to seeing a lot of folks there with an appetite for finding out, and a lot of questions I'll more than happily be able to answer.

Workshops

Obviously, we're not going to stop there. For those who will have attended the above mentioned presentation, as well as for the folks who have a fuzzy idea of how to build packages, but have never actually tried to do so (or did but failed), there is something for you as well: Packaging, hands-on: on Monday, in the BR-Room, at 14:00, I will guide you for two hours through your first steps at accomplishing what is next to witchcraft: building your first package, on your own, on your notebook.

The purpose here is to take every fear away at barriers to enter the secret cult of RPM wizardry. So bring along your notebook, a shell, vim or whatever editor you prefer, an openSUSE Build Service account (go to this mind-boggling URL to create an openSUSE account if you don't have one already -- if you have an openSUSE account, you have everything you need), and we'll do it step by step, slowly, to bring you to the overwhelming feeling of joy once you will have your first (and hopefully not last) RPM package for openSUSE on your harddisk.

Upping the ante

Can we do even better than that? Sure, we can. On Tuesday, there will be a second workshop session: Advanced Packaging, at 14:00 in the BR-Room. That one will be a bit more improvised, but we'll take on more complex scenarios, depending on what we will not have covered in the previous workshop. Things like subpackages, -devel packages, distribution integration, shared library packages (and the openSUSE packaging guidelines that apply to them), packaging Perl modules, Python modules, etc...

And the rest...

There are quite a few additional sessions that have my name on it, but I won't be able to organize those as well. So I'm looking for people to take them on.

Oh, and please bug me at the conference. I'm tall, and look evil, and can be evil at times, I have a creepy looking G+ profile photo (on purpose, I like it), but I don't bite, I don't pose, I'm a rather nice guy. As I'm not German, I don't mind hugs either, much like our all around nice guy from the flat of the land.

I've been in this project for a very long time, been involved in various bits of it, and have quite some experience in several technical (and not so technical) areas. I hope we'll be able to un-organize some small sessions on various matters you'd like to know more about, I'm sure I can help, and I totally want to spread my experience around. This conference is YOUR conference, so make the most of it (want to stress that so much that I even adhere to the bad practice of using <b/> tags in HTML). Drop your cultural habits for a few days, don't be shy, let's talk, have some beers (or water), get to know each other and, most importantly, have a lot of fun.

So, hopefully, see you there!

As I was starting the OBS webserver earlier today, I ran into a missing-gem error:

Missing these required gems:
  ci_reporter

So I installed the gem.

$ sudo gem install ci_reporter
Fetching: ci_reporter-1.6.5.gem (100%)
Successfully installed ci_reporter-1.6.5
1 gem installed

There was an error installing the documentation for ci_report:

Installing ri documentation for ci_reporter-1.6.5...

Invalid output formatter

For help on options, try 'rdoc --help'

ERROR:  While generating documentation for ci_reporter-1.6.5
... MESSAGE:   exit
... RDOC args: --ri --op /usr/lib/ruby/gems/1.8/doc/ci_reporter-1.6.5/ri --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.5 Documentation
(continuing with the rest of the installation)
Installing RDoc documentation for ci_reporter-1.6.5...

Invalid output formatter

For help on options, try 'rdoc --help'

ERROR:  While generating documentation for ci_reporter-1.6.5
... MESSAGE:   exit
... RDOC args: --op /usr/lib/ruby/gems/1.8/doc/ci_reporter-1.6.5/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.5 Documentation
(continuing with the rest of the installation)

But this error didn’t interfere with my starting the web server.

Anyway, I was curious what ci_report was all about.

CI::Reporter is an add-on to Test::Unit, RSpec and Cucumber that allows you to generate XML reports of your test, spec and/or feature runs. The resulting files can be read by a continuous integration system that understands Ant’s JUnit report XML format, thus allowing your CI system to track test/spec successes and failures.

It looks like CI::Reporter works best with projects that use a Rakefile along with the standard Rake::TestTask or Spec::Rake::SpecTask/RSpec::Core::RakeTask tasks for running tests or examples, respectively. This way, it hooks into Test::Unit or RSpec using environment variables recognized by these custom tasks to inject the CI::Reporter code into the test or spec runs.

There isn’t a fair amount of documentation on CI::Reporter yet, except: http://caldersphere.rubyforge.org/ci_reporter/

Back from the FrOSCon conference (the only one that has even weirder capitalization than openSUSE ;D).
Mixed feelings. While it was a bit boring during the day as there was pretty much no one passing by the stands (not just ours), I'm not really convinced it's that useful to have a stand there... Of course, the great weather didn't help, as most non-contributor-people who would might have come to the conference out of curiosity will most definitely have preferred making good use of the sunny weather that weekend. Understandable :)

Mind you, I definitely had a good time, as the organization is very well done, the catering is nice (at least for speakers and booth personnel, didn't try the other options), the barbecue with DJ on Saturday evening was excellent, and, of course, I got to see quite a lot of people I know through openSUSE and FOSDEM (quite a lot of people wearing the ultimate street cred t-shirt of FOSDEM supporters, btw ;)), and a few I didn't. Got to chat a lot with core Mageia contributors as well, which was definitely fun and interesting. Hence, lots of great FOSS people around, awesome.
Was obviously also great in the evening/night, chatting around beers (even if it was Kölsch (yellow water with a tiny bit of alcohol and some bitter)) with fellow contributors across different projects. Also got to meet Jan Krings for the first time (as well as Marcus Möller, Jan Krings and Jan Weber, which I've met IRL before).

If you've never been at such events (even more striking at FOSDEM methinks, because there's a huge crowd, with lots and lots of projects there, and a lot of discussions and cross-pollination going around), and are mostly on the "user" side of things, then just stop the hate. Forget about distrowars, competition, and all that. That's just totally not how it works for almost all the people who actively contribute to their projects. Even between BSD and Linux. We may have our differences and preferences, but we all respect the work, brains, excellence, and love everyone is putting into their respective undertakings.

But in terms of audience, I wonder whether FrOSCon shouldn't have a sharper focus. At least, the focus wasn't all that clear to me, it seems like the target is "everything". There are stands of distribution projects, which are typically for the non-Linux/BSD-users-yet to grab some DVDs and play with it. There are stands of vendors, who pay for their stand, and whom are either selling books, or showcasing their services and solutions to potential customers, or hunting for highly qualified hackers. That's a pretty different audience already, at least when compared to the more entry-level distribution showcase stands. Then there are tracks and "devrooms" (yes, they really call them the same as at FOSDEM :)), which is .. dunno.. depends, some did sound more advanced, for developers, and some were a lot more entry level (e.g., paraphrasing, "openoffice.org is open source, what does that mean for me, user ?").

Just my 2 cents, but I'm under the impression that it could serve a better purpose to be less general purpose and have a slightly sharper focus in terms of target audience. But hey, maybe it was just the weather (heard from others, e.g. from fellow openSUSEr Jan Weber) that there were clearly a lot more people the years before), and maybe the organizers are just fine with the amount and type of audience that was there.

Software Center with PackageKit backend in openSUSE Factory

Today the official coding period of GSoC 2011 ends. It’s been a four months journey, with challenges, failures and achievements, but nevertheless fun .

You may be wondering what is the status of my project; here it goes: current version of Software Center can be tested in openSUSE Factory; it can populate its database with data from an AppStream XML; it shows application information (fetched from the package manager); it installs and removes software, in the same friendly manner the ubuntu does (showing progress, handling dependencies).

Moreover, my patches to gobject-introspection, PackageKit and obviously software-center, are all upstream and released; kudos to the project managers and the community for helping me get them there.

There are still parts that need work; some of then have been intentionally left with lower priority from my initial plan, in order to get a functional version up by the end of the program; others weren’t covered by the planed feature set. These are: performance (current version is rather slow on first load, and also on showing list, due to many resolve calls), transaction history (it can be implemented using the almighty PackageKit), reviews (currently these are fetched from ubuntu servers), screenshots (same as reviews). Software Center itself passes a period of active development and changes, once its fancy Gtk+3 interface stabilizes, more work can be done into polishing the <other-distro> experience.

Although I’m generally happy with the result of the project, since this is a report, I want to outline what differed from my expectations and slowed me down from bringing a full feature set cross-distro Software Center:

• fast development – when I started hacking on software-center’s GUI, it was pygtk Gtk+2 based; a Gtk+3 branch existed, but was far from being usable; under the last few weeks, it was merged, and actively developed into a newly designed interface (which will become software-center 5.0);
• Gio, GLib, GMenu, GObject, usually libs starting with a capital G, which introspection bindings are about to stabilize; having to get them from trunk, and dealing with API breakage;
• waiting for the pygobject release; when it came, it broke my pygtk mixed work (since static vs GI are no longer permitted in the same program – which is the right choice. btw), and left me with no working GUI; luckily, I took the best advices on IRC, and also software-center devs fixed things along, so that the new UI isn’t affected by the underlying changes.

Something worth mentioning in this finale post is that OBS totally rocks.

Overall, I hope this effort won’t stop here, and with a bit of luck, it will be shipped by your favorite distribution

PS: for more implementation/testing/plan details, I have created this page on openSUSE wiki, please check it out.

Another problem I’ve run into while starting the obs web server after the system upgrade is:

/build-service/src/webui> ./script/server
=> Booting WEBrick
=> Rails 2.3.11 application starting on http://0.0.0.0:3000
No local development environment found: No such file or directory - /home/surfmonkey/branch/build-service/src/webui/config/environments/development.opensuse.rb
Using global development environment /home/surfmonkey/branch/build-service/src/webui/config/environments/development_base.rb
** Erubis 2.6.6
Missing these required gems:
 daemons  

You're running:
  ruby 1.8.7.334 at /usr/bin/ruby
  rubygems 1.5.0 at /home/surfmonkey/.gem/ruby/1.8, /usr/lib/ruby/gems/1.8

Run `rake gems:install` to install the missing gems.

I don’t remember running into this problem before.

$ rake gem:install daemons
rake/rdoctask is deprecated. Use rdoc/task instead (in RDoc 2.4.2+)
rake aborted!
Don't know how to build task 'gem:install'

The stack traces look like the following:

/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/task_manager.rb:49:in `[]'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:111:in `invoke_task'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:90:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:90:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:90:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:84:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:62:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/lib/rake/application.rb:59:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.1/bin/rake:32
/usr/bin/rake:19:in `load'
/usr/bin/rake:19

So I open up my Rakefile and make these lines

require 'rake'
require 'rake/testtask'
require 'rake/rdoctask'

to

require 'rake'
require 'rake/testtask'
require 'rdoc/task'

Supposedly, I should also add gem “rdoc” to my Gemfile:

$ cat /usr/lib/ruby/gems/1.8/gems/jquery-rails-1.0.9/Gemfile
source :gemcutter

# Specify your gem's dependencies in jquery-rails.gemspec
gemspec
# Rails is already being pulled in through gemspec
# gem "rails", :git => "git://github.com/rails/rails.git"
gem "rack", :git => "git://github.com/rack/rack.git"
gem "sprockets", :git => "git://github.com/sstephenson/sprockets.git"
gem "i18n", "0.6.0beta1"

But I’m unable to overwrite the write permission:

I don’t understand what’s going on. Deleting gemfile.lock wouldn’t help.

Someone on the web suggested adding rdoc/ to my .gitignore, too.

Anyway, I just go ahead and install the daemons:

$ sudo gem install daemons
Fetching: daemons-1.1.4.gem (100%)
Successfully installed daemons-1.1.4
1 gem installed
Installing ri documentation for daemons-1.1.4...
Installing RDoc documentation for daemons-1.1.4...

So what are these daemons, after all?

Daemons provides an easy way to wrap existing ruby scripts (for example, a self-written server) to be run as a daemon and to be controlled by simple start/stop/restart commands. You can also call blocks as daemons and control them from the parent or just daemonize the current process. Besides this basic functionality, daemons offers many advanced features like exception backtracing and logging (in case your ruby script crashes) and monitoring and automatic restarting of your processes if they crash.  — RubyGems.org

Finally, I’m able to successfully start the web server:

$ ./script/server
=> Booting WEBrick
=> Rails 2.3.11 application starting on http://0.0.0.0:3000
No local development environment found: No such file or directory - /home/surfmonkey/branch/build-service/src/webui/config/environments/development.opensuse.rb
Using global development environment /home/surfmonkey/branch/build-service/src/webui/config/environments/development_base.rb
** Erubis 2.6.6
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-08-22 16:03:59] INFO  WEBrick 1.3.1
[2011-08-22 16:03:59] INFO  ruby 1.8.7 (2011-02-18) [i586-linux]
[2011-08-22 16:03:59] INFO  WEBrick::HTTPServer#start: pid=9781 port=3000

. . . . . .

Since I upgraded openSUSE 11.3 to 11.4, the dependencies in my local buildservice repository got updated as well. When I tried to start the web server, it failed:

~/branch/build-service/src/webui> ./script/server
=> Booting WEBrick
=> Rails 2.3.11 application starting on http://0.0.0.0:3000
/usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:29:in `gem_original_require': no such file to load -- nokogiri (MissingSourceFile)

Nokogiri parses and searches XML/HTML very quickly, and also provides CSS3 selector support and XPath support for document searching.

I installed the nokogiri parser before the system upgrade, but it might’ve gotten lost or updated during the upgrade. So I have to install nokogiri again on 11.4:

~/branch/build-service/src/webui> sudo gem install nokogiri
Fetching: nokogiri-1.5.0.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing nokogiri:
        ERROR: Failed to build gem native extension.

        /usr/bin/ruby extconf.rb
checking for libxml/parser.h... no
-----
libxml2 is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

I remember seeing this problem before. The solution is to simply install the dependencies first:

$ sudo zypper install libxml2
Loading repository data...
Reading installed packages...
'libxml2' is already installed.
No update candidate for 'libxml2-2.7.8-16.17.1.i586'. The highest available version is already installed.
Resolving package dependencies...

Nothing to do.

The trick is to install libxml-devel package instead:

$ sudo zypper install libxml2-devel
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW packages are going to be installed:
  libxml2-devel ncurses-devel readline-devel 

3 new packages to install.
Overall download size: 2.6 MiB. After the operation, additional 18.9 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package ncurses-devel-5.7-14.1.i586 (1/3), 2.5 MiB (18.4 MiB unpacked)
Retrieving: ncurses-devel-5.7-14.1.i586.rpm [done (230.3 KiB/s)]
Retrieving package readline-devel-6.1-18.25.1.i586 (2/3), 42.0 KiB (75.0 KiB unpacked)
Retrieving: readline-devel-6.1-18.25.1.i586.rpm [done (0 B/s)]
Retrieving package libxml2-devel-2.7.8-16.17.1.i586 (3/3), 81.0 KiB (427.0 KiB unpacked)
Retrieving: libxml2-devel-2.7.8-16.17.1.i586.rpm [done (165.1 KiB/s)]
Installing: ncurses-devel-5.7-14.1 [done]
Installing: readline-devel-6.1-18.25.1 [done]
Installing: libxml2-devel-2.7.8-16.17.1 [done]

Also, install libxslt-devel:

$ sudo zypper install libxslt-devel
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW packages are going to be installed:
  libgcrypt-devel libgpg-error-devel libxslt-devel 

3 new packages to install.
Overall download size: 355.0 KiB. After the operation, additional 2.0 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package libgpg-error-devel-1.9-4.1.i586 (1/3), 47.0 KiB (216.0 KiB unpacked)
Retrieving: libgpg-error-devel-1.9-4.1.i586.rpm [done (156.2 KiB/s)]
Retrieving package libgcrypt-devel-1.4.6-3.1.i586 (2/3), 106.0 KiB (183.0 KiB unpacked)
Retrieving: libgcrypt-devel-1.4.6-3.1.i586.rpm [done (213.0 KiB/s)]
Retrieving package libxslt-devel-1.1.26-2.1.i586 (3/3), 202.0 KiB (1.6 MiB unpacked)
Retrieving: libxslt-devel-1.1.26-2.1.i586.rpm [done (228.3 KiB/s)]
Installing: libgpg-error-devel-1.9-4.1 [done]
Installing: libgcrypt-devel-1.4.6-3.1 [done]
Installing: libxslt-devel-1.1.26-2.1 [done]

It looks like nokogiri needs both of these two dependencies resolved first:

☑ libxml/parser.h 
☑ libxslt/xslt.h

Thus, the requirements for installing nokogiri are:

✓ ruby 1.8 or 1.9
✓ libxml2
✓ libxml2-dev
✓ libxslt
✓ libxslt-dev

Then, I’m able to install nokogiri:

$ sudo gem install nokogiri
Building native extensions.  This could take a while...
Successfully installed nokogiri-1.5.0
1 gem installed
Installing ri documentation for nokogiri-1.5.0...
No definition for get_options
No definition for set_options
No definition for parse_memory
No definition for parse_file
No definition for parse_with
Installing RDoc documentation for nokogiri-1.5.0...

• – – – – – –