nixternal

Right now I am working with the members of the Ubuntu Chicago LoCo team on creating a solid proposal for developing “Ubuntu Development Courses” that members of the Chicago community will lead. Right now we are looking for those that are in the Chicago land are that may be interested in such events. As it stands, I have come up with a basic, college-like, course layout.

Ubuntu Development 101 - Familiarization of Ubuntu development tools
This session will provide the attendees with a breakdown and brief run-through of the tools involved with Ubuntu development. These tools would include: Launchpad, mailing lists, IRC, development applications and scripts, and more.

Ubuntu Development 102 - Bug Triage
This session will provide the attendees with the knowledge necessary to help triage Ubuntu bugs. Attendees will learn the basics as well as some of the advanced topics with triaging bugs on Launchpad.

Ubuntu Development 103 - Packaging I
This session will provide the attendees with the knowledge necessary to build their very own package. Topics covered will include development applications, scripts, setting up development environments, creating the package, and more.

Ubuntu Development 104 - Packaging II
This session will provide the attendees with the knowledge necessary to merge, sync, and request merges/syncs for Debian packages into Ubuntu’s latest development cycle. Topics covered will include those mentioned as well as proper utilizing of certain development scripts as well as how to properly fill out a request, create a debdiff, and more.

Ubuntu Development 105 - Packaging III
This session will provide the attendees with the knowledge necessary to work with Debian on patches, request backports properly, how to do Stable Release Update requests, and anything else not covered by Packaging I or II.

Obviously none of this is set in stone at this time, as we are working on getting an infrastructure in place. One thing I would like to do, is keep these away from local LUG meetings as to not a) disturb the meeting process, or b) have our session disturbed due to socializing. We are currently looking for an ideal venue for this that will a) be easy to access, b) be free, c) have a projector, and d) have Internet. There are many places in the Chicago land area that fits this bill, so now we are just looking for the best place.

We figure that each event would take anywhere between 4 to 6 hours per session and may possibly be separated into mini-sessions. If we get this off the ground and have enough interest, we could keep it going and turn it into its own little BuntuCamp (BarCamp style) just for Ubuntu!

The reasoning behind this is not only teach interested individuals Ubuntu development, but also provide them the tools necessary to properly advocate the use of Ubuntu and its partner projects. I think once our members understand as many of the aspects involved with the development of Ubuntu, they will be able to better portray to future users the importance of Ubuntu and free software. Also, you get to learn Ubuntu hacking, what could be more fun?

If you are interested in such an event, I urge you to track the Ubuntu Chicago mailing list and let us know. If other LoCo teams are interested, feel free to contact me at nixternal - kubuntu - org.

night · mare [nayht-mare]

1. a terrifying dream in which the dreamer experiences feelings of helplessness, extreme anxiety, sorrow, etc.
2. a condition, thought, or experience suggestive of a nightmare: the nightmare of his years in prison.
3. (formerly) a monster or evil spirit believed to oppress persons during sleep.

That is the definition of nightmare according to Dictionary.com.

How many people had those feelings expressed in the definition? Well, from looking at the bug report, forum thread, mailing lists, and IRC, I think some may agree it was a nightmare. I am here to tell you that it was nothing more than a bad dream however.

A bad dream? Rich, you have got to be out of your mind! True, but I am always out of my mind, nothing new here.

Lets think about it for one minute. This libc6 issue didn’t occur in Dapper, Edgy, Feisty, or Gutsy, it occurred in Hardy. Hardy is currently in, what we like to refer to as, a development cycle or unstable release. Did it render our systems useless? Of course it did, but guess what? We have these great things called Live CDs, not only so you can test out Ubuntu or Kubuntu, but so you can also fix breakage that comes your way. Think about other operating systems where you don’t have this option. Sure, they may have a rollback option (which I am sure we will see eventually in Linux), or you may be one of the lucky ones where selecting “repair” from the installation CD fixes your problem, but most of the time with those other systems, you have to do some R&R, and I don’t mean rest and relaxation, I mean reformat and reinstall. Thank goodness for those Live CDs though, as I have seen more people fix their Windows machine with a Live CD more so than they have with the Windows CD or DVD that they paid hundreds for.

But still, MY SYSTEM DIDN’T WORK AFTER THIS UPGRADE! THAT’S RIDICULOUS! No it isn’t, you are using a distribution release that is meant for developers and for those who are not faint of heart.

OK FINE! BUT WHY WASN’T THERE TESTING DONE ON THIS!?! There was, it broke your system didn’t it? You tested it, now the developers know it didn’t work. Don’t say we didn’t warn you.

Pre-releases of Hardy are *not* encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu developers and those who want to help in testing, reporting, and fixing bugs.

Hey, don’t get me wrong, I was just as pissed off as many of you were, and actually on a couple of occasions spoke before thinking when this happened last night. We are human, we make mistakes, and we learn from our mistakes. With this being the only major issue I have seen come across during the Hardy development cycle, I have to say, we have learned a lot over the past few years if only one nightmare, or really a bad dream, occurred during a development cycle.

So remember, before you go off saying “I thought Ubuntu had a QA process”, or “Why wasn’t this tested?” Remember, in a development cycle, the people using and working with the OS are the QA process and they are the same people testing it.

The FIX took me no more than a few minutes in order for me to get my system(s) back up and running, probably less time than it took for me to bitch on IRC last night, or more time than it took some of you to bitch in an email, a bug report, or a forums post. I was always told that cooler heads prevail, and I seen that first hand. The people in the forums last night with the cooler heads, they had a quick howto on fixing the problem in a matter of minutes, they didn’t flip out claiming their company went out of business or something dramatic because an unstable version of their OS broke.

So with that said, this was nothing more than a bad dream

Lucas Nussbaum has graciously setup a mailing list with the approval of the great people over at Freedesktop.org. The purpose of this list is to allow all of the distributions to work together and for those working in distribution development. Lucas gave a brief example such as:

• How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot?
• How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4?
• Do you use a system that gives a limited set of rights to new contributors?

So for you KDE developers who are working in distribution development and are interested in the cross-distribution collaboration, go ahead and join the list. If you would like more information on Lucas’ announcement, feel free to read it in full HERE. He also has an mbox file for download consisting of the communications he had between some of the distributions interested. Thanks Lucas!

…it looks to hard

Well, I just wanted to write up a quick post here and let you know that it isn’t all that hard. If you just started using Ubuntu, or Linux in general, then yes, it might be a tad bit hard at first. If you can compile and install a tarball, then you are well on your way.

But I don’t know how to use the command line… This is a big one, especially with new users, and it seems today that most Linux distributions are trying to shy away from the command line as much as possible for new users. The one thing I always tell a new user, is not to be afraid of the command line. The command line is actually easier than a lot of people think. Sure there are plenty of confusing bits, and even I still get confused after reading a man page, but there is always Google. There are a lot of great tutorials out there for the command line. If you have a great command line tutorial you think a new user could learn from, add it in the comments please.

Once you have learned the command line a bit and are comfortable, then start downloading some tarballs and following the installation instructions. With a lot of packages you can get away with the typical

./configure
make
sudo make install

Most of the time though you will run into a tarball that doesn’t compile. Typically, if the developer did everything correctly, you will see why it didn’t compile. The main reason it didn’t compile is because you are missing a dependency. All you have to do in this case is search for the dependency or dependencies that are missing, and install them. Lucky for you, 99.9% of the time the dependencies are in the repositories, so it is usually an easy install.

Doing this will also get you familiar with the layout of Linux, such as the layout of the file system, how Linux operates behind the scenes, and more. After you have this down and are getting comfortable, then the MOTU and building Ubuntu and Debian package part will be easier. Once you are ready to look at packaging, what I did was go to KDE Apps and start downloading applications and packaging them. For you Gnome people, there is Gnome Files. All of the work that a MOTU or a packager does is located in a debian/ directory. The nice thing is there is a utility that helps you do this called dh_install that will extract the tarball and setup a default debian/ directory. From there it is up to you to get that directory up to shape, and get it to build out your package.

There are a lot of great readings to get you started with packaging. I recommend the Debian Policy Manual, the Debian Developer’s Reference, the Debian New Maintainer’s Guide, and the Ubuntu Packaging Guide. I think reading the Debian manuals first, just glancing through them to familiarize yourself with things, and then heading over to the Ubuntu guide is a good bet. There is a lot of documentation to help you get started, there is also #ubuntu-motu on IRC (Freenode) to help you out, as well as our mailing list.

I know it sounds like a lot and it still may very well seem hard to you. I have seen people with no solid knowledge, brand new with Linux, get up and running and even packaging in just a few months of playing around with their system. Some of you may know Juan Carlos Torres (Jucato) from his blog posts here on Planet Ubuntu. In less than 2 years time he has not only started to pick up packaging, but he has even started filing patches for KDE applications. 2 years may sound like a long time, but the only reason it took him that long is because he spent well over a year offering more tech support on IRC for both #kubuntu and #kde, than anyone I have ever seen. We even have/had IRC channel stats to prove nobody could touch him If you want to learn it, and you stick with it, in no time you will pick it up, and before you know it, people around the world will be using the package that you have created or updated.

If this type of thing interests you, which I believe it does interest a lot of new users, then keep an eye on the Ubuntu OpenWeek stuff coming up. Also in the IRC room for MOTU (#ubuntu-motu), you can find out about the MOTU Classroom as well, where some of our top MOTUs offer classes to those who want to learn. A quick word of the wise though, try not to become impatient or down on yourself if you aren’t getting it. These 2 things can cause burnout, which you definitely don’t want. In the past 10 or so years, I burnt out once, and for 2 years I wouldn’t even look at Linux, heck, I didn’t even want to look at a computer. Patience will definitely take you a long way in free software.

Any questions, concerns, links, ideas, or whatever, post in the comments, especially if you have some really good information that might be of interest to new users. Thanks everyone, and sorry for taking what I wanted to be a quick post, and making it one large run on, hopefully it isn’t to darn boring.

This is definitely easier than emailing each list to inform everyone of my absence.

Anyways, I have been left with a very unstable Internet connection at home which hasn’t worked itself out all of the way yet. Hopefully today will be a little better but I am not counting on it. It hasn’t been all that bad, because I have been able to catch up on school work and venture out and experience this so called thing called life.

Projects I have on hold and will be working on once I am able to get a decent connection at home:

• KDE
  • I will update the Techbase stuff for the KDE 4 Documentation TODO list when I can, I have emailed the kde-doc list, so check your mail
  • I am looking over the KHelpCenter code to see how the “What’s This?” and the PDF creation can be implemented cleanly
• Kubuntu
  • Will download the latest kdelibs package to work on the translations tab for LP translators
  • Looking over the edubuntu-desktop-kde package to see what else we can look at adding
  • I have a few bugs to close yet on a couple of packages, and I would like to get those done as soon as I can
  • 2 more days until string freeze - will have an updated, semi-final/final package built with the final string changes for translations (if you are using Kubuntu Gutsy, can you please check out the documentation and file any bugs that you see - thanks!

Hopefully I will be back to work here soon, only have about 15 minutes before I am done with school. Sorry for any inconvenience this has caused.

Not because I have finished 3 out of the 4 courses for the 8 week summer semester, but because 2 of those courses required the use of Windows. No more! The GUI design course utilized VB because, well it is so simple to do. And the ASP.NET class is well, ASP.NET

Now, with that out of the way. I know Mono is out there, and Mono Develop, however it was damn near impossible for me to follow along using Mono instead of the glorious Visual Studio (actually I am a fan of Visual Studio, if only Linux had such a powerful IDE). I would like to take some time out and become familiar with Mono and Mono Develop now that I have finished the class and realize just how easy ASP.NET coding really is. So if any of you have experience in doing so, please guide me a little bit on if it is possible. Maybe the problem I had was because ASP.NET in Visual Studio is drag-and-drop like crazy!

Oh, and also, when is somebody going to come up with a Qt version of Mono Develop? I would love to run it on my laptop, but there are just way to many libs, so I run it on my desktop at home that runs Gnome. Thanks!