When a group forms, one of the things it does, over time, is develop values. Different development teams have different values, and people that come into the development process have to learn and adopt those values.  One value of the FreeIPA project that is very different from other recent projects of mine is this: The main code repository is only for “published” code. Work in progress should happen elsewhere. The main git repository should be easily readable.
XML is not a pretty programming language. I suspect this fact is at the heart of many peoples frustration with maven as a build system for Java projects. I know that it was one of the reasons the Candlepin team decided to use buildr in stead of Maven as the build and package system.
If you get the above mentioned error while building an RPM, here’s what it means. rpmbuild has executed the script:
usr/lib/rpm/check-buildroot
This looks through the files that are set to be installed in your rpm to see if any of them contain the embedded path used to build or install them in the rpmbuild process.   For example, I have my ~/.rpmmacros file set to up with the following entry:
%_topdir %(echo $HOME)/rpmbuild
which means that I build in /home/ayoung/rpmbuild. Underneath this directory, I see, amongst other things, the subdirectory BUIOLDROOT. The current wisdom says that an RPM should use BUILDROOT as the target for any installs. This is the set of files that get packaged up for the final RPM. The files here then get checked to see if they have this path embedded in them. For example, when building rubygem libxml, I see:
+ /usr/lib/rpm/check-buildroot
Binary file /home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64/usr/lib/ruby/gems/1.8/gems/libxml-ruby-1.1.4/lib/libxml_ruby.so matches
Found ‘/home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64’ in installed files; aborting
There is a simple work around. in ~/.rpmmacros, add the line:
%__arch_install_post  /usr/lib/rpm/check-rpaths  /usr/lib/rpm/check-buildroot
Which is, think, a typo, but it shuts off the check. However, I wouldn’t advise doingthis.
In the case of libxml, the paths are there as an artifact of the build process. The .so carried the full path to the directory in which it was build as a way to link to the source files, for debuggins. I can see the path by running:
objdump –dwarf libxml_ruby.so
I don’t have a final solution, because I need to work through the gem install process, but the end effect will be
Update: Since this is a ruby binary RPM, the correct thing to do is to move the gem install into the %build stage and then copy it into ${BUILDROOT}. It currently happens in the %install stage. RPM is wise enogh to do much magic in the BUILD stage, such as producing the debuginfo rpm and so on.
Maven is too important a part of too many projects for most Java developers to ignore. However, some of the decisions made in building with Maven are suspect, mostly the blind download of binary files from a remote repository. While Maven gets more and more Open Source clean, there are still issues, and the biggest is building Maven itself. Both Debian and Fedora have fairly old versions of Maven, in the range of 2.0.7 as of this writing. Considering that the GA is 2.2.0 and There is work on 3.0, we risk a pretty serious divide in the Open Source Java world of we don’t keep up with Maven, and get a clean way to build it.
My work machine is a Fedora 11 (F11) X86_64 system. The palm development SDK is distributed as a series of .deb packages, specifically targeted at an 32 bit Ubuntu 8 system. While I have the advantage of having a 32bit Debian system at home, so I was able to run through the setup process for development, ideally I would be able to attach to and control the Pre from my work machine.
The first step is to download the .deb files onto the F11 machine. I actually only needed the novacom deb, which in my case is novacom_1.0.38_i386.deb. Deb files are accessable using ar (happy talk like a pirate day!).
In a new and empty directory, run
ar -vxf ~/novacom_1.0.38_i386.deb
And you will see the three contained files:
control.tar.gz data.tar.gz debian-binary
Extract the data file using tar
tar -zxf data.tar.g
This will add a usr directory with the binaries in
usr/local/bin/novacom{d}
Novacom is a two piece effort: a daemon an a client. First make sure you can run the daemon.
First, lets see the file type:
file novacomd
novacomd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
Let’s see what libraries it requires:
ldd novacomd
linux-gate.so.1 => (0x008f1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0078a000)
libusb-0.1.so.4 => not found
libc.so.6 => /lib/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x006ae000)
Note that the USB library is missing. I have it installed on my system, but only the 64 bit version. To get the 32 bit version, first, figure out what the 32 bit vversion is named.
yum search libusb
…
libusb.i586
…
And install
sudo yum install libusb.i586
F11 and the RHEL based approach for running 32bit apps on 64 makes this fairly easy to do. Unlike Debian based system which pretty much require you building a chroot if you are going to run a significant amount of 32 bit binaries, Red Hat based systems put 64 bit libraries into /usr/lib64 and 32 bit libraries int /usr/lib, so they don’t conflict. Now lddd shows we have everything:
ldd novacomd
linux-gate.so.1 => (0x00262000)
libpthread.so.0 => /lib/libpthread.so.0 (0x008a5000)
libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x00770000)
libc.so.6 => /lib/libc.so.6 (0x00263000)
/lib/ld-linux.so.2 (0x006ae00)
And we can now run this. Since it is talking straight to hardware, it insists on running as root:
./novacomd
[2009/9/22 11:40:48] novacomd version novacomd-62 starting…
[2009/9/22 11:40:48] novacomctl socket ready to accept
[2009/9/22 11:40:48] need to run as super user to access usb
so:
sudo ./novacomd
[2009/9/22 11:41:11] novacomd version novacomd-62 starting…
[2009/9/22 11:41:11] novacomctl socket ready to accept
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] going online
[2009/9/22 11:41:11] novacom_register_device:188: dev ‘e851588c804e8caa722490a0314ce9782dd4d9a4’ via usb type castle-linux
No we turn our attention to the client piece.
file novacom
novacom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
[ayoung@ayoung novacom]$ ldd novacom
linux-gate.so.1 =>Â (0x00173000)
libc.so.6 => /lib/libc.so.6 (0x006d2000)
/lib/ld-linux.so.2 (0x006ae000)
So we are ready to run. There is no novaterm in this deb. Instead, you run novacom in terminal mode. A little noted line in that I will make big here is:
./novacom $* -t open tty://0
A couple times I’ve had to answer to question: What licenses ship out with our system? If you are shipping something on top of RedHat (in our case, CENTOS) or SuSE ( I haven’t tested this) you can generate a list of package names and licenses with the following command.
rpmquery -a –qf %-30{NAME}:%{LICENSE}”\n”