tag 589103 +help
thanks

I have been looking at what it will take to build lsof on kfreebsd.
Obviously the first step is passing '-n freebsd' to './Configure' as noted
earlier on the bug report. You can see the current state of our work at

Vcs-Git: git://git.debian.org/git/collab-maint/lsof.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/lsof.git

However once that is done one hits the problem described in section 8.6 of the FAQ:

> 8.6        Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
>
>    Lsof may report:
>
>        Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
>        FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
>        FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
>    or
>        Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
>        FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
>
>    Those messages mean that lsof's Configure script failed to
>    create a local header file, ./lockf_owner.h, needed to use the
>    new kernel file locking code of some versions of FreeBSD 6 and
>    above.
>
>    The changes that implement that new locking code alter the
>    lockf structure in <sys/lockf.h> and introduce a new structure,
>    lockf_entry, to that header file.  When Configure detects the
>    presence of the lockf_entry definition in <sys/lockf.h>, it
>    tries to construct the local header file, ./lockf_owner.h.
>
>    Configure has to do that  because an unfortunate side effect of
>    the new kernel file locking code is that <sys/lockf.h> doesn't
>    contain the lockf_owner structure definition referenced in its
>    own lockf structure.  Lsof needs to access elements of that
>    lockf_owner structure to determine if a lock belongs to the
>    process that has a file open.
>
>    The missing lockf_owner structure definition is in the kernel
>    source file, typically /usr/src/sys/kern/kern_lockf.c.
>    Configure tries to extract the lockf_owner structure definition
>    from kern_lockf.c into lsof's local header file, ./lockf_owner.h.
>    If Configure can't do that, it reports:
>
>        FATAL ERROR: ./lockf_owner.h creation failed
>
>    If Configure can't even read kern_lockf.c, it first reports:
>
>        FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
>
>    The work-around for this problem is to update the FreeBSD
>    kernel /usr/src tree (e.g., do a CVSup or csup) on the system
>    where lsof is to be built and then do a "make buildworld"
>    followed by a "make installworld".
>

So the problem is to translate this into "Debian-speak". I think I see how
to do this in principle but some of the details elude me.

1.) Declare a build dependency: kfreebsd-source[kfreebsd-any]
2.) Have a clause in the override_dh_auto_configure rule that checks for
the kfreebsd OS and copies the compressed tarball to somewhere in the build
space; uncompresses and untars it; and sets the FREEBSD_SYS environment
variable accordingly.
3.) The kfreebsd-source copies will need to be cleaned up as part of the clean
rule.

The bit  that I am most unclear about is how to tie up the Debian version
for lsof, the kernerl version and how to pick the correct version of
kfreebsd-source from the virtual package. I suppose one way to go is
to make "lsof" a virtual package depending on
"lsof-linux | lsof-kfreebsd | lsof-hurd". lsof-kfreebsd would itself
be a virtual package depending on the real package "lsof-kfreebsd-OSVER".

Can one evade the whole issue by forcing lsof on to use /proc? Maybe
we should take that approach but discuss with upstream.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to