MOTU

For a few days I've been fighting with what appeared on the outside to be libc6 halting my ability to make a pbuilder build environment. The bug post is over at Debian (#479202). Turns out that something was wrong in perl and a patch has since been released. As of 12:08 yesterday (Ubuntu archive time) the beautiful 5.10.0-9.1 version has been released and synced into Ubuntu Intrepid repos. Mmmmmm, I can finally make Intrepid environments!

I wasn't initially able to create Intrepid environments once libc6 was working, I had to update to them from gutsy's. The fix to this is to use the hardy backported debootstrap package. There is a few ways you can do this yourself.

Method 1 (Easier): Download the package from your favorite archive and use dpkg to install it:

$ wget http://us.archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_...
$ sudo dpkg -i debootstrap_1.0.9~hardy1.deb

Method 2 (More involved): Enable the backports mirrors in your /etc/apt/sources.list file (optionally set up pinning). This method enables the entire backports repository and may not be preferred behavior.

Start by adding an entry to the backports repository at your favorite mirror and then update your package database

$ sudo su -c "echo 'deb http://us.archive.ubuntu.com/ubuntu/ hardy-backports main' >> /etc/apt/sources.list"
$ sudo apt-get update

You should now see 1.0.9~hardy1 as a candidate when you run apt-cache policy debootstrap. As per usual sudo apt-get install debootstrap will bring it up to the latest and greatest version possible. And that's what we want -- it will install a pbuilder script into /usr/share/debootstrap/scripts which can then let you specify intrepid create targets from the command line.

$ sudo pbuilder --create --distribution intrepid

See the official Ubuntu Help Site for a more detailed description of backports and enabling pinning such that packages are installed from the main/universe/etc repository over the backports unless specified, or check out the official Ubuntu Wiki on pbuilder for a howto on building packages in a clean test environment.

Hello everybody! This will be my first post syndicated on Planet Ubuntu and I thought I should take this opportunity and use it to introduce myself.

My name is Tim Bielawa (though to most I'm just 'Shaggy'), I'm a student at West Virginia University (seriously, it is a state, I promise!) and I'm majoring in Computer Science and Mathematics. My day job is working for the Computer Science Department as a Systems administrator (amongst other things) supporting our workstations and ever growing infrastructure. Oh, by the way, all of which (servers included) runs Ubuntu :). We're in the process of migrating all the workstations to Hardy now and by July first (mark that date to come and party in Morgantown, WVU for our release party!) rolling out with Hardy on the entire infrastructure.

I started with Slackware (9 through 11), and jumped between Debian (briefly), and Gentoo up until last Fall/Winter 2007 when I started this new job. Using Ubuntu everyday got me hooked, I rather like it :). I must admit, it took a while to get over my guilt issues of not having to ./configure && make && make install anymore -- it felt like cheating -- as if Linux was suddenly too easy and no longer a challenge to use.

I wonder how many new Ubuntu Linux users even know what that means (./configure && make && make install), or even better -- will ever roll their own kernels by hand? The less the better I think, because it means we're doing a good job of making Ubuntu the most user friendly community driven Linux distro out there.

Getting into this new position, working towards being a MOTU, has put the challenge and joy back into my Linux experience. Instead of compiling software for my box I'll be packaging it so it can work on anyones box, which if you ask me, is far more stimulating and most of all -- rewarding.

Before my introduction post gets too long I'll finish up. My goal for a job outside of college is to develop modeling software and/or graphics rendering engines. Basically if I don't turn into another John Carmack I'll be making a better MATLAB or Mathematica. To facilitate this goal I thought that joining the MOTU Science Team (though I wouldn't dare call myself a MOTU yet) would be the most logical decision. This way I'll be focusing around the kind of software I'll be writing one day.

I put this blog together to document my steps towards being a full fledged official MOTU and to maybe even help encourage others pursuing the same goal. I've got a patch submitted already for slocate (#155061) which has gotten great comments so far (Thanks to James Calver for his kind words. I'm glad my efforts helped you figure out bug fixing better!) and a new package (Bibus) up on REVU for inclusion in Intrepid.