Success at last!!! Finally was able to get the Gwibber library installed along with its long chain of dependencies. I was able to accomplish this without any help from the mailing list. I'm proud of myself because this setup has been one of my biggest challenges yet in this project and I worked through it. It was a frustrating couple of days but persistence paid off in this one.
After many failed attempts I decided to remove all of the libraries I installed and start over. I ended up running 'apt-get auto-remove' as well to clean out unused packages. That removed a lot of things, I was kind of nervous doing this but I rolled with it and it payed off. I did have to go back and reinstall a few 'accidentally' removed packages because of this command.
After that I went through the process of obtaining all the packages one more time and was able to get it installed. On my last attempt I did try something different. Instead of using 'apt-get' to install most of the packages, I installed each dependency by downloading the source code. I then compiled each package and installed. This way I was able to make sure all the dependencies for these packages were there. I noticed I had to install several things I do not remember getting when installing the packages through the package manager. Maybe they were automatically added but whatever, the last time worked!
So after getting the libraries installed I set up a project solution and created a small test program that prints to the console using the Gwibber library. It worked...Awesome!
Next up is our time-line for the project. We already have our project picked out, you can find it here. Now we just need to hash out a reasonable plan to complete this thing.
Oh...I just seen an email pop up. Jesse just sent out an email to the lead devs announcing our project selection. Exciting!!
Monday, February 28, 2011
Friday, February 25, 2011
No Gwibber yet
So I read up on the CFLAGS. Although I'm sure this will be helpful information for future reference it was not quite what I was looking for to solve our problem.
I hung around in the Gwibber IRC for a bit after asking my question. I also continued to play with installing the Gwibber library but did not get anywhere nor did I receive any other helpful tips in the chat room. I decided to ask one more question before I logged out, “Where can I find the Gwibber API?” The answer I received disappointed me, “There isn't one.”
This response has made me rethink our initial plan to create an extension using this library. It could a pain using a library with no documentation. I will discuss this with the team later but for now I am going to send out an email to the Gwibber mailing list to see if anyone out there in the Gwibber world can help me with tis error.
I hung around in the Gwibber IRC for a bit after asking my question. I also continued to play with installing the Gwibber library but did not get anywhere nor did I receive any other helpful tips in the chat room. I decided to ask one more question before I logged out, “Where can I find the Gwibber API?” The answer I received disappointed me, “There isn't one.”
This response has made me rethink our initial plan to create an extension using this library. It could a pain using a library with no documentation. I will discuss this with the team later but for now I am going to send out an email to the Gwibber mailing list to see if anyone out there in the Gwibber world can help me with tis error.
Thursday, February 24, 2011
Jinxed...
So I jinxed us last night when I stated that we have had no major hang-ups yet. Our first hang up has just occurred. We are trying to get the Gwibber library installed and are having problems finding the proper dependencies. After much trial and error we think we have all the dependencies but are running into a strange error during the make process. Here it is:
service.c: In function ‘_dbus_handle_service_interface_loading_started’:
service.c:1365: error: unused variable ‘reply’
service.c: In function ‘_dbus_handle_service_interface_loading_complete’:
service.c:1376: error: unused variable ‘reply’
Even more strange, initially this error was stemming from a couple lines in the 1200s. We ran make clean and tried make again and now these errors are occurring a little further down. Unfortunately the make clean command did not work for these. We have also tried commenting out the variables in the code but it generates a whole other set of issues so it appears these variables are being used???
We Googled this error but it returned nothing at all. So I decided to get on the Gwibber IRC channel a bit ago and post a question, hoping someone had seen this before. I did not receive any direct help to the issue but several people came back fairly quick with links to sites that may be helpful.
http://en.gentoo-wiki.com/wiki/CFLAGS http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/
Title: CFLAGS - Gentoo Linux Wiki (at en.gentoo-wiki.com)
Getting ready to check these sites out now. These guys seem to think that ignoring the errors will work. Before posting the question I already tried running make with the -i flag and it did not work, the make process failed. I do not know what CFLAGS are so I am about to find out. Hopefully these will help!
Report on my findings later....
service.c: In function ‘_dbus_handle_service_interface_loading_started’:
service.c:1365: error: unused variable ‘reply’
service.c: In function ‘_dbus_handle_service_interface_loading_complete’:
service.c:1376: error: unused variable ‘reply’
Even more strange, initially this error was stemming from a couple lines in the 1200s. We ran make clean and tried make again and now these errors are occurring a little further down. Unfortunately the make clean command did not work for these. We have also tried commenting out the variables in the code but it generates a whole other set of issues so it appears these variables are being used???
We Googled this error but it returned nothing at all. So I decided to get on the Gwibber IRC channel a bit ago and post a question, hoping someone had seen this before. I did not receive any direct help to the issue but several people came back fairly quick with links to sites that may be helpful.
http://en.gentoo-wiki.com/wiki/CFLAGS http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/
Title: CFLAGS - Gentoo Linux Wiki (at en.gentoo-wiki.com)
Getting ready to check these sites out now. These guys seem to think that ignoring the errors will work. Before posting the question I already tried running make with the -i flag and it did not work, the make process failed. I do not know what CFLAGS are so I am about to find out. Hopefully these will help!
Report on my findings later....
Wednesday, February 23, 2011
Missed me??!!
Wow! It has been a while since I have been here. Sorry for not updating more frequently but I have been REAL busy. Just because I have not been on here much does not mean I have not been working away at this project, I have been very active! Let me bring you up to speed on our project.
Our team's moral is high right now. Our project is moving along nicely and we have not had any major hang ups yet. I didn't really expect any but you never know, and it sounds like others are having some troubles. Hope it continues this way until the end of the semester, my fingers are crossed. Our team has meshed nicely. No major issues between us to report and everyone gets along and works well together. That is a big plus! We do have a few members that are dong a little more than others but we have met on this topic and addressed the issue and feel we have it under control. We are excited by our success so far in this endeavor and are ready to close out strong with an interesting addition to the Banshee project.
We are leaning towards a Facebook extension for Banshee. The lead developers mentioned this would be nice to have so we thought maybe we could tackle another project they were trying to throw our way, much like the bug fix they recommended. It may be a bit much to try to finish in the short time we have left in the semester but we are not for sure. Jesse is checking with the developers right now to see how big of a project they feel this will be. Although even if we cannot wrap this extension up by the end of the semester, we can establish a solid foundation and some main functioning that will give others a platform to build off of. We may become involved enough to see this thing through even after graduation.
While Jesse is doing that I am doing my part by looking through the code of some of the other available extensions to see if I can get an estimate of the complexity based on these other modules. I will report back on this later after I have some more time to look through the code.
So what else...
Well, our team made a solid contribution to the Banshee project recently. You can read all about it here. We made many changes to filenames and code to reference 'banshee' instead of 'banshee-1'. It may have been a little grunt work, but it was much needed grunt work as the 2.0 release of Banshee is schedule for April. We are satisfied with our work and the developers are thankful towards us for tackling this for the project.
My last blog posting left off with the Chapter 6 homework. Well I completed Chapter 7's tasks earlier so I might as well add my thoughts on those exercises.
7.2.2
This was a very simple exercise. It just had us experimnet with the 'diff' command. The command without the '-u' flag prints only the line or lines in the file that were changed. With the '-u' flag there is much more information shown on the screen. The number line of the code plus the surrounding code for reference is some of the information that is displayed. This is very helpful for locating the changes in the files. I know because I had to find locations of changes in our project based on these files .
As I was saying, I was already familiar with the patch file before this exercise. I was using a diff file to implement our fix and had no idea. There were many similar changes that were previously tracked so I used these tracked changes to make my own changes. Wish I would of jumped ahead and read this chapter first, it would have made interpreting the patch file a whole lot easier in the begining.
7.8
Was not really successful with this exercise. I was unsure of what they mean by comparing dev/null. I tried to diff this file with the 'foo' file but it returns the message 'diff: dev/null: No such file or directory'. I was not sure about this question so I moved on and will ask the professor about this one later.
7.9
The last exercise was more straightforward than the last. There was a tutorial with the needed commands listed. I downloaded the source code, changed the specified file and created the patch. Very simple process. We just did this process when submitting our own patch to the Banshee project. We used a git patch though.
Well I guess I will finish up with our plans for the upcoming week before Spring Break. We are waiting to hear back from the developers with their thoughts on us taking on this project with a only a couple of months to finish. As I said earlier, Jesse has been in contact with them regarding this subject. In the meantime, I am scouring the massive bug list for other possibilities in case something does not work out with the Facebook extension. I have asked the others to do the same and bring couple options to class on Thursday. After we make a choice on a final project we will hash out a reasonable time-line for reaching our goals.
Well that's it for now. Going to do some actual work on this project now instead of just talking about it. Cheers!!!
Our team's moral is high right now. Our project is moving along nicely and we have not had any major hang ups yet. I didn't really expect any but you never know, and it sounds like others are having some troubles. Hope it continues this way until the end of the semester, my fingers are crossed. Our team has meshed nicely. No major issues between us to report and everyone gets along and works well together. That is a big plus! We do have a few members that are dong a little more than others but we have met on this topic and addressed the issue and feel we have it under control. We are excited by our success so far in this endeavor and are ready to close out strong with an interesting addition to the Banshee project.
We are leaning towards a Facebook extension for Banshee. The lead developers mentioned this would be nice to have so we thought maybe we could tackle another project they were trying to throw our way, much like the bug fix they recommended. It may be a bit much to try to finish in the short time we have left in the semester but we are not for sure. Jesse is checking with the developers right now to see how big of a project they feel this will be. Although even if we cannot wrap this extension up by the end of the semester, we can establish a solid foundation and some main functioning that will give others a platform to build off of. We may become involved enough to see this thing through even after graduation.
While Jesse is doing that I am doing my part by looking through the code of some of the other available extensions to see if I can get an estimate of the complexity based on these other modules. I will report back on this later after I have some more time to look through the code.
So what else...
Well, our team made a solid contribution to the Banshee project recently. You can read all about it here. We made many changes to filenames and code to reference 'banshee' instead of 'banshee-1'. It may have been a little grunt work, but it was much needed grunt work as the 2.0 release of Banshee is schedule for April. We are satisfied with our work and the developers are thankful towards us for tackling this for the project.
My last blog posting left off with the Chapter 6 homework. Well I completed Chapter 7's tasks earlier so I might as well add my thoughts on those exercises.
7.2.2
This was a very simple exercise. It just had us experimnet with the 'diff' command. The command without the '-u' flag prints only the line or lines in the file that were changed. With the '-u' flag there is much more information shown on the screen. The number line of the code plus the surrounding code for reference is some of the information that is displayed. This is very helpful for locating the changes in the files. I know because I had to find locations of changes in our project based on these files .
As I was saying, I was already familiar with the patch file before this exercise. I was using a diff file to implement our fix and had no idea. There were many similar changes that were previously tracked so I used these tracked changes to make my own changes. Wish I would of jumped ahead and read this chapter first, it would have made interpreting the patch file a whole lot easier in the begining.
7.8
Was not really successful with this exercise. I was unsure of what they mean by comparing dev/null. I tried to diff this file with the 'foo' file but it returns the message 'diff: dev/null: No such file or directory'. I was not sure about this question so I moved on and will ask the professor about this one later.
7.9
The last exercise was more straightforward than the last. There was a tutorial with the needed commands listed. I downloaded the source code, changed the specified file and created the patch. Very simple process. We just did this process when submitting our own patch to the Banshee project. We used a git patch though.
Well I guess I will finish up with our plans for the upcoming week before Spring Break. We are waiting to hear back from the developers with their thoughts on us taking on this project with a only a couple of months to finish. As I said earlier, Jesse has been in contact with them regarding this subject. In the meantime, I am scouring the massive bug list for other possibilities in case something does not work out with the Facebook extension. I have asked the others to do the same and bring couple options to class on Thursday. After we make a choice on a final project we will hash out a reasonable time-line for reaching our goals.
Well that's it for now. Going to do some actual work on this project now instead of just talking about it. Cheers!!!
Sunday, February 6, 2011
Chapter 6 Exercises
We were assigned several exercises from the Chapter 6 in the open source text we are reading. The first was to search our project's bug tracker for the oldest bug. So I visited Bugzilla's website and searched for Banshee. Many results popped up, nearly 1,500 bug reports. Finding the oldest proved a bit tricky at first because the report opened date was not a displayed column in the bugs list. I figured that there had to be a way to view the opened date without viewing every case. After exploring the page I found a link to change the displayed columns. I changed columns to display the opened date and then sorted by date; up popped the oldest bug.
So I checked out the report:
https://bugzilla.gnome.org/show_bug.cgi?id=122391
It appears this bug pertains to the system icon not appearing properly when Banshee is set to startup automatically on login. When set to startup automatically the tray icon appears only a pixel thick. This bug report was opened In September of 03 and its last update was in 2007. I think it is odd that even though this is the oldest bug it is still marked as 'new'. I figure this bug is still open because it is a minor situation and there is a work around available and posted for it. Reading further through the report I see that this error has been discovered to be a fault on the part of the Gnome panel so it has been assigned to their maintenance team. Then I realized, this is why it is still open. This bug affecting Bashee is probably not a high priority fix on the Gnome developer's list. As of 2007 this bug is still occurring and it has been stale for over three years now. I am not for sure if this bug will ever be resolved.
The next task at hand was to create a Bugzilla account but I did this a long time ago. I have been exploring the Bugzilla website for a couple weeks now and am beginning to feel fairly comfortable with its interface.
After supposedly creating an account it was on to triage duty. I am familiar with this term because we have triage duty where I intern. I began to look over the Banshee bug list and decided to start with the newest because I figured no one had the chance to get to them yet. I sorted by status and began looking through all the bugs marked 'new', there were hundreds! The first couple I visited had extensive histories to them. I took time to read a couple more then I realized there is nothing I can add to these cases, I need to find the fresh cases. So I sorted by date again but this time listing the newest bugs at the top. Some of these bug reports were from today. I thought to myself, 'there has be some untouched cases here.' I opened the most recent case which was from earlier this morning and one of the main developers had already responded to it. I thought, 'WOW, these guys are really on top of things!'
After reading the top couple reports, I found one where the reporter posted this long error in the report instead of attaching it in a file. I wanted to cut out the text of the error and just attach in a file it to the report but was unable to do this. There was hardly any information left in the report except the long error message so I wanted to request more info but I am just not familiar enough yet with Linux, Ubuntu or Banshee to know what information to request. I looked through many other bugs but for the same reason I felt I could not help. I need to really dive into the program and learn its insides before I can really request the appropriate information. Knowledge of this code will come with a little time I am hoping.
I was beginning to get a bit discouraged when I came across a report that I felt I could do something about.
https://bugzilla.gnome.org/show_bug.cgi?id=640736
This user would like better descriptive text of the process when logging into a Last.fm account. I have a Last.fm account and have already set it up in Banshee so I am familiar with the login process. It is a bit convoluted and it requires the user to visit a Last.fm web page in order to allow access but it is sufficient. There is a dialog box that opens as you mouse-over the login button that explains the process better. I was going to post on the bug report to inform the reporter of the dialog box that pops up displays almost the exact information he is requesting but felt the need to ask first since I am a noob. I sent an email to the project emailing list with a link to the bug and my proposed actions. I explained to them the user request and my planned actions and asked for their input. Also mentioned I would be happy to look into changing the Last.fm login window to display the extra information if they thought the suggestion was a good idea.
After finally finding something, it renewed my interest. I thought that there may be other simple things I can do to start off. Well as I expected, I came across a few others.
https://bugzilla.gnome.org/show_bug.cgi?id=638571
This user would like a better description in the dialog box that is displayed as you mouse over the “Simplify” button in the “Now Playing” pane. Not sure this change is necessary, but the dialog could be a bit more descriptive.
https://bugzilla.gnome.org/show_bug.cgi?id=640124
This user would like the text “Transferring” removed from the pod cast download progress that appears in the sidebar of the program. This is an easy fix although I am not sure whether it is necessary either. I do experience the same issue as this user. Maybe replacing 'transferring' with a shorter word (although nothing comes to mind) or stacking it on top of the 'x of y files at...' text would be a feasible solution. Removing it, as the user suggested, is an option as well.
As with the first bug report, I emailed the project mailing list with the links to the bugs and my suggested resolutions. Don't know if these guys will think I'm a total idiot or if they will be excited for me to get involved but I am hoping the latter. We will find out, just waiting to hear back from someone now. If the project leads approve these changes I have already located the places within the code that needs changed. I can make these fixes and submit them for approval quickly. Even though these are very minor contributions it still feels pretty cool to be contributing to a very large project.
So I checked out the report:
https://bugzilla.gnome.org/show_bug.cgi?id=122391
It appears this bug pertains to the system icon not appearing properly when Banshee is set to startup automatically on login. When set to startup automatically the tray icon appears only a pixel thick. This bug report was opened In September of 03 and its last update was in 2007. I think it is odd that even though this is the oldest bug it is still marked as 'new'. I figure this bug is still open because it is a minor situation and there is a work around available and posted for it. Reading further through the report I see that this error has been discovered to be a fault on the part of the Gnome panel so it has been assigned to their maintenance team. Then I realized, this is why it is still open. This bug affecting Bashee is probably not a high priority fix on the Gnome developer's list. As of 2007 this bug is still occurring and it has been stale for over three years now. I am not for sure if this bug will ever be resolved.
The next task at hand was to create a Bugzilla account but I did this a long time ago. I have been exploring the Bugzilla website for a couple weeks now and am beginning to feel fairly comfortable with its interface.
After supposedly creating an account it was on to triage duty. I am familiar with this term because we have triage duty where I intern. I began to look over the Banshee bug list and decided to start with the newest because I figured no one had the chance to get to them yet. I sorted by status and began looking through all the bugs marked 'new', there were hundreds! The first couple I visited had extensive histories to them. I took time to read a couple more then I realized there is nothing I can add to these cases, I need to find the fresh cases. So I sorted by date again but this time listing the newest bugs at the top. Some of these bug reports were from today. I thought to myself, 'there has be some untouched cases here.' I opened the most recent case which was from earlier this morning and one of the main developers had already responded to it. I thought, 'WOW, these guys are really on top of things!'
After reading the top couple reports, I found one where the reporter posted this long error in the report instead of attaching it in a file. I wanted to cut out the text of the error and just attach in a file it to the report but was unable to do this. There was hardly any information left in the report except the long error message so I wanted to request more info but I am just not familiar enough yet with Linux, Ubuntu or Banshee to know what information to request. I looked through many other bugs but for the same reason I felt I could not help. I need to really dive into the program and learn its insides before I can really request the appropriate information. Knowledge of this code will come with a little time I am hoping.
I was beginning to get a bit discouraged when I came across a report that I felt I could do something about.
https://bugzilla.gnome.org/show_bug.cgi?id=640736
This user would like better descriptive text of the process when logging into a Last.fm account. I have a Last.fm account and have already set it up in Banshee so I am familiar with the login process. It is a bit convoluted and it requires the user to visit a Last.fm web page in order to allow access but it is sufficient. There is a dialog box that opens as you mouse-over the login button that explains the process better. I was going to post on the bug report to inform the reporter of the dialog box that pops up displays almost the exact information he is requesting but felt the need to ask first since I am a noob. I sent an email to the project emailing list with a link to the bug and my proposed actions. I explained to them the user request and my planned actions and asked for their input. Also mentioned I would be happy to look into changing the Last.fm login window to display the extra information if they thought the suggestion was a good idea.
After finally finding something, it renewed my interest. I thought that there may be other simple things I can do to start off. Well as I expected, I came across a few others.
https://bugzilla.gnome.org/show_bug.cgi?id=638571
This user would like a better description in the dialog box that is displayed as you mouse over the “Simplify” button in the “Now Playing” pane. Not sure this change is necessary, but the dialog could be a bit more descriptive.
https://bugzilla.gnome.org/show_bug.cgi?id=640124
This user would like the text “Transferring” removed from the pod cast download progress that appears in the sidebar of the program. This is an easy fix although I am not sure whether it is necessary either. I do experience the same issue as this user. Maybe replacing 'transferring' with a shorter word (although nothing comes to mind) or stacking it on top of the 'x of y files at...' text would be a feasible solution. Removing it, as the user suggested, is an option as well.
As with the first bug report, I emailed the project mailing list with the links to the bugs and my suggested resolutions. Don't know if these guys will think I'm a total idiot or if they will be excited for me to get involved but I am hoping the latter. We will find out, just waiting to hear back from someone now. If the project leads approve these changes I have already located the places within the code that needs changed. I can make these fixes and submit them for approval quickly. Even though these are very minor contributions it still feels pretty cool to be contributing to a very large project.
Wednesday, February 2, 2011
Chapter 5 Exercise
After setting up our project's source code on the Subversion server I completed the exercise in Chapter Five of the Open Source textbook we are reading. This exercise requires us to get the source code for FreeCiv, an open source role playing game, and build it on our machines. This is already a familiar process so it did not take me very long to complete.
I started by getting the source code from FreeCiv's source code repo. This is done by using the command 'svn co svn://svn.gna.org/svn/freeciv/trunk freeciv'. Running this command downloaded the code to my machine. It took a while to transfer all the code to my machine but it eventually finished.
I opened the INSTALL file to check the needed dependencies. I went through the list and checked if each was installed and discovered I was missing a few but could not install them by the name used in the documentation. So I decided to just try and build it without the few I was missing. This did not work, go figure!
The first package I was missing was referred to as 'glib'. Like I stated above, I could not find this package to install by its name so I searched the package manager. Here I found all of the missing packages that I needed.Through trial and error build attempts, I installed all my missing packages and was able to build the code. After that it was the same process, run the make command and then './ser' and the program was up and running.
Like I said this whole process probably took me 15 minutes and was familiar to me, maybe I am getting a little better at this open source stuff.... ;-)
I started by getting the source code from FreeCiv's source code repo. This is done by using the command 'svn co svn://svn.gna.org/svn/freeciv/trunk freeciv'. Running this command downloaded the code to my machine. It took a while to transfer all the code to my machine but it eventually finished.
I opened the INSTALL file to check the needed dependencies. I went through the list and checked if each was installed and discovered I was missing a few but could not install them by the name used in the documentation. So I decided to just try and build it without the few I was missing. This did not work, go figure!
The first package I was missing was referred to as 'glib'. Like I stated above, I could not find this package to install by its name so I searched the package manager. Here I found all of the missing packages that I needed.Through trial and error build attempts, I installed all my missing packages and was able to build the code. After that it was the same process, run the make command and then './ser' and the program was up and running.
Like I said this whole process probably took me 15 minutes and was familiar to me, maybe I am getting a little better at this open source stuff.... ;-)
Importing the code...
I have a little catching up to do so lets get to it. My last blog was about my experience installing the Subversion client and playing around in the Subversion playground Dr. Bowring setup for the class. The other part of that assignment was to set up the server side of Subversion locally on our machines. I did so with the assistance of the Subversion book Dr. B recommended. There were several options for setting up Subversion with different configurations. I choose just set up a local Subversion server to track all of my documents, this may be useful for tracking changes made to my school documents or other files stored on my machine. It only took a couple of commands to do this and it was set up. I played with it a bit but I think I will need to become more familiar with this tool before I put it to such use.
The past couple classes have been mostly discussion sessions. This past class we discussed our experiences at attempting the most recent assignment, obtain our projects source code and build it. Our team did well and has posted its experience report here. Some teams were having some real problems but so far (fingers crossed) everything has been going real smooth for us.
After our team gave its experience report Dr Bowring suggested that we get our source code setup on the Subversion server. This sounded like a great idea so I jumped on it when I had a free moment. Our code came from a Git repository and it needed to be migrated into a SVN repo. Therefore I looked for an article on-line on how to migrate a Git repo to a subversion repo but was unable to find any clear articles on this process. Strangely enough, there are tons of the reverse out there on the web, go figure??? So I decided to manually remove the .git files. This required me doing this this through a command line because the files were locked and I did not even have the option to delete them in the OS GUI. After displaying all the hidden files, I was able to remove all files ending in .git.
After the project was 'clean' I needed to figure out how to get the source code onto the server and versioned properly. I wasted a bit of time trying to just commit it for the first time but ran into nothing but problems. It appeared to begin to copy but would never finish or would fail with an error. So, I did some reading in the Subversion book and figured out it needed to be imported for the first time in order to set up the versioning of the files properly.
It took a very long time to finish the import but when it finished our source code showed up in the playground repo. Awesome!!! Just as a test, I removed all the source code from my working space and updated my folder. Presto, it was back. Just to make sure everything imported properly onto the server, I rebuilt the code I downloaded from the server and ran it. Banshee fired right up with no issues. Looks like the import was a success.
Now that the code is set up in the Playground repo we have moved on th the next stage of our project, locating and fixing a bug. We think we have already located the bug we want to fix. We currently using MonoDevelop to explore the code in order to find this bug. At first it appeared that this was going to be an easy fix but we have yet to locate the bug within the code. We do have a community of help out there so we decided to reach out to them for the first time for help. Jesse sent out an email to the emailing list explaining the bug we have taken interest in and asking for help on it's general whereabouts in the code.
As of right now, we have not heard anything back yet from the community. BUT, we are hopeful considering Jesse just sent this email out earlier today. Feedback or not, we are pushing forward with our project and will continue to pursue this bug.
The past couple classes have been mostly discussion sessions. This past class we discussed our experiences at attempting the most recent assignment, obtain our projects source code and build it. Our team did well and has posted its experience report here. Some teams were having some real problems but so far (fingers crossed) everything has been going real smooth for us.
After our team gave its experience report Dr Bowring suggested that we get our source code setup on the Subversion server. This sounded like a great idea so I jumped on it when I had a free moment. Our code came from a Git repository and it needed to be migrated into a SVN repo. Therefore I looked for an article on-line on how to migrate a Git repo to a subversion repo but was unable to find any clear articles on this process. Strangely enough, there are tons of the reverse out there on the web, go figure??? So I decided to manually remove the .git files. This required me doing this this through a command line because the files were locked and I did not even have the option to delete them in the OS GUI. After displaying all the hidden files, I was able to remove all files ending in .git.
After the project was 'clean' I needed to figure out how to get the source code onto the server and versioned properly. I wasted a bit of time trying to just commit it for the first time but ran into nothing but problems. It appeared to begin to copy but would never finish or would fail with an error. So, I did some reading in the Subversion book and figured out it needed to be imported for the first time in order to set up the versioning of the files properly.
It took a very long time to finish the import but when it finished our source code showed up in the playground repo. Awesome!!! Just as a test, I removed all the source code from my working space and updated my folder. Presto, it was back. Just to make sure everything imported properly onto the server, I rebuilt the code I downloaded from the server and ran it. Banshee fired right up with no issues. Looks like the import was a success.
Now that the code is set up in the Playground repo we have moved on th the next stage of our project, locating and fixing a bug. We think we have already located the bug we want to fix. We currently using MonoDevelop to explore the code in order to find this bug. At first it appeared that this was going to be an easy fix but we have yet to locate the bug within the code. We do have a community of help out there so we decided to reach out to them for the first time for help. Jesse sent out an email to the emailing list explaining the bug we have taken interest in and asking for help on it's general whereabouts in the code.
As of right now, we have not heard anything back yet from the community. BUT, we are hopeful considering Jesse just sent this email out earlier today. Feedback or not, we are pushing forward with our project and will continue to pursue this bug.
Subscribe to:
Posts (Atom)