At last, the old webcam Logitech Quickcam Web works on my Debian box!!!

I followed whatever is suggested at http://ubuntuforums.org/showthread.php?t=654153.

I had followed the commands that are given there. Recounting them here..

aptitude install qc-usb-sources
cd /usr/src
sudo m-a prepare
sudo m-a build qc-usb
dpkg -i qc-usb-modules-[your_version].deb
modprobe quickcam


Now, firing up gqcam fails. In XTerm, it was exiting with message, device file not found. In /dev, the file that corresponds to the cam is /dev/video0. I did a ln -s video0 video and now gqcam show a vague resemblence if what lies in front of its eye.

Wow! never expected I’ll get this cam working on this beige machine. Remember, the cam is no less than seven years old. It worked OK under Windows. But after quitting Windows, I had almost given up hopes on getting this cam work.

Now, gotta learn how to use this cam under Pidgin or such applications..

here is what ‘lsusb’ says about this cam: “Bus 002 Device 002: ID 046d:0850 Logitech, Inc. QuickCam Web”

reading and writing mails from rmail in Emacs

Its been a long search for me to get this thing working. Not because of dearth of sample settings around, but because it took me a while to get my search terms right.


;; settings for reading mails
(setq rmail-pop-password-required t)
(setq rmail-primary-inbox-list (quote ("pop://user@domain.com")))
(setq user-mail-address "your email address")
;; (setq rmail-preserve-inbox t)
;; (setq rmail-movemail-flags nil)
;; (setq rmail-movemail-program "/usr/lib/emacs/22.1/i486-linux-gnu/movemail")
;; (setq rmail-pop-password "guess my password")

;; settings to handle attachments in rmail
(defun metamail-message ()
(interactive)
(metamail-buffer (get-buffer-create "*Metamail output*")))

;; settings for sending mails
(setq send-mail-function 'smtpmail-send-it
message-send-mail-function 'smtpmail-send-it
smptmail-starttls-credentials '(("smtp.server" 25 nil nil))
smtpmail-auth-credentials
'(("smtp.server" 25 "email address" nil))
;; (expand-file-name "~/.authinfo")
;; must learn to properly setup ~/.authinfo soon
smtpmail-default-smtp-server "smtp.vsnl.net"
smtpmail-smtp-server "smtp.vsnl.net"
;; smtpmail-smtp-service 25 ;; defaults to 25
smtpmail-debug-info t)
(require 'smtpmail)


hm, still, I seem to be missing something or the other in the ~/.authinfo entries. Every entry that I saw on the Internet, I tried that out. I should be missing on some format of the entry to be made, I suppose.

Next, gotta see how to setup IMAP with RMAIL.

Then there is gnus to be conquered. But that will wait for a while. Gotta get other things straight here.

Since a few seniors such as RMS intend to use RMAIL and don’t intend to change to any other mail reader, gotta see what is in RMAIL. But a very simple mail reader, RMAIL is.

Gotta be careful what to put in load-path

Rmail was giving out a backtrace. I had nothing relevant to rmail in my .emacs file. So I was inclined to think that rmail was at fault. I pasted the backtrace on #emacs@freenode.net’s paste. Only to discover that rmail was added with a hook that none of the regulars had ever come across.

Looking at its definition, I soon discovered that shebang.el was the file that containing the hook that was creating the problem. Upon removing the hook and disabling the file from being loaded automatically, I got rmail working properly.

So, who had added thee offending file? I was suspecting my sister would have added since she had used Emacs a few times. But turns out that she knows nothing about adding things to load-path. So, I must have put that file in the load-path for whatever reason. heh, gotta watchout for what I put into the load-path from next time on.

Emacs (and Vi) automatically make scripts executable

http://www.debian-administration.org/articles/571 shows the how to. I have installed shebang.el. This entry here is to help me find it easier when I’m actually looking for it.

Interestingly, the same post explains how to achieve this with Vi as well. So, I’d better keep a reference to that post here.

PCC won’t build on Debian..

Until recently, pcc was only complaining that it couldn’t locate headers. I have only tried a plain one liner helloworld.c.

It complained about missing stdio.h. I pointed the location. Then it complained about a headers used by stdio missing. This went on for upto some four or five levels of headers within headers and at last, pcc would find errors with the headers themselves. Too bad I haven’t recorded those error messages before doing a ‘cvs-update’.

After the ‘cvs-update’, pcc now refuses to build.

Below is the output of the configure script.

santhi@debian:~/testing/pcc$ ./configure –prefix=/home/santhi/testing/pcc_install
checking whether make sets $(MAKE)… yes
checking for a BSD-compatible install… /usr/bin/install -c
checking build system type… i686-pc-linux-gnu
checking host system type… i686-pc-linux-gnu
checking target system type… i686-pc-linux-gnu
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ANSI C… none needed
checking whether byte ordering is bigendian… no
checking for gcc… (cached) gcc
checking whether we are using the GNU C compiler… (cached) yes
checking whether gcc accepts -g… (cached) yes
checking for gcc option to accept ANSI C… (cached) none needed
checking for flex… flex
checking for yywrap in -lfl… yes
checking lex output file root… lex.yy
checking whether yytext is a pointer… yes
checking for bison… bison -y
checking for a C compiler for mkext… not cross compiling
checking for strip… yes
checking how to run the C preprocessor… gcc -E
checking for egrep… grep -E
checking for ANSI C header files… yes
checking for sys/types.h… yes
checking for sys/stat.h… yes
checking for stdlib.h… yes
checking for string.h… yes
checking for memory.h… yes
checking for strings.h… yes
checking for inttypes.h… yes
checking for stdint.h… yes
checking for unistd.h… yes
checking for string.h… (cached) yes
checking alloca.h usability… yes
checking alloca.h presence… yes
checking for alloca.h… yes
checking for working alloca.h… yes
checking for alloca… yes
checking for mkstemp… yes
checking for strlcat… no
checking for strlcpy… no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating cc/Makefile
config.status: creating cc/cc/Makefile
config.status: creating cc/cpp/Makefile
config.status: creating cc/ccom/Makefile
config.status: creating f77/Makefile
config.status: creating f77/f77/Makefile
config.status: creating f77/fcom/Makefile
config.status: creating config.h

Target CPU is ……………….. i386
Target OS is ………………… linux
Compiler is called …………… ppc
Installing compiler into ……… /home/santhi/testing/pcc_install/bin
Installing pre-processor into …. /home/santhi/testing/pcc_install/libexec
Using assembler ………………
Using linker …………………
Using include path ……………
Using library path ……………

Configure finished. Do ‘make && make install’ to compile and install.

It shows two functions are missing. But that was not a problem before the ‘cvs-update’ and I don’t expect that to make a big fuss after the ‘cvs-update’ as well.

Running make says..

santhi@debian:~/testing/pcc$ make
cd cc && make all
make[1]: Entering directory `/home/santhi/testing/pcc/cc’
cd cc; make all -w
make[2]: Entering directory `/home/santhi/testing/pcc/cc/cc’
gcc -I../../os/linux -I../../arch/i386 -Dmach_i386 -Dos_linux -g -O2 -DLIBEXECDIR=\”/home/santhi/testing/pcc_install/libexec\” -DINCLUDEDIR=\”/home/santhi/testing/pcc_install/include\” -c cc.c
cc.c:150: error: expected expression before ‘/’ token
cc.c:151: error: expected expression before ‘/’ token
cc.c:152: error: expected expression before ‘/’ token
cc.c:152: error: initializer element is not constant
cc.c:152: error: (near initialization for ‘endfiles[0]’)
make[2]: *** [cc.o] Error 1
make[2]: Leaving directory `/home/santhi/testing/pcc/cc/cc’
make[1]: *** [cc] Error 2
make[1]: Leaving directory `/home/santhi/testing/pcc/cc’
make: *** [cc] Error 2

This error, when the code apparently compiles on NetBSD and OpenBSD systeems, presumably both systems use gcc.

I am left wondering what is wrong with this code. Contacting thee mailing list got a wiki page up in the pcc official site. They suggested that some header or lib path is wrongly set.

I searched for the error message over the Internet. Google could only find some 150 (give or take 10) hits of which only about a handful had the exact error message. Of them, one suggestion was, some build-essential packages are missing on the system.

configure script’s screen output shows nothing so badly missing. So, what am I staring at now? A correct C code for sure. A working gcc(4.2 that is available on Debian unstable). Some missing packages? What packages are missed so badly? The investigation continues..

Slackware’s magic pakcage manager

Until I read this post, I was thinking that dependency checking and related things is a part of package manager tool.

This post says otherwise. But, I have old memories of being a Slackware 9 user. I should find time to have Slackware on my system now. But the old experimental computer has just 128M RAM. Recent editions of Slackware need no less than 256M RAM. Gotta check out. Now with a bit more interest as this tool looks real great to work with — the oooooold school Unix (and Slackware’s policy as well till date). And I looove it!

A free pdf suite in the making

http://www.gnupdf.org/Main_Page is wokring to make a full blown pdf suite that can be used to make and edit pdf documents.

Now that pdf has become an ISO standard and FSF has tagged GNU PDF a high priority project, a good competitor to all the non-free pdf applications out there.

continuing with building pcc on Debian..

Its been a long time since I last updated about my work on pcc. I contacted the Debian Developer who had filed an ITP for pcc. But he had told he was busy and will send some patches along with explanations to get pcc compile a ‘hello world’ program.

I was growing curious and had lot of time on hand to look around. So, I took the source rpms from the Downloads section.

Installed alien and rpm and made debs from them as described here.

But the rpm way looks like too much of work for now. So, I wrote a gdb command file with 100s of ‘s frame bt’ after setting args and breakpoints and running. Then I built the pcc from cvs and ran gdb with the command file. GDB promptly spewed out all the lines of code that were executed along with the requested information. But haven’t looked in the 1000s of lines of code that is traced by this command file yet. I hope to figure out the problem today before I fall asleep 😀

An Emacs vulnerabitily..

http://www.ubuntu.com/usn/usn-541-1

Only a few days now I was discussing about enable-local-variables with one of the regulars at #emacs on freenode. He advised me not to enable local variables all the time, warning it might lead to vulnerabilities. Now someone has discovered such a vulnerability. Looks like this vulnerability is only Ubuntu specific.

A circa 77 year old lady, mother, grandmother in the street

There is a lady here in my street. She has been wandering this street for well over three years now. She has left her home in Rasipuram. Her sons and daughters live there. All of them have abandoned her. She happens to be a classmate of one of my relatives who lives in this street. This abandoned lady wears what the houses of this street give her, eats what is given to her. There is a temple in this street. Sri Rukmani Sametha Panduranga is the chief deity there. This lady draws some of her food from this Temple.

But when it comes to sleeping, the houses are not so hospitable to her as they were. She was let to sleep in the front portion of many houses, which took turns. As time went by, she started waking up very early and yell at the air in front of her as if there were someone. Now, her plight has come down to sleeping near the shady doors of the houses. That is to say, there is no roof on her head. The temple does not care to do that bit either. Every once in a while, someone in the street sponsors her tonsure.

Nobody in this street knows fully why her sons and daughers abandoned her. So far, only the essentials such as food and clothing are being provided by the residents of this street. There seems to be some link between her past and this street. Perhaps her childhood home was here. She refuses to leave this street. Refuses to go to oldage homes either. So there is no knowledge of any ailments she might be having.

A painful sight to see in the street. I learnt from our relative-her erstwhile classmate that her name is Sulochana. Whatever be the reason, she abandoning her home or her children abandoning her, the outcome is a real painful sight.

Anybody got suggestions about getting her return to her home? Or getting her accept to go to an oldage home?

The street name is Manikkam street. Located in Shevapet, Salem.