I created a new version for 1.6 update 16 by extracting the old version using rpm2cpio, modifying the spec file and recreating the SRPM using rpmbuild. I tested the package on 32-bit CentOS 5.3 and it worked without problems.

The SRPM for Sun Java 1.6 update 16 is available here. It works with the instructions mentioned in the url in the beginning of this posting.

Manu has done some big changes to the Mantis driver since the revision 3c897a20ff8b, but I could not view any channels with those changes. Until it gets fixed, I’ll stick to the revision 3c897a20ff8b.

To begin with, I downloaded the ISO image of openSUSE 11.1 64-bit installation DVD, which is available at openSUSE’s download site. I then installed it simply by using the defaults proposed by the installer. Since the default installation does not include the software necessary for building software (for example a C/C++ compiler), the very first thing to do is to install some necessary packages. I prefer command line tools, so I opened GNOME Terminal, used su to switch user to root (su -) and used zypper (zypper install package) to install the following packages:

• gcc33 (also installs cpp33, glibc-devel and linux-kernel-headers)
• gcc33-c++ (also installs libstdc++33 and libstdc++33-devel)
• gcc33-32bit (also installs  glibc-devel-32bit)
• libstdc++33-32bit
• boost-jam
• libXerces-c-devel (also installs libXerces-c28)
• gtk2-devel (also installs several other dependencies)
• rpm-devel (also installs popt-devel)
• flex

After all necessary packages had been installed, I had to create some symbolic links to make GCC 3.3 the default compiler for the system. This is because the gcc33* packages don’t create symlinks for commands cc, cpp and g++. The symlinks can be created using:

ln -sf /usr/bin/gcc-3.3 /usr/bin/cc
ln -sf /usr/bin/cpp-3.3 /usr/bin/cpp
ln -sf /usr/bin/g++-3.3 /usr/bin/g++

The build also needs both 32-bit and 64-bit version of Xerces library. The 64-bit version is already installed with the base installation, but installing 32-bit version side by side requires some special steps. You need to manually download the RPMs

• libicu-4.0-7.1.i586.rpm
• libXerces-c28-2.8.0-29.28.i586.rpm
• libXerces-c-devel-2.8.0-29.28.i586.rpm

and install them (in the order listed) using “rpm -i –force package.rpm“. You also need to fix 32-bit C++ linking because of a missing symlink in openSUSE’s package:

ln -sf /usr/lib/libstdc++.so.5 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3-hammer/32/libstdc++.so

I then created a new user “ingres” for building Ingres and again used su to switch user to ingres. The source code for community edition of Ingres 9.2 (build 134) can be downloaded from the Ingres ESD site (under Community Projects / Ingres Database). After downloading the source code package under /home/ingres (ingres user’s home directory), I extracted it there using tar:

ingres@ingdev:~> tar zfx ingres2006-9.2.0-134-gpl-src.tgz
ingres@ingdev:~> cd ingres2006-9.2.0-134-gpl-src/
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> ls
cazipxp  Kerberos5  pax  src  xerces-c-src_2_5_0
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src>

Since 9.2 is pretty old, it is necessary to make some modifications to the source code. Otherwise the build will simply fail. The changes I had to make can be downloaded as patches from http://pauli.borodulin.fi/misc/ingres/9.2b134-opensuse11.1-patches/. You just need to apply each of them by running “patch -p0 < file.patch“.

The INSTALL file contained in the src directory gives some general instructions in building Ingres. The first thing to do is to set up the build environment:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> export ING_ROOT=`pwd`
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> source src/tools/port/jam/bldenv
Ingres build environment is now set
Your ING_ROOT variable is set to /home/ingres/ingres2006-9.2.0-134-gpl-src
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src>

After the build environment had been set up, it was time for bootstrap and build:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> cd $ING_SRC/tools/port/jam
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> jam
...found 28 targets...
...updating 5 targets...
MkDir1 /home/ingres/ingres2006-9.2.0-134-gpl-src/tools
[... some output suppressed ...]
Chmod1 /home/ingres/ingres2006-9.2.0-134-gpl-src/tools/bin/iijam
...updated 5 targets...
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> mkjams
Creating $ING_SRC/tst->$ING_TST  link...
Creating $ING_SRC/bin->$ING_TOOLS/bin  link...
Building Jamfile files for: ingres
Doing MANIFEST files
[... some output suppressed ...]
tools: doing group
ING_SRC: doing top
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> cd $ING_SRC
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src>

This was the final step before building Ingres. By running “jam -q”, you can start building it:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src> jam -q
...patience...
...patience...
[... some output suppressed ...]
...updated 16316 targets...
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src>

The build is now ready. For the rest you can follow the instructions in the INSTALL file.

UPDATE 2009-07-28: It is possible to use newer GCC. At least GCC 4.1 seemed to work by simply using packages gcc41, gcc41-32bit, gcc41-c++ and libstdc++41-32bit instead of the ones listed in the beginning. Remember to make the necessary symlinks.

Ingres patches are cumulative, meaning that each patch also contain the fixes included in the previous patches. Since the list of fixed bugs is ordered by bug numbers and not chronologically, it’s pretty hard to figure what have been fixed since previous installed patch. For example there’s 145 new bug fixes between patches 13322 and 13435.

Here’s a simple tip, how to compare two readme files on Linux using command line tools. First, save the readme files on disk with names p13322.html and p13435.html. Then run

grep "Bug " p13322.html | perl -p -e 's/<.*?>//g' > p13322.txt
grep "Bug " p13435.html | perl -p -e 's/<.*?>//g' > p13435.txt

Now you have a simple listing of bugs fixed in the patches. You can then use diff to compare, what have been fixed between 13322 and 13435:

diff -u p13322.txt p13435.txt | grep "^+" | less

The best thing would be, if Ingres Co. provided their customers a simple web application, which could be used to check these. Until that… use this tip or propose a better one!

The script uses DBD-Ingres driver to access the imadb database, which is part of  the Ingres Management Architecture (IMA). The script retrieves the necessary data from the imadb and then prints it. A short, concise list of open sessions is printed first with a more verbose listing (“iimonitor show user sessions formatted” alike) following.

The version 1.0 of the script is available at http://pauli.borodulin.fi/misc/ingres/ima_sessions-v1.0.pl. The requirements for running the script are listed in the beginning of the script.

Now my current setup is:

• FFmpeg revision 17245
• DirectFB 1.0.1
• Xinelib 1.1.16.2
• VDR 1.6.0-2, with the following plugins
• xineliboutput 1.0.4
• epgsearch 0.9.24
• femon 1.6.6
• remote 0.4.0
• skinsoppalusikka 1.6.3
• streamdev 0.3.4
• sc 0.9.1

I also upgraded to the latest v4l-dvb tree for which I ported the Mantis driver by Manu Abraham.

NetBeans’s user interface for managing the security etc. settings of a web service is pretty simple and lacks a lot of the control for the configuration that is implicitly created by NB. This is unfortunate, because NB seems to create pretty advanced/complex configurations even there would not be need for such.

In WSF/PHP the security configuration of a web service (from the client viewpoint) can be defined by using WSPolicy class. An instance of this class may be given as a parameter to WSClient, which will then use the configuration when calling the web service. WSPolicy object can be instantiated by two methods: either by defining the settings as an array of values or by feeding in a separate policy XML file. The array method does not allow managing all of the supported settings and can only be used in very simple cases.

Because of the restrictions of the array method, it is necessary to use a separate policy XML file to describe the configuration when calling a secure web service created using NB. The policy XML file can be manually formed by studying the web service’s WSDL, which in fact, contains all the necessary information inside its policy elements. Because the policy elements can’t just simple be copied and pasted to a separate file, it is usually easier to take an existing policy file as a template and then modify it to fulfill the requirements of the service based on the WSDL.

After creating a simple PHP script and the necessary policy file in XML, I was able to call the service as expected. Here are the files:

• Policy file for calling SecureCalculatorApp
• Web service client code in PHP

Unfortunately, I didn’t get WSDL mode working. The problem seems to be that even the useWSA value is set to true on WSClient, addressing is not used in the WSDL mode. This prevents using WSDL mode with web services configured alike with NB 6.1’s SecureCalculatorApp.

Comparing the requests sent by different clients makes it easier to debug the reasons for the problems. Since not all clients allow dumping the created requests upon sending, it would be nice if it was possible to ask Metro to do it. Fortunately, this is possible through configuration. For doing this, Arun Gupta describes the possible properties in his blog.

The easiest way is to add parameters

-Dcom.sun.xml.ws.assembler.client=true
-Dcom.sun.xml.ws.assembler.server=true


to your Glassfish domain’s domain.xml as jvm-options elements.

• FFmpeg revision 15245
• DirectFB 1.0.1
• Xinelib 1.1.15
• VDR 1.6.0-2, with the following plugins
• xineliboutput 1.0.1
• epgsearch 0.9.24
• remote 0.4.0
• skinsoppalusikka 1.6.1
• streamdev 0.3.4
• sc 0.9.0

I’m using Matrox G550 and its tv-output to display the video image on my old 28″ analog television.

The actual reason for the upgrade was to get a recent FFmpeg version to play videos using xineliboutput’s media player. Everything went well except that for some reason, there’s a problem with the OSD when playing videos using software scaling (hardware scaling made OSD look awful). I posted a question about the problem on the VDR mailing list to see, if anyone else has had this problem. It seems to be some kind of initialization problem during playback, but I have not yet been able to find out the cause for it.

For those who don’t know what VDR is: It can be used to make a computer to function as a video disk recorder (article in Wikipedia).

SELECT file_name, file_ext FROM iifile_info WHERE table_name = 'mytable';

The file_name column contains the name of the file for the table without extension and the column file_ext contains the extension. If the database uses multiple locations, it is also necessary to check the value of the column ‘location’, which will tell you the location of the file.

But this is not all. Ingres also stores all secondary indexes in separate files. It is also possible to see, using the table iifile_info, which index is stored in which file. This way it is even possible to hunt down indices that require more disk space than you expected.