Chapter 7 in the TOS textbook went over fixing bugs and then creating patches from those bugs. There were three exercises that the book walked through with patches and I will go through my responses to each exercise individually.
7.2.2
Section 7.2 of the TOS book dealt with explaining what a patch is, how to create one with out subversion and how to compare the change between an original file and a new file. In exercise 7.2.1 it walked through creating a patch for a Hello, World program written in c. It was pretty simple with the change from "Hello, World." to "Hello, World!". Once the change took place, it walked through the "diff" command with the -u flag in order to see the differences between the original hello world program and the patched one. Exercise 7.2.2 asked to use the diff command with out the -u flag to see the difference from the "diff -u" command. The differences that I found were that "diff -u" gave more information than just "diff", and it was easier to understand "diff -u". "diff -u" told me which file contained the old line using "---" and which file contained the new line using "+++". It also denotes what was changed inside the file by displaying the old line in the original code with a "-" and the new line with a "+". The "diff" command with out the -u flag did not give as much information. It gave the line number that was changed and it told the original line denoted with a "<" and the new line denoted with ">", but it does not tell you which file the lines are from so it can make it a bit confusing. I mean, for this example it is probably okay because it is just one line but for multiple changes it can probably get a little tough to read.
7.8
I'm guessing I did this one right. It asked to create a patch file that represented a new file with "foo" being the name of the patch file and the contents being "bar". So I created the patch file and put "bar" as the contents and then diffed the /dev/null file with the foo.patch file. My results were that foo.patch had the new line with "bar" and that /dev/null was empty. Again I'm not sure if I did this one right or not. The wording was a bit weird to me.
7.9
In this exercise, it walked through creating a patch for the "echo" command from the "coreutils" project. They walked through how to change the code in order to make the "echo" command print sentences out in reverse and then output the "diff -u" of the old echo and the new echo into a patch file. Once I carried out all the necessary steps, I found that the code change they provided, did not reverse the sentence with the new "echo" command. Instead that command just repeats the first word in the sentence for each word in the original sentence. So for example:
original: is this reversed
echo command output: is is is
What I found, is that I did make an error in changing the code. for the line that says "fputs(argv[0], stdout);" I was supposed to replace argv[0] with argv[argc]. That would explain why the first word in my sentences would repeat. Once I made the correct change, the "echo" command reversed the sentence.
Wednesday, February 23, 2011
Wednesday, February 16, 2011
Bug fix progress
My team and I are taking the Banshee bug dealing with changing the file labeling from Banshee-1 to Banshee since version 2.0 of the software is approaching. Our bug report can be found here. We noted on the bug report that we would take the responsibility of taking on this task, since it is an easier, yet tedious, bug. We also asked for some assistance about how to approach it. We wanted to create a script at first and then submit that to the developers to run on the code in the repository, but they preferred that we submit the corrected code to them for review. They also gave us some helpful advice about which labels would be very easy and straightforward to relabel and which ones would be a little more difficult. The bug report activity can be found on our bug report page.
I have been in the process of relabeling the files and was able to relabel most of the files in the src folder with out running into any compile, install, or run problems. Some of the files in the src folder required root privileges to change them, so I figured I needed to proceed with caution in changing these files. So I took the approach of changing one file and then reinstalling to see what effects would occur. So I changed the first one and reinstalled. Banshee would not start up but when I went to go change it back, I could not find the file again because I did a new search for banshee-1 and it rid of the file because it was relabeled with banshee. Since, this was the case, I got rid of my source code and attempted to checkout and build from the source code on our team's repository. Some how the code in that repository does not want to compile and I'm not sure why. Brandon, my fellow team mate, said he was experiencing the same problem. So we will have to further investigate that matter, and if it comes down to it, we can place a new version of the source on it. Also we can use the code from the git repository and manipulate the newest version.
For now, I believe our team has to get together and figure out what exactly can be relabeled easily and what needs a little more thought before relabeling.
I have been in the process of relabeling the files and was able to relabel most of the files in the src folder with out running into any compile, install, or run problems. Some of the files in the src folder required root privileges to change them, so I figured I needed to proceed with caution in changing these files. So I took the approach of changing one file and then reinstalling to see what effects would occur. So I changed the first one and reinstalled. Banshee would not start up but when I went to go change it back, I could not find the file again because I did a new search for banshee-1 and it rid of the file because it was relabeled with banshee. Since, this was the case, I got rid of my source code and attempted to checkout and build from the source code on our team's repository. Some how the code in that repository does not want to compile and I'm not sure why. Brandon, my fellow team mate, said he was experiencing the same problem. So we will have to further investigate that matter, and if it comes down to it, we can place a new version of the source on it. Also we can use the code from the git repository and manipulate the newest version.
For now, I believe our team has to get together and figure out what exactly can be relabeled easily and what needs a little more thought before relabeling.
Wednesday, February 9, 2011
Choosing a Bug to Fix
My group and I have tried to come to a decision in the past week about what bug we would like to tackle for our first contribution to the Banshee project. The initial bug we were looking at was causing Banshee to crash due to a clean install setting the music library to point to the home directory of the user's operating system account. There was a work around to fix it via the command line, but the developers wanted a guard against this from happening. More information on this bug can be found on our wiki under Possible Contributions. We dropped this bug because we could not reproduce the bug and therefore we figured it may have been fixed.
The second bug we took a look at had to do with Banshee's search field. This field is used to find particular songs or albums using search terms such as rating, artist, song, etc. The problem there was that when searching for a particular term value, say rating, could contain no spaces in the term search. So for example "rating=5" displayed results while "rating = 5" produced no results. After finding where the string of the search box was being broken down and processed, we found that the parser was not designed to process spaces inside of terms. It could however process spaces outside of terms. So if one wanted to do a boolean search for both 5 and 3 star ratings one could do "rating=5 | rating=3" ( | representing OR operator) They would get all songs with a rating of 5 and 3. Notice that spaces are accepted between two terms and an operator. We spent a couple of hours trying to figure out how we could go about getting the parser to not process those spaces inside of a term, but we began to realize that this type of string parsing was a little more involved than we had hoped, so we dropped this bug.
I found a bug, that I was able to sort of fix and figured that it would be a great one to do. The problem here is that users were finding it annoying that when one double clicks on a song to play in a play list with a scroll bar present, the viewing pane would center the list around the currently playing song. The bug report can be viewed in a previous blog post called "Bug reproduction". I was able to fix the centering problem, but when a song would finish playing and Banshee moved to a song that was not in the current viewing pane, the song would play, but would not be viewable in the viewing pane. One would have to scroll down to view the currently playing song. This bug has been set up as a back up or a future project for our team, but if we never get to it then I'll probably end up fixing it myself.
We finally came to a bug that would be very easy for us to contribute to, but on the other hand would affect a lot of files since it is in the names and paths of a lot of files. The developers are wanting to change every instance of banshee-1 to banshee, because banshee-1 just denotes version 1 and since version 2 is growing near they would like someone to change all these instances. It'll probably be tedious work, but it's a great and easy start. To check out my group and I's report on our approach to this bug, then click here.
The second bug we took a look at had to do with Banshee's search field. This field is used to find particular songs or albums using search terms such as rating, artist, song, etc. The problem there was that when searching for a particular term value, say rating, could contain no spaces in the term search. So for example "rating=5" displayed results while "rating = 5" produced no results. After finding where the string of the search box was being broken down and processed, we found that the parser was not designed to process spaces inside of terms. It could however process spaces outside of terms. So if one wanted to do a boolean search for both 5 and 3 star ratings one could do "rating=5 | rating=3" ( | representing OR operator) They would get all songs with a rating of 5 and 3. Notice that spaces are accepted between two terms and an operator. We spent a couple of hours trying to figure out how we could go about getting the parser to not process those spaces inside of a term, but we began to realize that this type of string parsing was a little more involved than we had hoped, so we dropped this bug.
I found a bug, that I was able to sort of fix and figured that it would be a great one to do. The problem here is that users were finding it annoying that when one double clicks on a song to play in a play list with a scroll bar present, the viewing pane would center the list around the currently playing song. The bug report can be viewed in a previous blog post called "Bug reproduction". I was able to fix the centering problem, but when a song would finish playing and Banshee moved to a song that was not in the current viewing pane, the song would play, but would not be viewable in the viewing pane. One would have to scroll down to view the currently playing song. This bug has been set up as a back up or a future project for our team, but if we never get to it then I'll probably end up fixing it myself.
We finally came to a bug that would be very easy for us to contribute to, but on the other hand would affect a lot of files since it is in the names and paths of a lot of files. The developers are wanting to change every instance of banshee-1 to banshee, because banshee-1 just denotes version 1 and since version 2 is growing near they would like someone to change all these instances. It'll probably be tedious work, but it's a great and easy start. To check out my group and I's report on our approach to this bug, then click here.
Monday, February 7, 2011
Bug Triage
Chapter 6.7 in the Teaching Open Software book talked about the triage of bugs in a bug tracker. The exercise asked to review the bugs labeled "NEW" and try to perform some triage procedures on the bugs. I searched through a big portion of the new bugs for the Banshee software to try and find some bugs to do some triage on, but all the bugs seemed to be triaged very well. Duplicates were marked accordingly, all the bug reports were well reported, severity was chosen properly and all had been replied to in some way or another. It appears that the developers are on top of things with doing bug triage.
Bug reproduction
I was sifting through the bug tracker and found a bug that was easy to reproduce. The bug occurs when you double click on a song to play it. When you double click on the song, in a list of songs where a scroll bar exists, the scroll bar will shift down to a position that places that song in the middle of the list, which is a real annoyance, when someone is trying to click through songs quickly. The moving of the list can really throw someone off. So, I checked with the 1.9.2 release and I was able to experience the exact same behavior. This seems like a bug that would not be too hard to fix. The bug report can be found here.
Creating a Bug Tracker Account in Bugzilla
Creating an account on Bugzilla was very straightforward and simple. In Bugzilla, you just have to click on the "New Account" link at the top of the page, and from there it will direct you to a page where it will ask you for your email address. Once you have given an email address, you will receive an confirmation email with a link to navigate to an account creation page. At the account creation page, you are given a few fields where you can enter your real name (optional) and the password you wish to use. Once you have completed all of that, you then just use your email and newly created password as a login.
Oldest Bug in Banshee
One of the assignments in the Teaching Open Source book was to find the oldest bug in my chosen open source assignment and write up a little summary about the bug and why it has not yet been resolved.
Since my project was Banshee, I did an advanced search in Bugzilla and checked for bugs starting at its creation year back in 2005. After a few searches, I found that the oldest open bug was dated back to October 22, 2007. To see the bug report, just click on this link.
The bug had to do with an explicit red tag showing up in iTunes next to songs that were added to an iPod by Banshee. The user was saying that they would sync their iPod up with Banshee and place Banshee derived songs onto their iPod. From there, they would sync their iPod to iTunes to find that all the songs they added from Banshee had this explicit red tag showing up. The user also stated that this problem does not occur when using the libgpod svn trunk r1733.
I have a couple of theories as to why this bug is still open on Banshee's Bugzilla list. My first theory is that since r1733 of the libgpod library does not experience this problem, then there was no need to fix something that has already been fixed by a library revision. Of course, the libgpod r1733 could be an older revision and the user could be complaining about a the newest libgpod revision, but the bug report is not specific about which revision is experiencing the problem.
My second theory is that since this red tag is being experienced in an piece of Apple software, the developers did not see the bug as something major and just let it be.
Since my project was Banshee, I did an advanced search in Bugzilla and checked for bugs starting at its creation year back in 2005. After a few searches, I found that the oldest open bug was dated back to October 22, 2007. To see the bug report, just click on this link.
The bug had to do with an explicit red tag showing up in iTunes next to songs that were added to an iPod by Banshee. The user was saying that they would sync their iPod up with Banshee and place Banshee derived songs onto their iPod. From there, they would sync their iPod to iTunes to find that all the songs they added from Banshee had this explicit red tag showing up. The user also stated that this problem does not occur when using the libgpod svn trunk r1733.
I have a couple of theories as to why this bug is still open on Banshee's Bugzilla list. My first theory is that since r1733 of the libgpod library does not experience this problem, then there was no need to fix something that has already been fixed by a library revision. Of course, the libgpod r1733 could be an older revision and the user could be complaining about a the newest libgpod revision, but the bug report is not specific about which revision is experiencing the problem.
My second theory is that since this red tag is being experienced in an piece of Apple software, the developers did not see the bug as something major and just let it be.
Wednesday, February 2, 2011
Ch. 5 Freeciv build
Chapter 5 in the Teaching Open Source textbook, the author walked through how to build the source code of Freeciv, which is an open source turn-based strategy game. As I am going through the author's walk through on building the code, I did not get past installing the dependencies because I experienced a few problems.
The first problem I came across was installing the atk (Accessibility Tool Kit) dependency. I found out later that it was not required, but once I installed it I noticed I was having problems opening new windows. When I clicked on something to open it, the task bar would notify me that it was opening, but after a few seconds the task bar notification would disappear and nothing would open. So, I decided that a restart might fix the issue. Once I restarted my machine, my Ubuntu would not load. It would just stay at the loading screen for several minutes, which isn't normal, so I had to uninstall Ubuntu and then reinstall it. I figured that the problem with it crashing on me was due to it not being updated, so the next time around I updated the system before initiating anymore dependency installs.
The next round, I had to install everything before the atk dependency, but this time since atk was optional I did not even bother with it. My next step was to install a dependency called Pango. While going through the install process for this package, I found that Pango required a backend called FreeType, so I had to go out and find this package and install it. Once I had it installed, I tried installing Pango again only to get the same message that FreeType was required to install Pango. So, I decided to open up a file in Pango to investigate further only to find that I have run into an Ubuntu crash again! It was the same problem as last time, so I decided that it was just too much trouble to keep going so I gave up with trying to get these dependencies installed.
So, from my whole experience I found that I had more trouble installing the dependencies than the author did. His dependency installs were all just single install commands from the terminal which turned out successful. Mine, on the other hand, were going out and finding the dependency tar balls online and installing from those since the packages could not be found in Ubuntu. Sometimes they would install in a breeze and sometimes they required other dependencies in order for the main dependencies to run!
I guess the lesson here is that in the real world of open source development, building code can sometimes be a breeze and other times can be a throw your computer across the room experience. This will be the third time that my Ubuntu machine has crashed, so it looks like I'm going to have to start from scratch again...which is very annoying, by the way.
The first problem I came across was installing the atk (Accessibility Tool Kit) dependency. I found out later that it was not required, but once I installed it I noticed I was having problems opening new windows. When I clicked on something to open it, the task bar would notify me that it was opening, but after a few seconds the task bar notification would disappear and nothing would open. So, I decided that a restart might fix the issue. Once I restarted my machine, my Ubuntu would not load. It would just stay at the loading screen for several minutes, which isn't normal, so I had to uninstall Ubuntu and then reinstall it. I figured that the problem with it crashing on me was due to it not being updated, so the next time around I updated the system before initiating anymore dependency installs.
The next round, I had to install everything before the atk dependency, but this time since atk was optional I did not even bother with it. My next step was to install a dependency called Pango. While going through the install process for this package, I found that Pango required a backend called FreeType, so I had to go out and find this package and install it. Once I had it installed, I tried installing Pango again only to get the same message that FreeType was required to install Pango. So, I decided to open up a file in Pango to investigate further only to find that I have run into an Ubuntu crash again! It was the same problem as last time, so I decided that it was just too much trouble to keep going so I gave up with trying to get these dependencies installed.
So, from my whole experience I found that I had more trouble installing the dependencies than the author did. His dependency installs were all just single install commands from the terminal which turned out successful. Mine, on the other hand, were going out and finding the dependency tar balls online and installing from those since the packages could not be found in Ubuntu. Sometimes they would install in a breeze and sometimes they required other dependencies in order for the main dependencies to run!
I guess the lesson here is that in the real world of open source development, building code can sometimes be a breeze and other times can be a throw your computer across the room experience. This will be the third time that my Ubuntu machine has crashed, so it looks like I'm going to have to start from scratch again...which is very annoying, by the way.
Subscribe to:
Posts (Atom)