Inspirated

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).

Firefox 4 offers some compelling features such as HTML 5 improvements and a new add-on manager. Since it’s quite painstaking to compile the beta from source and quite messy to place pre-compiled binaries in system default folders (not to mention the compatibility checks and upgrade chores that would interrupt at each launch if you go back and forth between different versions), I created a repository at repo.inspirated.com which can be used to test the beta version without touching any 3.6 stable release already installed on the system:

To use the repository, issue the following commands:

$ su -c 'wget http://repo.inspirated.com/inspirated.repo -O /etc/yum.repos.d/inspirated.repo'
$ su -c 'yum install firefox-beta'

The beta refuses to run if an instance of old Firefox is already active. Therefore, close the older Firefox and then launch the 4.0b1 version using firefox-beta command or the “Firefox Beta” shortcut in the applications menu. A new profile shall be created at ~/.mozilla/firefox/beta/ in order to leave your older profile’s settings, bookmarks and extensions etc. intact.

(Click on the thumbnail for larger version.)

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.

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.

Over the 8 years of my acquaintance with computers valuable data has been lost at an average of twice per annum. I have tried all kinds of solution to help my situation only to fail miserably by forgetting to back up some important bits and pieces of information before upgrading my distro.

Backup solutions can mostly be factored into two approaches of archiving and cloning. If space is limited, you can archive your important data using utilities such as tar. This in fact was the approach I had been using until now. The downside appeared to be lesser accessibility of the files inside the backup. Say, I needed a small text-file from a 200 GB archive. It’d take me around 20 minutes to “get” to its location in the archive.

Which is why, I decided to shift to a newer approach. My laptop has a 320 GB hard disk and I own another 320 GB Western Digital Passport for extra data. To utilize the similitude, I bought another 500 GB Passport, transferred the “extra” data to it and then cloned the entire laptop hard disk to its 320 GB external cousin.

$ dd if=/dev/sda of=/dev/sdb

That is all. dd‘s performance was questionable, as it took around 15 hours to clone the entire 320 GB. Nevertheless, this time around I was satisfied with the final backup. Not only was it a bit-by-bit replica of my original data but also an accessible repository which I could access easily by plugging in the USB.