Skip to main content

no ImageRotate() in php5-gd?

ZenPhoto is awesome! It really is. It's still a moving target and while the growing changlog is almost frightening, I hope it won't die on featuritis. That being said, I still miss one function, a very simple one I assumed: to rotate pictures. No, not auto_rotate by its EXIF data but via the Rotate... buttons in the image details. However, these buttons are grayed out, with no reason given. Well, there's #3010 to "Disable rotation radio buttons if 'auto_rotate' not set - but I don't remember to turn off auto_rotate. Looking again at the config, I noticed that the auto_rotate button is grayed out too - what's going on?

Turns out, ZenPhoto is missing the imagerotate() funcition in our GD build. Hm, gd is provided by php5-gd and there we go:
> gd seems to build with an external gd library,
> php5 has it's own gd library shipped with it.
> One functions that isn't available when gd is build with an external lib
> is ImageRotate();
Well, the report is from 2005, now it's 2009 and this one has been tagged as wontfix, for debatable reasons. Sure, there are workarounds available, but I wonder how the others are dealing with this particular issue...

Could not lchown() symlink

Did I mention that I like rsnapshot very much? Well, I do, but this particular installation is giving me the heebeegeebees:

  WARNING: Could not lchown() symlink "/foo/some/symlink"
Apparently my Perl installation does not have the Lchown module, hence the messages. Well, I switched from SunFreeware to OpenCSW, but rsnapshot is using /usr/bin/perl anyway and rsnapshot itself is from a current GIT checkout, so why are these messages coming up just now? The cure for this is to install Lchown from CPAN - unfortunately, this does not went so well, and we have a lot of CPAN surgery ahead just to get Lchown working (again?):
  CPAN.pm: Going to build N/NC/NCLEATON/Lchown-1.00.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Lchown
cp Lchown.pm blib/lib/Lchown.pm
/usr/bin/perl /usr/perl5/5.8.4/lib/ExtUtils/xsubpp -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap \
                   Lchown.xs > Lchown.xsc && mv Lchown.xsc Lchown.c
cc -c  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 \
         -xspace -xildoff    -DVERSION=\"1.00\"  -DXS_VERSION=\"1.00\" -KPIC \
         "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Lchown.c
sh: cc: not found
*** Error code 1
Well, we could edit Config.pm, but this stock Perl-5.8 installation from Solaris10 does not seem to have this file. The OpenCSW version was no better, forcing it to compile with gcc did not succeed either, as expected:
[...]
gcc -c   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO \
           -xO3 -xspace -xildoff    -DVERSION=\"1.00\"  -DXS_VERSION=\"1.00\" -KPIC \
           "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Lchown.c
gcc: unrecognized option `-KPIC'
gcc: language ildoff not recognized
gcc: Lchown.c: linker input file unused because linking not done
So I went a different direction:
$ wget http://rsnapshot.org/downloads/extras/Lchown-1.00.tar.gz -O - | gzip -dc | tar -xf -
$ cd Lchown-1.00
$ perl Makefile.PL 
Checking if your kit is complete...
Looks good
Writing Makefile for Lchown
$ cat ../Lchown.diff
--- Lchown-1.00/Makefile        Mon Aug 31 22:03:58 2009
+++ Lchown-1.00.edited/Makefile Mon Aug 31 22:02:06 2009
@@ -23,12 +23,12 @@
 
 # They may have been overridden via Makefile.PL or on the command line
 AR = ar
-CC = cc
-CCCDLFLAGS = -KPIC
+CC = gcc
+CCCDLFLAGS = -fPIC
 CCDLFLAGS = -R /usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE
 DLEXT = so
 DLSRC = dl_dlopen.xs
-LD = cc
+LD = gcc
 LDDLFLAGS = -G
 LDFLAGS = 
 LIBC = /lib/libc.so
@@ -254,8 +254,8 @@
 
 # --- MakeMaker cflags section:
 
-CCFLAGS = -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO
-OPTIMIZE = -xO3 -xspace -xildoff
+CCFLAGS = -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO
+OPTIMIZE = -O2
 PERLTYPE = 
 MPOLLUTE = 

$ gpatch < ../Lchown.diff
$ make
$ sudo make install
Running rsnapshot again, the errors are gone now, heh!

rpc.statd: recv_rply: can't decode RPC message!

Apparently, this one bugged me before and then it just disappeared. Now it's back and the logs get filled again with:

Aug 30 01:54:08 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:54:39 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:55:10 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:55:41 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:56:12 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Again, not really flooding, but still annoying. While I still fail to see *which* message cannot be decoded, CentOS found a cure for this one. From looking at the diff, it seems rpc.statd is started too early (perhaps before the portmapper?). Well, restarting rpc.statd was enough to stop these messages for now - let's see if they show up again after the next reboot...

mdadm b0rked

Oh, the joys of Debian/unstable: a few days ago, udev was being upgraded - and introduced a conflict with mdadm. Unfortunately, it did not set the usual Conflicts: tag, so one has to go to the changelog to find a pretty terse comment:

     * New upstream release.
     + vol_id and libvolume_id have been removed. (Closes: #500883, #534765)
       Breaks: dmsetup (<< 2.02.51-1), mdadm (<< 3.0-3)
The real story however is told in #541884:
The next udev upload will not contain the vol_id program anymore, since
it was removed by the upstream maintainer in May, and will declare a
Breaks relationship with the current version of your package.

You need to update the rules file in your package to use:
   /sbin/blkid -o udev -p ...
instead of:
  vol_id --export ...
Your package will need to depend on util-linux >> 2.16.
Well, I won't blame them for ripping things apart, that's what unstable is for. In fact, I'd wish they'd do this more often to get rid of old packages. But a Conflicts: tag would have been nice too :-\

Update: the new udev package sets another tag called Breaks instead of Conflicts. Wow, I think I've never seen a Breaks: tag before.

stripped down opensolaris

OpenSolaris still only comes as a Live CD and can't be installed without a GUI, at least AFAIK. Well, I managed to boot the CD into cmdline mode, then started sshd to be able to login from a remote box - only to start the GUI installation again via X11 forwarding :-\
So, here are a few things I did to start a minimal OpenSolaris system and a few other things I always have to look for after another installation procedure - yes, the memory upgrade for my brain is already ordered.
$ svcadm disable gdm ppd-cache-update desktop-mime-cache mime-types-cache ogl-select \
                 gconf-cache input-method-cache pixbuf-loaders-installer fc-cache \
                 icon-cache pkg/update stosreg dbus hal autofs dns/multicast intrd \
                 rmvolmgr avahi-bridge-dsd name-service-cache routing/ndp
$ cat /etc/hostname.xnf0 /etc/defaultrouter /etc/nodename
192.168.10.12
192.168.10.1
foo
$ svcadm disable svc:/network/physical:nwam
$ svcadm enable svc:/network/physical:nwam
$ cp /etc/nsswitch.dns /etc/nsswitch.conf
$ cat /etc/inet/ntp.conf 
server de.pool.ntp.org
server europe.pool.ntp.org
server 2.pool.ntp.org
$ svcadm enable svc:/network/ntp
$ rolemod -K type=normal root
Now booting takes only 105 seconds on this box - heh, we just saved 5 seconds! :-)
$ grep -v ^\# /rpool/boot/grub/menu.lst 
timeout 30
default 0
title opensolaris
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/opensolaris
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=tty -v
module$ /platform/i86pc/$ISADIR/boot_archive

$ cat ~/.bash_profile 
export HISTSIZE=9000
export HISTTIMEFORMAT='%F %T '
export GREP_OPTIONS='--color=tty'
export EDITOR=vi
export PAGER=less

alias la='ls -lah'
alias locate='slocate'
Oh, and as a bonus, although totally unrelated to this article: check out this package manger cheatsheet - how often I have needed that ("How do I do 'dpkg -S' with RPM? Or pkg?"). Thanks, nakedape!

pgrep -u

I love proctools, they're so very handy and they're almost always available on Solaris and sometimes on Linux too. On MacOS you have MacPorts, but there's this annoying bug that will match all processes when -u or -U is used. Unfortunately, proctools development seems to be stalled, so we will have to fix this ourselves...or live with it :-\

Warning: No xauth data; using fake authentication data for X11 forwarding.

When connecting to remote hosts via Terminal.app in MacOS X, I always get this annoying warning. X11 forwarding is working though ($DISPLAY is set, even I'm not in a real xterm), I only wanted to get rid of this message:

$ ssh bob /bin/true
Warning: No xauth data; using fake authentication data for X11 forwarding.

$ xauth generate $DISPLAY .
xauth:  creating new authority file /Users/alice/.Xauthority
$ ssh bob /bin/true
$ 

syslog-ng & MacOS X

MacOS X still ships with good ol' syslogd which may suffice for most of us but I still prefer syslog-ng. Luckily MacPorts ships syslog-ng - unfortunately compilation fails with:

ranlib: file: libsyslog-ng.a(afsql.o) has no symbols
ranlib libsyslog-ng.a
ranlib: file: libsyslog-ng.a(afsql.o) has no symbols
if /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I..  \
  -I/opt/local/include \
  -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include \
  -I/opt/local/include   -I/opt/local/include/eventlog \
  -DHAVE_SOCKADDR_SA_LEN -DLIBNET_BSDISH_OS \
  -DLIBNET_BSD_BYTE_SWAP  -D_GNU_SOURCE \
  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
  -O2 -Wall -MT main.o -MD -MP -MF ".deps/main.Tpo" \
  -c -o main.o main.c; \
        then mv -f ".deps/main.Tpo" ".deps/main.Po"; \
  else rm -f ".deps/main.Tpo"; exit 1; fi
/usr/bin/gcc-4.0  -O2 -Wall  -L/opt/local/lib -o syslog-ng \
    main.o libsyslog-ng.a -lresolv  -lfl -L/opt/local/lib \
   -lglib-2.0 -lintl -liconv   -L/opt/local/lib -levtlog   -lnet \
   -lwrap 
Undefined symbols:
  "_configuration", referenced from:
      _configuration$non_lazy_ptr in libsyslog-ng.a(cfg.o)
      _configuration$non_lazy_ptr in libsyslog-ng.a(cfg-grammar.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
The compilation will succeed when we specify globals.o explicitly on the command line, but I wanted to take this opportunity to try a newer version of syslog-ng, the MacPorts way:
$ mkdir -p ~/.ports/sysutils/syslog-ng
$ cd ~/.ports
$ cp $macports/release/ports/sysutils/syslog-ng/Portfile sysutils/syslog-ng/
$ egrep '^version|master_sites|checksums' sysutils/syslog-ng/Portfile 
version           3.0.4
master_sites   http://www.balabit.com/downloads/files/syslog-ng/sources/3.0.4/source/
checksums      md5 86c39779261545d2289e9c309e262b8d
$ portindex
$ port clean --all syslog-ng
$ port install syslog-ng
Well, even the latest version will fail, so we fix it ourselves:
$ cd sysutils/syslog-ng/work/syslog-ng-3.0.4/src/
$ gcc  -O2 -Wall  -L/opt/local/lib -o syslog-ng globals.o main.o \
       libsyslog-ng.a -lfl -L/opt/local/lib -lglib-2.0 -lintl -liconv \
       -L/opt/local/lib -levtlog -L/opt/local/lib -lssl -lcrypto \
       -lz  -lz -lnet -lwrap  -lresolv
$ cd -
$ port install syslog-ng
The MacPorts install provides a hint how to (disable Apple's syslogd and) enable syslog-ng:
$ launchctl unload -w /System/Library/LaunchDaemons/com.apple.syslogd.plist
$ launchctl load   -w /Library/LaunchDaemons/org.macports.syslog-ng.plist
However, when doing this, syslog-ng is started over and over again, as if launchd doesn't recognize it as "already running" and respawns it all the time. No good :(