Edit ou create (if you don’t have it) the $HOME/.config/user-dirs.dirs file as bellow:

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
#
XDG_DESKTOP_DIR="$HOME"
XDG_DOWNLOAD_DIR="$HOME"
XDG_TEMPLATES_DIR="$HOME"
XDG_PUBLICSHARE_DIR="$HOME"
XDG_DOCUMENTS_DIR="$HOME"
XDG_MUSIC_DIR="$HOME"
XDG_PICTURES_DIR="$HOME"
XDG_VIDEOS_DIR="$HOME"

Simple, yeah!

References:

• http://www.freedesktop.org/wiki/Software/xdg-user-dirs

This Solaris machine had a GNU compiler (gcc, make, etc.) and I used them on this task.

Everything went fine on compilation, but when I had to use some modules dependent of socket library I faced with this error:

ld.so.1: perl: fatal: relocation error: \
file /home/xxx/utils/perl/lib/5.12.3/sun4-solaris/auto/Socket/Socket.so: \
symbol inet_aton: referenced symbol not found Killed

Reading some documentation about the inet_aton on Solaris systems I noted the function is not implemented on old versions of Solaris and the inet_pton function is used instead.

To solve this problem I had to change the script Configure and recompile the sources:

from:

d_inetaton='$d_inetaton'

to:

d_inetaton='undef'

Just to inform you, in new versions of Solaris (9 and so) the inet_aton function is implemented on libresolv library.

My 2 cents

#!/usr/bin/python
# -*- coding: utf-8 -*-

from sqlite3 import dbapi2 as db
import os

homedir =  os.environ['HOME']
cookie_file = homedir + '/.config/chromium/Default/Cookies'
output_file = homedir + '/cookies.txt'

conn = db.connect(cookie_file)
cur = conn.cursor()
cur.execute('SELECT host_key, path, secure, expires_utc, name, value FROM cookies')

f = open(output_file, 'w')

for row in cur.fetchall():
    f.write("%s\tTRUE\t%s\t%s\t%d\t%s\t" % (row[0], row[1], str(bool(row[2])).upper(), row[3], row[4]))
    # unicode handler
    f.write(row[5].encode('utf-8'))
    f.write("\n")

f.close()
conn.close()

Enjoy

When I tried to mount this pen drive on my Gentoo Linux, I was getting the error:

mount: unknown device

But what ?! dmesg, udevadm and lsusb were showing me that it was there:

lsusb:

Bus 002 Device 004: ID 0bda:0103 Realtek Semiconductor Corp. USB 2.0 Card Reader

dmesg:

usb 2-2: new high speed USB device using ehci_hcd and address 4
scsi4 : usb-storage 2-2:1.0
scsi 4:0:0:0: Direct-Access     Generic  2.0 Reader   -SD 1.00 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg1 type 0
sd 4:0:0:0: [sdb] Attached SCSI removable disk

After looking carefully to output messages on Ubuntu 10.10 LiveCD, I realized that only the card reader was being recognized, the internal storage was not.

Well, in order to resolve this problem I had to recompile the kernel and activate the option CONFIG_SCSI_MULTI_LUN:

Device Drivers -> SCSI device support

[*] Probe all LUNs on each SCSI device

After reboot the system with my new kernel I could see the expected output message from dmesg:

usb 2-2: new high speed USB device using ehci_hcd and address 4
scsi4 : usb-storage 2-2:1.0
scsi 4:0:0:0: Direct-Access     Generic  2.0 Reader   -SD 1.00 PQ: 0 ANSI: 0 CCS
scsi 4:0:0:1: Direct-Access     Generic  2.0 Reader   -FD 1.00 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg1 type 0
sd 4:0:0:1: Attached scsi generic sg2 type 0
sd 4:0:0:1: [sdc] 256000 512-byte logical blocks: (131 MB/125 MiB)
sd 4:0:0:1: [sdc] Write Protect is off
sd 4:0:0:1: [sdc] Mode Sense: 03 00 00 00
sd 4:0:0:1: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdb] Attached SCSI removable disk
sd 4:0:0:1: [sdc] Assuming drive cache: write through
    sdc:
sd 4:0:0:1: [sdc] Assuming drive cache: write through
sd 4:0:0:1: [sdc] Attached SCSI removable disk

Now, I could mount the device /dev/sdc and transfer the whole backup to my homedir.

To the curious the pen drive model with 128MB is showed bellow:

My 2 cents

Well, there are various reasons to you have a ARM Linux distro inside a Virtual Machine. One of them would be to have a test environment to you validate your programs before to release to an embedded linux (ARM).

Debian was choosed because is the most supported ARM distro and you will have an compatible environment with your embedded system (eglibc).

Hey! Ho! Let’s go:

• Download a ARM kernel and a vmlinuz image under debian.org FTP site (I choosed squeeze/testing flavor):

wget http://ftp.debian.org/debian/dists/testing/main/installer-armel/current/images/versatile/netboot/vmlinuz-2.6.32-5-versatile

wget http://ftp.debian.org/debian/dists/testing/main/installer-armel/current/images/versatile/netboot/initrd.gz

• Create a disk image (please, create a raw disk! It will be useful future):

qemu-img create -f raw debian.img 10G

• Start Debian image using qemu:

qemu-system-arm -m 256 -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.gz -hda debian.img -append "root=/dev/ram"

• After install Debian in the disk image, we will mount the contents of disk image:

sudo kpartx -av debian.img

sudo mount /dev/mapper/loop1p1 ./mnt/ -o loop

• Copy the initrd image and the kernel to your system (outside of mountpoint). These two files will be used to start our Debian installation:

cp ./mnt/boot/initrd.img .

cp ./mnt/boot/vmlinuz-2.6.32-5-versatile .

• Now, we can start Debian image installed in the disk image:

qemu-system-arm -m 256 -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img -hda debian.img -append "root=/dev/sda1"

In the next posts I will talk about ARM architecture, toolchains, cross compilers and embedded linux.

When java command is executed at shell, generally, you will receive this error message:

Error: can't find libjava.so.

To solve this problem just edit 3 files located at JDK installation dir and be happy

• $JAVA_HOME/bin/.java_wrapper
• $JAVA_HOME/jre/bin/.java_wrapper
• $JAVA_HOME/jre/bin/realpath

All these 3 files have similar code snippet as bellow:

    case "`uname -m`" in
        i[3-6]86 | ia32 | ia64 | i?86)
            proc=i386
            ;;
        sparc*)
            proc=sparc
            ;;
        *)
            proc=unknown
            ;;
    esac

Edit each file and  include the architecture x86_64 in the first case-statement and the problem will be fixed:

i[3-6]86 | ia32 | ia64 | i?86 | x86_64)

Everything was migrated and fully functional until I receive a desperate call from my friend telling me that svn service was not working. I was stranged with that notice, because I had already done some tests in some repositories (commit and checkout).

After better explanations, I realized that only one repository was in trouble:

svn ls http://myhost.com/projectx

svn: Repository moved permanently to 'http://myhost.com/projectx/'; please relocate

What ?!?! Yes, yes, yes !!! Look at the error…a brutal 301 HTTP error code just at my eyes.

Well, the errors logs from Apache didn’t tell me anything useful, just the known error:

"OPTIONS /projectx HTTP/1.1" 301 241 "-" "SVN/1.6.5 (r38866) neon/0.28.6"

I resolved change the name of this directory to projecty and the repository changed back to work miraculously.

So, I decided to read the subversion faq and to me surprise again, look what I found:

http://subversion.apache.org/faq.html#http-301-error

Yeah…this fucking bug made me crazy !!! =P

It’s not possible you have a folder in your DocumentRoot that it has the same name that a repository inside your SVNParentPath…bizarre !!! O_o

And this bug is not treated as a bug…that I think is incredible… unbelievable!!!

For this and others limitations that I have done usage of Git, Mercurial and Bazaar…

SVN is past, centralized repository is past…but this is a history for a future post