Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-09-01 Thread Norbert Preining
Hi Samuel, On Sam, 01 Sep 2007, Samuel Thibault wrote: Well, either should work fine for hurd-i386 because it happens that Ok, for now I leave your patch in there. We will see what upstream will do, and what will be included by Jonathan into the xetex sources. Thanks a lot. Norbert

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-31 Thread Norbert Preining
On Die, 28 Aug 2007, Michael Casadevall wrote: Independently of Samuel, I ended up patching the same bug in Texlive, but I did a different method of fixing On Mit, 29 Aug 2007, Samuel Thibault wrote: That should rather be sizeof(FILE*): rgfp is an array of FILE*, not an array of FILE.

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-31 Thread Samuel Thibault
Hi, Norbert Preining, le Fri 31 Aug 2007 20:47:50 +0200, a écrit : On Die, 28 Aug 2007, Michael Casadevall wrote: Independently of Samuel, I ended up patching the same bug in Texlive, but I did a different method of fixing On Mit, 29 Aug 2007, Samuel Thibault wrote: That should rather

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-29 Thread Samuel Thibault
Hi, Michael Casadevall, le Tue 28 Aug 2007 01:17:10 -0400, a écrit : +#ifdef NOFILE FILE*rgfp[NOFILE+1];/* stack of input/include files */ +#else +FILE **rgfp; +#endif /* NOFILE */ + intcfp = 0;/* count of files in stack */ intcOpenBrace = 0;

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-27 Thread Michael Casadevall
Independently of Samuel, I ended up patching the same bug in Texlive, but I did a different method of fixing NOFILE instead of simply defining it to 256; According to the POSIX reference I found, NOFILE is the maximum files that can be opened at one time by a single process. On hurd, this is

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-16 Thread Norbert Preining
Hi Samuel, first, thanks a lot. BTW, is this the first version that does not build? Or have prior version been build without problems? That would be strange, since we haven't changed anything in recent times. On Mit, 15 Aug 2007, Samuel Thibault wrote: texlive-bin currently FTBFS on hurd-i386

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-16 Thread Norbert Preining
Hi, again me ... On Mit, 15 Aug 2007, Samuel Thibault wrote: --- texlive-bin-2007/build/source/Work/texk/detex/xxx.l.orig 2007-08-14 22:44:53.229859000 +0200 +++ texlive-bin-2007/build/source/Work/texk/detex/xxx.l 2007-08-14 22:45:19.329634000 +0200 @@ -59,6 +59,10 @@ #endif

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-16 Thread Samuel Thibault
Hi, Norbert Preining, le Thu 16 Aug 2007 11:11:55 +0200, a écrit : first, thanks a lot. BTW, is this the first version that does not build? It actually never built on hurd-i386. On Mit, 15 Aug 2007, Samuel Thibault wrote: texlive-bin currently FTBFS on hurd-i386 because of the copy of icu

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-16 Thread Norbert Preining
On Don, 16 Aug 2007, Samuel Thibault wrote: It actually never built on hurd-i386. Ok. Well, I have to admit no, because the patch can't hurt other archs in any way: the aclocal.m4/configure *-*-gnu*) match can only happen on hurd-i386, and #defining NOFILE after all #includes cannot hurt in

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-16 Thread Samuel Thibault
Hi, Norbert Preining, le Thu 16 Aug 2007 11:41:50 +0200, a écrit : Well, I have to admit no, because the patch can't hurt other archs in any way: the aclocal.m4/configure *-*-gnu*) match can only happen on hurd-i386, and #defining NOFILE after all #includes cannot hurt in any way.

Bug#437949: texlive-bin: FTBFS on hurd-i386 because of icu

2007-08-14 Thread Samuel Thibault
Package: texlive-bin Version: 2007-13 Severity: important Tags: patch Hi, texlive-bin currently FTBFS on hurd-i386 because of the copy of icu that it embeds. Here is the patch that already got applied to the icu package and is being forwarded icu upstream. There was also a problem with xxx.l