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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
27 matches
Mail list logo
