Re: My Hurd speaks PostScript
Marcus Brinkmann wrote:
> On Fri, Nov 19, 1999 at 08:18:01PM +0000, Chris Lingard wrote:
> > A week or so ago I got stuck when building the Hurd, there was a
> > failure in the doc directory when it tried texi2dvi. Marcus suggested
> > that I try to build tetex from source, and then post in the patches.
> > This is the first tar ball for me that is totally stable. I just kept
> > adding packages until the thing built and worked.
> Thanks for your work on this!
> > It has a script called klibtool that pre-dates libtool. I intend to
> > change it so that it calls libtool.
> That's a good idea. Only the very latest libtool has the correct info for
> the Hurd.
> > I get a few discrepencies when I
> > build libtool. The binary debhelper package was short of perl scripts
> > on both Debian and Hurd; but not the same ones, so some trading took
> > place.
> You don't need to build libtool, it is binary-all: Which means it works on
> all platforms. Anyway, can you be more specific about your problems?
> Wht do you mean with "both Debian and Hurd"? Which version numbers were you
> > The current source tries to build everything so I had to get the X
> > headers and libraries so that it would make xdvi.
> Please, please use those from
> Although there may be some easy to track bugs in the imake stuff scripts (a
> blank too much somewhere)
> > Also it needs xlib,
> > xlib-dev and libpng; but though these were installed it still made its
> > own version.
> It made its own xlib? Are you sure?
> > There is also a call to a command line getopt.
> Bah, it is in util-linux. Please work around it by building a copy of it
> locally. util-linux is still on the TODO list.
> > The fonts and stuff go in /usr/share; but the binaries go in /bin. I
> > would prefer to keep TeX out of the root partition, so would prefer
> > either /usr/lib/bin and /usr/local/lib/texmf as in UNIX, ot
> > /usr/share/bin and /usr/share/texmf. This way you can mount another
> > partition, and keep the root partition clean.
> Hu? Please don't touch the file locations, you are going beyond the porting
> issues here.The packages should be almosrt identical to the Linux packages,
> that's the only way we can avoid a lot of confusion and additional work.
> In this particular case: /usr/share/bin is an oxymoron, binaries are usually
> not shareable (ix86 doesn't run on alpha etc).
> /usr/lib/bin is not used in Debian, same for /usr/local.
> There are more isues with file location, for example the FHS standard
> document. Again, please try to be minimal in your changes. Patches are less
> acceptable by upstream authors if they do some weired stuff unrelated to
> porting issues.
> > Do you want me to work on this package, if there is nobody else? I do
> > not know Debian Hurd rules yet but can soon learn.
> Well, "Kapil H. Paranjape" <firstname.lastname@example.org> was already working on it,
> and it seemed he completed it, but I don't know if he tackled the issues you
> raised. The klibtool/libtool issue is definitely worth investigation. Kapil,
> did your build produce the same sonames as a Linux build? That's important.
> Please coordinate your work and let us know what the final results are.
> `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
> Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
> Marcus.Brinkmann@ruhr-uni-bochum.de, email@example.com PGP Key ID 36E7CD09
> http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ firstname.lastname@example.org
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org