Ticket #178 (new defect)

Opened 5 months ago

Last modified 5 months ago

driver installs with unmet dependencies

Reported by: jgombos Owned by: bluey
Priority: normal Component: Debian/Ubuntu
Version: Severity: minor
Keywords: Cc:

Description

The driver installs without complaining when the OS provides version 2.3.6.ds1-13etch10 of glibc. The driver seems to require version 2.4 or 2.7, so the deb package should enumerate that as a dependency to prevent broken installations.

Driver version: 1.0pre2

Change History

Changed 5 months ago by jgombos

This is the output after installing:

# /etc/init.d/iguanaIR start Starting Iguanaworks USB IR daemon.../usr/bin/igdaemon: /lib/libpopt.so.0: no version information available (required by /usr/bin/igdaemon) /usr/bin/igdaemon: /lib/libc.so.6: version GLIBC_2.4' not found (required by /usr/bin/igdaemon)` /usr/bin/igdaemon: /lib/libc.so.6: version GLIBC_2.4' not found (required by /usr/lib/libiguanaIR.so.0) /usr/bin/igdaemon: /lib/libc.so.6: version GLIBC_2.7' not found (required by /usr/lib/libiguanaIR.so.0)`

Changed 5 months ago by jgombos

Another missing dependency:

The /etc/init.d/iguanaIR script calls a binary executable with the literal name "daemon". This does not seem to be a core tool in debian. To workaround, I ran "aptitude install daemon", which in fact provides a tool with the name "daemon". The proper fix is probably to reference the daemon package as a dependency.

Changed 5 months ago by bluey

"daemon" is only supposed to be called only on redhat/fedora distros. On debian/ubuntu systems, we use "daemon-start-stop" -- I think the problem is our init script isn't properly detecting that you have a debian system. Can you run: 

head -1 /etc/issue | sed 's/ .*//' | tr 'A-Z' 'a-z'

that should return "debian" . It is a little obtuse, but if you look at the script, we look for the $LOCKFILE variable to see if the distro is fedora (set earlier) and if it is not, we use start-stop-daemon. So either we aren't seeing the "debian" or somehow you have a value for $LOCKFILE set that is messing with our script. Maybe we need to unset that variable at the top. Let me know what you see to the above command.

Changed 5 months ago by jgombos

My /etc/issue is correct.. I made the comment about "daemon" not in response to a problem, but just my inspection of the script. I didn't notice that LOCKFILE is only set for redhat. Sorry for the confusion.

So the glibc dependency is the only anomaly here (which is fixed in my installation because it was recompiled).

Note: See TracTickets for help on using tickets.