The final package arrived today containing the (100% Organic Orgasmic) shirt and certificate:
(Click on the thumbnail for larger version.)
Tags:
Google,
GSoC,
Open Source,
Rants,
T-Shirts,
Ubuntu
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
Related Links
Time Spent
60 hours.
Highlights
New features were added to Attachment Upstreamer in order to make it more suitable for issues encountered by Ubuntu maintainers (as suggested by Bryce from his experience as the X.org maintainer).
Concerns
None.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Branch, Merge Revision: Implemented caching of Bugzilla credentials using Gnome Keyring and
ConfigParser.
- Merge Revision:
- Branch: Added support for excluding attachments based on filename matching using glob patterns.
- Branch: Added support for extracting Tar and Zip archives when the number of files in them is below a specified limit.
- Branch: Added support for excluding attachments based on their sizes, optionally Gzipping them in an effort to make the size acceptable.
- Branch: Added support for enforcing content-types of attachments based on their filenames.
Minor Tasks
- Various bugfixes and code-cleanup for previously merged GSoC code.
Actions for the Following Report
The Launchpad and Bugzilla sides of the Upstreamer are to be cleaned up and made dependent on launchpadlib-toolkit and BugzillaAdapter respectively. This will help future scripts which rely on Bugzilla communication as well as make such things agnostic to the implementation lying beneath the adapter (e.g., whether we’re using Curl/XML-RPC/REST to talk to the server).
Tags:
API,
Arsenal,
Bugzilla,
Code,
Curl,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
XML-RPC
Related Links
Time Spent
50 hours.
Highlights
The send-attachments-upstream.py script was migrated from XML-RPC to Curl for communicating with Bugzilla. The script was the refactored in order to provide capabilities such as attachment filtering. Various bugfixes and improvements were catered to along the way.
Concerns
None.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Branch, Merge Revision: Reimplemented attachment sending using
pycurl.
- Branch, Merge Revision: Refactored the script in order to provide options such as
-o (copy only attachments uploaded by bug owner).
Minor Tasks
- Branch, Merge Revision: Fixed regular expressions for parsing results and handling of Unicode attachment titles.
Actions for the Following Report
Implement the following improvements in send-attachments.py:
- Caching Bugzilla credentials.
- Filename exclusion for attachments.
- Archive extraction.
- File size limits.
- A command-line switch to enforce MIME content-types based on file extensions.
Tags:
API,
Arsenal,
Bugzilla,
Code,
Curl,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
XML-RPC
Related Links
Time Spent
10 hours.
Highlights
Communicating with Bugzilla is done through the python-bugzilla wrapper library. This could have been achieved by using xmlrpclib directly but doing that would require reinventing a whole lot of wheels by handling Bugzilla specific XML-RPC eccentricities.
Concerns
None.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Branch: Added support for copying attachments to a remote bugzilla:
$ ./send-attachments-upstream.py --user=krkhan@inspirated.com --pass=xxx https://bugs.launchpad.net/ubuntu/+bug/223435 https://partner-bugzilla.redhat.com/show_bug.cgi?id=593603 |
Logging in Launchpad [Success <Logged in as Kamran Riaz Khan>]
Logging in Bugzilla [Success <Logged in as krkhan@inspirated.com>]
Uploading: Dependencies.txt [Success]
Uploading: Disassembly.txt [Success]
Uploading: ProcMaps.txt [Success]
Uploading: ProcStatus.txt [Success]
Uploading: Registers.txt [Success]
Uploading: Stacktrace.txt [Success]
Uploading: ThreadStacktrace.txt [Success]
Uploading: Stacktrace.txt (retraced) [Success]
Uploading: ThreadStacktrace.txt (retraced) [Success] |
Minor Tasks
- Revision: Added python-bugzilla in lib and modified setup.py accordingly.
- Revision: Initial commit for sending attachments to a remote Bugzilla.
- Revision: Added error handling for API calls.
Actions for the Following Report
Add support for creating new bugs in a remote Bugzilla based on data from a Launchpad bug.
Tags:
API,
Arsenal,
Bugzilla,
Code,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
XML-RPC
Related Links
Time Spent
40 hours.
Highlights
This week was spent on trying to get my Launchpad branches merged upstream. During the process many concerns were raised which resulted in a number of patches and discussions.
Concerns
Quoting Stuart Bishop’s response from Launchpad-dev:
I’m really not sure of the best way to tackle this problem. The
Librarian data is not stored in the database because there are
multiple TB of files. The team membership information is in the
relational database. There are no indexes anywhere to the contents of
the Librarian files. I think we need some sort of external search
engine (I don’t think we don’t want to integrate this into the
Librarian core). Ideally we could feed it subscriber information
allowing it to determine the set of 32000 attachments that ubuntu-bugs
has access to rather than having to calculate this information from
the relational db and then feed the ids to the search engine.
Whatever approach certainly needs signoff from the LP team leads, as
the resource requirements are non trivial and someone needs to pay for
the hardware.
Waiting Items
None.
Stalled Items
- Implementation of
Bug.findAttachments().
Accomplishments
- Merge Proposal: Got the
export-Person-getBugSubscriberPackages branch approved after fixing various tests and bugs.
- Merge Proposal: Implemented Horspool’s algorithm and fixed various bugs in the
implement-Bug-findAttachments branch. The branch itself didn’t get approved because of its design approach for searching the attachments:
I’m going to mark this review as ‘disapproved,’ not because the code is
bad (it isn’t) but because I don’t think this is the right solution to
the problem. I’m sorry to say that I don’t know what the right solution
to the problem actually is at this point, but I’d guess that something
involving FTIs would be a start, or some kind of asynchronous processing
of searches (though then you get into all kinds of knotty stuff with
callbacks).
Minor Tasks
For reading the file in chunks, I took the Wiki code for Horspool algorithm, converted it to Python and modified a little so that it would work with stream files.
Actions for the Following Report
There doesn’t appear to be a straightforward efficient way for searching bug attachments. I’ll discuss the course of my future development with Bryce tonight and decide whether I should head over to Arsenal development or should I focus on the proposed (albeit germinal) solutions from IRC and the mailing list.
Tags:
API,
Arsenal,
Code,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu
Related Links
Time Spent
15 hours.
Highlights
During the course of my SoC work on Launchpad I have been following a simple procedure for developing API calls:
- Find a similar functionality which is already implemented upstream.
- Log PostgreSQL queries while using that functionality and then analyze the queries made along with database schemas to devise a plan for implementing the new feature.
As documented in my previous report, I had to implement a property/method for exporting “Source Packages” a “Team” was subscribed to. Going through the chores listed above, I ended up with a query for structural subscriptions table which joined teams and source packages. The method worked perfectly. That is, until I reopened the interface definition today and searched for my changes. I landed on something that looked similar and then realized that the method was already there in Launchpad, just not exported yet.
That condensed my work to just a few lines as I discarded my own changes and their unit tests and exported the method that was already present upstream. Lesson learned: Search your project thoroughly before starting the coding phase in case you’re duplicating someone else’s efforts.
Concerns
The method for getting bug subscriptions for a team had this comment on top:
# XXX: Tom Berger 2008-04-14 bug=191799:
# The implementation of these functions
# is no longer appropriate, since it now relies on subscriptions,
# rather than package bug supervisors.
def getBugSubscriberPackages(self): |
I’m not sure if a merge proposal for exporting this operation would be accepted since the implementation is “no longer appropriate”. Will discuss this with Bryce in detail tonight.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Patch: Exported
Person.getBugSubscriberPackages() as read only operation.
Minor Tasks
The process of returning a collection of source packages created a circular import dependency which broke down the process of WADL resource generation. Again, going around Launchpad code revealed that this could be fixed by just returning a generic Interface and then patching it later on in lib/canonical/launchpad/interfaces/_schema_circular_imports.py.
Actions for the Following Report
Searching for bug attachments in source packages is already possible using my bugs-findAttachment branch. In case Person.getBugSubscriberPackages() is considered okay, I have all the Launchpad pieces in place now for doing this in Arsenal: “Search for text in all bug attachments for packages this team is subscribed to”. Really looking forward to having a bit more “freedom” with the codebase than I had with Launchpad.
Tags:
API,
Arsenal,
Code,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu
Related Links
Time Spent
20 hours.
Highlights
The process of “presenting” my code to a giant project like Launchpad made me learn a lot about how to plan, execute and test modifications for large-scale open source projects. It’ll be fun to see the final outcome merged upstream.
I am also feeling more and more confident dealing with Launchpad development. It’s gratifying to know that if I need some API calls during the course of my SoC work which aren’t already there, I’ll be able to implement them on short notices.
Concerns
As per the discussion with Bryce, the approach for attachment search needs to be changed a bit. Instead of going through the “Product -> Bugs -> Attachments” route, we need to instead focus on the “Team -> Source Packages -> Bugs -> Attachments” alternate.
Waiting Items
None.
Stalled Items
None.
Accomplishments
- Patch: Added unittest for
bugs collection.
- Patch: Added unittests for
bugs.findAttachments.
- Written merge proposal for project-bug-collection branch:
Merge proposal for lp:~inspirated/launchpad/project-bug-collection
Summary
As part of my Google Summer of Code project, I had to implement attachment searching functionality in Arsenal. The end-product would allow user to specify a search string which would be searched in all the bug attachments for a project.
Doing this efficiently required two modifications in Launchpad:
- Exposing a bug collection for a particular product (this branch)
- Implement an attachment search method for a particular bug
Proposed fix
Export a bugs CollectionField for IProductPublic.
Pre-implementation Notes
- The exported field should be read-only
Implementation Details
- Bug schema does not refer to Products directly. Therefore, a join was required to query BugTasks which point towards the Product in question and then query the Bugs related to that BugTask.
Tests
$ bin/test -vv -m lp.registry.tests.test_product -t test_bug_collection |
Demo and Q/A
Create a Launchpad instance:
>>> from launchpadlib.launchpad import Launchpad
>>> launchpad = Launchpad.login_with('just testing', 'https://api.launchpad.dev/beta/')
The authorization page:
(https://launchpad.dev/+authorize-token?oauth_token=ppd2bRZDnN6VX94lRqrq)
should be opening in your browser. After you have authorized
this program to access Launchpad on your behalf you should come
back here and press <Enter> to finish the authentication process. |
Load a project:
>>> project = launchpad.projects['firefox']
>>> project
<project at https://api.launchpad.dev/beta/firefox>
>>> project.bugs
<lazr.restfulclient.resource.Collection object at 0x925c04c> |
Use the bugs collection:
>>> for bug in project.bugs:
... print bug.title
...
Firefox does not support SVG
Reflow problems with complex page layouts
Firefox install instructions should be complete
Firefox crashes when Save As dialog for a nonexistent window is closed |
lint
The changes are lint clean.
- Written merge proposal for implement-Bug-findAttachments branch:
Merge proposal for lp:~inspirated/launchpad/implement-Bug-findAttachments
Summary
As part of my Google Summer of Code project, I had to implement attachment searching functionality in Arsenal. The end-product would allow user to specify a search string which would be searched in all the bug attachments for a project.
Doing this efficiently required two modifications in Launchpad:
- Exposing a bug collection for a particular product
- Implement a attachment search method for a particular bug (this branch)
Proposed fix
Export a read operation findAttachment in IBug which returns a collection of IBugAttachment.
Pre-implementation Notes
- The search operation is essentially a text-only grep.
Implementation Details
- Zope configuration had to be updated to export the method
- Multi-line searches break the GET request with a “HTTP/1.1 400 Bad Request” response
- The attachments are all opened as regular file objects and then searched for the target pattern.
Tests
bin/test -vv -m lp.bugs.tests.test_bug_find_attachment |
Demo and Q/A
Open any Launchpad bug in a browser:
https://launchpad.dev/bugs/15 |
Create an attachment and upload any text file containing the string ‘char buf’.
Create a Launchpad instance:
>>> from launchpadlib.launchpad import Launchpad
>>> launchpad = Launchpad.login_with('just testing', 'https://api.launchpad.dev/beta/')
The authorization page:
(https://launchpad.dev/+authorize-token?oauth_token=ppd2bRZDnN6VX94lRqrq)
should be opening in your browser. After you have authorized
this program to access Launchpad on your behalf you should come
back here and press <Enter> to finish the authentication process. |
Load the bug:
>>> bug = launchpad.bugs[15] |
Search for the attachment containing the string ‘char buf’:
>>> results = bug.findAttachments(text=u'char buf')
>>> for attachment in results:
... print attachment.title
...
Buffer Overflow Intro.txt |
lint
The changes are lint clean.
Minor Tasks
Around 8 hours were spent trying to find out why on earth my API calls weren’t getting recognized by apidoc or launchpadlib. In the end, Leonard Richardson pointed out that I was missing a make clean for regenerating the WADL cache. Can’t say it feels great to know that overlooking a build command resulted in so many hours of thorough debugging.
I had another issue with Librarian not recognizing the attachment files created during unittests. Luckily it was resolved quickly when Tim Penhey suggested that I need to commit the local transaction in order for the Librarian to see it.
A minor bug with my previous commits was also fixed which resulted in TypeErrors since the arguments weren’t being sent as Unicode strings.
Actions for the Following Report
As outlined earlier on, “Team -> Source Packages -> Bugs -> Attachments” search is the next target.
Tags:
API,
Arsenal,
Code,
GSoC,
Launchpad,
Open Source,
Python,
REST,
Ubuntu,
Unit Testing
