lsof fails to build from source on debian's non-linux variants
(kfreebsd-i386, kfreebsd-amd64, and hurd-i386).

This appears to be at least partly because of a hardcoded line in
debian/rules:

 ./Configure -n linux

which obviously is wrong on these other platforms.

Here is a recent failed build log on kfreebsd-amd64:

https://buildd.debian.org/fetch.cgi?pkg=lsof;ver=4.81.dfsg.1-1;arch=kfreebsd-amd64;stamp=1245273862

Note that lsof's upstream claims at least that it builds fine on FreeBSD:

  ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/README

(no mention of hurd there).

christoph tried today just changing debian/rules to use

 ./Configure -n freebsd

but that didn't work either:
 [...]


You can access the FAQ directly here:

 ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ

It would be really nice to have lsof available on kFreeBSD.  It's also a
build-dependency of some packages (i ran into this with xdotool, which
uses lsof in the build process' test suite), so its lack on those arches
is actually causing other trouble in the archive.

block 590827 with 589103
thanks

#589103 is a bug against lsof to make that tool available on for the
kFreeBSDs (and hurd, if possible).  lsof does work on regular FreeBSD
systems.  debian GNU/kFreeBSD shouldn't be deprived of the tool.
 [...]

I don't think this is an acceptable solution, because it breaks the test
scripts (they actually rely on lsof, the check for their presence isn't
superfluous)

tag 661575 +help
forwarded 661575 abe@purdue.edu
thanks

Abe,
	Thanks again for your work on lsof.

	There seems to be no support in the lsof code for the Hurd operating
system. I cannot say I am surprised but it does I believe meet your
criteria for support as it is readily available for download and
installation as per http://www.debian.org/ports/hurd/ .

	I have copied the Debian Hurd mailing list as they are most likely to
be able to provide patches and advice.

	Thanks. Nicholas

Nicholas Bamber, le Tue 24 Apr 2012 22:33:15 +0100, a écrit :

Well, I don't think the Hurd already has interfaces for lsof to get any
information.  That would have to be added first...

Samuel

Samuel,
	AFAIK I think if the /proc filesystem had /proc/*/fd you'd be pretty
much there. I guess I should have copied an upstream Hurd mailing list
as well.

Nicholas Bamber, le Tue 24 Apr 2012 23:16:42 +0100, a écrit :
is any interface to actually implement /proc/*/fd either.
also subscribed to debian-hurd.

Samuel

See msg.defs.

Roland McGrath, le Tue 24 Apr 2012 16:34:52 -0700, a écrit :

That will give only ports to the fds.  How to get back to actual file
paths?

Samuel

That actually rings a bell from some other Hurd issue. Isn't there some
bit of purest thinking that we have no right to assume that a file
descripter actually implies a physical file, hence the question just
cannot be asked. If that is so then the best Hurd might ever be able to
offer lsof is the current /proc file system.

Oh, well that's a different story (and one best discussed on bug-hurd).
There were past proposals about this, but I don't have a pointer.


Thanks,
Roland

Nicholas,

You write:

Thanks for the inquiry.  I am now 8 years into retirement and
have reduced lsof work to the minimum necessary to support a
few remaining dialects, including mainstream Linux.  As a
result I'm not inclined to take on a new port.

Since the lsof sources are open software with just a few
restrictions imposed by the Purdue copyright, it would be
permissible for someone else to do the Hurd port.

Regards,

Vic

Nicholas Bamber, le Wed 25 Apr 2012 00:53:59 +0100, a écrit :

There is sense in that, yes.  That can also happen on Linux actually,
when the file is removed.

The best you can have is what path was used to open it.  In the Hurd,
only the process itself knows.

The process can be asked for the path.  It just has to avoid throwing it
away after opening it, and define an interface to fetch it.

Samuel