Hi,

I have been using httrack for some time now, and was a bit irked that it was
not included in the openSUSE repositories for 11.4. I decided to install it
from the sources and downloaded the tarball here.

I found some problems along the way, and here are my solutions and workarounds
which may help some other people and/or help Xavier fix some bugs.

I) Compilation

I unpacked the files to "~/Software Installs" and make aborted with an error.
My fault: spaces in directory names and compiling are a no-no, so changing the
name to ~/Software_Installs took care of that.

II) Installation

make install did its task, but neither the man pages nor the program itself
were available.
(could not find library libhttrack.so.2)

To see the manpages:
mandeb -qp (as root)
or sudo /usr/bin/mandb -qp (as user)
will update the manpages database.

Or you just wait until a nightly cron job does it for you :-)

To run the programs:
ldconfig (as root)
or sudo /sbin/ldconfig

after that the libs will be available, and the programs will run.

To Xavier: This could be done from script while installing (you have to be
root anyhow).

III) Desktop Integration 

a) Program webhttrack does not apear on the GUI menu.
so run either :
SuSEconfig -module desktop-file-utils  (as root)
or sudo /sbin/SuSEconfig -module desktop-file-utils  (as user)

if you don't care about sanity checks or are using another distro try:

/usr/bin/update-desktop-database (as root)

webhttrack and "Browse Mirrored Websites" is now on the menu (in KDE :
Internet/More Programs and Recently Installed)

b) but the icons are missing

This is bug, the paths to the icon files are wrong.

As root open the files:
/usr/local/share/applications/WebHTTrack.desktop
and
/usr/local/share/applications/WebHTTrack-Websites.desktop

and change the line:
Icon=/usr/share/httrack/icons/webhttrack.xpm
to
Icon=/usr/local/share/httrack/icons/webhttrack.xpm

This bug should be easy to fix.

IV) Runtime

I think for most of you webhttrack should be running smoothly now.

Not so for me. I have a different network configuration.
Router/firewall with squid-proxy and my own name-server running (no DNS
blocking from ISPs or governments) between the internet and my internal net.

But this means firefox does not resolve names locally but the name-server on
the proxy does. Squid talks directly to bind, so the "search" directives in
/etc/resolv.conf on both machines are being ignored.

Assuming my machine is called frodo.linux.site webhttrack opens a firefox
window/tab with address : <http://frodo:8080/>.
As it is not necessarily local, firefox calls the proxy (instead of using the
"No Proxy for" configuration of firefox), squid calls bind, finds nothing and
sends "The domain name does not exist" to firefox. 
Meanwhile 2 webhttrack, 1 httserver and a couple of sleep processes are
happily running in the background.

It would definitely be better to use a fully qualified domain name for the
address eg here <http://frodo.linux.site:8080/>. firefox would know it is local
and not even use the proxy.
Or use <http://localhost:8080/>.

I found out that you get this URL from the log of htserver in /tmp, extracting
it in /usr/local/bin/webhttrack.

So my workaround is :
Near the end of the file /usr/local/bin/webhttrack, before the cleanup
function or at least the browser invocation, insert the line :

SRVURL=`echo -n $SRVURL | sed -e "s/\/\/$(hostname):/\/\/$(hostname
--fqdn):/"`

You could also use:
SRVURL=`echo -n $SRVURL | sed -e "s/\/\/.*:/\/\/localhost:/"`

This will do the trick.


To Xavier:
IMHO the cleanest solution would be for htserver to print the fqdn to the log
instead of just the hostname.

I really think you should fix this asap, because otherwise you may get
problems with the new TLDs of ICANN.

You can test it even now:
Type <http://io/> or <http://tm/> or <http://ac/> on the address-bar in firefox (o
just io or tm or ac). You'll see
webpages coming up.
For io you are being connected to <http://nic.io>.
(afaik this works also in windows, not in XP but in Vista and 7 it works).
So if the host is by chance called io webhttrack will try to connect to
<http://nic.io:8080/> and not to localhost.
With all the new TLDs coming, you can expect a lot more conflicts.


Well, I hope this helps someone
ccs