Category: Trick


Firefox and Desktop directory

If you are having problem with Firefox recreating the Desktop directory, just see the following trick.

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:

In past week I had to compile a new version of Perl in a Solaris box.

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

cookies.txt for Chromium (linux)

A simple python script to extract all cookies from Chromium and export them to the cookies.txt file:

#!/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 ;)

Today, I was backing up some old data from a another laptop to a USB pen drive (SD/MMC card reader) using Ubuntu 10.10 LiveCD. This pen drive was no SD card, or else, it had only itself capacity (128 MB =P).

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

This problem refer to the installation of old JDKs on 64bit Linux systems.

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)

Yesterday, I had a nightmare night after migrating some non-virtualhost sites to virtualhost sites inside Apache2.

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.

After 1/2 hour trying to find any potential mistake in configuration files, I decided to investigate the directories in DocumentRoot and to my surprise what I found…a folder named “projectx“.

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

Well, I hope you see this post before you have to pass for this error.

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

In a previous post I have commented about the bridge mode on VirtualBox. Now, I will explain how to access your virtual machine using NAT network mode.

Before start your virtual machine, we have to set these configurations:

$ VBoxManage setextradata diablo "VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/GuestPort" 22
$ VBoxManage setextradata diablo "VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/HostPort" 9090
$ VBoxManage setextradata diablo "VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/Protocol" TCP

  • diablo is the name of the virtual machine
  • e1000 is the network card of the virtual machine (it can be pcnet – usually when host machine is not a genuine Intel)
  • ssh is the name of the service (you can choose any name)
  • 22 is the port of the service inside the virtual machine
  • 9090 is the port that will be binded in host machine
  • TCP is the protocol used by the service (SSH)

PS.: It’s not necessary to be root to apply these configurations.

Let’s see if the virtual machine is configured correctly:

$ VBoxManage getextradata diablo enumerate
Key: GUI/AutoresizeGuest, Value: on
Key: GUI/Fullscreen, Value: off
Key: GUI/LastCloseAction, Value: powerOff
Key: GUI/LastWindowPostion, Value: 56,35,720,451
Key: GUI/MiniToolBarAlignment, Value: bottom
Key: GUI/MiniToolBarAutoHide, Value: on
Key: GUI/SaveMountedAtRuntime, Value: yes
Key: GUI/Seamless, Value: off
Key: GUI/ShowMiniToolBar, Value: yes
Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/GuestPort, Value: 22
Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/HostPort, Value: 9090
Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/Protocol, Value: TCP

It seems OK. Now start your virtual machine and run the command bellow in host machine:

$ netstat -anl | grep 9090
tcp        0      0 0.0.0.0:9090            0.0.0.0:*               LISTEN

How you see, when the virtual machine is started, the VirtualBox binds the GuestPort forwarding all connections to HostPort inside the virtual machine.

To access the virtual machine just run the command bellow :

$ ssh -p 9090 localhost

If you wish access some service of the host machine through the virtual machine (assuming you are using NAT mode), just access it by the IP address 10.0.2.2.

My 2 cents.

Changing process name

A simple trick to change a process name in C programming is to do it:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>

int main(int argc, char **argv) {
    int st = 0;
    int pid = fork();

    /* copy new name to child process */
    if(pid == 0) {
        printf("Check my pid: %d\n", getpid());
        strcpy(argv[0], "new_name");
        sleep(20);
        exit(0);
    }

    wait(&st);
    return 0;
}

To see it in action, firstly, compile the program:

gcc -Wall -o test test.c

Now, execute it in background mode:

./test &

Then, check the name of the process through the given pid:

ps -auxww | grep pid

Yeah!!! The key is argv[0] !!! ;)

You can include arguments too, just do it:

strcpy(argv[0],"newprocess -a -x -y");

Now, use your imagination… =]

Emerge easter egg

Today I’ll post just a little easter egg inside the emerge command (Gentoo linux):

Say hello to Larry, the cow! ;)

These days I began to develop a new feature to Google Chromium and fix some ones (certain problems in Chromium gets me angry…very angry!!! =P).

I resolved to write this post because in the official build guide there is not mention how to workaround the problem with gcc-4.4 and the WebKit bug (you can see it here).

The problem resides in the file:

$CHROMIUM_ROOT/src/third_party/WebKit/WebCore/WebCore.gyp/webcore.target.mk

If you don’t apply this patch you will see various erroneous lines saying that there are undefined references into file libwebcore.a as these bellow:

undefined reference to findColor
undefined reference to findEntity
undefined reference to findValue

Pay attention: you have to apply the patch after synchronize your code with the remote repository and run the command “gclient runhooks –force” inside $CHROMIUM_ROOT/src or else the changes will be overwritten!

To apply the patch, just do it:

cd $CHROMIUM_ROOT
patch -p0 < /path/to/patch.doc

Some informations:

  • ccache statistics:

  • time compilation:
~  1h56m08s
  • target machine:
2.6.32-gentoo-r4-fx #1 SMP PREEMPT x86_64 Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz
  • tools:
  • gcc 4.4.3 / ccache 2.4

    Extra informations:

    • if you desire compile the code with ccache just change the Makefile inside $CHROMIUM_ROOT/src
    • all object code and binaries are put into directory $CHROMIUM_ROOT/src/out, if you wanna run a “make distclean” just remove this directory…this Makefile (from h3ll) does not have a distclean target!!!

    In the next article I will explain how to compile Google Chromium with LLVM/Clang ;)

    Follow

    Get every new post delivered to your Inbox.