stick's corner

… and I’m looking forward to meeting you all! I will also give a talk about RPM Packaging Collaboration so remember to show up on Sunday if you are interested!

Today I had a very nice surprise laying on my office desk. It was a postcard from my dear friends from Brno (so called #fedora-cs mafia ) depicting a 3D image of a geeko on sand. Luckily I was able to find two shops (here and here) which offer this jewel. The latter one also had the 3D picture so I can share this viewing pleasure with you (click on it to animate):

It looks even better in real-life!

I use Mozilla Thunderbird as my e-mail client and I prefer plain-text messages over HTML format. When you view a threaded conversation it looks like this:

I found a little hack on Mozilla website which adds different colors for various quote levels in messages. Unfortunately the example is no longer valid for Thunderbird 3, because the default color scheme had changed. I modified the CSS to fit the new look and ended up with this:

If you like it, just run the following code to have it applied:

cd ~/.thunderbird/*.default
mkdir chrome
cat <<EOF > chrome/userContent.css
/* Quote Levels Colors */
/* bar color: #729fcf */
blockquote[type=cite] {
    color: #394f67 !important;
    background-color: #edf3f9 !important;
}
/* bar color: #ad7fa8 */
blockquote[type=cite] blockquote {
    color: #563f54 !important;
    background-color: #f4eff4 !important;
}
/* bar color: #8ae234 */
blockquote[type=cite] blockquote blockquote {
    color: #45711a !important;
    background-color: #f0fbe5 !important;
}
/* bar color: #fcaf3e */
blockquote[type=cite] blockquote blockquote blockquote {
    color: #7e571f !important;
    background-color: #fef5e6 !important;
}
/* bar color: #e9b96e */
blockquote[type=cite] blockquote blockquote blockquote blockquote {
    color: #745c37 !important;
    background-color: #fcf6ec !important;
}
EOF

Don’t forget to restart Thunderbird!

If you are closely following Ruby development and especially the situation around ruby gems, you might already know of Gemcutter. It is a new service, which provides a very easy way how to publish gems and also a good API to deal with them. It is not trying to replace RubyForge as whole, just its gem hosting (+ now defunct GitHub gem hosting) and will soon become the central and the only place for Ruby gems. The whole site is MIT licensed and the code is available on GitHub.

During the winter holidays I wrote a simple script which utilizes the Gemcutter API and prints versions of rubygem-* packages in our devel:languages:ruby:extensions Build Service repository compared with the corresponding gem versions on Gemcutter. Using this script and a great gem2rpm (more particularly gem2rpm-opensuse command which applies openSUSE template and is available from rubygem-gem2rpm package), I was able to update nearly a hundred of gems in just two hours. Rails rubygems have a specific packaging in openSUSE, so I left them out, but more than 90% of the rest didn’t need any changes in autogenerated spec file.

This brought me an idea. If only Gemcutter had an option to somehow send out notification that a new gem has been pushed, we could automate the process and have up-to-date rubygems in our devel:languages:ruby:extensions repository almost instantly. (We would still need to keep the list of “dirty” rubygems that need to be updated manually, though. For example, Rails packages I mentioned earlier, where we keep multiple versions, or others where we need to add a patch replacing /usr/local/bin/ruby with /usr/bin/ruby in scripts).

Few days later, Gemcutter gained RSS feed support, but only for the gems one is interested in. I didn’t find the option to have RSS feed for all gems. This could have helped in creating such mechanism, but that won’t be needed anymore because …

… yesterday Nick Quaranto of Gemcutter announced webhook support. I’m really excited, because that’s exactly what we need! When one registers a webhook, Gemcutter emits a POST request on a certain URL when a gem is pushed or updated. This request is a JSON document containing the info about gem. What we need is to create a mechanism that:

• receives notification via POST JSON request
• checks whether the package is not “dirty” → exit if it is (and probably send some email …)
• fetches the package from the Build Service or create a new one
• fetches the new gem, removes the old one
• runs gem2rpm-opensuse to create a spec file replacing the old one
• adds changelog entry
• pushes the updated package back into the Build Service

Last but not least: If Fedora and Mandriva had gem2rpm templates in a perfect shape too, Build Service could provide packaged gems also for their distributions.

So what do you think? Any volunteers for this? Right now, I’m off to fix some small bugs I found in gem2rpm while fiddling with it …

I wish you a Merry Christmas and a Rocking New Year 2010!

(created using geekobuilder)

If you need to get the full URL of an image, just put the following code snippet into ApplicationHelper module in your app/helpers/application_helper.rb:

  def image_url(source)
    abs_path = image_path(source)
    unless abs_path =~ /^http/
      abs_path = "#{request.protocol}#{request.host_with_port}#{abs_path}"
    end
   abs_path
  end

I wonder why this function is not already a standard part of Rails.

(Idea by Rob Biedenharn)

Thanks to Tom we now have avatars in openSUSE Build Service, so e.g. Involved Users list looks like this:

If you have a shady man instead of your nice photo, go to gravatar.com and setup your own one. Don’t forget to add the email address you are using in the Build Service!

I travel to work by bus. While they are usually in Prague Public Transit’s traditional colors – red and white, today this one came to bus stop:

I was really happy that I could go to SUSE offices on Geeko Bus. It really made my day!

Today I applied the new Robert Lihm’s theme called Bento to GameStore web, so it doesn’t look like a quick hack anymore. This theme, which will be used across all openSUSE.org websites in the future, will also help to integrate GameStore into rest of the openSUSE infrastructure. You can visit the site by clicking on the mandatory screenshot below.

The middle of November was very exciting for both Fedora and openSUSE communities. At first, openSUSE project unleashed its 11.2 release, which was followed by Fedora 12 a few days after. I thought it would be interesting to dig into bug reports which were filed during the development of these two releases in respective bugzillas.

I’m not going to compare the absolute number of bugs, nor the ratio of reported/closed ones, because I think these statistics are easy to find. Also, Fedora 12 development took 6 months, while openSUSE 11.2 took 11 months and this is not very comparable. What I was interested in was how much work happens inside the companies and how much outside their walls, in the community. Please, bear in mind that development is not only about reporting, closing bugs and their count. A lot also happens on wikis, openFATE or other tools, so these statistics could be a little bit skewed. Enough talking, here comes the data and charts …

* – assignee could be mailing list, it does not have to be an individual

Chart 1: Bugs reported by

Chart 2: Unique reporters

When we look at the reporters charts, we see that they are quite similar. This is good!

Chart 3: Bugs assigned to

Chart 4: Unique assignees

The next two charts are where we can see drastic differences. What are the reasons for this? Well, I was able to come up with these:

• like mentioned above, openSUSE project utilizes other tools, e.g. openFATE, to steer development
• openSUSE is younger project than Fedora, so the community involvement is lower (sometimes it is still very hard for externals to understand WHAT and HOW should be achieved)
• Novell folks do not reassign bugs to community members, even if the problem is fixed via Build Service submit request, the bug stays assigned to ‘insider’ who closes it
• some of the assignees are in fact mailing lists that contain both internal and external people, but they belong to novell.com domain
• Fedora uses bugzilla for package reviews, these often include external people but are not actual bug reports

Can you think of any more reasons? What can we do to improve the situation and to engage openSUSE community more?