~kanarip

Just for fun, I started building ruby-1.8.6 and ruby-1.9.1 packages for Enterprise Linux 5. These would be opt-in repositories, "channels" if you will, fast-tracking an Enterprise Linux 5 box to newer versions of Ruby, and many of the packages that depend on Ruby one way or the other (such as Ruby on Rails packages, and many Ruby Gems).

I started out with the Fedora packages, obviously, and after getting a bunch of packages in said repositories, and testing and patching and rebuilding a bunch of times, it became obvious;

For the type of situation where you want two of these "fast-track" repositories, or even just multiple versions of the same packages built under different conditions, it turns out to be mandatory that a Koji build of a certain package contains a globally unique package NEVRA (Name, Epoch, Version, Release, Architecture), so they can be distinguished between the two (very much different) versions of the package. That is to say, one package NEVRA can only be built once, and can only be duplicated to other destination tags.

Example: The ruby-shadow package (a requirement for Puppet, which makes it very important to me) is binary compiled, either against ruby-1.8.6 or ruby-1.9.1. For one version (e.g. upstream's 0.9.7) to be available through both repositories, one builds ruby-shadow-0.9.7-1.el5.src.rpm.

I build the package against two Koji build targets, each one using a build tag that causes a buildroot to be created with either ruby-1.8.6 or ruby-1.9.1; in my case these build targets are feature-el5-ruby-1.8.6 and feature-el5-ruby-1.9.1.

Koji however will only allow one specific package NEVRA to be built just once. But, ruby-shadow-0.9.7-1.el5.src.rpm has to be built twice; once for ruby-1.8.6, and once for ruby-1.9.1. Since one build with the same NEVRA already exists, another cannot be built.

Ergo, you need some kind of indication of the build-root/build-tag/destionation-tag in the package NEVRA...

And we go off rebuilding everything again... ;-)

Note to self: when using external repositories and building on those, please remember that priorities in tag inheritance does matter.

Thank you.

Today is the day we come together with a bunch of Linux experts, and start knocking down some of the items on our TODO list, as well as -hopefully- share more information and responsibility on the overall Linux infrastructure inside our company, and the Linux infrastructure at a lot of out customers both!

On February 9th, Mike McGrath wrote:

Toshio Kuratomi is awesome.

That is all.

+1 Mike, and so are you!

I'm very much pleased to be able to announce that Zarafa, one of the best Linux groupware suites, is now available through the standard Fedora and EPEL repositories.

After Zarafa itself had already announced inclusion to the repositories, news that was dented through major news sites such as heise.de, Robert Scheck and myself sat together at FOSDEM and worked on the packaging until we were both sufficiently satisfied.

It's currently set up to allow the maximum amount of flexibility one could ever wish for. Normally, the packages provided by Zarafa consist of the backend server, gateway (IMAP/POP), the PHP libraries needed for the Webmail interface, and too many other things to really build up a scalable infrastructure without installing all capabilities on all servers in such infrastructure -which introduces it's own world of pain.

Now, apparently, we still need to figure out some things. For one, I get a SIGPIPE / Broken pipe when I run zarafa-server with UNIX passwd authentication. The availability of a platform like Fedora (fast-pace moving forward) allows us however to solve this kind of issues way before Enterprise Linux 6 hits public beta.

You gotta love it!

I've always been a huge fan of Zarafa, one of merely two serious competitors in the Open Source groupware market.

The other competitor is Zimbra, but I have somewhat less of an incentive to sink my teeth into that Java mess, which installs in /opt/zimbra/, and uses it's own vendored libraries rather then those available in the system stack. This, in my opinion, is just wrong, raises cost and gives you less overall options and control. But enough about Zimbra, because obviously the suite *just works* (and a lot of people are very much happy with it).

I have (and still am) running Zarafa at my company for about a thousand users, and Zarafa's headquarters are pretty close to my company's. I get to speak to Zarafa's people regularly, and most of it is while I'm wearing my Fedora hat ;-)

Either way, now that Robert Scheck and myself are attempting to package Zarafa for our dear distribution, Robert and I run into the following when using Fedora 12:

[jmeeuwen@ghandalf SPECS.mine]$ sudo zarafa-spooler -F
zarafa-spooler: symbol lookup error: /usr/lib64/libmapi.so.1: undefined symbol: _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_

Robert has created a topic on Zarafa's forum about this some time ago.

Let me first emphasize that Zarafa is upstream for three libraries:

1. inetmapi
2. perlmapi
3. libmapi

This symbol is undefined in libmapi only, as you can see in Robert's comment.

I once succeeded (I don't know how) to make the command result in a stack trace:

[jmeeuwen@ghandalf spooler]$ gdb /usr/bin/zarafa-spooler
GNU gdb (GDB) Fedora (7.0.1-30.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/zarafa-spooler...(no debugging symbols found)...done.
(gdb) run -F
Starting program: /usr/bin/zarafa-spooler -F
[Thread debugging using libthread_db enabled]
Unable to open configuration file /etc/zarafa/spooler.cfg
Continuing with defaults
Wed 03 Feb 2010 03:53:54 AM CET: Unable to open pidfile '/var/run/zarafa-spooler.pid'
Wed 03 Feb 2010 03:53:54 AM CET: Starting zarafa-spooler version 6,30,9,18385 (18385), pid 7285
Wed 03 Feb 2010 03:53:54 AM CET: using SMTP server: localhost

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fcb820 (LWP 7285)):
#0  0x0000000000000000 in ?? ()
#1  0x0000003d0da20ca9 in M4LMsgServiceAdmin::GetMsgServiceTable(unsigned int, IMAPITable**) () from /usr/lib64/libmapi.so.0
#2  0x0000003d0e259782 in CreateProfileTemp(char*, char*, char*, char*, unsigned int, char*, char*) () from /usr/lib64/libinetmapi.so.1
#3  0x0000003d0e259a3b in HrOpenECSession(IMAPISession**, char*, char*, char*, unsigned int, char*, char*, char*) () from /usr/lib64/libinetmapi.so.1
#4  0x0000003d0e259b29 in HrOpenECAdminSession(IMAPISession**, char*, unsigned int, char*, char*) () from /usr/lib64/libinetmapi.so.1
#5  0x00000000004069a1 in InitThreadData(thread_data*) ()
#6  0x00000000004075bd in ProcessQueue(char*, char*) ()
#7  0x00000000004078ff in running_server(char*, char*) ()
#8  0x000000000040d04e in main ()
(gdb)

I'm not at all too familiar with C/C++ code, and/or libtool (a more recent version of libtool in Fedora is rumored to have caused this?), and so my first step is to Google. Googling for "undefined symbol" doesn't really give you anything else then forum topics with questions and often not even solutions to very particular problems though :/

So, I turn to you, dear Lazyweb, and I'm asking you to help me wrap my head around it and put the finger on the sour spot.

SPEC: http://www.kanarip.com/custom/SPECS/zarafa.spec

SRPM: http://www.kanarip.com/custom/f12/SRPMS/zarafa-6.30.10-1.fc12.src.rpm

Thanks in advance!

I love to be able to announce the first "sysadmin-main" meeting within my company, Operator Groep Delft. You read that right, that's the exact same name the Fedora Infrastructure team - an example to us all as far as I'm concerned, uses to indicate the group of people ultimately in control of all systems and services. Read the more detailed description. I'm going to try and apply this very concept to my company's internal system administration.

Instead of taking care of the Linux infrastructure with no dedicated Linux engineering resources, we decided that utilizing all of the available Linux competencies within the company would be more efficient, more effective, more flexible and would vastly improve redundancy, collaboration and expertise between the bunch of us.

Since we're a consultancy company, most of our Linux Engineers are hired out to customers, making billable hours, earning us all money, and are thus not in a position to really sit down and take care of OGDs Linux infrastructure as well. Basically our engineers can only spend that one minute they have left at the end of a day or the hour they would otherwise waste on one of those boring meetings -they merely require the facilities to do so.

So instead we decided to try and make it a community effort of some sort, in the sense that all sysadmin-main engineers require a minimal Linux certification level of RHCT, and will have access to Life, Everything and The Universe once we've sat together and introduced them to all procedures and such.

Now, nothing is set in stone yet, but at least we're going to have a bunch of interested people show up at our meeting soon, which will hopefully lead to a large group of engineers willing to do interesting stuff.

We'd plan and assign -amongst ourselves- the tasks in our queue. If either of us needs a little more time, we save up to 8 hours a week to spend at more intrusive changes like migrations, upgrades, planning, documentation, build & test, development, that sort of thing. We (as a group) would decide what we do, how we do it, and who actually gets to execute.

Ultimately, I'd be (held) responsible (or accountable?) for the group, and my manager would be responsible for the well-being of the infrastucture as a whole, just like he is now.

Just to give you an impression of what it takes to do what we do between the two of us at this moment, in the very little time that we have available; Zarafa, HA/LB Red Hat Directory Services, Puppet (with help of puppetmanaged.org modules), Cobbler, SELinux (enforcing), Nagios, Munin (looking at Zenoss to replace both), 15 mod_security enabled webservers, 4 database servers, 6 development environment staging boxes, and a couple of workstations.

PS. For those of you who read this, and are colleagues of mine, you can find more information on https://nix-noc.ogd.nl/trac/

If I'm not mistaken, today is the birthday of not just one, but two great friends!

Congratulations both Max Spevack and Jan Wildeboer!

Over the last couple of days it seems more and more people are stepping up to get Ruby 1.9.1 in Fedora, along with the packaging changes and all that. From a new list just two months ago, we now have 17 members working on the same problems collaboratively.

Worth noting is that I'm receiving patches from people that understand Ruby way better then I do, so it's one big happy learning experience for me too ;-) (Noted I do not use Ruby myself, nor do I program using Ruby)

Thanks to Ben Shakal, we're now over the issue I posted about earlier on the Ruby SIG mailing list, where gem install would work, but executing or requiring the gem wouldn't. Great work Ben, thanks!

From here on out, I'm going to extend the Ruby repositories for Fedora 12 and Fedora Rawhide to include some of the ruby gems with the new packaging guidelines. I'm still going to need new packaging guidelines to go along with the new packages so I'm probably going to build those packaging guidelines as I go along.

More news on Ruby later this year, hope to have some working stack early next year.

Hope you all have a merry Christmas!

You may have seen Lydia's blogpost on FUDCon Toronto as she experienced it. It's the first time she's been at an event like this, while it is my trazillionth time. So, she was interested to see what kind of work we do at such events, what kind of unmess the unconference is like (I've told her many stories about Greg DeKoenigsberg throwing the markers on the floor in Brno, for example), and of course she misses Max Spevack ;-)

All and all, from her story, it may have appeared to you that I'm more of an Ambassador out of the house then I am at home ;-) Hope you all appreciate her $0.02

So now that I have this new netbook thingy, kinda like a key-chain accessory, I want the packages I have installed on my huge-ass need-a-truck laptop to be on the netbook as well. I could, of course, do a rpm -qa on one end and install the packages listed on the other end, but that's not very sustainable. Here's what I did:

1. Let Puppet collect the packages on node ghandalf.kanarip.com
2. Let Puppet install all of those packages on weee.kanarip.com

Like the snail said, riding on the back of the turtle: Weeee!

With a little help from my friends (Andreas Thiennemann in particular), I managed to get my hands on a piece of equipment I was planning on buying anyway; a netbook.

Here in Canada though, these things are particularly cheap.

Next on the list of things to do is:

1. Never boot anything but a superior version of the greatest Operating System on a piece of equipment as cool as a netbook. The first thing that Acer will attempt to boot is a Windows Vista based eRecovery Suite in order for you to install Windows XP Home. I rest my case.
2. Download Fedora 12.
3. Check the list of things you need to know before trying all kinds of things to make the foo work. In my case, I found this page very useful. For one, it helped me boot Fedora ;-)

I finally managed to come up with a bunch of proper patches that give us Ruby 1.9.1 packages again, the way we want them to be after our little HackFest at FUDCon in Toronto. At first, they would succeed in rpmbuild, but not in mock or koji, but after all I got them to build in mock. Assuming they will then build in koji too, I'm submitting a couple of scratch builds now in the background as the Internet in the Hotel isn't all that fast, and after the builds have finished we may have some packages to play around with ;-)

Only a handful people seemed interested in a FUDCon session on Ruby, Ruby-1.9.1, the Enterprise Edition, packaging foo and so forth, so it's not part of the BarCamp ;(

I'm planning to have the session tomorrow though, just after lunch, in one or the other room, so if you are interested please follow around the guy with the bad haircut wairing a Von Dutch hooded sweater ;-)

FUDCon starts! ;-)

I'm having trouble creating a Re-Spin for Fedora 11, as you might have suspected given the number of Re-Spins released by Fedora Unity for this number 11 release.

This time, it is networking in the installer image that isn't at all functional. I suspect changes to NetworkManager, released as an update for Fedora 11, have caused the dependencies to shift, and those dependencies might not be in the installer image (install.img) nor the initrd.img.

To troubleshoot such things is rather difficult, and takes up a lot of time. Maybe I'm just being inefficient at it (any hints can go to kanarip@fedoraunity.org please!).

Anyway, I just wanted to let you know that that's what causing the hold-up.

It feels like this is part 7 or 8 in the ruby series, but I hope you're still hanging in there ;-)

Last time I blogged about Ruby 1.9.1 search paths, but after some converstation with Stephan Kasal in private, and some more on the Ruby SIG mailing list, I'm leaning towards the simplest ever search path;

/usr/local/lib{,64}/ruby
/usr/local/share/ruby
/usr/lib{,64}/ruby
/usr/share/ruby

As I also mentioned in this message, this looks very clear and straightforward to me! Regrettably, I have not yet had much response on the mailing list. I hope to be doing some rebuilds of packages depending on ruby later on, see how that goes, and maybe release a 1.9.2 release candidate version somewhere.

Are you a Ruby enthusiast or maybe a Ruby on Rails web application developer? Did you know Fedora has a Special Interest Group (SIG) for Ruby related development and issues?

If you are a Ruby dev, but you didn't know about the SIG, here's our Wiki page (lists SIG members, things to do, and needs a little work), and we now have a mailing list. Whether you are with Fedora already, or just use Fedora, Extra Packages for Enterprise Linux (EPEL) or Enterprise Linux itself (Red Hat, CentOS), this mailing list is your chance to get in touch with the developers and packagers that work on your platform.

I've posted a few things on Ruby before, I know, but this is one thing I really wanted to share with you. I'm thinking of making the search path look like this:

[jmeeuwen@ghandalf ruby-1.9.1-p243]$ ruby-1.9.1 -e 'puts $:'
/usr/local/lib64/ruby/1.9.1
/usr/local/lib64/ruby
/usr/local/share/ruby/1.9.1
/usr/local/share/ruby
/usr/lib64/ruby-1.9.1/site/1.9.1
/usr/lib64/ruby-1.9.1/site/
/usr/share/ruby/site/1.9.1
/usr/share/ruby/site/
/usr/lib64/ruby-1.9.1/vendor/1.9.1
/usr/lib64/ruby-1.9.1/vendor/
/usr/share/ruby/vendor/1.9.1
/usr/share/ruby/vendor/

Ergo;

1. Your local, architecture specific, ruby version specific stuff
2. Your local, architecture specific stuff
3. Your local, architecture independent, ruby version specific stuff
4. Your local, architecture independent stuff

   ^^ This would include results from "gem install"

5. Packaged, architecture dependent, ruby version specific stuff, such as ruby gems from RPM, or ruby libs
6. Packaged, architecture dependent stuff
7. Packaged, architecture independent, ruby version specific stuff
8. Packaged, architecture independent stuff

   ^^ This is where "yum install rubygem-*" would put it's files

9. Architecture dependent ruby vendor, ruby version specific stuff
10. Architecture dependent ruby vendor stuff
11. Architecture independent, ruby version specific, ruby vendor stuff
12. Architecture independent ruby vendor stuff

Did I forget anything? Comments?

A Fedora 12 Release Party in the Netherlands, how does that sound?

I'm asking, just to see how many people would be interested. Since there's more then just Dutch speaking Fedora enthusiasts in the Netherlands, part of this blog post is in English, and for those of you that don't speak Dutch; drop me a line on whether you'd like a Fedora 12 Release party in NL (or not), at kanarip@kanarip.com.

In het Nederlands dan;

Wat zou je denken van een Fedora 12 Release feestje? Een paar highlights van de nieuwe features, een paar PCs met de nieuwste versie erop zodat je deze kunt uitproberen, een aantal CDs en DVDs, en een lokale mirror voor als je je laptop wilt upgraden (met opstarten van netwerk, preupgrade, yum update/upgrade, jij kiest).

Daarbij natuurlijk de gelegenheid voor een hapje en een drankje en een gesprek met andere Fedora enthousiastelingen...

Hoe klinkt dat? Laat het me weten via kanarip@kanarip.com -we kunnen dan een beetje inschatten over welke orde van grootte we het zouden kunnen gaan hebben.

I've made rubygem-passenger-2.2.5-2 packages available for Fedora 10, Fedora 11, Rawhide and EPEL-5 for those interested. You can find them at http://www.kanarip.com/custom/ if you're interested.

PS> Rubygem-passenger (a.k.a. mod_rails/mod_rack) will not be in Fedora until someone fixes the package shipping its own version of Boost

PS^2> Rubygem-passenger's %{_bindir} files have now been fixed, but for passenger-stress-testing you'll need rubygem-hawler (which is in the repositories as well)

If there is no objections within the next few days, I would like to upgrade rubygem-git to version 1.2.4 (instead of 0.7.0 which is now in Fedora 11). It is a requirement for one of the projects still in development over at my company. I'm not sure how many people use it, so I wanted to let you know ahead of time I'm going to upgrade it (unless there's significant objections).

Drop me a line if you have objections ;-)

All that I can think of given recent discussions on list fedora-advisory-board list, concerning "What is Fedora?" and "What is Fedora Project?", as well as the topic on "Fedora 14 (two releases away folks) Feature Proposal", is this:

Maybe we focus too much on what the users want to consume from us -as we perceive it, while it is all there-, rather then focussing on what we want the user to consume, while we have a chance.

We oughtta be leading, not following. Should we be following <random-user>'s opinion on GNOME vs. KDE? Should we define the Fedora Project to be whatever is in anyone's mind? Should we attach a slogan to anyone's gut feeling or should we just continue to do what we do so well? Should we not be leading by example, including giving GNOME and KDE and XFCE an equal chance at being positioned as the most excellent desktop? Isn't that part of what Fedora is about?

A micro blogpost ago, I said I was going to upgrade to Rawhide. And I did. Some of you asked "How?", and so let me start by telling you exactly that; Remember I was running Fedora 11 x86_64, fully up-to-date before I started the following procedure, which I've been repeatedly executing between Alpha and Beta releases ever since Red Hat Linux 9 -and yes sometimes it fails and nukes your machine, be very, very careful.

1. In a terminal, type:
   

   # yum upgrade

2. See dependencies resolve, and fail resolving. For the part they fail resolving, determine whether you are going to need these packages after you upgraded. In my case, there is too much useless crap installed I can remove (netcdf-devel, other *-devel, packages I use once or show off to somebody but never use again, etc.), and there's things I don't really need for the work that I do on my laptop (codecs anyone?). So, in my case;
   

   # yum -y remove <all-packages-with-failed-dependencies>

3. Again, attempt to upgrade and type:
   

   # yum -y upgrade

4. Give it some time, if you have as many packages installed as I do. Around 2300 packages in my case, that is.
5. First thing you do after success, is reboot.
6. Enjoy Rawhide!

Now, for the part where have some initial thoughts on Rawhide as it currently is;

• Apparently, my mirror isn't fully up to date. I have no gnome-shell package but that was the reason I wanted to try out Rawhide earlier then normal; I normally yum upgrade my way through to Rawhide during the same time a Beta release is pending or readily available.
• Hence, I have yet to enjoy the nastyness that comes with running a desktop environment that is still being developed, while trying to do some actual work.
• The GTK(+? 2? Dunno, don't care) theme thing (engine?) has slightly changed. For one, the standard buttons that say "Quit", "Save", "Close", etc. are not as huge anymore, and so now they seem to me like actual buttons (rather then empty spaces I can click on). However seamingly insignificant, its an improvement!
• The most yum upgrade trouble I had was about this packaging effort I had once done for a customer; practically, there was no Fedora* trouble in yum upgrading. There was some RPMFusion package that wouldn't upgrade, but so be it (gstreamer-plugins-bad).
• There is some packages in Rawhide that, I assume, have to be rebuilt (or otherwise updated). Amongst these:
  

  $ package-cleanup --problems
  Setting up yum
  Loaded plugins: dellsysidplugin2, fastestmirror, refresh-packagekit
  Reading local RPM database
  Processing all local requires
  Missing dependencies:
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires NetworkManager = 1:0.7.1-8.git20090708.fc11
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires NetworkManager-glib = 1:0.7.1-8.git20090708.fc11
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libnm_glib.so.0()(64bit)
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libnm_glib_vpn.so.0()(64bit)
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libpolkit-dbus.so.2()(64bit)
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libpolkit-gnome.so.0()(64bit)
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libpolkit-grant.so.2()(64bit)
  Package NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64 requires libpolkit.so.2()(64bit)

• For the rest of it, everything works!

More thoughts and feedback and stuff after I've installed the new gnome-shell!

I'm upgrading to Rawhide to get GNOME 2.28, amongst other things. Just letting you know ;-)

I'm at FAD EMEA 2009 today, and I have to say; Mornings in Rheinfelden are much more beautiful then back home!

Fridays big event was a Pragmatic Source Code Management workshop, where amongst other things I emphasized the importance of consistent changesets, branching, tagging, using distributed version control systems or not, and what some of the advantages or disadvantages are.

As demo-case(s), I basically opened up a few Subversion and GIT repositories I had stored on my laptop, and showed the audience some of the different workflows implemented with various projects like anaconda (very operating system version specific branching), or vmime (which originally isn't a GIT repository, but where we have upstream, downstream with patches, and then some of the patches having been accepted upstream but not others).

Additionally, we worked on a couple of real-life use-cases where each time the question was, "How would you like to see this situation improved, and what tooling or process could or would you use?"

Some time after the meeting I'm in right now (FAD EMEA 2009), and a very interesting and intensive Red Hat VDI implementation project, I'll make sure that I post some of the slides or notes I think are interesting.

You've probably read this once or twice already, but tomorrow starts the Red Hat Developer Conference 2009. I was interested as soon as I saw the agenda. So I'm there (Are you? Why not?)

I hear rumors about a lab being available, and I hear about a coders competition. I wasn't going to participate in the competition, but now that I'm thinking about it... why not participate and get my ass kicked? Might be a very intense learning experience... hmmm...

Either way, there's also a Fedora track... I think I know where I'm gonna be. Can I show my face on the next FUDCon having to admit I was getting my ass kicked in a coders contest, skipping the Fedora track at a Red Hat Developers Conference? I don't think so ;-)

I've blogged about this before, and now I get this:

Need I say more?