Bug#676129: [tex-live] Bug#676129: texlive: pdflatex generates an invalid pdf if a particular combination of images are inluded
Hi all, On 06/05/2012 09:30 AM, Norbert Preining wrote: I don't expext that we fix that before release, but it might be worth investigating. I have no idea how to fix this properly, but running pdfclean -x solves the problem with acroread, with means something is in an object stream that should not be. Indeed, adding \pdfobjcompresslevel = 1 % or 0 appeared to be a working workaround. Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Hi Hilmar,
On 11/28/2010 01:54 PM, Hilmar Preusse wrote:
luafilesystem: that local patch will go away soon (it is possible
to slide the new functions in elsewhere, where they are not
interfering with the upstream).
The patch is still in the lualib used by luatex. Did you made already
a decision if that code is needed (and should be pushed upstream to
the lua project)?
Thank you for reminding me, I had completely forgotten about this :(
I now am in the process of upgrading luatex to use luafilesystem 1.5.0,
and I will move most of the extra functionality to a different source
file, as I wrote above.
Nevertheless, there are two change sets that will remain in my version
of the lfs.c file: one portability bug fix and one extension. Both of
these are interesting enough to go upstream, in my opinion.
The portability fix is in get_dir(), where the stock lfs version
assumes a glibc-style runtime library that calls malloc() automatically
inside getcwd(). I got a compilation failure report on that, for
the Sun Studio compiler on Solaris 10 Sparc.
The extension is an extra field thats is retunred by lfs.attributes(),
named 'permissions'. This represents the file permissions as a simple
9-letter string (it uses r, w, and x only).
Best wishes,
Taco
--- lfs.c.orig 2010-11-28 15:19:45.0 +0100
+++ lfs.c 2010-11-28 15:43:19.0 +0100
@@ -128,16 +128,19 @@
** If unable to get the current directory, it returns nil
** and a string describing the error
*/
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
static int get_dir (lua_State *L) {
- char *path;
- if ((path = getcwd(NULL, 0)) == NULL) {
+ char path[PATH_MAX];
+ if (getcwd((char *)path, PATH_MAX) == NULL) {
lua_pushnil(L);
lua_pushstring(L, getcwd_error);
return 2;
}
else {
lua_pushstring(L, path);
-free(path);
return 1;
}
}
@@ -669,6 +672,46 @@
#endif
}
+ /*
+** Convert the inode protection mode to a permission list.
+*/
+
+#ifdef _WIN32
+static const char *perm2string (unsigned short mode) {
+ static char perms[10] = -\0;
+ int i;
+ for (i=0;i9;i++) perms[i]='-';
+ if (mode _S_IREAD)
+ { perms[0] = 'r'; perms[3] = 'r'; perms[6] = 'r'; }
+ if (mode _S_IWRITE)
+ { perms[1] = 'w'; perms[4] = 'w'; perms[7] = 'w'; }
+ if (mode _S_IEXEC)
+ { perms[2] = 'x'; perms[5] = 'x'; perms[8] = 'x'; }
+ return perms;
+}
+#else
+static const char *perm2string (mode_t mode) {
+ static char perms[10] = -\0;
+ int i;
+ for (i=0;i9;i++) perms[i]='-';
+ if (mode S_IRUSR) perms[0] = 'r';
+ if (mode S_IWUSR) perms[1] = 'w';
+ if (mode S_IXUSR) perms[2] = 'x';
+ if (mode S_IRGRP) perms[3] = 'r';
+ if (mode S_IWGRP) perms[4] = 'w';
+ if (mode S_IXGRP) perms[5] = 'x';
+ if (mode S_IROTH) perms[6] = 'r';
+ if (mode S_IWOTH) perms[7] = 'w';
+ if (mode S_IXOTH) perms[8] = 'x';
+ return perms;
+}
+#endif
+
+/* permssions string */
+static void push_st_perm (lua_State *L, STAT_STRUCT *info) {
+lua_pushstring (L, perm2string (info-st_mode));
+}
+
typedef void (*_push_function) (lua_State *L, STAT_STRUCT *info);
struct _stat_members {
@@ -688,6 +731,7 @@
{ modification, push_st_mtime },
{ change, push_st_ctime },
{ size, push_st_size },
+ { permissions, push_st_perm },
#ifndef _WIN32
{ blocks, push_st_blocks },
{ blksize, push_st_blksize },
Bug#287800: gnuplot: mp terminal won't allow prologues:=-1
On 09/20/2010 03:06 PM, Sanjoy Mahajan wrote: I'm CCing the main metapost developer in case this is not right. You are, in fact, 100% right. Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562358: mpost returns 1 on successful run?
Hi Norbert, Norbert Preining wrote: Hi Taco, on the Debian side we got a bug report that with the switch from TL2007 mpost to TL2009 mpost the same file suddenly makes mpost return 1 (failure in shell) instead of 0. Any issued diagnostic messages set the return code to 1. Issued errors are 2, issued fatal errors give 3. It has been like that in the original sources since the eighties, just as in TeX (but possibly there was a special patch in web2c earlier that reverted 1 back to 0, I don't know) So yes, that is intended. Error return codes start at 2. Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562176: [Dev-luatex] Bug#562176: luatex: FTBFS on hurd-i386: unconditional PATH_MAX usage
Hi,
Thanks, applied.
Best wishes,
Taco
Norbert Preining wrote:
Hi Taco,
Pino (in cc) found that luatex does not build on GNU/Hurd, but some
simple changes does fix that.
You might add that to luatex itself. (patch attached)
Thanks a lot and all the best
Norbert
On Mi, 23 Dez 2009, Pino Toscano wrote:
Hi,
currently[1] luatex does not build on GNU/Hurd.
The problem is the unconditional usage of PATH_MAX.
The attached patch solves the issue, malloc'ing the buffers as needed.
It also adds a small bit to recognize the GNU platform.
[1]
https://buildd.debian.org/fetch.cgi?pkg=luatexarch=hurd-i386ver=0.47.0-1stamp=1261470395file=logas=raw
Thanks,
--
Pino
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`... then I decided that I was a lemon for a couple of
weeks. I kept myself amused all that time jumping in and
out of a gin and tonic.'
Arthur cleared his throat, and then did it again.
did you...?'
I found a
small lake that thought it was a gin and tonic, and jumped
in and out of that. At least, I think it thought it was a
gin and tonic.'
`I may,' he addded with a grin which would have sent sane
men scampering into the trees, `have been imagining it.'
--- Ford updating Arthur about what he's been doing for the
--- past four years.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
___
dev-luatex mailing list
dev-lua...@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561500: Metapost: segmentation fault while text is included with btex etex
Hi,
Norbert Preining wrote:
- mpost should not segfault on a missing etex
I cannot reproduce the segfault. The output below is from /bin/bash,
but I also tried with zsh, same results. Does debian have a private
executable, or is it reusing the texlive one?
logistic.mp is attached.
Best wishes,
Taco
My machine is:
[t...@ntg tmp]$ cat /etc/issue
Mandriva Linux release 2009.0 (Official) for x86_64
Kernel 2.6.27.21-desktop-1mnb on a Dual-processor x86_64 / \l
[t...@ntg tmp]$ grep ^TEX\\b `kpsewhich texmf.cnf`
TEX = etex
[t...@ntg tmp]$ export LANG=fr_FR.UTF-8
[t...@ntg tmp]$ export LC_CTYPE=fr_FR.UTF-8
[t...@ntg tmp]$ /opt/tex/texlive/Master/bin/x86_64-linux/mpost logistic.mp
This is MetaPost, version 1.208 (kpathsea version 5.0.0)
(./logistic.mpfatal: exec failed: No such file or directoryfatal:
Command failed: etex --parse-first-line --interaction=nonstopmode
mp303041.tex; see mpxerr.log
logistic.mp
logistic.mpx
! Unable to make mpx file.
l.33 label.bot(btex
$r$ etex, ((rmax-0.2)*ux,0));
Transcript written on logistic.log.
[t...@ntg tmp]$ valgrind /opt/tex/texlive/Master/bin/x86_64-linux/mpost
logistic.mp
==31629== Memcheck, a memory error detector.
==31629== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==31629== Using LibVEX rev 1854, a library for dynamic binary
translation.
==31629== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==31629== Using valgrind-3.3.1, a dynamic binary instrumentation
framework.
==31629== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==31629== For more details, rerun with: -v
==31629==
This is MetaPost, version 1.208 (kpathsea version 5.0.0)
(./logistic.mpfatal: exec failed: No such file or directory==31630==
==31630== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
==31630== malloc/free: in use at exit: 3,603,612 bytes in 166,876
blocks.
==31630== malloc/free: 262,049 allocs, 95,173 frees, 74,446,521 bytes
allocated.
==31630== For counts of detected errors, rerun with: -v
==31630== searching for pointers to 166,876 not-freed blocks.
==31630== checked 3,401,368 bytes.
==31630==
==31630== LEAK SUMMARY:
==31630==definitely lost: 6,778 bytes in 283 blocks.
==31630== possibly lost: 0 bytes in 0 blocks.
==31630==still reachable: 3,596,834 bytes in 166,593 blocks.
==31630== suppressed: 0 bytes in 0 blocks.
==31630== Rerun with --leak-check=full to see details of leaked memory.
fatal: Command failed: etex --parse-first-line --interaction=nonstopmode
mp303082.tex; see mpxerr.log
logistic.mp
logistic.mpx
! Unable to make mpx file.
l.33 label.bot(btex
$r$ etex, ((rmax-0.2)*ux,0));
Transcript written on logistic.log.
==31629==
==31629== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
==31629== malloc/free: in use at exit: 3,601,967 bytes in 166,872 blocks.
==31629== malloc/free: 262,050 allocs, 95,178 frees, 74,446,584 bytes
allocated.
==31629== For counts of detected errors, rerun with: -v
==31629== searching for pointers to 166,872 not-freed blocks.
==31629== checked 3,400,824 bytes.
==31629==
==31629== LEAK SUMMARY:
==31629==definitely lost: 6,269 bytes in 281 blocks.
==31629== possibly lost: 0 bytes in 0 blocks.
==31629==still reachable: 3,595,698 bytes in 166,591 blocks.
==31629== suppressed: 0 bytes in 0 blocks.
==31629== Rerun with --leak-check=full to see details of leaked memory.
verbatimtex
%latex
\documentclass{article}
\begin{document}
etex
beginfig(1)
numeric rmin, rmax, r, dr, n, ux, uy;
rmin := 2.9; rmax := 3.9;
r := rmin; n := 175;
dr := (rmax - rmin)/n;
ux := 8cm; uy := 8cm;
for i = 1 upto n:
x := 0.5; % our starting point
for j=1 upto 75: % initial iterations
x := r*x*(1-x);
endfor
for j=1 upto 150: % the next 100 iterations
x := r*x*(1-x);
draw (r*ux,x*uy) withpen pencircle scaled .5pt;
endfor
r := r+dr;
endfor;
draw (rmin*ux,0) -- (rmax*ux,0);
draw (rmin*ux,0) -- (rmin*ux,uy);
labeloffset := 0.25cm;
label.bot(decimal(rmin), (rmin*ux,0));
label.bot(decimal((rmin+rmax)/2), ((rmin+rmax)/2*ux,0));
label.bot(decimal(rmax), (rmax*ux,0));
label.lft(decimal(0), (rmin*ux,0));
label.lft(decimal(0.5), (rmin*ux,0.5*uy));
label.lft(decimal(1), (rmin*ux,uy));
label.bot(btex $r$ etex, ((rmax-0.2)*ux,0));
label.lft(btex orbit etex rotated 90, (rmin*ux,0.75*uy));
endfig;
end;
Bug#561500: Metapost: segmentation fault while text is included with btex etex
Jean-Paul Vincent wrote:
==19611== Address 0xffa8 is not stack'd, malloc'd or (recently)
free'd
==19611==
Hardware or kernel bug? I will try 2.6.30 kernel (I am working with 2.6.31
kernel).
With an address like that, a segfault does not surprise me in the
least ;) In case it helps any: the error almost certainly happens
in the vfprintf that is called by mpx_abort that is called from
do_spawn from line 3956 in mpxout.w:
3954: if (child == 0) {
3955:if(execvp(cmd, options))
3956: mpx_abort(mpx, exec failed: %s, strerror(errno));
3957: } else {
It looks to me like your strerror() may return gibberish, which hints
at locale problems. Can you see what happens if set LC_MESSAGES in the
environment to something like 'C'?
Best wishes,
Taco
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561500: Metapost: segmentation fault while text is included with btex etex
Jean-Paul Vincent wrote: It seems this is the same output as before. Can I try something else? If you are willing to compile from scratch, then a backtrace of a non-stripped metapost would be quite helpful. http://foundry.supelec.fr/gf/project/metapost/frs/ This has a slightly different version of kpathsea, but that should not matter for this bug. Unpack, then run ./build.sh --nostrip , and ask gdb for a backtrace right after the crash. Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561500: Metapost: segmentation fault while text is included with btex etex
Hi, Jean-Paul Vincent wrote: #1 0x004054a7 in mpx_printf (mpx=0x7581e010, header=value optimized out, msg=0x46c1e8 Command failed: %s; see mpxerr.log, ap=0x7fffd810) at ../../../source/texk/web2c/mplibdir/mpxout.w:214 Ok, got it, I think. Please apply the diff below to mpxout.w and the error should go away (and that makes it a glibc difference). Best wishes, Taco Index: source/texk/web2c/mplibdir/mpxout.w === --- source/texk/web2c/mplibdir/mpxout.w (revision 1123) +++ source/texk/web2c/mplibdir/mpxout.w (working copy) @@ -211,7 +211,9 @@ if (mpx-lnno!=0) fprintf(mpx-errfile, %d:, mpx-lnno); fprintf(mpx-errfile, ); + va_start(ap, msg); (void)vfprintf(mpx-errfile, msg, ap); + va_end(ap); fprintf(mpx-errfile, \n); } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561500: Metapost: segmentation fault while text is included with btex etex
Hi, Jean-Paul Vincent wrote: Le dimanche 20 décembre 2009 à 11:04:33 +0100 (CET), Taco Hoekwater écrivit : I cannot reproduce the segfault. - Hardware or kernel bug? I will try 2.6.30 kernel (I am working with 2.6.31 kernel). That second patch I sent you privately works (tested by Norbert), and that will be included in metapost 1.209. For bugs.debian, here it is again: Index: source/texk/web2c/mplibdir/mpxout.w === --- source/texk/web2c/mplibdir/mpxout.w (revision 1123) +++ source/texk/web2c/mplibdir/mpxout.w (working copy) @@ -260,6 +260,8 @@ va_start(ap, msg); fprintf(stderr, fatal: ); (void)vfprintf(stderr, msg, ap); + va_end(ap); + va_start(ap, msg); mpx_printf(mpx, fatal, msg, ap); va_end(ap); mpx-history=mpx_fatal_error; -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Norbert Preining wrote: Dear Taco, one of the lua Gurus here at Debian checked the embedded libs and found that most of the included libs are very similar to upstream, and he offered to push the few changes in your code to upstream. What do you say? (See attached email, including the diffs between current upstream of the lua libs and code in texlua). But what happens then? Luatex becomes dependent on an external library that may or may not be distributed by debian (or anyone else)? Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Norbert Preining wrote: On Sa, 19 Dez 2009, Taco Hoekwater wrote: But what happens then? Luatex becomes dependent on an external library that may or may not be distributed by debian (or anyone else)? No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian. I don't understand this point. The files are statically linked, so how can there be any reuse? And the advantage for you is that there are less changes if you incorporate new versions of upstream libraries. But that is certainly true. Here is my opinion on those patches: luafilesystem: that local patch will go away soon (it is possible to slide the new functions in elsewhere, where they are not interfering with the upstream). luasocket: this (hstrerror) patch is good thing to go upstream. luazip: this is not a local patch, I am just using an outdated version. Best wishes, Taco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#458059: [NTG-pdftex] Bug#458059:
David Kastrup wrote:
Frank Küster [EMAIL PROTECTED] writes:
There is a configuration variable nest_size level, but it doesn't seem
to help in this case: The attached file gives an error
! TeX capacity exceeded, sorry [grouping levels=255].
although my texmf.cnf has nest_size=500.
I find it awfully hard to reliably trigger a semantic nest size
overflow. The best I have been able to come up with was
Can anybody think of a semantic nest without grouping apart from
unrestricted hmode (which I use above)?
The example that was attached by Frank (or Stijn?) does just fine.
As I suspected, the problem is a macro error, not an actual
limit. With \tracingall, the run ends with the output below.
We cannot fix this: the enlarging limits will just result in a
capacity exceeded message with a higher counter.
Best wishes,
Taco
[EMAIL PROTECTED] ...nd \z@ [EMAIL PROTECTED]@@p \boldmath {{b^c}}
}
\makebm #1$-\bm {#1}
$
[EMAIL PROTECTED] ... {\hbox {#1$\displaystyle [EMAIL PROTECTED] #2$
}}{\hbox
{#1$\textstyle \m...
[EMAIL PROTECTED]@@p ...fmmode [EMAIL PROTECTED] #1{#2}{#2}{#2}{#2}
\else \bfseries #1#2\fi
[EMAIL PROTECTED] ...nd \z@ [EMAIL PROTECTED]@@p \boldmath {{b^c}}
}
\makebm #1$-\bm {#1}
$
[EMAIL PROTECTED] ... {\hbox {#1$\displaystyle [EMAIL PROTECTED] #2$
}}{\hbox
{#1$\textstyle \m...
[EMAIL PROTECTED]@@p ...fmmode [EMAIL PROTECTED] #1{#2}{#2}{#2}{#2}
\else \bfseries #1#2\fi
[EMAIL PROTECTED] ...30049 [EMAIL PROTECTED]@@p \boldmath {{b^c}}
}
\makebm #1$-\bm {#1}
$
\makelabel ...h {\makebm }\normalfont \bfseries #1
:}
\sbox #1#2-\setbox #1\hbox [EMAIL PROTECTED] #2
[EMAIL PROTECTED] }
[EMAIL PROTECTED] ...i \fi \sbox [EMAIL PROTECTED] {\makelabel {#1}}
\global \setbox
[EMAIL PROTECTED] \...
l.11 \item[$a^{b^c}$]
$a^{b^c}$
! == Fatal error occurred, no output PDF file produced!
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458059: [NTG-pdftex] Bug#458059:
David Kastrup wrote:
Taco Hoekwater [EMAIL PROTECTED] writes:
David Kastrup wrote:
Can anybody think of a semantic nest without grouping apart from
unrestricted hmode (which I use above)?
The example that was attached by Frank (or Stijn?) does just fine.
But that's not without grouping as far as I can see, so it is not really
different from what I had. If you put a line {
before the problem, then it will again bomb out with a grouping error
instead. At least that is what I think I see when looking at the error
message and context.
In short: I don't see how one can trigger semantic nest errors when the
semantic nest limit is more than twice the grouping limit (which it
isn't right now).
I was still very much focused on the bug report when I wrote the above,
so I misread your reply.
You are almost certainly right about the nest2*groups, just with maybe
a small extra delta, like nest2*groups+2 (because many functions push
the semantic nest before the save stack). I do not want to spend the
time (probably a lot of time) finding out the absolute truth, but I
agree that a nest_size of 600 appears to make the error unreachable.
Best wishes,
Taco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458059: [NTG-pdftex] Bug#458059:
Taco Hoekwater wrote: You are almost certainly right about the nest2*groups, just with maybe a small extra delta, like nest2*groups+2 (because many functions push the semantic nest before the save stack). I do not want to spend the time (probably a lot of time) finding out the absolute truth, but I agree that a nest_size of 600 appears to make the error unreachable. In (pdf)tex, that is. Not in Aleph|Omega|Luatex, and I am not sure about XeTeX. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482303: luatex: getpwnam() implicitly converted to pointer
Hilmar Preusse wrote: The problem meanwhile causes an FTBFS (fails to build from source) on ia64. I've seen a patch in the SVN (Revision 1279), which seems to address the problem. Can we check it out and use it to work around the problem? Sure, I see no problem with that. It is just a build issue, after all. Because luatex is still beta software (as best), I am not eager to undertake such backports myself, I hope you understand that. But I certainly have no problem with you patching it. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458059: [NTG-pdftex] Bug#458059:
Hi Frank, Stijn, Frank Küster wrote: Dear TeX(-k) people, dear pdfTeX team, late last year Norbert Preining already asked on the TeXk list about a problem encountered in Debian, namely a TeX capacity exceeded error on grouping levels. Nobody could help back then, but now someone started to analyse this further (many thanks, Stijn!). So could you please (again) have a look? Why aren't these quarterword/halfword bounds configurable? They simply cannot be configurable at runtime because that would be too late, the entire memory structure depends on these sizes. There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error ! TeX capacity exceeded, sorry [grouping levels=255]. although my texmf.cnf has nest_size=500. Should/can we change max_quarterword, or are there side effects? Technically, at compile time we could have max_quarterword=65535 and even max_halfword=2^30 on all modern platforms, but it more or less requires switching to the memory_word structure used by Omega/ Aleph/Luatex for efficiency reasons. Also, such a change is not something to be undertaken lightly. I've done that for luatex and iirc there were a few small, subtle side-effects that took me entire days to hunt down. Definately a bad idea at last minute before texlive 2008, and therefore IMO probably not worth the trouble at all (for pdftex). Or should the grouping levels instead use halfword? Or would you like to do it in a completely different way? This is a real life problem which affects building the PostgreSQL documentatin. In any case, we should try running the test with aleph or luatex to be sure but I (at least half-)expect that the actual limit will not matter, and that it simply will never be large enough due to some form of recursion. I can try this tomorrow, will let you know then unless someone beats me to it. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482311: luatex: check_isnode() implicitly converted to pointer
Hilmar Preusse wrote: On 22.05.08 Taco Hoekwater ([EMAIL PROTECTED]) wrote: dann frazier wrote: Hi Taco, Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `check_isnode' implicitly converted to pointer at ../../../../src/texk/web2c/luatexdir/lua/llanglib.c:168 This is often due to a missing function prototype definition. This bug was already fixed in my upstream source, but thanks for taking the effort of reporting bugs. Is the fix for that problem (together with the fix for This one yes. http://bugs.debian.org/482303) already in 0.25.3, i.e. can we mark these bugs as fixed in upstream? That one no. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482311: luatex: check_isnode() implicitly converted to pointer
Hi, dann frazier wrote: Package: luatex Version: 0.25.2-1 Severity: important Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `check_isnode' implicitly converted to pointer at ../../../../src/texk/web2c/luatexdir/lua/llanglib.c:168 This is often due to a missing function prototype definition. This bug was already fixed in my upstream source, but thanks for taking the effort of reporting bugs. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482303: luatex: getpwnam() implicitly converted to pointer
dann frazier wrote: Package: luatex Version: 0.25.2-1 Severity: important Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `getpwnam' implicitly converted to pointer at ../../../src/texk/kpathsea/tilde.c:103 This is often due to a missing function prototype definition. For more information, see [2]. luatex provides its own pwd.h file which is getting included instead of the system pwd.h file and does not include a prototype for getpwnam(). If the luatex pwd.h file is not available in the include path, the system one gets properly included: Thanks, I have come up with a solution where luatex is using the system-wide pwd.h except while crosscompiling for win32 (that is what the file was there for). Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480725: [dev-context] (fwd) Bug#480725: mptopdf does not work with beginfig(-1)
Hi Norbert, Norbert Preining wrote: forwarded 480725 [EMAIL PROTECTED] thanks Dear Hans, dear Taco, on the Debian side we got the attached bug report together with a patch for mptopdf.pl. Can you comment on it, or consider it for inclusion? The patch would have to be a bit elaborated on before inclusion can be considered, I believe. A random file named whatever.ps is highly likely not to be metapost output at all. The extra functionality would be cool to have, but mptopdf had better check if the .ps really was created by metapost (by grepping for the %%Creator comment). Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446617: (fwd) Bug#446617: texlive-metapost: Omits font encoding from output
Braun Gábor wrote: (Please leave [EMAIL PROTECTED] on Cc) We got a bug report on Debian which still uses mpost as present in TeX Live 2007 (ie) 0.993. See below for the bug description and a test file. Is this fixed by MetaPost 1.00, or is this something new? Works for me (MetaPost 1.000). This bug will be fixed in MetPost 1.001 (to be released this week) Best wishes, Taco
Bug#446617: texlive-metapost: Omits font encoding from output
Norbert Preining wrote: On Mo, 05 Nov 2007, Taco Hoekwater wrote: This bug will be fixed in MetPost 1.001 (to be released this week) Thanks, great. BTW: Can you provide (by any chance) a diff from 1.000, or even better, a diff from current texlive sources ;-) I will do a tl checkin immediately after release. Is it good enough if I send you the versio number, or do you need a diff/patch file? Cheers, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446617: (fwd) Bug#446617: texlive-metapost: Omits font encoding from output
Norbert Preining wrote: forwarded 446617 [EMAIL PROTECTED] thanks Dear Taco! Dear all! (Please leave [EMAIL PROTECTED] on Cc) We got a bug report on Debian which still uses mpost as present in TeX Live 2007 (ie) 0.993. See below for the bug description and a test file. Is this fixed by MetaPost 1.00, or is this something new? Works for me (MetaPost 1.000). Gábor, can you test the metapost 1.000 source distribution from http://foundry.supelec.fr/projects/metapost/ to make sure? Best wishes, Taco
Bug#441595: [Dev-luatex] building luatex with external lua headers/libs
Norbert Preining wrote: Hi Taco! First of all, thanks for the rework of the zzlib stuff, now it is easy to compile luatex with external zlib libs/headers. Now there is the wish that we compile luatex also with the external lua (5.1) libs/headers. You can't, and shouldn't. I am not using a not-quite stock lua51. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441595: [Dev-luatex] building luatex with external lua headers/libs
Norbert Preining wrote: On Do, 27 Sep 2007, Taco Hoekwater wrote: (5.1) libs/headers. You can't, and shouldn't. I am not using a not-quite stock lua51. Ah, good to hear. So you did patch the lua51, too. I didn't know that. Thanks for pointing this out. The main reason is that stock lua believes that all text files use the native line ending. That is a big nono in TeX land, where files are often transported to and fro (networked) machines. So I assume it is the same with the other luaX libs. Yes, you are limited to just zziplib and the set of libraries that are also used by pdftex (for now). The other stuff is either modified by me or not really a dynamic library at all. Best wishes, Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345604: [Fontinst] License of the fontinst documentation
Frank Küster wrote: But there's also files in the talks subdirectory for which no source is currently available. Do you know about the license situation for them, or should I try to contact Ulrik or Taco? And, for that matter, I guess roadmap.eps has been created with MetaPost - do you happen to have the sources available? I completely forgot I helped with that talk. The documents were prepared by Ulrik (I do not have sources and am not an author). Taco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
