The Program
And with the final code submission uploaded at Google Code, Summer of Code 2010 officially draws to a close. What a ride it has been!
My first post on Inspirated regarding Summer of Code took place all the way back in March 07 when I submitted a proposal for Fedora. Three and a half years later, I finally appreciate the fact that GSoC is about much more than just the code. In fact, “Summer of Open-Source” would probably be a more suitable title for the program despite sounding half as sexy. When my proposals got rejected I had to learn, contribute and integrate more with the open-source crowd. When one of the applications finally made it beyond the selection process, I had to “bond” with the organization I was going to be working with. During the coding weeks, I had to communicate regularly with my mentor and Ubuntu community in order to ensure that I was progressing in the right direction. To summarize, becoming a part of the open-source universe is as important an aspect of GSoC as producing open-source code.
The Code
Here’s a quick rundown of the code produced for the program (without including the intermediate branches and patches):
Attachment Search
- Merge Revision: Expot API call for listing the source packages a team has subscribed to.
- Branch: Search attachment files using Horspool’s algorithm. The branch eventually didn’t make it upstream as it was decided that with the existing implementation the searches would be too expensive for Launchpad, essentially requiring a solution with a different design approach.
Arsenal and python-launchpadlib-toolkit Modifications
- Package, Package, Package: These libraries had to be modified extensively in order to provide support for the Arsenal scripts developed during GSoC. Classes like
LaunchpadApplication, LaunchpadBugzillaApplication and BugzillaAdapter perform regular chores for these applications e.g., authentication, web-scraping and keyring manipulation.
Attachment Upstreamer
- Script: Command-line script for upstreaming attachments from a Launchpad bug to a remote Bugzilla.
- Script, Template: CGI script for demonstrating the capabilities of Arsenal library and python-launchpadlib-toolkit.
Bug Matchmaker
“Incompatibility: In matrimony, a similarity of tastes, particularly the taste for domination.” — Ambrose Bierce
Fortunately, matchmaking across different bug trackers was easier.
- Script: Command-line script for searching a remote Bugzilla for similar entries to a given Launchpad bug.
Automatic Patcher
- Script: Command-line script for automatically generating patched Debian packages for a given Launchpad bug using diff files found in its attachments.
The Nutshell
The processes of collaborating, getting code reviewed and improving accordingly has gone a long way in instilling more confidence in me as a FLOSS developer. On the technological side of things I’ve had to deal with REST APIs, Zope Interfaces, OAuth procedures, web-scrapers based on Curl, Debian patch systems, a plethora of Python and a good-bit doze of different development paradigms.
It has been awesome working with the Ubuntu community and Bryce’s guidance has been absolutely crucial for ensuring that something useful was produced by my project. I’d like to thank everyone involved in the program for making it so much fun. I Know What I Did This Summer.
Tags:
AJAX,
API,
Arsenal,
Bugzilla,
Code,
Curl,
Debian,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
XML-RPC
As eleven weeks of the-best-summer-ever draw to an end, here’s the final coding report for GSoC 2010.
Related Links
Time Spent
60 hours.
Highlights
The week was spent mostly cleaning and packaging the code accumulated over the summer. To demonstrate some of the aspects of the Arsenal library, I also created a proof-of-concept CGI script which upstreams Launchpad attachments for a bug to a remote Bugzilla. The task was fun, as the efforts put into refactoring things into launchpadlib-toolkit and BugzillaAdapter finally paid off and it took only a few hours to get the script working (that too with most of the time spent learning AJAX).
Concerns
None.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Branch, Merge Revision:
- Revision: Added support for quilt.
- Revision: Added support for using patch utility for quilt packages where the diff files update debian/* stuff themselves.
- Revision: Cleaned up the library to provide
LaunchpadApplication and LaunchpadBugzillaApplication.
- Revision: Fixed
BugPatcher to use LaunchpadApplication as base class.
- Revision: Cleaned up
LaunchpadBugzillaApplication to take username password as arguments instead of modifiers.
- Branch, Merge Revision: Fixed packaging issues to release
debs for Karmic and Lucid.
- Branch: Implemented a CGI script demonstrating the upstreaming capabilities of Arsenal library. An example run can be seen in this screencast.
Minor Tasks
- Revision: Some more code cleanup.
- Revision: Check
launchpadlib version before appending ‘/beta‘ during API URL detection.
Actions for the Following Report
- Fill the final evaluation.
- Write a summary of the overall GSoC experience.
- Start waiting for the t-shirt.
Tags:
AJAX,
API,
Arsenal,
Bugzilla,
Code,
Curl,
Debian,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
XML-RPC
Threads are love. Threads are speed. And more often than not, threads are a consistent PITA. However, I’ve had an accidental epiphany just a few hours ago:
“When in doubt When you need to communicate among threads, use synchronized Queues.”
There. This magic mantra will solve more issues in your life than you can ever imagine, and certainly more than I expected.
Getting back to the topic at hand, adding threading support to the program has sped up the bookmark checking process by a factor of about 435895234. Coupled with fixing of some parsing bugs, Bookmark Undertaker v0.3 is finally capable of providing a quick, stable and consistent way of sanitizing your Firefox favorites:
This time, I’ve also tried to provide Deb and RPM packages on the release page for easy installation by the Debian/Ubuntu/Fedora populace.
Ushering in the era of communist applications:
“If everyone gives one thread, the poor person will have a shirt.” — Russian Proverb
Tags:
Beautiful Soup,
Bookmark Undertaker,
Bookmarks,
Code,
Deb,
Debian,
Fedora,
Firefox,
Mozilla,
Open Source,
PyGTK,
Python,
Red Hat,
RPM,
Technology,
Threading,
Ubuntu
While developing PyS60 apps is one of the most fun things you could do with your Nokia phone, debugging them isn’t as zippy as one would hope for in a Py development environment. To make up for that, PyS60 gives the developers an option for directly connecting to the interpreter through Bluetooth. Doesn’t sound very appealing? How about this: You connect your laptop with the cellphone, jump in at some place in the code while your app is executing and then use lappy’s big keyboard for exploiting different code and values in the interpreter. Sounds better?
To accomplish this on a Linux distro, you will need the following packages installed on your system:
| Name |
Links |
gnome-bluetooth |
|
uucp/cu |
|
After making sure that both are present on your system, install PyS60 on your phone if you haven’t already done so.
Now the fun part:
- Switch on Bluetooth in the cellphone.
- Launch
bluetooth-properties and click on “Setup New Device”.
- Select your cellphone.
- You will be shown a pin.
- Enter the pin when queried on the cellphone.
- The phone should be successfully paired.
- Authorize your Linux system to make automatic connections to the phone.
- As
root, run this shell script:
[root@orthanc ~]# ./rfcomm-listen.sh |
Serial Port service registered
Waiting for connection on channel 2
- Launch PyS60 interpreter and select “Bluetooth Console” from the application menu.
- Select your Linux machine.
The command you ran in previous step should have new output:
[root@orthanc ~]# ./rfcomm-listen.sh |
Serial Port service registered
Waiting for connection on channel 2
Connection from 00:17:4B:B6:35:31 to /dev/rfcomm0
Press CTRL-C for hangup
The cellphone screen should be showing something like this:
- As
root again, open a new terminal and run:
[root@orthanc ~]# cu -l /dev/rfcomm0 |
Connected.
- Hit Enter till prompt (
>>>) appears, then type:
>>> import appuifw
>>> appuifw.query(u'Hello World', 'text')
- Viola, you should have an input box on the mobile screen:
- Enter any text and press the OK key. It should be show up in the terminal you were using to type in code:
>>> import appuifw
>>> appuifw.query(u'Hello World', 'text')
u’Finally’
- Exit the interpreter by typing
CTRL+D on an empty line:
>>> import appuifw
>>> appuifw.query(u'Hello World', 'text')
u’Finally’
>>>
Interactive interpreter finished.
cu: Got hangup signal
Disconnected.
Pat yourself on the back. Now, you can use your Bluetooth console to import your modules, execute some stuff and then jump in the middle to test some extra lines or values. In fact, I found it to be a pretty darned good way of learning about PyS60′s API. Res secundae!
Tags:
Bluetooth,
Code,
Debian,
Debugging,
Fedora,
Flag 42,
Linux,
Mobile,
Nokia,
Open Source,
PyS60,
Python,
Series 60,
Symbian,
Technology,
Tutorial,
Ubuntu
