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.

Permalink | 2 comments
Post 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.

Permalink | One comment
Post tags: AJAX, API, Arsenal, Bugzilla, Code, Curl, Debian, GSoC, Launchpad, Open Source, Python, REST, Ubuntu, XML-RPC

Related Links

Time Spent

90 hours.

Highlights

• Refactored Attachment Upstreamer in order to migrate Launchpad and Bugzilla chores to launchpadlib-toolkit and BugzillaAdapter.
• Implemented match-upstream.py for matchmaking Launchpad bugs in remote trackers.
• Implemented bug-patcher.py for generating patched Debian packages for Launchpad bugs.

Concerns

None.

Waiting Items

None.

Stalled Items

None.

Accomplishments

• Branch, Merge Revision: Migrated Attachment Upstreamer to use launchpadlib-toolkit.
• Branch, Merge Revision: Migrated Attachment Upstreamer to use BugzillaAdapter.
• Revision: Updated launchpadlib-toolkit to serve scripts such as Attachment Upstreamer through attachment filters and wrappers.
• Branch, Merge Revision: Implemented match-upstream.py with support for multiple level searches for finding a bug’s attributes in a remote tracker. Supports searching titles, git commit ids and attachment filenames.
• Branch: Implemented bug-patcher.py with support for modifying Debian packages which use cdbs patch system to generate a patched version using a bug’s attachments.

Minor Tasks

• Created a LaunchpadBugzillaApp class which shares majority of the initialization code for send-attachments-upstream.py, match-upstream.py and bug-patcher.py.
• Fixed various bugs in LaunchpadBugzillaApp for dealing with Gnome Keyring and Launchpad authentication.
• Added various filters to launchpadlib-toolkit.

Actions for the Following Report

• LaunchpadBugzillaApp should be derived from LaunchpadApp which would allow using the latter for scripts such as bug-patcher.py where Bugzilla portions aren’t required.
• Update Bug Patcher to include support for remaining Debian patch systems.
• Clean up the code accumulated over GSoC development and write tests.

Permalink | No comment
Post tags: 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

Permalink | No comment
Post 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:

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:

1. Switch on Bluetooth in the cellphone.

   

2. Launch bluetooth-properties and click on “Setup New Device”.

   

3. Select your cellphone.

   

4. You will be shown a pin.

   

5. Enter the pin when queried on the cellphone.

   

6. The phone should be successfully paired.

   

7. Authorize your Linux system to make automatic connections to the phone.

   

8. As root, run this shell script:

   [root@orthanc ~]# ./rfcomm-listen.sh

   Serial Port service registered
   Waiting for connection on channel 2

9. Launch PyS60 interpreter and select “Bluetooth Console” from the application menu.

   

10. 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:

    

11. As root again, open a new terminal and run:

    [root@orthanc ~]# cu -l /dev/rfcomm0

    Connected.

12. Hit Enter till prompt (>>>) appears, then type:
    

    >>> import appuifw
    >>> appuifw.query(u'Hello World', 'text')

13. Viola, you should have an input box on the mobile screen:

    

14. 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’

15. 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!

Permalink | 4 comments
Post tags: Bluetooth, Code, Debian, Debugging, Fedora, Flag 42, Linux, Mobile, Nokia, Open Source, PyS60, Python, Series 60, Symbian, Technology, Tutorial, Ubuntu