iguanaworks / iguanair

Iguanaworks USB IR Project: firmware and software

IguanaIR software / firmware project

This project provides the software and firmware used with the IguanaWorks usbir hardware. This hardware is used to communicate via infrared signals between remote controls, computer systems, and consumer electronics. The hardware is most commonly used along side LIRC or WinLirc by individuals building customized media centers or similar projects, but people have also controlled glowing juggling balls or used these devices in university projects.

This code currently supports multiple Linux distributions on PCs or embeded platforms, such as the Raspberry Pi, along with Windows 7 through Windows 10. Windows XP and Vista should also work, but are not explicitly supported at this time. This software includes firmware update tools, command line testing tools, and Python (version 2 or 3) and C programming APIs for people who want to write their own code to interact with devices controlled by infrared signals.

Alternatively, a Linux kernel driver also supports the IguanaWorks usbir hardware and does not require or use the software provided here.

With either this software, or the kernel driver, Linux users commonly rely on LIRC to decode the infrared signals into a more user-friendly format such as "TV Power" or "Heater On":

• http://www.lirc.org/

Windows users usually rely on WinLIRC for signal decoding and coupled with plugins for frameworks such as Girder or EventGhost these configurations can tie infrared signals into home automation:

• http://winlirc.sourceforge.net/
• https://www.promixis.com/girder.php
• http://www.eventghost.org/

The hardware can be purchased from our website and bulk discounts are available:

• http://www.iguanaworks.net

The IguanaWorks website also provides Windows binaries, frequently asked questions, and a support site to contact the developers with questions, issues, or descriptions of interesting projects.

Thank you for your interest.

-The IguanaWorks Team

iguanair's Issues

Error: couldn't open connection to iguanaIR daemon: No such file or directory

Hi,

using debian stretch, LIRC 0.9.4c and the iguanair compiled driver, I run into the following issue.

The iguaraIR sockets are properly created:

root@light:~# ll /var/run/iguanaIR/
total 0
srwxrwxrwx 1 iguanair iguanair 0 Jun 24 23:54 0
srwxrwxrwx 1 iguanair iguanair 0 Jun 24 23:54 ctl
lrwxrwxrwx 1 iguanair iguanair 1 Jun 24 23:54 iguana -> 0

I can verify that IguanaIR is properly working using igclient:

root@light:~# igclient --get-version
get version: success: version=0x0308

but lircd complains when I want to send IR signals:

Jun 25 00:53:30 light lircd-0.9.4c[9016]: Notice: accepted new client on /var/run/lirc/lircd
Jun 25 00:53:30 light irsend[9025]: lirc_command_run: Sending: send_once SONY KEY_POWER
Jun 25 00:53:30 light lircd-0.9.4c[9016]: Error: couldn't open connection to iguanaIR daemon: No such file or directory
Jun 25 00:53:30 light lircd-0.9.4c[9016]: Warning: Failed to initialize hardware
Jun 25 00:53:30 light lircd-0.9.4c[9016]: Error: error processing command: send_once SONY KEY_POWER
Jun 25 00:53:30 light lircd-0.9.4c[9016]: Error: transmission failed

I found out using strace that lircd tries to open this socket : /var/run/iguanaIR/auto

The issue can be resolved by creating a symlink /var/run/iguanaIR/auto targeting /var/run/iguanaIR/0

Why is lircd trying to open that file "auto" ?

remove stopped or removed flag in usbclient.c

Reported by jdunn on 23 Jun 2009 02:36 UTC
After the addition of the stopped flag to the usb client objects the functionality of the stopped flag is at least partially duplicated. Most likely we can get away with a single flag. Actually I'm sure we can. The worker thread wrapper should do the freeing of the usb. In any case, this works alright for now, and will be fixed in a later patch.

Check out libusbx

Reported by jdunn on 5 Feb 2013 02:22 UTC
Currently libusb post version 1.0 works fine for our purposes, but for more advanced USB devices a fork of libusb has been made called libusbx. We should add a new driver if there is any benefit in linking directly to libusbx, however, they provide a drop-in replacement for the libusb 1.0 line so I believe it is technically unnecessary for the time being.

firmware files are missing

After running a make install the firmware .hex files are missing the in the installation directory; these do exist in the current 1.1.0 distribution.

Part of the problem is that the source dir files/python/usr/share/iguanaIR-reflasher/hex/ seems empty

The debian packaging is not acceptable into the distro.

The debian packaging under the packaging dirrectory is not acceptable into the distro. Some points:

• There is a hard requirement to have libraries in separate package(s) due to the multilib effort.
• Development files (headers, unversioned .so links) should go to -dev package(s).
• Given this mandatory package structure it's probably a bad idea to have different tool in separate packages,. Three or four packages for this codebase should be enough.
• The standards compliance '5' it overall too old, current is 10. Same goes for Standards-Version:
• The GPL v2-only copyright files does not match the actual sources, whihc partly uses LGPL.
• The missing systemd support is of course a blocker.

Attaching a modernized debian packaging. Basically, I don't see the point updating the upstream sources with this, it would be better to mantain it as a separate package for SID/Buster with the goal to have it accepted (which should be perfectly possible with this package).

debian.zip

EDIT: This packaging is based on d1a3474, the current tip in the git repo. The patch series is a snapshot of the pull request.

EDIT2: Here also the issue that the directory containing the source tarballs at iguanaworks.net cannot browsed. This blocks distribution source scanners which looks for new releases.

Iguana Works still activ

Is Iquana Works still active? I placed an order but dates for the support tickets are 2 years old. Can I expect delivery?

Crashing on Ubuntu 20.04

Latest code in git crashes on Ubuntu 20.04

The latest tarball (instead of git master) does not crash but lirc-drv-iguanair doesn't link and lirc-lsplugins will say Error: /usr/lib/x86_64-linux-gnu/lirc/plugins/iguanair.so: undefined symbol: iguanaListDevices

When instead running git master I get this crash running igdaemon:

(gdb) r --devices
Starting program: /usr/bin/igdaemon --devices
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fc6c00 in findDeviceEndpoints (info=0x4, maxPacketSize=0x7ffff7faa012) at /home/morgan/Downloads/iguanair/software/usb_ir/drivers/libusb.c:576
warning: Source file is more recent than executable.
576         usbDevice *head, *prev = NULL;

Not sure what the problem is..

C# wrapper

I have a project in C# using the IR blaster. Currently this relies on LIRC and Mono, which I would very much like to remove.

Unfortunately, I don't know much about C++ or building drivers. I know you built a plugin for WinLIRC. Do you have, can you make, can you help me make a C# wrapper for your driver?

Ultimately, I'd love to see a driver (and wrapper) for Windows 10 IoT.

Thanks

any alternative to WinLIRC's transmit.exe?

I am using IguanaWorks USB device and WinLIRC 0.9.0i to communicate with two set-top boxes for a large broadcast recording project. The recording application is NextPVR, which supports a command line execution to implement channel changes via an IR emitter, whenever the user switches channels during viewing or recording. We are testing this using transmit.exe and setchannel.bat, a utility I wrote to send the full channel number via transmit.exe.

Both setchannel.bat and transmit.exe work at the command line, but both fail when invoked from within NextPVR.

Apparently, the problem is, the transmit.exe source code (https://sourceforge.net/p/winlirc/code/HEAD/tree/trunk/winlirc/transmit.cpp) is using WP_COPYDATA. This assumes a client/service architecture, and uses the clipboard (WM_COPYDATA) to communicate between client and server. Since client and server run under different desktop sessions, they don't share a clipboard so the messaging fails.

Do you have any suggestion for how this simple code could be rewritten to avoid this problem? Can the IGdaemon be used to replace transmit.exe? Do you know of developers who may have created alternatives to transmit.exe which do not use clipboard communications?

Support 64 bit on Windows

We should be able to build the service as 64 bit, although it doesn't really matter. However, we'll want to supply both 32 and 64 bit versions of the various libraries. The pipe layer between the client library and the service means we can handle clients of either architecture, but we'll want to test to make sure there isn't a stray "int" laying around.

Please update build information

The information on http://www.iguanaworks.net/support/ is partly outdated. It's about Fedora specifics (plain bugs), the Ubuntu debian situation and the upcoming lirc plugin system.

Too dumb to create a merge request for the wiki, but an ordered set of three patches are available at http://ur1.ca/k9z9l, http://ur1.ca/k9z9o and http://ur1.ca/k9z9q .

Compilation errors in swig-generated code.

Compiling gives errors as attachhed. They seem bad enough to drop the concerned python code from the bulid.

warnings.txt

New Resource busy error message

Reported by bluey on 1 Oct 2013 19:57 UTC
If you start igdaemon and it cannot connect to the device, it reports

Oct 01 18:50:49 2013 ERROR:   updateDeviceList failed: Failed to set device configuration: Resource busy

Can we make this ask if igdaemon is already running or if the kernel driver iguanair is not blacklisted? It would be nice to point users in the right direction to fix / and we can have a FAQ entry on this error.

Purging protocol v1

When we switch to version 2 of the client/device protocol we will:

• drop or replace the pin configuration codes, removing IG_DEV_GETCONFIG0 from iguanaIR.h and moving them into protocol-versions.h

lirc driver does not support device enumeration

As heading says, the lirc driver lacks support for device enumeration. LIRC implements enumeration using the DRVCTL_GET_DEVICES drvctl.

The easy way to check is to use mode2 --list-devices

Enumerating the iguana devices should give something like

/run/iguanaIR/0   [1234:5678]   /sys/class.......
/run/iguanaIR/1  [1234:6789]   /sys/class....

The only mandatory part is the first word i. e., the actual device to use in LIRC, The rest is optional, free-format info usable in a UI.

I'm attaching
0001-Add-device-enumeration.patch.zip

a patch which fixes the generic parts, without actually doing the enumeration

WinLirc not reconnecting when igdaemon restarts

Reported by jdunn on 16 Aug 2013 01:06 UTC
WinLirc should reconnect if it's connection to the igdaemon is lost. Unfortunately, this currently requires a change to the WinLirc source code due to the way libiguanair connects to client sockets directly. See #308 for some history.

libusb device index is not the hardware device index

Reported by jdunn on 18 Feb 2013 18:17 UTC
Within the libusb based drivers we use a devIndex given by libusb and print it as if it were the hardware index. It is not the hardware index and we need to find the hardware index instead/in addition to this index.

Check for the kernel module

Reported by jdunn on 18 Feb 2013 18:20 UTC
Since there is now a kernel module available for our hardware and installed in Fedora18 we need to update the driver to identify when the module has claimed the USB device. Once it is found we could provide a command line option to trigger a release of the hardware so that our daemon can communicate with it.

Output without modulation

Reported by bluey on 25 Jul 2012 14:04 UTC
Sometimes you want to output the IR signal with no carrier -- ie the input expecting a demodulated signal as is sometimes found on the IR in port of receivers, etc.

So, feature request: when carrier frequency set to 0, do not do any modulation. This way you can plug dual socket directly into those kinds of stereos to control them.

support TCP ports

Reported by bluey on 8 Oct 2007 03:14 UTC
Be nice to use TCP for communication with the service, allowing for remote access and easier porting of the daemon to windows. First step would be to make socketName only accessible to the daemon, and provide an API for clients to connect and request a mapping to a port based on a request string. Ideally, in the future we would support both unix sockets and tcp sockets, and possible windows named pipes.

Well, we now can handle windows named pipes, and given another implementation of pipes.h we could probably support TCP without a problem. That requires a couple changes though. Specifically, we would need to create a struct with function pointers that would be loaded at start time so we could listen on multiple interfaces at the same time.

pulses are consistently short

Reported by jdunn on 22 Jun 2009 12:46 UTC
It appears that somewhere during the changes from 0x0004 to 0x0102 a bug was introduced that makes the signals approximately 12[pct] shorter than intended. I have not yet measured this myself, but it seems quite believable.

listenToClients oddness

While working on #10 I saw that we pass function pointers to listenToClients, but since that function's implementation is always compiled into the same module as the client-interface.c it seems pointless. The pointers might make sense if there was some plan to provide different implementations of handleReader, clientConnected, or handleClient. Instead we have multiple implementations of the calling function. That doesn't make much sense, so I'll probably rip that bit of indirection out.

iguanair device should stop reporting IR activity after period of inactivity

Reported by seanyoung on 18 Aug 2014 11:57 UTC
If there has been no IR activity for 100ms, the iguanair can stop sending usb packets. This causes unnecessary CPU wakeups and thus battery life on mobile.

Note that most IR receivers work like this, iguanair is the exception here (see linux kernel code, drivers/media/rc/*.c).

Ideally the device would send a last usb packet which specifies it will no longer send IR data until some IR activity has been detected.

Can't compile for OSX

When doing a cmake -G Xcode I get an error:

-- The C compiler identification is Clang 7.0.0
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
CMake Error at CMakeLists.txt:92 (message):
  Unrecognized CMAKE_SYSTEM_NAME


-- Configuring incomplete, errors occurred!

Looking at the code history, I see there used to be a Makefile but now you're using CMake. Is it possible that OSX was forgotten in this transition? How can I proceed? Thanks

meta-information from igdaemon

Reported by jdunn on 28 Nov 2008 19:03 UTC
Currently clients just try to connect to the sockets that correspond to devices. In addition to these socket there should be another socket that the daemon uses to list the currently connected devices and update interested clients about how the list changes.

File descriptor leaks on Linux

The underlying issue will probably be very closely related to #10, but this is on the Linux side. Every disconnect / reconnect / rescan cycle leaks one file descriptor. Further, if a client is connected at disconnect time we leak a second file descriptor. I'm going to guess that this is a leak of the idev->readerPipe and the client->fd.

Build improvements and testing

We specifically call out bash in the runCmake script, but could just as easily get away with sh so we should probably switch just to be compatible w systems that don't have bash by default (FreeBSD for one?). While testing the build on FreeBSD I also realized I was using the clang compiler, so we should confirm everything works with that compiler and officially support it (if any changes are required).

Variable overlap

Reported by jdunn on 26 Oct 2014 03:10 UTC
While implementing --resend in the firmware I figured out that tmp4 and last_pulse actually overlap with the first two bytes of the control_pkt buffer. This is bad, but not causing us any problems right now. I believe fixing this would require a new loader so I will put this off until we need a new loader (0x0400) for some other reason.

Server did not understand

Hi
I am trying to configure iguanaworks in raspberry pi 3. I followed everything in getting started. I got every test ok but when try to use irrecord -H iguanaIR I got errors like this

irrecord -H iguanaIR
Using driver iguanaIR on device auto
Apr 04 02:02:23 2018 ERROR: Server did not understand version request, aborting. Is the igdaemon is up to date?
Apr 04 02:02:23 2018 ERROR: Server did not understand version request, aborting. Is the igdaemon is up to date?
Could not init hardware (lircd running ? --> close it, check permissions)

Some idea
Thanks

No systemd support.

Effectively, all linux:es have moved to systemd. Adding systemd support is trivial, and doesn't hurt if system uses traditional sysV.

Attaching /lib/systemd/system/iguanair,service and usr/lib/tmpfiles.d/iguanair.conf form the fedora package. They should be fine upstream, one of the ideas with systemd is that all distributions shares these files. txt-suffuixes as required by github...

Remaining issue is to configure 80-iguanaIR.rules so that it doesn't duplicate creation of the temprary directory on a systemd installation.

iguanaIR.service.txt
iguanair.conf.txt

Resource Busy Windows

Tried Running winlirc with a stock remote file and got no output from my device.

Named the device, still no output

Troubleshooting the device I got this and I cannot see what is locking it up:

Microsoft Windows [Version 10.0.22631.3737]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>cd C:\Program Files (x86)\IguanaIR

C:\Program Files (x86)\IguanaIR>igdaemon -v -v -v
Jun 14 22:20:31 2024 DEBUG: Parameters:
Jun 14 22:20:31 2024 DEBUG: recvTimeout: 1000
Jun 14 22:20:31 2024 DEBUG: sendTimeout: 1000
Jun 14 22:20:31 2024 DEBUG: driverDir: C:\Program Files (x86)\IguanaIR
Jun 14 22:20:31 2024 INFO: Loaded driver: C:\Program Files (x86)\IguanaIR\driver-libusb.dll
Jun 14 22:20:31 2024 ERROR: trying to claim usb:0:1
Jun 14 22:20:31 2024 ERROR: updateDeviceList failed: usb_claim_interface failed 0: libusb0-dll:err [claim_interface] could not claim interface 0, win error: The requested resource is in use.

Jun 14 22:20:31 2024 ERROR: scan failed.

take a careful look at the lirc driver

Reported by jdunn on 23 Nov 2010 19:22 UTC
I believe the lirc driver could probably use a careful check-through to look for a few specific thigns:

• check if we need to do anything to support SEND_START and SEND_STOP
• see if we can get the timings any more precise for LIRC
  • possibly look into using the compression schemes we've come up with
• overall just make sure it's not unnecessarily complicated or delaying.

"fatal error: config.h: No such file or directory" on attempt to make

Hi, I am new to linux specifics, I just bough your IR USB transiver device and trying to make it work with Raspberry Pi 3. It didn't work with default apt-get package lircmd 0.9.0-pre1, because there is no iguana driver, so I built the last version of Lirc from git lircmd 0.9.4d, which doesn't have driver as well, so now I am trying to build the driver from this git project. Although I am getting error on attempt to make:

pi@raspberrypi:~/git/iguanair/software/lirc-drv-iguanair $ make
cc -I../usb_ir -fpic -DPLUGINDOCS=\"/usr/local/share/doc/lirc/plugindocs\" -I/usr/local/include    -c -o iguanair.o iguanair.c
In file included from /usr/local/include/lirc/ir_remote_types.h:52:0,
                 from /usr/local/include/lirc_driver.h:21,
                 from iguanair.c:31:
/usr/local/include/lirc/include/media/lirc.h:9:20: fatal error: config.h: No such file or directory
 #include <config.h>
                    ^
compilation terminated.
<builtin>: recipe for target 'iguanair.o' failed
make: *** [iguanair.o] Error 1

Any help would be greatly appreciated!

Prior to next release TODO

We're actually quite close but here are the things that should be looked at before the final release:

Tasks:

• upgrade libusb on windows to libusb1.0: in progress
• build the existing firmware with latest PSoC and see if we get something happier with OSX That didn't work... see comment below.
• rpmlint
• a real pass through the wiki and docs
• make a pass through the TODOs fixed or removed most. leaving a few for another time

Issues to examine and possibly fix:

• #15, See if replacing the DLL works It does.
• #13, will be fixed after upgrading libusb on windows
• #1, make a final decision, but likely not in this release. not today
• #4, most of the framework is in place, but more useful for us during programming than for customers no today
• #9, cursory look and see how hard it would be to fix fixed in my repo
• #31, once leamas has a chance to look at it

check if windows is joining with threads correctly

Reported by jdunn on 1 May 2012 01:20 UTC
In the daemon.c file we have a call to joinThread, but there doesn't appear to be a similar call in the win32/service.c file. My guess is that we're just not properly cleaning up the threads as they exit. Not a big deal since this is one thread per device detected, but still.

igdaemon.exe stops when data is not consumed by client

Reported by mortenab on 13 Dec 2010 10:36 UTC
If data is not consumed by client, the igdaemon.exe crashes.

Reproduce by:

• Make a program that sends 0x12 command to start receiving IR data
• Do not consume data from igdaemon (iguanaIR-0 named pipe)

Duty cycle on sends not 50/50

Reported by bluey on 2 May 2008 22:36 UTC
The duty cycle on IR sending is not exactly 50/50. This is because of an asymmetry between pulling the voltage on the LED to 5V vs pulling the voltage on the LED down to ground (and an asymmetry in the LED).

At 150kHz, the duty cycle is 60/40 (4us on, 2.66us off). This works out to having the LED on an extra 0.66us. The duty cycle is approximately

0.5+/- carrier_frequency*0.66us

This offset is clearly more significant at higher frequencies. At 38kHz, the duty cycle is 52.5 / 47.5 but it grows with freq to 60/40 at 150kHz.

This is not a problem since even a 60/40 duty cycle will work for most applications. Is we want to push to higher frequencies (why?) we might want to try to compensate for this offset in the firmware.

These measurements were made by measuring the current flowing through the LED. Attached is a graph of one cycle at 150kHz. 1V = 20mA

python bindings report better errors

Reported by bluey on 5 Nov 2008 02:28 UTC
If device hung, have python binding report better error messages.

irsend: hardware does not support sending

Hi. I am trying to debug my installation of one of these.

I've tried to follow along these instructions but am getting nowhere. I am using the device as a transmitter not a receiver. This was all working in the past but just stopped for whatever reason.

I have your repo installed. I have rebuilt lirc on Ubuntu and installed the .deb. Here is the current state:

# ps -ef |grep igdae 
iguanair  6001     1  0 08:46 ?        00:00:00 /usr/bin/igdaemon --log-level=0 --send-timeout=1000 --receive-timeout=1000 --driver=libusb -l /var/log/iguanaIR.log
# ps -ef |grep lirc
root     18132     1  0 09:27 ?        00:00:00 /usr/sbin/lircd --output=/run/lirc/lircd --device=/dev/lirc0
# lircd -H ? 2>&1 | grep igua
	iguanaIR
# ls -l /dev/lirc*
lrwxrwxrwx 1 root root 15 Apr 27 09:27 /dev/lircd -> /run/lirc/lircd
# igclient --get-version
get version: success: version=0x0308

But still, sending commands doesn't work:

$ irsend SET_TRANSMITTERS 1
irsend: command failed: SET_TRANSMITTERS 1
irsend: hardware does not support sending

At this point I'm stumped.

High CPU usage accumulated over time

The accumulated cpu usage is quite high for a program like this.
Might be related to #17.

IG_DEV_SETCHANNELS with firmware revision 0x0003

Reported by jdunn on 29 Jul 2010 22:46 UTC
So, looking at the igdaemon log I think it may be a bug in the daemon. The telling lines are:

Jul 29 01:17:10 2010 ERROR: Unknown packet type in request: 0x17
Jul 29 01:17:10 2010 ERROR: handleClientRequest(0x00) failed with: 22 (Invalid argument)  

Basically it looks like the daemon didn't translate the client's
IG_DEV_SETCHANNELS call as it was supposed to according to
protocol-versions.c. Upgrading the firmware is a fine work-around for the problem. I would guess that a breakpoint in translate device's if statement would find the issue fairly fast.

bool translateDevice(uint8_t *code, uint16_t version, bool fromDevice)
{
    if (version <= 4)
        version = 0;
    else
        version = 1;

    return translateClient(code, version, fromDevice);
}

ID length issue

Setting a 12 byte ID causes minor problems since the firmware can only store exactly 12 bytes for the ID. We need to make sure that when the ID is read back that it gets properly terminated. Also, support UTF-8 would be a good idea.

weird SONAME and .so links.

The generated SONAME looks unversioned:

 $ objdump -p foo/usr/lib/libiguanaIR.so | grep SONAME
 SONAME               libiguanaIR.so

A SONAME is supposed to be versioned. Also. the standard setup on POSIX systems is symlinks corresponding to the SONAME. Compare e. g., llibgmp:

  $ objdump -p /usr/lib64/libgmp.so.10.3.1 | grep SONAME
  SONAME               libgmp.so.10
 [mk@snorken iguanaIR]$ ls -l /usr/lib64/libgmp*.so*
 lrwxrwxrwx 1 root root     16 Jun 22  2016 /usr/lib64/libgmp.so.10 -> libgmp.so.10.3.1
 -rwxr-xr-x 1 root root 604888 Jun 22  2016 /usr/lib64/libgmp.so.10.3.1

This is how programs and in particular distributions handles the binary compatibility. Please make update the iguanaIR soname to a versioned one and update the installed files. BTW, this is a breakage introduced with cmake, the autotools libraries were fine.

changelog for debian

When building a debian package on raspbian (and probably other debian variants) from source, it errors with:

dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision

I tried fixing this by changing the first line of the change log from

iguanair (1.2.0-unstable-1) unstable; urgency=low
to

iguanair (1.2.0-unstable) unstable; urgency=low

(see 9336f12 which should probably be reverted as it didn't fix the problem).

More digging and I found that we need

iguanair (1.2.0) unstable; urgency=low

to be the changelog file. This, however breaks setting the distro that we need to upload to Ubuntu launchpad ppa.

I think the right approach is to have the default checkout build on proper debian but have all the extra changelogs for supports distros return what they did before 9336f12:

iguanair (1.2.0-zeisty-1) ziesty; urgency=low

the make_version.sh script is broken

It uses svn data, not git. Actually, on a modern box it tries to use svn but it fails because the svn data is too old.