Debian Bug report logs - #661575
lsof: FTBFS on Hurd

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Daniel Kahn Gillmor <[email protected]>

To: [email protected], [email protected]

Subject: lsof FTBFS on non-linux arches

Date: Wed, 14 Jul 2010 18:39:33 -0400

[Message part 1 (text/plain, inline)]

Package: lsof
Version: 4.81.dfsg.1-1

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:

> 16:45 < christoph> jep but changing to freebsd doesn't work
> 16:46 < christoph> Creating ./lockf_owner.h from /sys/kern/kern_lockf.c
> 16:46 < christoph> FATAL ERROR: can't read /sys/kern/kern_lockf.c
> 16:46 < christoph> FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
> 16:47 < dkg> sounds like it needs kernel source available to do that. (from 
>              00FAQ)
> 16:47 < dkg> FAQ question 8.6
 [...]
> 17:26 < christoph> having the kernel-source package doesn't help has it doesn't 
>                    ship that file .. digging
> 17:27 < christoph> and there doesn't seem to be a package that does


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.

	--dkg

PS if debian-bsd folks reply to this, please CC me as i'm not on the list.

[signature.asc (application/pgp-signature, attachment)]

Message #12 received at [email protected] (full text, mbox, reply):

From: Daniel Kahn Gillmor <[email protected]>

To: Petr Salinger <[email protected]>, [email protected]

Cc: [email protected], [email protected]

Subject: Re: Bug#590827: xdotool: FTBFS on GNU/kFreeBSD (due to unsatisfied Build-Depends on lsof)

Date: Thu, 29 Jul 2010 11:13:04 -0400

[Message part 1 (text/plain, inline)]

block 590827 with 589103
thanks

On 07/29/2010 11:47 AM, Petr Salinger wrote:
> Package: xdotool
> Version: 1:2.20100602.2915-1
> Severity: serious
> Tags: patch
> User: [email protected]
> Usertags: kfreebsd
> 
> 
> Hi,
> 
> the current version fails to build on GNU/kFreeBSD.
> It looks like lsof is needed on for testsuite.

#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.

> Please restrict it's b-d only on linux "lsof [linux-any]"
> and allow missing lsof in t/ephemeral-x.sh script.
 [...]
> --- xdotool-2.20100701.2961.orig/t/ephemeral-x.sh
> +++ xdotool-2.20100701.2961/t/ephemeral-x.sh
> @@ -69,7 +69,7 @@ fi
>  if ! which lsof > /dev/null 2>&1 ; then
>    echo "Unable to find lsof. This is a required tool."
>    cleanup
> -  exit 1
> +  exit 0
>  fi

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)

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Message #31 received at [email protected] (full text, mbox, reply):

From: Nicholas Bamber <[email protected]>

To: [email protected]

Cc: [email protected], Raoul Borenius <[email protected]>, [email protected], [email protected]

Subject: lsof on Hurd

Date: Tue, 24 Apr 2012 22:33:15 +0100

tag 661575 +help
forwarded 661575 [email protected]
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

Message #40 received at [email protected] (full text, mbox, reply):

From: Samuel Thibault <[email protected]>

To: Nicholas Bamber <[email protected]>

Cc: [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Wed, 25 Apr 2012 00:14:35 +0200

Nicholas Bamber, le Tue 24 Apr 2012 22:33:15 +0100, a écrit :
> 	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.

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

Samuel

Message #45 received at [email protected] (full text, mbox, reply):

From: Nicholas Bamber <[email protected]>

To: [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Tue, 24 Apr 2012 23:16:42 +0100

On 24/04/12 23:14, Samuel Thibault wrote:
> Nicholas Bamber, le Tue 24 Apr 2012 22:33:15 +0100, a écrit :
>> 	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.
>
> 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.

Message #50 received at [email protected] (full text, mbox, reply):

From: Samuel Thibault <[email protected]>

To: Nicholas Bamber <[email protected]>

Cc: [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Wed, 25 Apr 2012 00:22:47 +0200

Nicholas Bamber, le Tue 24 Apr 2012 23:16:42 +0100, a écrit :
> 	AFAIK I think if the /proc filesystem had /proc/*/fd you'd be pretty much
> there.

Of course, but that doesn't change the actual issue: I don't think there
is any interface to actually implement /proc/*/fd either.

> I guess I should have copied an upstream Hurd mailing list as well.

It does not matter very much actually: most upstream Hurd people are
also subscribed to debian-hurd.

Samuel

Message #55 received at [email protected] (full text, mbox, reply):

From: Roland McGrath <[email protected]>

To: Samuel Thibault <[email protected]>

Cc: Nicholas Bamber <[email protected]>, [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Tue, 24 Apr 2012 16:34:52 -0700 (PDT)

> Of course, but that doesn't change the actual issue: I don't think there
> is any interface to actually implement /proc/*/fd either.

See msg.defs.

Message #60 received at [email protected] (full text, mbox, reply):

From: Samuel Thibault <[email protected]>

To: Roland McGrath <[email protected]>

Cc: Nicholas Bamber <[email protected]>, [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Wed, 25 Apr 2012 01:42:20 +0200

Roland McGrath, le Tue 24 Apr 2012 16:34:52 -0700, a écrit :
> > Of course, but that doesn't change the actual issue: I don't think there
> > is any interface to actually implement /proc/*/fd either.
> 
> See msg.defs.

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

Samuel

Message #65 received at [email protected] (full text, mbox, reply):

From: Nicholas Bamber <[email protected]>

To: Roland McGrath <[email protected]>, [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: Bug#661575: lsof on Hurd

Date: Wed, 25 Apr 2012 00:53:59 +0100

On 25/04/12 00:42, Samuel Thibault wrote:
> Roland McGrath, le Tue 24 Apr 2012 16:34:52 -0700, a écrit :
>>> Of course, but that doesn't change the actual issue: I don't think there
>>> is any interface to actually implement /proc/*/fd either.
>>
>> See msg.defs.
>
> 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.

Message #70 received at [email protected] (full text, mbox, reply):

From: Roland McGrath <[email protected]>

To: Samuel Thibault <[email protected]>

Cc: Nicholas Bamber <[email protected]>, [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: lsof on Hurd

Date: Tue, 24 Apr 2012 16:56:45 -0700 (PDT)

> Roland McGrath, le Tue 24 Apr 2012 16:34:52 -0700, a écrit :
> > > Of course, but that doesn't change the actual issue: I don't think there
> > > is any interface to actually implement /proc/*/fd either.
> > 
> > See msg.defs.
> 
> That will give only ports to the fds.  How to get back to actual file
> paths?

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

Message #75 received at [email protected] (full text, mbox, reply):

From: "Vic Abell" <[email protected]>

To: "'Nicholas Bamber'" <[email protected]>

Cc: <[email protected]>, "'Raoul Borenius'" <[email protected]>, <[email protected]>, <[email protected]>

Subject: RE: lsof on Hurd

Date: Tue, 24 Apr 2012 19:50:53 -0400

Nicholas,

You write:
>
> 	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

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

Message #80 received at [email protected] (full text, mbox, reply):

From: Samuel Thibault <[email protected]>

To: Nicholas Bamber <[email protected]>

Cc: Roland McGrath <[email protected]>, [email protected], [email protected], Raoul Borenius <[email protected]>, [email protected]

Subject: Re: Bug#661575: lsof on Hurd

Date: Wed, 25 Apr 2012 02:21:59 +0200

Nicholas Bamber, le Wed 25 Apr 2012 00:53:59 +0100, a écrit :
> 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.

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.

> If that is so then the best Hurd might ever be able to offer lsof is the
> current /proc file system.

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

Send a report that this bug log contains spam.