॥ स्वक्ष ॥

To content | To menu | To search

Tag - Ubuntu

Entries feed - Comments feed

2010 October 11 [Monday]

Extract msi archive format on Ubuntu

I was googling for some information which was only available in a .msi archive format which I could not extract directly on ubuntu. Since I didnt have windows on the machine, I could not extract it there and just copy the files over to linux.

On ubuntu, installing WINE (and trying to extract with msiexec) didnt work -- wine kept whining about it not being an executable (on linux? *g*), the source being from an untrusted source, etc...

Next, I tried p7zip -- install it with

sudo apt-get install p7zip-full

Then, change directories, and type:

7z x filename.msi

While this extracts all the files, it will still not be easily viewable nor is it usable -- windows executable dlls, bitmaps, windows installer package, microsoft cabinet archive, some icons, and other useless cruft compressed in the folder. Other than manually digging out text files for the information, there was no easy option.

The data was locked inside the database (hint, extract the cabinet archive) in the .mbd (MS Access) format. Google threw some perl modules to convert a .mbd file to .txt. BUT there was a gnome mbd-reader tool which you can easily install with

sudo apt-get install mdbtools

sudo apt-get install mdbtools-gmdb

Then, click on Applications>Office>MDB Viewer.

In Ubuntu, mdbtools includes command line tools such as mdb-export and mdb-schema and to export data from the MS Access .mdb files, extract contents from each table from each .mdb file through the shell --for which one needs to determine table names before using:

mdbtools <filename.mdb> <table name> <output_filename.txt>

mdb-export filename.mdb tblfoo

The compressed archice included among other things, files with .ocx and .tlb extensions. More googling (yay!)

TLB, a Visual Basic OLE Type Library, is a binary file containing all the type information for using procedures or classes in DLLs.


o. mdb-tools and postgresql script

2010 July 26 [Monday]

Patches and the Packaging toolchain

Background assumptions::
o. A clean ubuntu hardy installation.
o. Some familiarity with command-line basics.
o. Have installed pbuilder.

That done, we can continue...


If you have ever used the apt-get or aptitude {Aaron has a nice writeup on aptitude Vs. apt-get} command : "sudo aptitude install <packagenames>"  on your Debian/Ubuntu system you used a tool that automatically installs a packaged software on your system. This would automatically pull all the dependencies for your Linux system to run smoothly. It saves you the pain of having to install software manually by pulling code in a tar.gz folder, extracting, etc...

Secondly, when you download a source package from a Debian/Ubuntu "deb-src" repo, its already a debian package.i.e the source files have been placed in a suitable directory tree, appropriate configuration files have been added, and the package contains scripts to help with the building and installation of the package. This is what allows you to just install from source with "apt-get -b source some-package-name" as mentioned before.

This post is different. As in, its not a path of least resistance (packaging an existing debianized package for Ubuntu). This is about creating a binary package from a source package, with customization, modification, or other tedious trouble. To do so, you do the following :

Wikipedia says,

The Debian build toolchain is a collection of software utilities used to create Debian source packages (.dsc) and Debian binary packages (.deb files) from upstream source tarballs.

These tools are used in the Debian project and also in Debian-based distributions such as Ubuntu.

One of the first steps was creating a .dsc as outlined at  https://wiki.ubuntu.com/PackagingGuide/Python

I had already pulled the stable source from LP [bzr branch lp:systers] but noticed that none of the files had copyright or license notices. I also had a number of questions on patching the current systers stable branch for releases and another part of the project as mentioned on the wiki was to work with the MM 3.0 port team. So I requested an upstream MM core-dev to comment on the following:

  • Q0. Currently systers runs only on Ubuntu-Hardy with python2.5 and systers has the habit of working only with ubuntu- LTS releases, hence Lucid could be the porting target.  I feel the tasks involved are -- convert  all .py programs compatible to python  2.6 or 2.7;  carry out code changes if any on the 2.6 or 2.7 .py files to make them work on lucid or Hardy , make package and test the package.
  • Q1. Currently systers code uses python2.5 and I'd like to know if it has to run/port compatibly on Lucid would that involve converting code to python2.7 (or python2.6)? That seems like a large task so I'd like to hear your comments. 
  • Q2. Would it involve making these python programs of systers which is currently compatible with 2.1.10 to be made compatible to mailman 3.0-- I'm not sure how different MM-2.1.10 is from MM-3.0 and assume this involves changes in code.  So what does working with the MM 3.0 port team entail?
  • Q3. According to the debian manuals the existing stable branch should contain licences for all files, to be packaged since GNU-Mailman would require this. Currently none of the stable branches or code fixes pulled from the systers repo have any license files. Am I supposed to contact the individual authors (I dont know them all) or should I just ask Jennifer/Robin ?

The reply I got was lucid (could not resist a pun) and in sum, I'd heard some of the packaging stuff before (in Debian? or was it in Ubuntu?):

  • o. Core-devs dont usually work on maintaining non-mainline stuff unless it's their own. So if you want your "feature-changes-patch" included in upstream, you'd have to be willing to maintain them long-term and that would involve a large commitment. If its not in mainline upstream, there is nobody to coordinate packaging or patches. As the developer of your "feature-changes-patch", its your baby which you should be willing to test and maintain each time mainline changes.
  • o. Ubuntu packaging of Mailman 2.1 introduces some bugs -- best compiled from source. Bringing another package (mailman-systers?) for an existing upstream package within Ubuntu could be an issue.
  • o. Mailman 2.1 and Mailman 3.0 are *entirely* different code bases. That means these wonderful systers feature changes would have to be re-implemented, not ported. Porting (as I asked above in Q0, Q1,Q2) would involve moving between python versions and this changes so many things when you are moving between two OS releases (in this case, Ubuntu hardy and lucid). Besides MM3.0 (in alpha stage) was an entirely different code base compared to 2.1 which is in feature freeze.
  • o. While it would be better to contribute code directly to MM3.0 ...BUT... using the existing code raises the license issues in Q3 above. This is something I cant answer as "legalese" is beyond me. Technically, all GPL code (for a FLOSS project) requires authors be willing to assign their work to the free software foundation, as explained in the gnu-licenses page: http://www.gnu.org/licenses/why-assign.html. IIRC, Ubuntu and Debian would require the license.txt file for packaging too. There is a list of FSF approved software licenses.

2010 July 17 [Saturday]

SoftwareHardware fails

Ever been in a situation where you are trying to solve one problem but have more hoops to jump than necessary!?
This rant has been building up this past week and it all started with bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'

Seems that bzr has to be upgraded on hardy {--And now this? --after I had purged and re-installed bzr because the earlier installation was giving weird errors and I didnt want to waste time going off on a tangent. argh, I was wrong about wasting time with bugs!

I was suggested a PPA but for that was not an optimal path for me. Besides, here I was trying to pull a MM revision from LP, but instead have to build bzr and then work on MM..... ~fun.

Alan (thanks :)) suggested I edit the sources.list and add "deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main" and then do an apt-get update, then apt-get upgrade which would upgrade bzr to the version in the ppa without all the compiling and building hoop jumping.

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

What a killjoy !!

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
The following packages will be upgraded:
Setting up bzr (2.1.2-1~bazaar2~hardy1) ...
removing incorrectly installed bash example /etc/bash_completion.d/bzr

Finally.... I upgraded bzr which allowed me to pull the branch: $ sudo bzr branch lp:mailman/2.1. An hour later.......gee, where was I now? The download was still 'in progress' and was'nt all this supposed to be incidental to testing Mailman...!? That was the night before. The next morning after yet-another-regular-unscheduled-power-outage, it was LaunchPad going down for an hour or so --some twit was DDOSing their server. What an incredibly productive activity!

LP returns and the development machine decides to die with a "/dev/sda1 error : fsck died with exit status 4". Now I knew this was my lucky day!!

Dug out a liveCD and ran 'fsck -f /dev/sda1' manually, where:

-f = force fsck even if filesystem seems clean
-cc = run badblocks check with a non-destructive test
-k = write new list of badblocks to current list
-p = automatically repair errors if possible without requiring human input
-v = verbose output

It found 5 inodes containing multiply claimed blocks and repaired it but for a while everything was in slow-motion --  I panicked about it taking ages to check a mere 40 gb of inodes and blocks. Colourless did the math on why it will take ages "just consider the sustained transfer rate of the drive which will probably be in the low 10s of mb/s. lets say you are getting 20mb/s second transfer, that is still going to be 2000 seconds to scan the disk, or 33 minutes".

Ah, talk of collective agida!

Earlier today fsck.ext1: No such file or directory while trying to open /dev/hda1. The superblock could not be read or does not describe a correct ext2 filesystem -- the hdd would not be detected and system refused to boot, refused to detect partitions. I spoke too soon earlier. It was super lucky saturday, not lucky friday!! This time the LiveCD was an arm's length away after last night's use and I checked out "fsck", "e2fsck" ...zilch, No response.

There is a good utility called TestDisk, which is available as a package for both debian and ubuntu -- sudo apt-get install testdisk, and you can run it from liveCD if your disk ever fails. It goes without saying that TestDisk will be useful only if your disk is detected by BIOS and hence alive.

Now, the worst I could think was "bad sectors==dead disk" but before that I had to check for loose wiring and then see if the BIOS detected the drive. The disk was spinning as I could hear the 'whrr' sound. Unplugged and re-plugged the wires a few times ...Nada...Bios would not detect the hdd. Convinced that it was the worst "bad sectors==dead disk", I shut everything down. A few hours later I switch it it on and voila the disk was detected and grub was soon asking which OS I wanted to boot into. That means it was just a loose connection (HOPEFULLY :)).

A BIG 'thanks' to ALL the folks who helped out with suggestions and listened to my kvetch. Much appreciated :)  If I'd ever have to calculate "productive time" sans all the idiocy around then its scary to note the amount of time that is wasted scheduling my day around a power outage, hardware issues and software bugs, and then there is this mundane thing called 'life'. I wish I had 10-days of silence instead.

- page 1 of 13