patch to support hurd-i386

Christian Kurz shorty at getuid.de
Thu Dec 28 18:25:10 EST 2000


On 00-12-27 mouring at etoh.eviladmin.org wrote:
> On Wed, 27 Dec 2000, Christian Kurz wrote:
> > here's a patch so that ssh also supports hurd-i386. Thanks for
> > incorporating. The patch comes from Robert Bihlmeyer <robbe at orcus.priv.at>.
> > 
> > > openssh 2.2.0p1-1.1 does not build on the Hurd. The appended patch
> > > fixes that. Changes in detail:
> > 
> > > * PAM is not (yet?) supported, so the PAM dependencies are only put into
> > > the control file on architectures != hurd-i386.
> > 
> > > * Hurd has no random device, therefore /etc/ssh/ssh_prng_conf is needed.
> > > Added to conffiles.
> > 
> > > * Do not try to generate a hostkey while building the package. This is
> > > useless, and it will fail on the Hurd if ssh is not yet installed.
> > 
> "make install" should alway check if it should generate hostkeys.  The
> package manager should not be calling 'make install' unless it's doing a
> test run (via -n).  Also in the most recent CVS tree all ssh-keygen are
> relative to the make directory.  

Well, we will try to fix this bug as good as possible in our packaging
building system. I'm mostly concerned about the other patches that hurd
needs.

> > > * Hurd has no MAXHOSTNAME. Two instances replaced by fixed limit, where
> > > only the first N bytes were used, anyway. Two more instances replaced
> > > by a grow-until-fits loop.
> > 
> HURD does not have MAXHOSTNAME?!  They must have removed it from the MACH
> header files or NeXTStep added it.  I would want to know Markus' view on
> that aspect of the patch.  I find it overly complex (besides the fact
> we have xmalloc() and xrealloc() to handle the null returns that should
> fail using fatal()). I see one or two nice things suggestions in the
> patch.  I think they may want to consider either defining MAXHOSTNAME
> (because it's used by a lot of software) or we can test and set a limit if
> there is none.

Well, that's why I forwarded it to you guys, to first here your opinion
and maybe talk with the author of the patch about it, before applying it
to our debian package of ssh or incorporating it into the CVS of
openssh. 

Ciao
     Christian
-- 
While the year 2000 (y2k) problem is not an issue for us, all Linux
implementations will impacted by the year 2038 (y2.038k) issue. The Debian
Project is committed to working with the industry on this issue and we will
have our full plans and strategy posted by the first quarter of 2020.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 242 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/509cbeeb/attachment.bin 


More information about the openssh-unix-dev mailing list