Macros don't seem to deal with floating point values. This works:

%define five 5

%if 0%{?five} <= 5
  %define string A
%else
  %define string B
%endif

%define five 5.3

%if 0%{?five} <= 5
  %define string A
%else
  %define string B
%endif

Quoting integers makes comparisons lexical. This will evaluate to false:

%define five 5

%if "0%{?five}" == "5"


Perhaps the most frustrating one for me was that commented out macros are expanded. This has surprising results if your macro expands to multiple lines. Say my spec file includes the following:

%description
#%foo                                                                           
blah


And foo happens to expand to multiple lines:

%define foo one\
two\
three


My description will end up being:

Description :

two
three
blah


]]>



  
  http://dannf.org/bloggf/tech/wootoff-lights.html
  
 Andrew, I bought those wootoff lights as well, and have them connected to a hub on my mythtv system so I can activate them with a remote. I use the hub-ctrl.c utility from this page with this simple wrapper script that searches for the hub:

#!/bin/sh

bus=$(lsusb | grep TUSB2046 | cut -d' ' -f2)
dev=$(lsusb | grep TUSB2046 | cut -d' ' -f4 | sed 's/:$//')
port=4

hubctrl=/home/dannf/hub-ctrl

if $hubctrl -b "$bus" -d "$dev" -v | grep "Port ${port}:" | grep -q power; then
  toggle=0
else
  toggle=1
fi

$hub-ctrl -b "$bus" -d "$dev" -P "$port" -p "$toggle"



Note that not all hubs implement the port power feature - but luckily I had an unused one laying around that does.


Unfortunately, one of my lights won't spin unless the physical power switch on the light is toggled - hopefully that's not true for yours.

]]>



  
  http://dannf.org/bloggf/tech/physical-mac-address.html
  
 I needed to query a card to get its permanent mac address (the value programmed into the card, even if the admin has ifconfig'd it differently). This can be done with the linux kernel's ethtool API, but the ethtool command doesn't currently support it and google didn't know how either. I had to figure it out myself.


Now google, you no longer have an excuse - I expect you to know next time I ask.

]]>



  
  http://dannf.org/bloggf/tech/etchnhalf-kernel-in-p-u.html
  
 2.6.24 kernels targeted for etch are available for testing in
 etch-proposed-updates. Some architectures are missing for this first upload,
 but fixes are pending for the next upload.

]]>



  
  http://dannf.org/bloggf/etchnahalf.html
  
 For those unfamiliar with the project, etch-and-a-half has the goal of
 making the existing etch release work on more hardware, but with minimal
 risk to existing etch users.


 This will be done by *adding* new kernel packages to the existing release.
 Kernel selection isn't final yet - the kernel team would like to use 2.6.24
 if it proves itself stable in time; 2.6.22 is the backup choice.
 

 etch-and-a-half isn't restricted to kernel updates by-definition; new
 X drivers, or proven-safe X driver updates are reasonable candidates as
 well (though at this point, no changes have been proposed).


 An oft-asked question is around updating desktop packages, e.g. new versions
 of GNOME/KDE. This is beyond the scope of etch-and-a-half because it
 introduces a great deal more change than just additional hardware support,
 its wouldn't be a transparent upgrade to existing etch users, and we cannot
 say with a high level of confidence that it wouldn't introduce regressions
 for existing users.


 That said - a localized change to a package that adds support for new hardware
 and clearly doesn't break existing hardware is a valid candidate for any stable
 release. Such requests should be submitted to the SRM team like any other
 stable update request.


 The current plan for etch and a half is to release as part of a point release.
 4.0r4 is the planned point release, since 4.0r3 is planned to have a quick
 turnaround to fix issues with 4.0r2. This means that pre-release bits will
 be made available via proposed-updates - testers are greatly appreciated.


 There is no plan to add support for etch-and-a-half to the etch branch of d-i.
 Rather, support will likely be added in a beta of the lenny installer.
 

 A wiki page exists here,
 and a coordination list has been setup on teams.debian.net.

]]>



  
  http://dannf.org/bloggf/tech/on-irc-proxies.html
  
 Adeodato mentioned using ctrlproxy, so I thought I'd ramble a bit about my experience w/ IRC proxies in general.


 dircproxy was the first
 IRC proxy software I tried. It did the job, but the thing that annoyed me
 the most was that only one client could connect at a time. I'd get home and
 realize I was still connected at work, and then have to login and send a kill
 signal to xchat.


 When I found out about ctrlproxy, and that it supports multiple clients, I
 was very excited. It did the job, but occasionally it would hang and need
 to manually killed/restarted, and it had this weird problem of writing logs
 for one channel to the log file of another.


 Most recently (and for probably a year now) I've been using
 bip. I immediately hit an issue
 with one server - bip would constantly reconnect/disconnect. Upstream
 immediately went to work on the problem, determined it was a bug in the
 server itself, and (iirc) sent the server maintainers a patch. Now that's
 support! bip has been stable for me for nearly 2 years now.


 I'd also suggest comparing the bug pages for dircproxy, ctrlproxy, and bip. That's not always a good way to measure relative stability, but it resembles my experience in this instance.


]]>



  
  http://dannf.org/bloggf/tech/etch-on-hannibal.html
  
 Last night I decided to install etch on my pre-built
 MythTV system. The process is documented
 here

]]>



  
  http://dannf.org/bloggf/tech/proliant-etch.html
  
 HP announced support for Debian 4.0 ('etch') on
 ProLiants today. See the
 HP/Debian page for details.

]]>



  
  http://dannf.org/bloggf/tech/ilo2-vsp-setup.html
  
 That's a mouthful. We had a customer asking for information on this, so
 I did a couple screen captures using
 byzanz to demonstrate.


 The first
 shows howto setup a system to do bios over serial. I did this w/ the remote java
 console, but you can also do this locally on the system (or the ActiveX console I
 suppose, but I've never tried this myself). In brief, you need to
 choose a serial port to map to the VSP (I use COM2 aka ttyS1), and tell the 
 system to redirect the BIOS to the same serial port at your desired baud (115200
 in this example).


 The second
 shows me initiating an ssh session, setting up a virtual cd-rom, and 
 booting the debian installer. Of course you could use local media or
 even PXE boot. But either way you need to tell the installer to direct
 its console to the same port that you've configured as the VSP and
 at the same baudrate (console=ttyS1,115200n8 in this example).


 Note that if the screen goes blank after attempting to boot from the CD
 it is likely that the installer is displaying a graphical splash screen.
 Simply hit F1 to transitition to a text-mode help screen.

]]>



  
  http://dannf.org/bloggf/tech/svn-load-in-sid.html
  
 svn-load, a DFSG-free replacement for svn_load_dirs, is now in unstable.
 John Wright has been working on adding support for doing preset pattern-based
 moves, which I hope will be ready in the next upload.

]]>



  
  http://dannf.org/bloggf/tech/pysvn_load_dirs.html
  
 Users of subversion may have noticed that the svn_load_dirs
 script was removed from Debian due to a lack of a license from upstream. So far,
 attempts to get a DFSG-free licensed version have failed, so I've
 begun a new python implementation
 that is licensed under GPLv2.

 0.1 is functional and uses the same syntax as the original, but is
 missing a few features that prevent it from being a drop-in
 replacement. I hope to remedy this in the coming weeks.


]]>



  
  http://dannf.org/bloggf/tech/poor-mans-rss.html
  
 I suffer from an in ability to successfully monitor multiple sources of
 information. For example, I rarely check on lists that I have procmailed out
 to their own folder. If its a list I need to stay on top of, I have to
 dump it to my primary inbox. For one list, I even dump messages to my inbox
 *and* keep a copy in a subfolder. That way I can keep on top of what's going
 on, but also keep a low-barrier-to-delete since I know I have an archival
 copy. I do think its important for me to check e-mail regularly, but there is
 some part of my brain that considers e-mail to be a time sink, and prevents
 me from going beyond what it considers the bare-minimum: Inbox messages.


 Another instance of this disorder struck me with RSS. There are web pages that
 I check every day, and not all of them have RSS feeds. I played with a few
 different RSS readers a while back, and decided that
 straw was my favorite. But
 I could not get myself in the habit of bringing up a second application. Later
 I started using Firefox, and I thought I'd have
 better luck with something like Sage.
 But even that was easy to avoid because it requires actually opening up the
 sage panel. I would either never check it or, in times of boredom, check it too
 often. Since then I've given up on RSS readers. These days I've stolen an idea
 from Alex Chiang and just keep a
 bookmark folder called "daily" and one called "monthly". Every morning I hit
 the "Open All in Tabs" item in the
 daily folder, and quickly ctrl-w through pages w/ no new content. My
 daily folder includes things like bug reports I'm monitoring for activity,
 gitweb views of files where I'm waiting for a fix, blogs, parcel tracking,
 comics, wiki watch lists, etc. Since a few of these pages are rather
 important, I always remember to do it and therefore force myself to browse
 the others as well. Most days I spend less than 10 minutes "wasting time"
 going through them.

 
 Its strange to both be aware of poor working habits, yet know from years of
 experience that I'll be more successful if I work around them rather than
 trying to retrain myself.

]]>



  
  http://dannf.org/bloggf/tech/bug404927.html
  
 We're trying to mitigate the severity of #404927 by working around the issue in udev.
 But, to do that, we need someone to provide us with udevinfo output for these
 controllers. If you have access to one, please help!

]]>



  
  http://dannf.org/bloggf/tech/bip.html
  Lucas, try
bip. It's not nearly as
buggy
as ctrlproxy, and allows
multiple client connections, unlike
dircproxy.

]]>



  
  http://dannf.org/bloggf/tech/hp-debian-proliant.html
  
 As announced
 in August, HP has now gone live with support for ProLiant. More information
 is available at http://hp.com/go/debian.


 Admittedly its odd to announce sarge support right before etch releases, but
 hey - we had to start somewhere.


 On a similar topic, I started a 
 wiki a while ago to track the status of sarge and etch on various ProLiant
 models. I think it'd be cool to have similar pages for various vendors. By
 linking to d-i installation reports, I hope this will reduce duplicate
 information.

]]>



  
  http://dannf.org/bloggf/tech/contentlessping-xchat.html
  
  Good idea Tollef.
  Here's an xchat port.

]]>



  
  http://dannf.org/bloggf/tech/hpodder.html
  
 hpodder is awesome, thanks John!



]]>