he1ix' blog

currently just the commands:

SELECT id,name FROM projects;
SELECT * FROM wikis;
SELECT * FROM wiki_pages limit 10;
SELECT * FROM wiki_pages WHERE wiki_id = '1' AND title = 'Howtos';
SELECT * FROM wiki_pages WHERE parent_id = '34';
SELECT * FROM wiki_pages WHERE parent_id in (SELECT id FROM wiki_pages WHERE parent_id = '34');
UPDATE wiki_pages SET wiki_id = '12' WHERE wiki_id = '1' AND title = 'Howtos';
UPDATE wiki_pages SET wiki_id = '12' WHERE parent_id = '34';
-- UPDATE wiki_pages SET wiki_id = '12' WHERE parent_id in (SELECT id FROM wiki_pages WHERE parent_id = '34');
UPDATE wiki_pages SET wiki_id = '12' WHERE parent_id = '35';
UPDATE wiki_pages SET wiki_id = '12' WHERE parent_id = '87';

browsing the git history in a compact yet still highly condensed view containing all important information:

git log --graph --source --oneline --branches --tags

a short cheat sheet of commands I used several times to migrate SVN-repositories to GIT…

• preparation

  sudo aptitude install subversion git-svn svn co https://my.server.private/repos/my_repo cd my_repo svn log -q | grep -v '^--*$' | cut -d '|' -f 2 | sort | uniq > ../my_repo_authors.txt cd .. vim my_repo_authors.txt ### go ahead and edit the authors file

• git-svn clone the subversion repository

  ### use "--no-metadata" only if you don't want the git-svn-id tags in the commit-messages git svn clone --no-metadata --stdlayout \ --authors-file=my_repo_authors.txt \ https://my.server.private/repos/my_repo \ my_repo.git-svn

this is based on redmine-1.0.0

we need a more recent version of rails and rubygems than those shipped with lenny, so first add the backports-repository to your sources.list:

deb http://www.backports.org/debian lenny-backports main contrib non-free

then, update your package list:

sudo apt-get update

and install the above mentioned packages Continue reading ‘installing redmine on debian/lenny using mod_passenger’ »

“gpsturbo“ seems to be a potential open-source rival for GSAK that a friend of us suggested (he knows the author in person), so I decided to give it a try. Currently, no Linux-binaries are available, so here are my notes what is required to build it on Ubuntu from scratch:

sudo aptitude install subversion libasound2-dev libcups2-dev libfreetype6-dev

Compilation has been done in a clean karmic chroot, which already contained my default package selection for compilation-chroots:

apt-get install wget devscripts gnupg aptitude sudo vim bash-completion libxext-dev

“schroot” is a secure chroot tool that allows a non-privileged user on a system to switch to a chroot in a secure manner. This can be used to set up automated builds etc. that don’t have to run as root.

Unfortunately, RedHat Enterprise doesn’t ship with schroot-packages, so here’s a way to build them: Continue reading ‘building “schroot” on RHEL-5.4’ »

Well, I don’t want to lose to many words about VisualStudio compared to any professionally acting development tool, but there seem to be (non-)surprisingly many people out there suffering from the same insane problem…

When re-compiling a project, with the intention of only processing those files that have been changed since the last run (or those depending on such files), the linker fails in a miserable way:

1>CVTRES : fatal error CVT1100: duplicate resource.  type:ICON, name:1, language:0x0409
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

As common when using tools from Redmond, the error message is of almost no real help, since it does not tell anything about the file(s) that caused this problem. BTW, you won’t find any more details in the oh-so-detailed build-log either…

Well, the relly bad problem here is the linker itself, who tries to incorporate a given icon file into the executable binary, and thus runs the visual studio resource compiler (“RC.EXE” iirc), which in turn terribly cries out noticing there is already a compiled resource file where it would like to create a new one so desperately… Having left you standing there in the rain, compilation fails. It doesn’t even consider to tell you which files conflict or simply override the old resource file.

To avoid this, navigate to the topmost folder in your destination tree, and look for files having a “.res“ suffix. Using a sane cygwin shell, simply do something like:

find | grep ".res$" | xargs rm -v

Having removed the .res-files, recompiling works like a charm. Well, I’m going home into the GNU-zoo now, enough of this annoyance…

create or edit /etc/schroot/schroot.conf:

 #################################################
[hardy_i386]
description=Ubuntu Hardy Heron 8.04 (LTS) 32-bit
location=/scratch/md0/chroot/hardy_i386/
# type is required for setup-scripts to mount /proc etc. correctly
type=directory
run-setup-scripts=true
priority=3
users=<<FILL_IN_DESIRED_USERS_HERE>>
personality=linux32
aliases=hardy32,LTS32
#################################################
[hardy_amd64]
# type is required for setup-scripts to mount /proc etc. correctly
type=directory
description=Ubuntu Hardy Heron 8.04 (LTS) 64-bit
location=/scratch/md0/chroot/hardy_amd64/
priority=3
users=<<FILL_IN_DESIRED_USERS_HERE>>
# run-exec-scripts=true
run-setup-scripts=true
aliases=hardy64,LTS64

then bootstrap your desired variant:

debootstrap --verbose --variant=buildd --arch i386 hardy \
    /scratch/md0/ne704/chroot/ubuntu-hardy-32/ \
    http://de.archive.ubuntu.com/ubuntu/

Since I use to forget things, I decided create my own blog-entry to solve compilation-issues with Qt. Stolen straight from datafreak.eu :

Basic XLib functionality test failed!
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_X11 and QMAKE_LIBDIR_X11 in \
 [...]/qt-all-opensource-src-4.5.2/mkspecs/linux-g++-64.

Debian/Ubuntu:

apt-get install libxext-dev

yum install libX11-devel libXext-devel

very basic instructions, still incomplete

for additional resources, see FHZ 1000 for Linux

installation

install the required kernel-modules on your openwrt:

ipkg install kmod-usb-serial
ipkg install kmod-usb-serial-ftdi
insmod usbserial vendor=0x403 product=0xf06f debug=0
insmod ftdi_sio vendor=0x403 product=0xf06f debug=0

NOTE: you have to re-plug the FHZ module after loading the kernel modules!

testing

requires perl, so we need a perl-installation on openwrt. in your buildroot-environment, call

make menuconfig

select “Languages” —> “Perl” and select these packages to be built as modules:

perl perlbase-autoloader perlbase-config perlbase-cpan perlbase-dynaloader
perlbase-errno perlbase-essential perlbase-fcntl perlbase-file perlbase-io
perlbase-posix perlbase-selectsaver perlbase-socket perlbase-symbol
perlbase-term perlbase-tie perlbase-time perlbase-xsloader

build the packages

make

after installing at least the perl and perlbase-time packages, you can use a simple perlscript to talk to the FHZ (for protocol details, see FHZ1000 Protocol ): just download and execute fhztest.pl for a simple handshake-test. note: the script requires stty, so maybe you have to recompile your busybox-binary since the default one (from kamikaze 7.09) doesn’t include it…

as an alternative, you can continue by compiling the perl-module Device-SerialPort which is also required by FHEM . simply create feeds/packages/lang/perl-device-serialport in your buildroot-environment, download the provided Makefile and place it in the created directory. next, you have to create a symlink from package/feeds/packages/ that points to the above directory and update your configuration via

make menuconfig

there should be a new additional entry in “Languages” —> “Perl” called “perl-device-serialport” that has to be selected. save, exit and issue

make package/feeds/packages/perl-compile

after compilation, there should be a new ipkg-package in bin/packages/mipsel/ that has to be installed on your openwrt. doing so, you can use fhztest-serialport.pl to test the communication. calling the script should produce some output like this:

root@OpenWrt:/opt/tools/fhz# perl fhztest-serialport.pl 
Saying hello...
Sending: 8106c98202011f60 -- Result: 8
Got:     810bc97601021f0278071c3780 [0]
Sending: 8105044fc90185 -- Result: 7
Got:     8107c9b3010285012a [1]

to diagnose problems, look at the logfiles, try to un- and reload the kernel modules (don’t forget to un- and replug the FHZ after that!), …