Technical Details

The problem manifests itself as:

sudo make install
... snipped for brevity ...
mktexlsr: Done.
updmap-sys --enable Map=culmus.map
updmap: This is updmap, version $Id: updmap 14402 2009-07-23 17:09:15Z karl $
updmap: using transcript file `/var/lib/texmf/web2c/updmap.log'
updmap: initial config file is `/var/lib/texmf/web2c/updmap.cfg'
make: *** [install] Error 2

But if you look at updmap’s manpage there is no documentation for the return codes. Also there is no explicit place where it exits with return code 2 in the code. After some straceing I found the culprit in the combination of the set -e in the top of /usr/bin/updmap and the function pickLocalFile in /usr/share/tex-common/debianize-upddmap which overrides certain behaviors in updmap. The pickLocalFile uses the following lines

localfile=""
localfile="`ls $debDirname/*local*cfg 2>/dev/null`"
if [ -n "$localfile" ]; then

To check if there is a local configuration file under /etc/texmf/updmap.d. If such file doesn’t exist, instead of creating one (as the maintainers of debianize-updmap intended) it fails due to the set -e in /usr/bin/updmap. Thus updmap exists with error code 2, instead of completing the installation.

Meanwhile, until the bug is fixed, there is a simple workaround

Workaround

Before installing, execute

sudo touch /etc/texmf/updmap.d/10local.cfg

And now the regular sudo make install installation should finish successfully.

As the problem is a result of a Debian bug, I don’t expect to release a new version of culmus-latex, instead I’ll report the bug to the Debian team.

For future reference for myself, and as another code example to mechanizes sparse documentation I’m giving bellow the gist of the simple bot I wrote:

        self.browser = mechanize.Browser()
        self.browser.set_handle_robots(False)
 
def login(self):
    self.browser.open(self.login_url)
    self.browser.select_form(name="userlogin")
    self.browser["wpName"] = self.username
    self.browser["wpPassword"] = self.password
    res = self.browser.submit()
 
def find_pages(self, prefix):
    self.browser.open(self.find_pages_url)
    self.browser.select_form(nr=0)
    self.browser["from"] = prefix
    res = self.browser.submit()
 
    data = res.read()
    link_regex = re.compile('<td><a href="([^"]*)"[^<]*</a></td>')
    return link_regex.findall(data)
 
def delete_page(self, page_url):
    self.browser.open(page_url + "&action=delete")
    if "Kindle" not in self.browser.title():
        print self.browser.title()
        if raw_input("Confirm: ") != "y":
            return
    self.browser.select_form(nr=0)
    self.browser["wpReason"] = "Spam"
    self.browser.submit()
 
def run(self, prefix):
    self.login()
    pages = self.find_pages(prefix)
    print "Found %d page" % len(pages)
    for i,page in enumerate(pages):
        print "Deleting", i
        self.delete_page(page)

This isn’t a complete code example, as the rest of the code is just mundane, but you can clearly see how simple it is to use mechanize.

The interesting parts are:

• Initializing the browser object using mechanize.Browser()
• Openning pages: browser.open(url)
• Selecting forms: browser.select_form(name="userlogin") (selecting forms by name) browser.select_form(nr=0) (selecting forms by their sequential number in the page).
• Filling forms is done by assigning values to the form fields on the browser object: browser["wpName"] = self.username
• Submitting: browser.submit()

After a quick searching I came across clang complete. This plugin uses clang to parse your code and suggest completion. Auto-complete worked out of the box for the standard library, STL and Boost, and it worked properly (already better than OmniCppComplete). If you want to use libraries which aren’t in your default search path, i.e. gcc need you to specify -I flags or you need -D flags, you’ll need to pass them on to clang. This may sound difficult, but the developers of the vim script provide a wrapper to automatically understand what should be the proper flags from your build system. All you need to do is pass CXX='~/.vim/bin/cc_args.py g++' to make and the script will record your flags in a .clang_complete file, which it will use from now on. After you do it (except a little glitch, see bellow), omni-completion will work for every library in your code base.

There are still some glitches that need to be polished. First of all, the suggested way to invoke cc_args.py isn’t perfect. Make changes working dirs as it recurses through your code base, so cc_args.py‘s working-dir isn’t the same as yours, but the plugin will search for the .clang_complete file in your working-dir (the one vim has). The solution is just to move the .clang_complete files to the main directory of the project, from whatever subdirectory it created them in, and merge them (simpler than it sounds). Also this task needs to be done once for every project, so no big deal.

There are two other problems that still bother me. The plugin’s author says that if you set the plugin to use libclang it would work much faster and use caching. However, libclang isn’t currently packaged for Ubuntu 11.10. This should be solve next month with the release of Ubuntu 12.04, which provides it. The second problem is a weird bug in clang. When I try to compile a C++11 file with clang (providing the -std=c++0x flag, it segfaults, pretty weird. But I guess a bit more searching and maybe some bug-reporting will fix this issue (sadly, this means that the plugin can’t autocomplete c++11 features as well).

Despite some rough edges it’s way better than any previous C++ completion for Vim I ever seen. At the begging I hesitated when I had to remove OmniCppComplete due to conflicts with clang complete, and now after a (very) shot time using clang complete I don’t think I’ll miss it anytime soon.

Update May 2, 2012: Ubuntu 12.04 got released, so I finally checked the status of the completion using libclang. Apparently, you also need to install the libclang-dev package (in addition to libclang1, or else, clang_complete will output cryptic error messages. The clang 3.0 that comes with Ubuntu 12.04 no longer segfaults on c++11 code, but it refuses the compile anything with boost’s shared_ptr, due to issues with move semantics.

Things You’ll Need

• A scanner with automatic document feeder (ADF). The ADF is really important, without it, scanning is a nightmare. If you don’t have one, get one (they’re really cheap). You’re office probably has one with duplex scanning which is even better.
• A good scanning software that support creating PDFs. I use XSane, the GUI isn’t great but it does the job. I’ve also tried Simple Scan, which didn’t work properly for me, and the default HP software for windows (I can’t describe a bigger bloatware).
• pdftk - A great program to manipulate PDFs.

The Scanning Process

There are three relevant scanning options in my opinion for hand-written notes:

• 300DPI gray-scale. This results in around 550kb for each page of notes. Quality is great, but sometimes you can see the writing on the other side of the page in a slight gray.
• 600DPI black and white. Quality is a bit lower than gray-scale, but the size is about half, just 200kb per page. It takes longer to scan, but an ADF usually means it’s not an issue.
• 300DBI BW. This will again reduce the size. But this time at a noticeable loss in quality. I recommend this only if file-size is your greatest concern.

In order to make the choice a bit less vague here are some example scanned pages: 300 Gray, 300 BW and 600 BW. The notes are written using a rollerball pen (pilot v-ball grip). Here is a another comparison, this time using a ballpoint (Fisher Space Pen). As you can see the quality difference is more pronounced in the ballpoint. Hence, if you want you’re scans to be smaller and keep the quallity, use a rollerball and 600dpi. If you use a ballpoint, pay the price and go for 300dpi grayscale. Also, stay away from blue pens, they are less readable in grayscale and might be unreadable at all in BW (I’ve tried to make some simple image manipulations to improve scanning blue-ink to black and white, which I have some improvements which hopefully I’ll release some time).

I’ll also use plain white paper intended for printers. I find it of higher quality (and cheaper) than ruled paper, and it results in better scans.

Page Reordering

If you’ve a duplex scanner this tip isn’t for you. For the rest of us, the most convenient method to scan paper I found, is to make one scan for the odd pages and then take the pile flip and scan the even pages (back pages) from back to front (reverse order). Afterwards use pdftk to join them:

pdftk A=odd.pdf B=complexity-even.pdf shuffle A Bend-1 output final.pdf

Thats my 2 cents on scanning lecture notes. If you got other great tips, comment and share them.

@reboot python ./manage.py runfcgi ...

which I changed into:

@reboot until status mysql | grep start ; do echo "Mysql isn't running yet...>&2"; sleep 1; done; python ./manage.py runfcgi ...

Basically it loops and checks whether the MySQL service got started. If so, it would start Django as it did before. On the other hand, if MySQL isn’t running it would just sleep for a second and repeat the check.

A small issue is that if for some reason MySQL won’t start at all, it will loop for ever. If this happens, it would mean that I’ll have to manually kill that cronjob, but I would have to login anyway to see what wrong with the MySQL. So, while this method can’t support dependencies like init.d does, it does provide a good-enough solution.

OfflineIMAP claims to be faster, but I haven’t really checked it (and I’m not sure how important that is giving that it runs in the background). From what I saw configuring them is mainly a task of cut-and-paste, but getmail requires to list every label you want to backup, which I consider is a major downside. As both are able to save the mails to maildir format, it should be easy to back it up using duplicity.

Conclusion: This was a short comparison, mainly to guide me in choosing the right backup for me, you may have different opinions (which, of course, I would gladly hear). I finally chose OfflineIMAP, mainly due to the labels issue.

Note on desktop clients: It seems that every decent one can be configured to work with a local maildir, so you can use them to read the backups. As I prefer Gmail’s interface, I will only use desktop clients in case I’m offline, so read-only access from desktop client seems good enough for me.

As you can see, Amazon sells Kindle edition for higher price than a paperback. This book of course isn’t the only example for this ridiculous pricing method, and if one browses the Kindle store he will surely find more.

This really upsets me, as there is no honest reason to price an electronic edition higher than a real dead-tree paper edition. In both cases, the author and the publisher get their royalities and share of the profits. But the Kindle editions doesn’t have many related expenses, like storage, transportation (from the publisher to Amazon), and above all printing costs.

I don’t know who is to blame for this absurd thing, Amazon or the publisher (or even both). But the few things I know are that this bad for everyone, the customer because he pays more and Amazon/publisher as in the long run, this encourages piracy as the customer feels he’s being unfairly treated thus he will be more willing to play an unfair game as well.

Getting Started

Start by pulling the sources for the already available package. I’ll by using gitg as an example throughout this tutorial.

$ apt-get source gitg

This will create a folder according to the version of the package, something like gitg-0.2.4. Extract the new version besides it and cd into its directory. The next step is to copy the debian/ directory from the old source package the code you’ve just extracted.

$ cp -R ../gitg-0.2.4/debian/ .

Dependencies

There are some dependencies you’ll need:

$ sudo apt-get install devscripts
$ sudo apt-get install dpkg-dev

You’ll probably want to do:

$ sudo apt-get build-dep gitg

in order to make sure you’ve all the relevant build time dependencies.

Update debian/ Files

The next step is to update the files under the debian/ sub-directory.

$ DEBEMAIL="Guy Rutenberg <myemail@domain.com>" debchange --nmu

This will update the debian/changelog and set the new version. --nmu will create a new “non maintainer upload” version, meaning if the current version was 0.2.4-0ubuntu1, it will change it to 0.2.4-0ubuntu1.1. This will make sure that there won’t be any collision between your package and an official one. If you update to a new upstream version. It might be more suitable to use something like this:

$ debchange --newversion 0.2.5+20111211.git.20391c4

If necessary, update the Build-Depends and Depends sections of debian/control.

Building the Package

If your building a package directly from version control and not part of an official release, you may need to run

$ ./autogen

at this point.

Now to the actual building:

$ debuild -us -uc -i -I -B

-us -uc tells the script not to sign the .dsc and .changes files accordingly. -i and -I makes the script ignore common version control files. -B tells debuild to only create binary packages. You can also pass -j followed by the number of simultaneous jobs you wish to allow (e.g. -j3, like in make) which an significantly speed things up.

Installing the Package

The package will reside in the parent directory, for example:

../gitg_0.2.5+20111211.git.20391c4_amd64.deb

At this point you’re basically done. If you want to install the package you can use

sudo debi

while you’re still inside the build directory.

Creating Source Packages

If you want to go the extra mile and create source packages, it will make things easier for others to build their own packages based on yours.

You’ll need to create a an “orig” tarball

../gitg_0.2.5+20111211.git.20391c4.orig.tar.bz2

that hould contain the original source-code without the debian specific patches.

Now you can run the debuild command like before but without the -B flag.
This will create the following files:

../gitg_0.2.5+20111211.git.20391c4.debian.tar.gz

../gitg_0.2.5+20111211.git.20391c4.dsc

References

UpdatingADeb
Man pages for debuild, dpgk-genchanges, dpgk-buildpackage.

]]>
			http://www.guyrutenberg.com/2011/12/17/creating-a-deb-for-an-updated-version/feed/
		3
		
		
		
		http://www.guyrutenberg.com/2011/12/10/using-gitg-without-installing/
		http://www.guyrutenberg.com/2011/12/10/using-gitg-without-installing/#comments
		Sat, 10 Dec 2011 21:54:31 +0000
		Guy
				
		

		http://www.guyrutenberg.com/?p=922
		
			I’m working on adding spell checking support to gitg. If you intend to use gitg without installing it, a little hack is necessary. You’ll need to symlink the gitg directory (the one with the source files) as ui.


ln -s gitg ui
./configure /pathto/below/gitg

The reason is that gitg will look for Glade UI files under $(datadir)/gitg/ui and in gitg’s source the UI files are in the gitg directory and not in ui.

You can see above a screenshot of gitg with spell checking enabled. Hopefully I’ll be done with the changes soon and they will be merged to upstream quickly.
Update: There are couple more things to do in order to get gsettings’ schemas right.

mkdir glib-2.0
ln -s ../data glib-2.0/schemas
glib-compile-schemas data/
XDG_DATA_DIRS=".:/usr/share/" ./gitg/gitg

For the schemas thing see glib-compile-schemas‘ man page.
Update 2011-12-17: Jesse (gitg’s maintainer) hasn’t responded to my email regarding the new feature, so I’ve open a bug (#666406) for it. If you’re willing to try the changes yourself, you can pull them from git://github.com/guyru/gitg.git spellchecker.
]]>
			http://www.guyrutenberg.com/2011/12/10/using-gitg-without-installing/feed/
		0
		
		
		
		http://www.guyrutenberg.com/2011/12/10/gnome_compile_warningsmaximum-syntax-error-in-configure/
		http://www.guyrutenberg.com/2011/12/10/gnome_compile_warningsmaximum-syntax-error-in-configure/#comments
		Sat, 10 Dec 2011 17:23:48 +0000
		Guy
				
		

		http://www.guyrutenberg.com/?p=918
		
			I’m still encountering migration issues from Gentoo to Ubuntu. Apperantly, Gentoo is much more user friendly than Ubuntu when it comes to compiling packages. In Gentoo you’ve got almost all the major dependencies you need. In Ubuntu, on the other hand, you need to hunt them down. It’s much easier with the main ones, as they are listed. But there are some small ones which are harder to track. I came across the following error while trying to compile gitg, a GUI for Git, today:


./configure: line 14447: syntax error near unexpected token `maximum'
./configure: line 14447: `GNOME_COMPILE_WARNINGS(maximum)'

After not so short investigation I found out I was missing gnome-common

sudo apt-get install gnome-common

Why can’t be one distribution which is user-friendly like Ubuntu and in the same time developer-friendly like Gentoo?
]]>
			http://www.guyrutenberg.com/2011/12/10/gnome_compile_warningsmaximum-syntax-error-in-configure/feed/
		2