1) mflua.1 has never been in TeX Live. I guess someone created it for
Debian (or other) without sending it upstream? Anyway, I will copy it
into TL. Although mflua.1 doesn't have the usual Debian disclaimers for
man pages, I assume that's ok :).
2) It would be welcome, and the fixes seem ok in
it looks like the LuaTeX binaries were compiled with "-g -O2", but
running "readelf" and "objdump" shows that they're stripped, so I
don't think that that's the issue here.
FWIW, it's my understanding that what matters for execution speed is not
the presence or absence of debug
I noticed that there is now a package context-legacy.r69173.tar.xz in
the TL/archive subdir . I contains a lot of stuff
"tex/context/patterns/mkii".
Yes, Siep created context-legacy to continue to support mkii.
I guess I have to package that and upload it into Debian.
Indeed.
The files are not in the "minimal distribution" (which includes binaries,
fonts etc.), but they are still present in the context zip itself.
Mojca - by the "context zip" do you mean cont-tmf.zip? I'm guessing not
.. please advise. Because, as Siep said, the current cont-tmf.zip
contains
Thanks for bringing this to our attention. The primary wdiff
maintainer (Martin von Gagern) has not been active on the project in
some time so I'm not sure how soon the project will get to it.
Denver, Martin (Martin, are you there?) - in principle, all GNU packages
should be
STill, also this will not work for Debian, as here only collection <->
collection relations can be tracked.
If all the hyperref deps are in c-latex (I just moved them), and the
Debian c-latex is installed, why won't hyperref then work?
force me to package at the collection level was
Subject: colletion-latexbase hyperref.sty depends on collection-latexextra
letltxmacro.sty
Ok, but before I change anything: hyperref has a package-level
dependency on letltxmacro (and a bunch of others). Why doesn't that
suffice?
As far as I can see (per previous mail to the tex-live
Thanks for the explanation.
I think we should add all known hyperref deps to c-latex, anyway.
Because, why not. It's improbable that anyone would install latex and
not use hyperref, nowadays. I'll do that.
However, I think package-level deps are the only solution to some
(other) problems. -k
esint10.mf
is empty, besides comments and a lone
\endinput
Is this on purpose?
No, I just didn't notice. In the 2019/07/19 update of esint, esint10.mf
is supposed to be generated from esint.dtx, while only that stub file in
fact shows up. I am not sure. Running
Subject: [pdftex] Add option -synctex to pdftex(1)
I applied this patch (and made some other updates at the same time).
TL r51815. Thanks. -k
not sure if this is the correct mailing list.
It's fine.
Subject: [pdftex] Add option -synctex to pdftex(1)
Sure, why not. Thanks. -k
Hi Hilmar,
... -lfreetype -lz -lgs
/usr/bin/ld: libdvisvgm.a(DLLoader.o): undefined reference to symbol
'dlclose@@GLIBC_2.2.6'
Martin can answer better (cc-ing), but I am under the impression that
dlopen/dlclose are not intended to be used when -lgs was linked. At any
rate, as far as
please move powerdot to -extra!
Moved for tonight's build. Thanks for doing the search. -k
Hi Hilmar,
please consider to move enumitem.sty from texlive-latex-extra to
texlive-latex-recommended or even texlive-latex-base.
I think I'd prefer to move powerdot to c-latexextra, instead of adding
enumitem to c-latexrecommended (I see no need for c-latex[base). But if
you think that
It looks like a good idea to move ifplatform to collection-base ???
Agreed, moved, thanks. -k
I think in this particular case it would be better to move them to the
docfiles?
Sure, agreed. Moved for tonight's build (in upstream TL). Thanks. -k
Added wordcount.sh to TeX Live for tonight's build. Thanks. -k
I'm fine with installing patches in TL. If Thorsten wants to create his
own ttf2pk2 somewhere as the upstream, and have us (TL) pull from there,
that's fine too.
Thanks,
Karl
Do you think (or AKira) that this is the problem for mips?
For sparc I am a bit stymed.
Yes, it's all about BigEndian architectures (and ICU and upmendex).
(And don't bother explaining that sparc is endian-neutral, the practical
reality is that it is still bigendian in our world.)
And
On another front:
@iftex
@macro cl{name}
{@smallertt@phantom{concurrency:}@llap{cl:}}\name\
@end macro
@end iftex
What's inside @iftex is supposed to be valid Texinfo.
(Just like @ifinfo, etc.) To lapse into plain/raw TeX,
@tex should be used. That's why it exists.
I reported it here: http://tracker.luatex.org/view.php?id=965
I'm glad Luigi could eventually reproduce the problem.
Why luatex loads different files depending from which directory it is
run?
I cannot explain anything about luatex behavior, which is (especially at
the moment) in a
Hi Igor,
checksum mismatch in local font cmb10 (-770990554 != -770990554)
This is complaining that a number is not equal to itself, clearly a
representation problem as you describe. I think you should report it,
with your analysis, on tracker.luatex.org. Perhaps it is already fixed
in
Hi Norbert,
I am not sure, but it might be related to this discussion on
the fontinst mailing list:
http://www.tug.org/pipermail/fontinst/2016/001692.html
No, Igor is reporting something unrelated, purely in LuaTeX's handling
of vf files. The fontinst issue that Michael and
> Also, "man ofm2opl" says about "-charcode-format" option,
> which does not exist:
Sorry, that describes on the legacy WEB version, now we call
it as 'wofm2opl'. Try wofm2opl --help.
In the C version, 'ofm2opl', the corresponding option
is -char-format.
Akira, if the
lots of mails here
Indeed. I'm afraid I can't keep up, so after these short replies, I'm
bowing out of this thread.
I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting to be able to *check* all of them.
I don't
would be useful for install-info to be able to do some transformation,
along with a transformation of the filename. (Karl, please explain why
you think this is a bad idea.)
Having I-I being able to transform dir file entries I have no particular
objection to. I suppose that is the
Perhaps it's naive, but I feel like I might just want a dir like this so
that I can find what I want and don't have to change global state and/or
restart the viewer just to read different versions:
I agree. You can have that now. It does not need new features, so far
as I can see.
That doesn't happen, and nobody seems to miss it. If the shell can
avoid a lot of complexity handling multiple versions of programs, I
suspect it may not be necessary for documentation either.
Indeed. Which is why I don't understand why we're having this whole
thread. Sorry. It
Here's what I don't get: suppose there are two versions of Emacs
installed, emacs-x and emacs-y. Presumably Debian (and anyone else) has
some method for the user to choose which one is invoked by just emacs.
Can't that method, whatever it is, also switch the Info files that are found?
For
* my wish list: support of sub directories and links within subdirs
in this case selecting a link would *first* search for the
Hmm. Sadly, I just cannot comprehend -- this seems like an
unspecifiable, unmanageable, mess. I expect I'm missing something.
Officially supporting
/usr/share/info/emacs-24/emacs.info.gz
FWIW, to the best of my knowledge, $(infodir) has always been a flat
directory, and dir files a flat namespace. The problem of multiple
versions, similar to multiple languages, has never been satisfactorily
resolved. This is the first time I
l.56 \initial {\\}
Works for me with current texinfo.tex and the input below (to force
creating the \initial line). I don't doubt there was a bug in some
version of texinfo.tex in this regard, but I routinely run Texinfo
documents with \indexentries, so I doubt it existed for long. -k
* coreutils: (coreutils)coreutils invocation. Multi-call program.
I do not have a program named coreutils on my system, despite the
documentation, and I installed coreutils-8.23 from original sources.
Maybe coreutils.texi should not contain this Info entry?
Not that that particular case
- move euenc to collection-latexrecommended
It's tiny, so ok. Also makes sense, in that if fontspec+luatex wants to
read it, it is not xetex only.
By the way, there is no fontspec-luatex package in TeX Live.
But I get the drift.
- make collection-luatex depend on collection-xetex
I just committed changes to texlive-ru and texlive-en such that lmodern
is not loaded for texlive-ru. I also added the line
\usepackage[T2A]{fontenc}
to texlive-ru.tex, which seemed to be the other crucial change. I
assumed the textual changes were related to (the many) changes
between 2010 and
Norbert and all,
It seems I added the t2alm*.fd files in 2012, sent to me by Vladimir
Lomov (cc'd) as part of an update to the Russian translation of the TL
guide.
http://tug.org/svn/texlive/trunk/Master/texmf/doc/texlive/texlive-ru/t2almr.fd?view=logpathrev=29712
(I unfortunately misspelled his
Hi Juliusz,
What about mnsymbol? It's a fairly small package, and is a simple,
hassle-free way to get a bunch of mathematical symbols that blend
relatively well with many common fonts
I guess I don't have any overwhelming argument against it, but it would
be nice if I had a note
Do what you want in Debian, of course. (Do you exactly 100% follow the
TL collection constituents now?)
For TL, I see that c-fontsrecommended has txfonts and pxfonts. Perhaps
I should exchange those with the newtx and newpx in extra, but I'm not
sure. I have a feeling that an awful lot of
as far as I understand it seems that at least Karl Berry agrees in
that regard)
I hadn't realized that the ligatures only failed with non-fully-embedded
PDF's. Such PDF's are inherently defective; it's been a long time since
Adobe recommended anything but full embedding (not that I think
FWIW, I don't see how adding ff and the like to the OT fonts simply as
independent glyphs for rendering, not related to any OT or Unicode
ligature mechanism, could confuse anything.
I agree the real bug is in poppler (and/or Debian's choice of using
these OT fonts without sufficient testing), but
revert to the old-style names in the OTF
Seems like there should be no need to revert. In principle, couldn't
the fi ligature glyph appear as both f_i and fi? In other words,
add a bunch more duplicate glyphs; nothing else need change, as I
understand it ... f + i would still lead to f_i,
The problem is that the ligatures are named
f_i
Adobe wants it that way these days, as I understand it. (Personally I
think they were terribly wrong to try to change something so fundamental
but, surprisingly, they didn't ask me. :)
See section 6 (or search for ligature) in
Jerome said:
i can't actually build the tool and make live tests but a careful
reading shows that all the changes really make sense and look ok
So we should go ahead and apply the proposed changes in TL.
Ok, Peter?
Thanks,
Karl
--
To UNSUBSCRIBE, email to
What do you think?
Seems clear to me, but I forwarded the message to Jerome (Laurens).
As the synctex author, he's the one who should be in the loop :).
I will report back if he replies to me.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Is there a reason for it, and why do we not switch to ttf2pk2
and get rid of one more lib in libs?
Peter removed freetype1 and ttf2pk in the sources some time ago,
so they'll be gone in TL 2014.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
I am not sure who is currently maintaining mendex,
As you know, it was part of the general Japanese-TeX import into TL, so
I suppose you and Akira are :), with the rest of us chipping in as
necessary.
Please apply whatever patch you see fit.
#define TAIL(x) (x+strlen(x))
The first x
Foo. Bar.
Foo. Bar.
Foo. Bar.
NaN. Bar.
NaN. Bar.
NaN. Bar.
with texinfo 5.1.dfsg.1-4 (I've removed the blank lines).
What are you reporting? The above looks correct to me; the previous
behavior (of preserving intersentence spacing in some
texi2html, which texinfo superseeds, allowed the rendering of @math
environments to images in HTML output. Please add similar functionality
to texinfo.
Is this planned
Well, Patrice and I haven't talked about that specifically. Patrice?
(We have had other discussions about
Hi Karl, hi all,
We need peb's input on this. I expect it can be done for TL'14.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
$ echo $LINES $COLUMNS
64 208
Start info with the make info file from make-doc 3.81-5.1:
$ info make
Enter these keystrokes:
i p TAB TAB
Result: segfault.
I can reproduce this, even without all the special compiler flags (-g only).
../../../binutils/doc/binutils.texi:4378: warning: @itemx should not
begin @table
../../../binutils/doc/binutils.texi:4386: @itemx must follow @item
It's a real error in the Texinfo, that unfortunately C makeinfo did not
diagnose. It needs to be reported to the binutils maintainers.
The following additional files are here:
uhvbrc8a.pfb
uhvboc8a.pfb
uhvrrc8a.pfb
uhvroc8a.pfb
Ok, I removed them. Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Frank and Saulo,
Thanks for the report.
1. I moved adjustbox to collection-latexextra.
2. Yes, in general, satisfying dependencies with the static collection-*
assignments we have is impossible, for a variety of reasons. This is
one reason why everything is installed by default (in the
Cross-manual links should work correctly in the next release of
makeinfo, and not depend on being in the same place. We've expended a
lot of effort on the problem. You can try the development version if
you like. I hope a first pretest will happen fairly soon.
Until then, what I have done is
FWIW, I agree with Norbert's analysis regarding cyrfonts and have
nothing to add ...
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Norbert,
to go to the Top dir file again showed nothing.
After removing the hardening flags it worked again, so I assume that is
is related to that. The way we are compiling is wiht
FYI: we are finally getting close enough to a texinfo pretest that I
tried your hardening recipe
Is there something that has been checked in *after 2012-05-16
r26437 | peter | 2012-05-16 09:44:41 +0200
shows kpse_cnf_get being re-exported. I see nothing in cnf.c now that
would stop the symbol from being exported.
Maybe you did your build just before that change? Don't know how else
I have no knowledge of what is in Debian where. Thanh sent me a change
that fixed it for him. I committed it some days ago, likely after May 16.
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
np somewhere between 20120410 and20120510 it seems that
cnf.h
is not installed anymore.
Peter changed kpathsea/Makefile.am not to install cnf.h and several
other .h's. I'm not sure why, or if he and I discussed it. Peter?
k
On Di, 15 Mai 2012, Michael Biebl wrote:
!pdfTeX error: pdflatex (file ./test.pdf): PDF inclusion: /Group
dict missing
== Fatal error occurred, no output PDF file produced!
Well, I'm glad it doesn't crash any more. I recall Thanh (or someone)
making fixes in this area.
As for the actual problem, I've forwarded it to
Isn't there any way to actually fix this bug and allow the coexistence
of scalable-cyrfonts-tex and texlive-fonts-extra?
The cyrfonts filenames would have to be changed. Whether doing that
would be worse than the current conflict is not my call.
Is there any alternative TeX font
A diff against the latest CVS version of the info directory is
attached.
I applied it. Thanks.
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
By the way, the package is already called ÂâÂÂucsÂâ in TeXLive.
I know :).
How can I change the package and directory name on CTAN?
In general, request the change of CTAN maintainers when you make the
upload, and they will discuss it with you. And yes, I would upload with
I wonder whether it is sensible to always call the package ucs
Please do. There are far too many gratuitious name differences already,
and ucs is at least a little more specific than unicode.
Thanks,
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Does anyone have an idea why this might happen?
Not out of my head. And Sergey's main server (gnu.org.ua) apparently
developed hardware woes, so I doubt he'll be able to answer anything
Texinfo-related quickly.
(I tried compiling current sources, but that didn't work out,
Sergey has
After some tests, I removed the popen/pclose declarations from
kpathsea/c-std.h. We'll see if problems arise on other systems.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
After some tests. I changed kpathsea/getopt.h to omit the declaration of
getopt when compiling under C++. We'll see if problems arise on other
systems.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi again Julian,
I wonder which library the getopt(_long) calls are
taken from - is it from the kpse library or the libc++ library? If
the prototypes are different, are the behaviours different as well?
If so, might it be wiser to rename the functions so that the behaviour
is
Hi Julian,
Perhaps the simplest solution is to rename the kpathsea
version as kpse_getopt
I don't think that's simple -- requires investigating/changing all uses
of getopt(_long) everywhere in the source. It would make sense in the
long term, but don't want to go there now, just for the
Hille,
Regarding the popen/pclose companion bug:
[2] http://bugs.debian.org/64524
I rather suspect they are declared in the headers of all systems on
which one would compile TL nowadays, so my first thought is simply to
remove those declarations altogether from c-std.h.
If someone would
Both header files are included by FileFinder.cpp (part of dvisvgm
[part of TL source code]) and g++ 4.7 refuses to compile the source
Sigh. Well, I suppose we can add !defined (__cpluscplus) easily enough.
If someone would like to send me a patch, that would be nice, else I'll
look at
Hi Norbert,
I think you missed one point ... thumbpdf didn't have real problems,
I was simply reacting to the error messages you reported, since I didn't
have anything else to go on.
I also have the feeling that it comes from the fact that texi2pdf
is run two times, and the second
So my question before uploading a fixed version is: based on his
reply, am I allowed to add his original PDF documentation to the
package?
Mojca, if you want to include the original PDF in the CTAN upload, feel
free to do so. Indeed, I think it makes some sense to do that. It is
Package thumbpdf Warning: Missing driver name.
I didn't look, but I doubt texi2dvi actually works with thumbpdf,
given the name. DVI ... PDF ... not the same thing :).
Package thumbpdf Warning: Compressed PDF objects of PDF 1.5 are not
supported.
Well, this seems clear enough.
Done that, see the diffstat at the head of the individual patches.
I installed it for dvips, with doc tweaks.
I await ChoF/et al. reply before doing *dvipdfmx.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
I attach the two patches, both apply (with some fuzzyness) to current
sources in TeX Live.
I agree with Peter. I installed the second patch.
Thanks, Mathias and all!
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Is there schedule for a new texinfo package?
No.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Akira,
I think there is no 2G limit for the output file in the
present dvips even in 32bit systems.
Right, as I already explained, there is no limit specifically in dvips.
I can only surmise that on w32 the compiler does 64-bit file stuff by
default. Unless you did a ton of 64-bit
dvips seems to have a size limit for output postscript files:
http://bugs.debian.org/383781 at least on 32bit systems. Is there any
chance to fix this?
Hi Hille -- the short answer is no (as far as I can tell).
Here's the long answer:
Despite your laudable attempts at recompiling
It is now on CTAN, hence I guess it will be in TL 2010, right?
Right.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Regarding
http://bugs.archlinux.org/task/20065?dev=1047
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501520
http://www.feferraz.net/en/P/Flashcards_in_LaTeX
Unfortunately Fernando's patch apparently no longer works with the
current geometry. I get:
./flashcards.cls:88: Package keyval
Well, I definitely do not want to add set -e to our fundamental scripts
a week before our final release. But if you want to add it for Debian,
I don't know of any specific reason not to. You can experience the
pain, or lack thereof.
As I've written before:
- I am not a fan of set -e in general,
Subject: Re: Bug#588378: texlive-latex-base-doc: oldgerm.sty documentation
missing
I asked RobinF about making oldgerm.pdf or if he'd rather we upload it.
(My experience is that he usually prefers to create it himself.)
k
--
To UNSUBSCRIBE, email to
Hi Vladimir,
You are surely right that other filename-related race conditions exist,
and that adding the pid to the temp file for fls is merely a palliative,
not a fix. However, since that's the case that was reported, and since
it was easy to do, it seemed worth doing. That's all.
Thanks,
I made the change below (this is web2c/lib/openclose.c), let me know if
problems. I hope compilers won't give any guff about the cast and sprintf.
k
--- openclose.c (revision 17609)
+++ openclose.c (working copy)
@@ -37,12 +37,19 @@
static void
recorder_start(void)
{
-/* Alas, while we
recorder_name = (string)xmalloc(strlen(kpse_program_name) + strlen(pid_str)
+ 5);
I knew I was forgetting something obvious. Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
but I wonder, why use intermediate file for recorder at all? Why not to
open $(jobname).fls in the first place?
Don't want to overwrite the file from a previous run, I suppose.
I'm not enthused about using mkstemp (and providing a fallback), but
perhaps we can add the pid to the temp
9 #ifdef KPATHSEA
10 #includekpathsea/c-auto.h
11 #includekpathsea/pathsearch.h
12 #includekpathsea/tex-file.h
13 #endif
In general, I think #include kpathsea/config.h must come first, and
should replace the #include
command is expected to create the file a.pdf, but the pdf is written
to stdout:
epstopdf --filter --outfile=a.pdf a.ps
Thanks for the report.
Want to try this version before I release it?
(It once again lets --outfile override --filter. I'll clarify the man
page, too.)
k
Hi Frank,
Is there a reason not to include this? It appears to me as if TeXLive
contains the contents of CTAN://fonts/urw/antiqua/uaq.zip,
Plus the contents of urw/antiqua, it looks like. More or less. Sort of.
not of CTAN://fonts/psfonts/urwvf/*.
Well, in theory we could
Unfortunately, the POT file is very out of date
(http://translationproject.org/POT-files/gnulib-1.0.0.1991.dbebf.pot
Gnulib folks -- perhaps we should set up a cron job to update it
monthly, or some such?
Unfortunately I don't know how the previous pot was generated. Maybe
a Makefile
First, I checked in the fix for pdfxmltex.ini.
(/home/norbert/tl/2009/texmf-dist/tex/context/base/supp-pdf.mkii
! You can't use `macro parameter character #' in horizontal mode.
l.82 \def\@@mptopdf@@twodigitrounding#
Is there any way to escape into TeX in an xmltex document?
I think it is a matter of time when somebody as for revtex4 class option
wrapper in order to use documents written using revtex4 package.
FYI, I suggested that to the APS as soon as I realized what had happened
with revtex4.1 (ie, that revtex4.cls had disappeared). They rejected
the
because etex is gone.
etex is not gone. That would be crazy. If you deleted it in Debian,
please undelete it.
- first the TEX seting in texmf.cnf should be changed,
I don't agree. As far as I can see, etex is exactly the right thing to
be using, and there is no alternative.
-
/home/hille/ptex-bin-3.1.10+0.04b/tetex-src-3.0/texk/web2c/ptex-src-3.1.10/tex2.c:3476:
undefined reference to `kpse_make_tex_discard_errors'
I speculate that a different (old) types.h is being read in the tex*.c
compilations, because otherwise the identifier
#6 0x7fffeac0c509 in kpse_fontmap_lookup () from
/usr/lib/libkpathsea.so.4
I feel completely brainless these days, but kpathsea/ChangeLog has this
entry:
2007-08-27 Karl Berry k...@tug.org
* fontmap.c (map_file_parse): free the original pointer, not the
potentially
xfrac.sty from collection-mathextra needs template.sty from
collection-latex3. I didn't test any other components of the mh package
(in which xfrac.sty is included).
It's up to you to decide whether it is possible to fix that by moving
around packages or letting mathextra
It's only present on Windows.
Not so. It is on all platforms now.
$ pwd
.../Master/bin
$ lsd */vlna*
-rwxr-xr-x 1 karl root 19776 Jun 30 10:26 alpha-linux/vlna
-rwxr-xr-x 1 karl root 11278 Aug 13 20:04 i386-cygwin/vlna.exe
-rwxr-xr-x 1 karl root 14268 Sep 12 2008 i386-freebsd/vlna
We either have to patch latex.ltx
No.
or patch the .ini files to contain scrollmode?
Yes. Go ahead and do it if you want, or wait for me if you have to :).
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
I attach the patch against current TeX Live's fmtutil in
Build/source/texk/tetex/fmtutil.
Looks fine to me. I applied it.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
1 - 100 of 221 matches
Mail list logo
