Planet Ubuntu

A while ago, somone told me that people might like to hear a bit about what I actually do, so this is the first in a series of blog entries about what interesting stuff I spend my time on.

Some of you may have heard of ubuntu-vm-builder before. if not, it's a tool that you can use to create Ubuntu based virtual machines in a snap. On my home system (with a local mirror and such), it takes about 45-50 seconds to create a complete virtual machine.

It started out as an alternative approach to the JeOS (just enough OS) concept at the end of the gutsy cycle. At that point, it was still a bit fragile, and the resulting vm needed a bit of work before it would actually work. During the Hardy cycle we applied a lot of love to it, so that it could actually complete an install without any handholding. A big thanks to Nick Barcet for helping out a lot with this!

Why talk about this now? Well, the topic came up again at UDS back in May. We wanted to make it easy for everyone (not just Ubuntu users) to create Ubuntu based virtual machines. A few suggestions flew back and forth (mostly about packaging for other distro (and perhaps even Windows)). At some point, someone suggested to build a web interface for it, and put it online. That way, anyone could log on the the webpage and build a new VM. Neat! However, building a VM is a heavy task, so the hosting would be costly. We then came up with a rather novel idea: We'll stick the web interface... in a virtual machine! We can then offer the virtual machine for download for various hypervisors. Now, *that* is neat!

So if you were running VMWare on your own system, you would download the vm image built for VMWare, fire it up and using a web interface you'd create a NEW virtual machine that you can use.

The main problem is that ubuntu-vm-builder was written in bash, which made adding lots of logic rather tedious and it also made it quite difficult to embed in a web interface, so I've been spending most of my time over the last week or so rewriting it in Python, and making it suitable for use as a library. I've now gotten to the point where it actually works, and the code structure is approaching sanity. It currently builds Hardy images for KVM just fine. Dapper, Feisty, Gutsy, and Intrepid will be coming shortly, and VMWare Workstation and Server, VirtualBox, and Xen hypervisors are planned as well. If someone wants to write a plugin for building other distributions, they can even do that! When I'm done with the VMBuilder itself, I'll get back to the webinterface. I already have a working prototype, which was made with the old vm-builder, so that shouldn't take to long. I'll keep you updated on my progress.

A while ago I blogged about my participation in the c’t programming contest to write a bot that plays against the 1979 Atari console.
Submission deadline was June 30th, and the results are trickling in now.

I am on rank 104, which I’m more than satisfied with. Unsurprisingly I didn’t make the top 50, I spent way too little time on it. But I had lots of fun with it, I have something that works, and at least outperforms my own Asteroids skills

In case anyone is interested in it, the source code is on http://piware.de/bzr/ct-asteroids/. It’s a bzr branch, so you can bzr get the directory.

We’re at part 4 already - WOW!

The main reason for publishing these interviews is that I think sponsors get far too little pats on the back, hugs and free ice cream, also there’s a lot of people who don’t know about it yet and should because it’s their entry point to making Ubuntu better, improving their packaging skills and getting in touch with the awesome people that are in the MOTU team.

I talked to Nathan Handler who sent us a positive avalanche of review requests and is doing amazing work.

What has your sponsoring experience been like up until now?
I have had a great experience with the sponsoring process. My sponsors have been very helpful, and they have been very quick in reviewing my patches. If one of my patches wasn’t perfect, they worked with me until it got uploaded. I’m looking forward to the day when I will be able to sponsor other contributors’ uploads.

Did you learn a lot in the process of sponsoring? Do you remember the last things you learned?
I have learned almost everything I currently know from my sponsors, and I am still learning. Just the other day, I created a patch for a package in a bzr branch. I had never done this before. Without one of my sponsors advising me to do that, the patch probably would never make its way into the repositories. Now, I will know for next time to check if the package is maintained in a bzr branch before trying to patch it.

Which packages do you mostly look after? Do you follow some kind of strategy when you try to fix bugs and make Ubuntu better?
I don’t look after any specific package(s). Up until about last week, I had been spending a lot of time merging and requesting syncs for packages in the universe and multiverse repositories. Currently, I am
working on patching bugs and clearing up the really-fix-it list. Before I start any work on a bug, I read through every comment. This allows me to learn what sort of progress (if any) has been made. It also prevents me from working on a bug that someone else is already working on. Sometimes, there is even a solution to the bug that has been posted as a comment.

Is contributing to Ubuntu hard? If so, what should be easier?
Contributing to Ubuntu is not hard once you learn some of the basics. Some of my first bugs were adding missing Depends/Recommends/Suggests to the debian/control file in packages. These types of bugs are very easy to fix. The hardest part for new contributors is locating these easy bugs. We can make it easier for them by tagging these easy bugs with the ‘bitesize’ tag. This tag was designed to be used to mark bugs that are easy enough for new contributors to fix. However, not many people take
the time to search for new bugs that can be tagged with this tag. Another way we can help new contributors is by offering mentoring for bugs. For my first bug, Emmet Hikory (persia) was offering mentorship. Without his help, I probably would have quit working on that bug.

Is there a message you would like to go out to the Ubuntu sponsors?
I would like to thank all of the Ubuntu sponsors. Besides patching bugs themselves, they also find time to test and upload the patches of contributors like myself, who are unable to upload directly to the
repositories. Their hard work helps make this community the great community that it is.

One to new contributors?
The first bug is the hardest. Before you can fix it, you need to learn about the layout of a package, and how to use the various packaging tools available. However, when your first patch gets uploaded to the repositories, you will feel a sense of pride in knowing that you helped contribute to Ubuntu. After that, patching bugs will become a lot easier. You will also feel more motivated to contribute. However, always remember, this is a community. You are never on your own. If you need help, ask for it. You will learn more by doing this, and you will also meet many new friends.

Thanks a lot for the great work you do! Keep it up!
No problem Daniel. I have no intention of stopping any time soon. I’mlooking forward to getting to work more with you and the other MOTUs.

It’s great and refreshing to talk to people on their MOTU adventure. Their energy and passion for making Ubuntu better every day is just awesome. I also talked to Luke Yelavich who is not only an amazing person in our community (Accessibility team, various MOTU teams, etc etc.) but is also an excellent musician: I saw him play the drums and the piano in Prague and was absolutely astounded.

First of all thanks for doing sponsoring - you kick ass!
No problem, I’ll help whenever and whereever I can.

Do you still remember when you first were being sponsored? What did it feel like?
Yes, I remember rather clearly. I found it both exciting, and nerve wracking. Exciting because I knew I was helping improve/update something in Ubuntu, as well as knowing I was another step further to becoming a MOTU.
Nerve wracking because while I thought I’d done everything right, I was wondering whether I had missed some small thing that was vitally important.

I hope everybody was nice and friendly…
Of course they were, and encouraging.

I’m happy to hear that.
Do you have a lot of conversations with people you sponsor? Do a lot of patches need discussion?
I generally don’t have much in the way of conversation with people who’s work I sponsor, and most patches I sponsor don’t really need discussion, save for the occasional thing here and there that I’m happy to add myself, and remind the contributor about in the bug report.

That sounds good - it keeps the process efficient, but still instructional.
Yes indeed.

So is there a pretty common mistake or anything else you’d like to see improve or are you generally happy?
Mostly happy, but I think one thing that would be nice is to make sure all changelog entries are clear to the point that someone who has never touched the package before can pick it up and work out what has been done. I have also had to pull one or two people up occasionally on the lack of explanation in the changelog entries, so far as they state something along the lines of something similar to “kept blah from previous merged version” etc.

That makes a lot of sense - one thing I sometimes ask for myself is a reference to some kind of discussion that has happened before, like an upstream bug number or a reference to a CSV commit.

Yes. I find myself doing a merge, and trying to work out why a change was made, and having to ask the previous merger, and even them not even being sure why somethign was done.

Exactly. What kind of packages do you mostly sponsor? Is there anything new contributors could help you with?
I mostly sponsor packages related to Ubuntu Studio, and accessibility related packages, mostly related to the GNOME accessibility stack, with the exception of helping with the sponsors queue from time to time.
At the moment, there is nothing I need help with, but in the future, if I manage to grow the accessibility team and developer interest, sponsorship help may be needed.

So people with an interest in Ubuntu’s accessibility should keep an eye on https://wiki.ubuntu.com/Accessibility/Team or just talk to you?
Just talk to me. The wiki is in no shape to be referred to atm.

Ok, excellent.
What kind of patches / fixes would you like to see more?
Patches/fixes that go to Debian first, so they can be synced/merged. I can’t really think of any at the moment.

That sounds like a good advice - it sounds like a recurring theme in these interviews.
Is there another message you would like to go out to new contributors?
A couple of things:

1. Please make sure nobody is doing what you plan to do, so that nobody wastes time needlessly. If we don’t step on each other’s toes, we can get more work done, and be more efficient in getting work done.
2. Take your time. Once you know you are the one to work on something, don’t rush it. You will only miss something that could be important, in which case you will have to go back and re-do it, taking up more time than is otherwise needed.
   If there is a time constraint, ask for assistance and work through it with someone to ensure it gets done as soon as possible, and before that big deadline.
3. If you have a merge request filed, please check regularly to ensure that it is the latest against the latest debian version. A few times I have had to ask people to re-merge against a newer Debian revision.
   This can happen if the queue is long, and your request is not attended to straight away, so please ensure it is against the latest Debian revision. That way, the request can be processed, and you can move on.
4. Other than that, get to know who you are working with, and who sponsors your requests. You then have a greater chance of getting good feedback/support when it comes time to apply to be a MOTU.

That’s great advice, I’m sure new contributors will appreciate it. In terms of getting to know your fellow developers: there’s always somebody who can help you out in #ubuntu-motu.
Yep exactly.

One piece of advice from myself: if you ever get to see Luke Yelavich play the drums or the piano, skip whatever plans you had before and go to see him.
lol! I’m not that good.

He’s always that modest.
Thanks a lot for the great work you do! Keep it up!
No problem, and don’t be affraid to help out however you can. We won’t bite.

Age: 19
Location: Murcia, Spain
IRC Nick: pochu

How long have you used Linux and what was your first distro?
I started with Ubuntu in December 2005 with Ubuntu Breeze Badger, and have been using Linux since then. I mostly use Ubuntu, but I have a Debian VM for testing the packages I maintain there.

How long have you been using Ubuntu?
See above

When did you get involved with the MOTU team and how?
I started contributing back in January 2007 with small packaging fixes, adding/fixing desktop files… I had no programming skills by that time (and they are still very poor, although I’m working on that!), so I started with simple tasks, and I’ve been taking more complex things as the time passed. I’ve concentrated in some packages too, and I maintain some in Debian and Ubuntu.

What helped you learn packaging and how Ubuntu teams work?
The #ubuntu-motu channel in IRC has always been a great help, with a lot of MOTUs and other wannabes hanging there and willing to answer questions or point to the proper documentation.

Also, the wiki, the PackagingGuide and the Debian Policy have been good places to consult when I didn’t know anything, or was unsure.

But the most important thing has been to do packaging. You can read a lot of documentation, but won’t learn packaging until you start working on it.

Favorite part of working with the MOTU?
The fact that many MOTUs are volunteers motivates me. Also the environment, and the good work the team does in a universe of thousands of packages.

Any advice for people wanting to help out MOTU?
Start contributing. You don’t need to know programming. You don’t need to know packaging. You don’t even need to know what that means! Just have a look at https://wiki.ubuntu.com/MOTU/GettingStarted and https://wiki.ubuntu.com/MOTU/TODO and start contributing. And don’t hesitate to ask in #ubuntu-motu on IRC or in the ubuntu-motu-mentors mailing list if you have any questions, even if you think they are obvious.

You have been working on a lot of different packages in the last cycles, what are you going to focus on in Intrepid?
I’m contributing to the DesktopTeam, merging gstreamer related packages, and looking at GNOME packages I’m interested in. I’m also looking at the SponsorsQueue from time to time, and do some reviewing.

Also I don’t want to duplicate efforts, so I’ve been working with Sebastian Dröge in having the GStreamer stack in sync with Debian.

For the Intrepid cycle I want to keep the GStreamer packages in sync with Debian and try to reduce the duplication work between the Debian and Ubuntu GNOME teams.

How do you think Intrepid will special for our users?
With GNOME 2.24 it will be a very solid release. It will be a pity it’s not LTS

Favorite quote?
I don’t have a favourite one, but I like this one a lot:
“A real friend takes your hand and touches your heart”

What do you do in your other spare time?
I like to go to the cinema, to meet my friends, and to watch the tv.

PDF creation got actually fairly easy. OpenOffice.org, the Cups printing system, KDE provide methods for easily printing nearly everything to a PDF file right away. A feature that even outperforms most Windows setups today. But there are still PDF related task that are not that simple. One I often run into is automated PDF creation on a web server. Let’s say you write a web application and want to create PDF invoices on the fly.

There are, of course, PDF frameworks available. Let’s take PHP as an example: If you want to create a PDF from a php script, you can choose between FPDF, Dompdf, the sophisticated Zend Framework and more (and commercial solutions). But to be honest, they are all either complicated (as you often have to use a specific syntax) to use or just quite limited in their possibilities to create a pdf file (as you can only use few design features). As I needed a simple solution for creating a 50+ pages pdf file with a huge table on the fly I tested most frameworks and failed with most of them (often just as I did not have enough time to write dozens of line of code).

So I hoped to find a solution that allowed me just to convert a simple HTML file to a PDF file on the fly providing better compatibility than Dompdf for instance. The solution was … uncommon. It was no PHP class but a neat command line tool called “htmldoc” available as a package. If you want to give it a try just install it by calling “aptitude install htmldoc”.

You can test htmldoc by saving some html files to disk and call “htmldoc –webpage filename.html”. There a lot of interesting features like setting font size, font type, the footer, color and greyscale mode and so on. But let’s use htmldoc from PHP right away. The following very simple script uses the PHP output buffer for minimizing the need for a write to disk to one file only (if somebody knows a way of using this without any temporary files from a script, let me know):

// start output buffer for pdf capture   ob_start(); ?> your normal html output will be places here either by dumping html directly or by using normal php code <?php // save output buffer $html=ob_get_contents(); // delete Output-Buffer ob_end_clean(); // write the html to a file $filename = './tmp.html'; if (!$handle = fopen($filename, 'w')) { print "Could not open $filename"; exit; } if (!fwrite($handle, $html)) { print "Could not write $filename"; exit; } fclose($handle); // htmldoc call $passthru = 'htmldoc --quiet --gray --textfont helvetica \ --bodyfont helvetica --logoimage banner.png --headfootsize 10 \ --footer D/l --fontsize 9 --size 297x210mm -t pdf14 \ --webpage '.$filename;   // write output of htmldoc to clean output buffer ob_start(); passthru($passthru); $pdf=ob_get_contents(); ob_end_clean();   // deliver pdf file as download header("Content-type: application/pdf"); header("Content-Disposition: attachment; filename=test.pdf"); header('Content-length: ' . strlen($pdf)); echo $pdf;

As you can see, this is neither rocket science nor magic. Just a wrapper for htmldoc enabling you to forget about the pdf when writing the actual content of the html file. You’ll have to check how htmldoc handles your html code. You should make it as simple as possible, forget about advanced css or nested tables. But it’s actually enough for a really neat pdf file and it’s fast: The creating of 50+ page pdf files is fast enough in my case to make the on demand access of htmldoc feel like static file usage.

Please note: Calling external programs and command line tools from a web script is always a security issue and you should carefully check input and updates for the program you are using. The code provided should be easily ported to another web language/framework like Perl and Rails.

Hoy conoci a uno de los moderadores de Foros del Web, llamado metacortex... bueno entre tanto que conversamos... me mostro un libro que me dejo impresionado, hecho con GIMP, Sodipodi, Scribus y ademas con Ubuntu 6.06... y como una imagen vale mas que mil palabras, aqui les dejo este caramelito.

Today I met one of the Foros del Web moderator, metacortex... Well we talked alot... but he showed to me a book that really shocked me, its a book done with GIMP, Sodipodi, Scribus and all that on Ubuntu 6.06. And 'cause an image its worth a thousand words... i have some for you:

This 3-day weekend (it was the Independence Day here in the US this Friday) turned out to be a 3-day stay indoors weekend for us. Due to a hurricane (don’t remember the name now) that is fast approaching the East coast, we were rocked by severe thunderstorms every single night.

We had planned to watch the new Indiana Jones movie at the outdoor movie night in Southern Village but managed to get inside the car right before the wind kicked in and the sky was lit with lightning. By the time we got home, it looked pretty bad outside.

Saturday we woke up to see a neighbor’s car buried under some pretty think branches and trees snapped in half (the shot above is actually in front of my house). The sun came out a bit and we thought the worst had passed. Boy were we wrong! Saturday evening the storm came back with a vengeance and we lost electricity early in the evening. What do you do when there’s no TV, internet or electricity and need to entertain 2 little girls?

You play cards, eat, board games, eat, monkey around, eat some more! Today, Sunday and the skies are pretty dark and the thunders are still rolling. Meanwhile my entire family is enjoying a Brazilian barbecue (I just got off the phone with my dad) and celebrating my youngest sister’s wedding (she got married this Thursday but I couldn’t make it). The “church” wedding will be in August in Southern New Jersey and I won’t miss it!

Last month I celebrated my birthday in New Jersey and you can see above what happened to my dad and I after the barbecue and many Blue Moons!

The first step for UCSA is already done! Augeas finally got it’s second ACK! So we just need to wait until the archive admins include it on the archive! I’ve been working on it’s packaging and resolving a really disturbing Bug, but given the help i have received from the really lovely, patient and helpful reviewers it’s already accepted (Thank you all guys! :D).
Now we need to focus on the next step of it, where i will appreciate really much if you want to help on it. It doesn’t need a lot of knowledge, so if you want to get involved on ubuntu and don’t know how, this is your shot!

How you ask? I will answer this question later, first a little description about augeas:
Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files.

But, how does it recognizes all the native formats of the configuration files? It’s not black magic, well it’s almost black magic, but it need some recipes for it, and those area called lenses.

Great, but, what are those lenses? Lenses are the building blocks of the file -> tree transformation; they combine parsing a file and building the tree (the get transformation), with turning the tree back into an (updated) file (the put transformation).

Sounds awesome, but also really hard… You know what? It’s not hard, they are just a list of regular expressions and directives in a really easy format, don’t believe me? Give a look at the official documentation on how to write them. It’s not hard, you just need to know (or learn) the syntax of those config files and the POSIX regexp syntax (man re_syntax).

Awesome i want to help! Tell me how!! Ok, i have create a wiki page with the lenses we have now and the ones we want, so you only need to give a look at it and start working on the lense you want after assigning it to yourself. Once you have it, please file a Bug against augeas with the following format:

Summary: Please add lense for $PACKAGE
Description: Augeas doesn’t support $PACKAGE configuration files.
And attach your lense to it.

Also if you feel like you want to, send it to upstream using their list (augeas-devel AT redhat DOT com), or just let me send it.

So, let’s work on this little things to have UCSA as soon as possible and make ubuntu even better!

P.D: If you write a lense also add a comment on it with your name an e-mail to have track of who wrote them like this:
(* Written by Joe Hacker <joe.hacker@isp.net> *)

The download file for the AZ team interview on the Gutsy Geeks radio show is now available here. I just listened to it myself, and I said “ah” to many times, but I think it came off ok. It did give our team some media exposure in Arizona, which is always a good thing.

I’ve been working on this post for quite awhile and have started over several times along with writing it in my head. On Wednesday I became a father.  That’s right…. There is now a small child that relies on my wife and I for everything.  From food and shelter to training and instruction. I’m not one for [...]