Day Fourteen: Submitting a Patch to XBMC

Several members of my group struggled with Personal Package Archives (PPA) when compiling XBMC from source. The process is relatively simple once you discover the command format and find the PPA that you need  (I went through these steps for XBMC in an earlier post), but we felt that this information should be present in the readme file. The readme sends you here to a broken link for support documentation on adding a PPA to your system. The readme also links to the recommended PPA for XBMC (development version) here, but it does not provide the command for adding this PPA to the apt-repository, even though this readme is specifically for Ubuntu.

For our first bug-fix, we decided to update this documentation to reflect more accurate information and also to make it easier for future users. XBMC has a wiki page that describes the process of submitting a patch in great detail; however, it does not really mention standards for documentation. The changes to the readme file and running the "diff -u" command were fairly simple tasks. The difficult part was working up the courage to actually submit the file. We double-checked everything and then double-checked it again. The whole process was definitely more nerve wracking than it needed to be, but none of us had ever submitted a patch to an open source community before. 

The ticket can be found here. It seems like we have already received some comments from the developers. I hope everything goes well *crosses fingers*.

Day Thirteen: Fixing the Code

Chapter 7 in the online Teach Open Source textbook deals entirely with patching. It includes many helpful tips and exercises that prepare readers for a real patch submission. The assignment for this class includes exercises 7.2.2, 7.8 and 7.9.

Exercise 7.2.2: Comparing Diff Formats
In the previous sub-section, 7.2.1, the author provides a simple "Hello World." C program for the reader to use. After creating a copy of the file and changing the period to an exclamation mark in the new file, the author runs the following command to diff the two files:

diff -u hello.c.punct hello.c

The "-u" flag represents the unified diff format and creates the following output:


--- hello.c.punct 2012-02-10 01:06:26.431385116 -0500
+++ hello.c 2012-02-10 01:04:49.221384225 -0500
@@ -5,6 +5,6 @@
 #include <stdio.h>

 int main() {
-    printf("Hello, World!\n");
+    printf("Hello, World.\n");
     return 0;
 }

Without this flag, the output is much simpler and shows only the lines that are different, but this format lacks context without the rest of the code. Here is the same command but without the "-u" flag:

8c8

<     printf("Hello, World!\n");

---

>     printf("Hello, World.\n");

Exercise 7.8: Create a Patch for a New File

I  am not sure that I fully understand this exercise. The directions are to "create a patch file that represents a new file, foo being created with the contents bar." I assume this means to create a folder, "foo," that does not contain anything. I diff'd foo with /dev/null, but I received an error (diff: foo/null: No such file or directory). The patch file was created, but it is empty. Here is the command that I ran:

diff -u foo /dev/null >exercise-7.8.patch

Exercise 7.9: Patch Echo

This exercise is very straightforward. Just follow the instructions, and everything works perfectly. I ran the modified echo file and received the reversed message. Here is a copy of my patch:

--- src/echo.c.reverse 2012-02-10 01:48:15.131391331 -0500

+++ src/echo.c 2012-02-10 01:49:16.921559563 -0500

@@ -260,9 +260,8 @@

     {

       while (argc > 0)

         {

-          fputs (argv[0], stdout);

           argc--;

-          argv++;

+          fputs (argv[argc], stdout);

           if (argc > 0)

             putchar (' ');

         }

Day Twelve: Debugging the Code

The assignment for next class is to read chapter 6 in the online Teach Open Source textbook and complete exercises 6.4 through 6.7.

There is not a whole lot of reading in chapter 6 compared to some other chapters. It is centered around the exercises instead of blocks of text and encourages the reader to spend time learning about how a bug tracker system works through practical application. XBMC uses Edgewall Software's tracking system, which is simply called Trac. The landing page for XBMC's tracking system can be found here. All of the descriptive fields mentioned in 6.2.1, such as summary, description, comments, reporter, owner, version, severity and priority, status, and resolution, are present in XBMC's tracker.

Exercise 6.4: Find the Oldest Bug
The oldest bug for XBMC is Ticket #3077. It was created on 07/15/06, and it was last modified on 01/19/10. Based on the description, playback from a playlist does not function as intended when the user the user tells XBMC to play with dvdplayer. Once the first item is played, XBMC reverts back to the default mplayer. The owner, arnova, submitted a placeholder patch to fix the bug, but there has not been any detectable activity for over two years now. It is possible that a fix was included in a later release and the owner and/or the developers simply forgot to close the bug report. This is definitely worth investigating.

Exercise 6.5: Create Your Bug Tracker Account
I mentioned during our group presentation last class that XBMC's forum would not let me register again. I created a username/password several weeks ago but forgot my credentials. There are no obvious ways to retrieve lost log-in information, like a "forgot your password?" link, so I tried to create a new account. I used my private gmail account and my school gmail account, but both attempts returned a message that states that XBMC does not allow spammers to register for the forum. One of my other group members, Julie, mentioned that she had a similar problem, but she said it went away after a day or two. I waited a day and even created a new gmail account, and yet I am still getting the same response whenever I try to register. I contacted the webmaster and hope to receive a reply soon. The bug tracker is linked to the forum username/password; therefore, I will be account-less for a little while.

Exercise 6.6.1: Reproduce a Bug
I looked a lot of the bug reports and tried to find one that seemed easy to reproduce. Ticket #12592 states that XBMC crashes when a movie is renamed in a certain way. The steps to reproduce are as follows:

1. Open XBMC and go to you Movie library
2. Select any of your movies
3. Hit 'c' to open context menu, then select 'rename movie'
4. type some diacritic letters anywhere into the text field (but not at the end)
5. move cursor at the end of the field and hit the backspace key twice quickly

When I hit 'c', a context menu opens, but there is no option to rename the video. The bug reporter mentions that the bug is absent on Windows (the report is for OS X). I was curious to see if a similar problem existed on the Linux version, but it appears that there is slightly different functionality or implementation here. Perhaps the hotkeys are different, and I just did something wrong; however, another user reported that he or she was unable to reproduce the bug in Linux just two days ago.

Exercise 6.7: Bug Triage

Without my username, there is not much I can do to triage bugs. I noticed a few bug reports that could use a closer inspection, such as the one mentioned in exercise 6.4. Most reports that I found were reasonably documented from a technical aspect. I will work more on this exercise once I hear back from the webmaster and get a working username/password.

Day Eleven: Choosing a Bug-fix

My team met earlier today to discuss possible bug-fixes for XBMC. There are dozens, if not hundreds of active tickets, but there are relatively few specific to Linux. Some of the more interesting bug reports that we came across were for different systems, such as Apple TV and iOS. While several users report similar problems, we cannot duplicate these errors without access to similar systems and testing possible fixes would be a nightmare due to this limitation. Many of the Linux-specific bug reports mention the bug and provide a possible solution either in the report or in the comments. It would be possible to implement these fixes and submit a patch, but I am not sure that is what our professor had in mind with this assignment. Still, if the report is listed as open and the fix is in plain sight, perhaps the community is just waiting for someone to make the extra effort.

I noticed that a lot of the reports were self-reported, as in a developer noticed the bug and posted it for other developers to see. In these cases, the reports were quickly assigned to the developers with the skills or the knowledge required to fix the bug. These reports mainly deal with problems that were introduced by the beta release or problems that are extremely important.

However, all hope is not lost. In the midst of assignment-irrelevant reports, I found a possible gem. Ticket #12124 mentions a missing dependency (libltdl-dev) and asks for someone to add this package to the build-dep list and to the README.ubuntu file. This missing dependency could explain why I had trouble installing XBMC on Ubuntu 11.10. This bug might seem a little simple, but there is not much else out there at the moment. A new beta release is on the way soon, so I expect more bug reports here shortly.

Another issue that I noticed is, for lack of a better term, bug responsibility. In some reports, community members traced the bug to a conflict between XBMC and 3rd-party applications or add-ons. If finding a bug in the core functionality of XBMC does not yield any promising results, it is possible to look for bugs in these popular add-ons.

Day Ten: Examining an Article

In IEEE's July/August 2009 publication of Software Domain-Specific Modeling, there is an article by David Garlan, Robert Allen, and John Ockerbloom that addresses the difficulty of software reuse. The article is titled Architectural Mismatch: Why Reuse is Still so Hard, and this title alone was enough to catch my attention. I worked a little with various components and popular APIs in my graphical user interface design class to develop software mash-ups. It seemed difficult to me then because I was learning all of the languages involved, but I just assumed that my lack of experience was the main culprit--who wouldn't struggle with learning three new languages and various APIs for one assignment? The software that we were designing was grossly over-simplified compared to an entire system built for business application, yet it introduced some of the problems that the authors discuss in their article. When trying to design a system from modular parts, one can read all of the documentation and build a system that fits together conceptually; however, when one goes to actually build the system, the interactions between parts can reveal emergent properties, such as architectural mismatch, that impede the development process.

The authors state that a component makes three types of assumptions: assumptions about the application domain, assumptions about infrastructure, and assumptions about components at the same level of abstraction. The main solution the authors suggest for this mismatch is to work withing an "architecturally specialized design domain." This may limit interactions between some components that are built with different domains in mind, but component integration and design standards greatly lessen the headaches involved with trying to link two components that might be incompatible due to an inherent flaw in the way that they were designed.  Ultimately, money decides software engineering best practices. Designing a commercial off the shelf (COTS) product is supposed to be a simpler, more cost-effective way to design products. The next to last paragraph in the article says it all: "Even supposing that you have appropriately modeled evolution's cost, the potential for architectural mismatch might eventually make changing an existing system too expensive to allow effective innovation." Even if the designers make a system that works as advertised, there is a risk for "architecture lock-in" that could outweigh the benefits in the long run.

Day Nine: The Cathedral and the Bazaar

Our current assignment is to read Eric Raymond's essay, The Cathedral and the Bazaar (CatB), which can be found here, and blog our reflections. Having read through the essay in its entirety, I am surprised that Raymond never lists his "lessons learned" all together. The way the text and his stories relate to a specific lesson learned makes sense, but to leave them scattered throughout the text without a single list of every lesson for reference seems strange. Here is a list of every lesson learned for reference:

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend
17. A security system is only as secure as its secret. Beware of pseudo-secrets
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

That should be all of the lessons that Raymond listed. Every lesson is interesting to me in some way, but lesson five, and the story behind it, reveals a fact that I have only recently come to realize: the community determines the success and the livelihood of the software. This concept is obvious now, but, before I looked over FOSS projects last semester and discovered that some projects have been abandoned and neglected for many years, I never thought of software from this perspective.

Just today, I installed Ubuntu 11.10 on my HP Mini 1125nr and discovered that there is a bug with how the OS handles the monitor backlight. My netbook's screen would go dim and would only turn back on if I reset the computer. After a quick Google search, lessons seven and eight  revealed themselves in a forum topic and a link to a bug report. An initial user reports a problem; several users report having a similar problem; knowledgeable users and/or developers suggest a solution; the bug is fixed in the next release. The bug could have been avoided with more extensive testing before release, but the problem as quickly identified and fixed with the help of "many eyes."

Now that my group is able to compile XBMC from source, I look forward to diving deeper into the community and the software. I am sure that, in my efforts to contribute to XBMC, I will experience something that relates to at least one of Raymond's many lessons. It is important to recognize the strengths and weaknesses of open source and learn from these lessons.

Day Eight: Building XBMC from Source

Between working and learning C and Vi for my Operating Systems class, I was not able to put any more time into compiling Freeciv since my last post. Upon starting my Ubuntu install in VirtualBox this afternoon, I discovered that I had somehow corrupted my operating system because it would not boot to desktop. I deleted that setup and installed a new machine with the latest version of Ubuntu. Everything is working fine now, but the delay put me behind schedule. My other group members are reporting success so far in building XBMC from source code. I will document my progress here and list all the steps along the way.

(note: the following steps are for Ubuntu users)
Step 1: Install Source Code
If you do not already have git installed, you can install it from terminal with this command:

sudo apt-get install git-core

Navigate to your home directory and issue this command:

git clone git://github.com/xbmc/xbmc.git xbmc

Step 2: Install Dependencies 
This single line installs most of the dependencies:


sudo apt-get install git-core make g++ gcc gawk pmount libtool nasm yasm automake cmake gperf zip unzip bison libsdl-dev libsdl-image1.2-dev libsdl-gfx1.2-dev libsdl-mixer1.2-dev libfribidi-dev liblzo2-dev libfreetype6-dev libsqlite3-dev libogg-dev libasound2-dev python-sqlite libglew-dev libcurl3 libcurl4-gnutls-dev libxrandr-dev libxrender-dev libmad0-dev libogg-dev libvorbisenc2 libsmbclient-dev libmysqlclient-dev libpcre3-dev libdbus-1-dev libhal-dev libhal-storage-dev libjasper-dev libfontconfig-dev libbz2-dev libboost-dev libenca-dev libxt-dev libxmu-dev libpng-dev libjpeg-dev libpulse-dev mesa-utils libcdio-dev libsamplerate-dev libmpeg3-dev libflac-dev libiso9660-dev libass-dev libssl-dev fp-compiler gdc libmpeg2-4-dev libmicrohttpd-dev libmodplug-dev libssh-dev gettext cvs python-dev libyajl-dev libboost-thread-dev libplist-dev libusb-dev libudev-dev

And then one more line for newer versions of Ubuntu:

sudo apt-get install autopoint libltdl-dev


Step 3: Add XBMC's PPA to Your System
You can use these commands to add the PPA to your apt repository:

sudo add-apt-repository ppa:team-xbmc/unstable
sudo add-apt-repository ppa:pulse-eight/libcec

(These are other possible PPAs but they should not be necessary)
ppa:team-xbmc/ppa
ppa:team-xbmc/xbmc-ppa-build-depends
ppa:nathan-renniewaldock/xbmc-stable


Then update apt-get:

sudo apt-get update


Then run the "magic command" to build the dependencies

(note: this part did not work for me on 10.04, but xbmc compiled correctly anyways)
sudo apt-get build-dep xbmc        

Step 4: Compile
Navigate to the xbmc directory and run the following commands:
./bootstrap
./configure
make
make install    (note: might need to admin privileges)


Unfortunately, my compilation breaks during the make process, and I am unable to compile XBMC from source at the moment. I tried to utilize all of my resources, but it is obvious that I will need to make a topic on XBMC's forum or start a conversation in the IRC.

I have tried to compile the source code from the SVN repository as well and discovered some missing dependencies that were not installed from the provided command line code. Here are the extra dependencies that I had to install: libmms-dev, libwavpack-dev, libfaad-dev

The SVN version did not compile either. I will retry the process on a different virtual machine running an older version of Ubuntu. That is the only thing I can think to do at this point.

UPDATE:
I created a new virtual machine with Ubuntu 10.04 and went through all of the steps again. It compiles successfully and I am able to run it by calling "xbmc" through the terminal. Hooray!