Debian Bug report logs - #290937
hearse doesn't support 64-bit platforms

version graph

Package: hearse; Maintainer for hearse is Roderick Schertler <>; Source for hearse is src:hearse.

Reported by:

Date: Mon, 17 Jan 2005 21:18:02 UTC

Severity: wishlist

Found in version 1.4

Forwarded to Roderick Schertler <>

Full log

Message #42 received at (full text, mbox):

Received: (at 290937) by; 11 Mar 2005 16:26:21 +0000
From Fri Mar 11 08:26:21 2005
Return-path: <>
Received: from [] 
	by with esmtp (Exim 3.35 1 (Debian))
	id 1D9mxw-0003os-00; Fri, 11 Mar 2005 08:26:20 -0800
Received: from ( [])
	by (Postfix) with SMTP id 03CA2F7E3BA
	for <>; Fri, 11 Mar 2005 16:25:47 +0000 (UTC)
Received: from fishtest (unknown [])
	by (Postfix) with SMTP
	id EB7E714981DB; Fri, 11 Mar 2005 16:25:44 +0000 (UTC)
Message-ID: <00cf01c52656$fc8d5190$1901a8c0@fishtest>
From: "Alexis Manning" <>
To: "Roderick Schertler" <>
Cc: <>
References: <> <> <> <> <> <> <>
Subject: Re: Bug#290937: doesn't accept my bones
Date: Fri, 11 Mar 2005 16:25:48 -0000
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-HotPOP: -----------------------------------------------
                   Sent By FREE Email
             Get your FREE POP email at
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
	(1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=-3.1 required=4.0 tests=BAYES_44,HAS_BUG_NUMBER 
	autolearn=no version=2.60-bugs.debian.org_2005_01_02
As you pointed out, there hasn't been a big demand for this platform.  So
there's no one to share bones files with for that platform, and your Debian
user would be reduced to hopefully uploading bones and sobbing piteously.

That doesn't mean I'm not interested in the underlying problem though.  As
you correctly say, the existing code is geared to expect four 32-bit values
for version info.  To be honest, this was due to a sheer lack of foresight
on my part.  Initially it was intended to be for Windows NH only, and other
platforms didn't come into consideration until later.  That said, it's a bit
much to assume that the DevTeam will retain this method of versioning bones
files indefinitely.  Even if they do, there are other supported variants
(such as Slashem) which may well diverge, and (currently unsupported)
roguelikes who will have their own weird and wacky versioning system.

So certainly, in the future I want a nice backward compatible method of
taking an arbitrary amount of version information and getting a unique
identifier from it.  The easiest way that comes to mind is to build up a
string of the version numbers and then take an MD5 of it.  That one's going
on my 'To do' list, but I don't expect to have much time free to do it in
the near future, real life being what it is.  I also don't think it's very
urgent, rather the kind of thing that's good to have out of the way in case
the DevTeam decide to change their versioning system overnight.  They don't
consult with mere mortals like me, y'know :)

So the underlying problem will be fixed once I get some free time.  Please
let me know if you hear about this issue from any other users - once there's
a bit of demand from 64-bit NH users, it'll be worth adding support for them
to the server.


-- A.

Send a report that this bug log contains spam.

Debian bug tracking system administrator <>. Last modified: Sat Apr 19 00:49:39 2014; Machine Name:

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.