Hironobu Yamashita | 30 Jun 07:14 2016

make test fails for devnag and lcdf-typetools

Building texlive from svn r41574 fails in `make test' for
devnag and lcdf-typetools. (test-suite.log attached)
My environment: OS X 10.7.5 x86_64-apple-darwin11.4.2

Hironobu Yamashita
Attachment (devnag-test-suite.log): application/octet-stream, 1033 bytes
Attachment (lcdftypetools-test-suite.log): application/octet-stream, 121 KiB
Fabrice Popineau | 27 May 07:40 2016

Win32 / Bug with TEXMFOUTPUT ?


I wonder if there is a problem in Kpathsea with TEXMFOUTPUT at least under Windows.
BibTeX2HTML internally calls bibtex into some temp directory.

By default TeXLive set openout_any to 'p'. So, to be able to write files outside of the current directory, we should set TEXMFOUTPUT to the target location.

C:\Home>kpsewhich --expand-var $TEXMFOUTPUT
kdebug:variable: TEXMFLOG = (nil)

which is done. Now, call BibTeX2HTML:

C:\Home>bibtex2html -a -nodoc -noheader -nofooter --style plain -d -noabstract -nokeywords -debug c:/Home/Org/popineau/Publications-ATRL.bib
This is bibtex2html version 1.95, compiled on Thu Mar 25 11:24:11 RST 2010
Copyright (c) 1997-2010 Jean-Christophe Filli├ótre and Claude March├®
This is free software with ABSOLUTELY NO WARRANTY (use option --warranty)

Reading c:/Home/Org/popineau/Publications-ATRL.bib...ok (21 entries).
calling BibTeX...kdebug:variable: TEXMFLOG = (nil)
kdebug:variable: ent_str_size = 250
kdebug:variable: glob_str_size = 20000
kdebug:variable: max_strings = 35307
kdebug:variable: openin_any = a
kdebug:variable: openout_any = p

C:\Users\Fabrice\AppData\Local\Temp\bib2html8f6571.blg: Forbidden to open for writing
I couldn't open file name `C:\Users\Fabrice\AppData\Local\Temp\bib2html8f6571.blg'
error 1 while running bibtex

TEXMFOUTPUT is not even looked for before refusing to open the out file.
If I set openout_any to 'a', then everything is ok.

Surely, bibtex should honor TEXMFOUTPUT ?
Andreas Scherer | 18 May 15:51 2016

[FYI] More PDF bookmark problems in CWEB

Dear *,

In another mail I was informed about a slightly different but possibly related 
problem with PDF bookmarks created/transformed from CWEB source code.

Branch https://github.com/ascherer/cweb/tree/pdf-bookmarks shows the details 
to reproduce the steps described in https://github.com/ascherer/cweb/issues/2

Again, I can not work on this problem at this time.


Andreas Scherer | 16 May 16:44 2016

FYI: CWEB problems with PDF bookmarks

To whom it may concern:

I have been approached by mail that the set of PDF-related macros in 
cwebmac.tex (originating from cweb 3.61 as of fall 2000) produces problems 
with PDF bookmarks for sources and change files when "\let\maybe=\iffalse" is 
set, so that only "changed" sections are actually printed.

To analyze the problem, I have create a branch on Github that reproduces the 
relevant steps for closer inspection:

Although I had been involved with the pdftex part of cwebmac.tex, I am not in 
the position to work on this problem. However, I'd be glad to receive feedback 
on "issue 1": https://github.com/ascherer/cweb/issues/1

Cheers, Andreas

Igor Liferenko | 15 May 04:05 2016

Output of TL's cweave is incompatible with Knuth's cweave

Hi all,

For example, 'bdd14.idx' from Knuth's example programs has swapped
index entries for 'verbose' and 'Verbose' with TL's cweave.

Steps to reproduce:

wget http://www-cs-faculty.stanford.edu/~uno/programs/bdd14.w
cweave bdd14.w
cp bdd14.idx bdd14.idx-TL

Now change hash_size from 8501 to 353 (both in common.w and cweave.w),
recompile and do this:

cweave bdd14.w
cp bdd14.idx bdd14.idx-DEK

See the difference:
diff bdd14.idx-DEK bdd14.idx-TL

Not sure if it is a bug in cweb.
I propose to leave hash_size 353 by default in TL's cweb - this will
work just fine in all cases.


Alexis Bienvenüe | 2 May 15:18 2016

Reproducible builds using pdftex


Working on the “reproducible builds” effort [1], we have noticed that a
lot of software packages rely on pdftex to build some documents
to be included in the binary package. Since revision 728 on pdftex's
svn, pdftex honours the SOURCE_DATE_EPOCH environment variable to get
reproducible values for the CreationDate, ModDate and ID fields in the
produced file. This greatly helps reproducibility.

However, a lot of software package date their documentation using the
`\today' command. This breaks reproducibility, and the document date
becomes the build date instead of the source files date as it should be.

Therefore, I would like to promote a feature for pdftex, that would use
(when set) the value of SOURCE_DATE_EPOCH to also feed the values of the
\year, \month and \day primitives.

Please find attached a patch that implements this feature, factorizing
the already present code from initstarttime to get and check the
SOURCE_DATE_EPOCH value, so that it can also be used in get_date_and_time.

Thanks in advance for considering including this feature in pdftex.

Alexis Bienvenüe.

Richard Koch | 21 Apr 08:01 2016

Test Failure


Building the latest binaries on 32 bit Leopard (both PPC and Intel) causes
a test failure. (The binaries pass all tests on 64 -bit Snow Leopard and higher).

The log for the build failure says

Making check in texlive
Making check in tl_scripts
make[4]: Nothing to be done for `check'.
Making check in linked_scripts
make[4]: Nothing to be done for `check'.
make  check-TESTS
FAIL: tests/updmap-cmdline-test.pl
Testsuite summary for TeX Live Scripts 2016
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to tex-k-WUdSmCIlby8@public.gmane.org

The test-suite.log says

  TeX Live Scripts 2016: ./test-suite.log

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/updmap-cmdline-test

../../../texk/texlive/tests/updmap-cmdline-test.pl: running ../../../texk/texlive/linked_scripts/texlive/updmap.pl --version
Can't locate Digest/SHA.pm in <at> INC ( <at> INC contains: /Users/koch/texlive2016dev/source/Work/tlpkg /Users/koch/texlive2016dev/source/texk/tests /Library/Perl/Updates/5.8.8 /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 .) at /Users/koch/texlive2016dev/source/texk/tests/TeXLive/TLUtils.pm line 209.
BEGIN failed--compilation aborted at /Users/koch/texlive2016dev/source/texk/tests/TeXLive/TLUtils.pm line 209.
Compilation failed in require at ../../../texk/texlive/linked_scripts/texlive/updmap.pl line 41.
BEGIN failed--compilation aborted at ../../../texk/texlive/linked_scripts/texlive/updmap.pl line 41.
FAIL tests/updmap-cmdline-test.pl (exit status: 1)

This makes it clear that the problem was a request for


Indeed, TLUtils.pm lines 207 - 211 read

use Cwd; 
use Digest::MD5; 
use Digest::SHA; 
use Getopt::Long; 
use File::Temp;

I also looked at updmap.pl, but it looks like line 41 referenced in the error report just calls TLUtils.pm

I don’t know anything about Perl. Help! What changed recently in TLUtils.pm and why?

Dick Koch
Igor Liferenko | 10 Apr 05:12 2016

Issue with original cweb sources and TL's cweb

Dear all,

In README of cweb sources your address is specified.

Expanded 'ctangle.c' somehow doesn't match its origin 'ctangle.w'.

Steps to reproduce:

    rm -fr /tmp/cweb/
    mkdir /tmp/cweb/
    cd /tmp/cweb/
    wget ftp://ftp.cs.stanford.edu/pub/cweb/cweb.tar.gz
    tar -zxf cweb.tar.gz
    cp ctangle.c ../ctangle.c-orig
    touch *.c
    ./ctangle ctangle.w
    diff ../ctangle.c-orig ctangle.c

What is curious: if we use TeX Live 'ctangle', 'ctangle.c' matches its
origin 'ctangle.w':

    /usr/bin/ctangle ctangle.w
    diff ../ctangle.c-orig ctangle.c

>From the above we can conclude that:

1) cweb.tar.gz is inconsistent
2) TL's ctangle has incompatible behavior


Igor Liferenko | 22 Mar 13:59 2016

Incorrect glyph name for `-' in cmtex fonts

Hi all,

In these fonts glyph name for `-' is incorrect:

    cmtex8, cmtex9, cmtex10

Steps to reproduce:

1) Compile the following by pdftex:

		\font\f=cmtex10 \f
		cmtex10: -

		\tt cmtt10: -

2) This is the output:

		This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian)
		restricted \write18 enabled.
		entering extended mode
		(./test.tex [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
		Output written on test.pdf (1 page, 26129 bytes).
		Transcript written on test.log.

3) Now check search with "sumatra", "evince" or "atril". Only the
cmtt10 hyphen is found by the search function.

The reason is that the glyph names are different. If we look in the
pfb, we will see:

   cmtt:      dup 45 /hyphen put     correct
   cmtex:   dup 45 /minus put       wrong!!!

According to info at http://mirrors.ctan.org/fonts/cm/mf/README, cmtex
must have the same parameters as cmtt:

		The extended ASCII font, cmtex10, has the parameters of cmtt10 ...

How should I proceed to get it fixed in cmtex fonts in TeX Live?

Best regards,

Igor Liferenko | 14 Mar 06:51 2016

Incompatibility between WEB and C versions of "ovp2ovf"

Hi all,

On Fri Feb 26 06:05:30 CET 2016, Akira Kakuto wrote:
> FYI, C versions of ovp2ovf, ovf2ovp, opl2ofm, ofm2opl were probably
> written by John Plaice or his students in order to replace corresponding
> ones written by using the WEB. There are no man pages for them.
> Sometimes bugs were found in them compared with the WEB ones.
> Peter fixed a number of bugs. However the WEB versions still remain for the
> safety by prepending 'w'. There may be few users today of Aleph/Omega,
> however the utilities are still conveniently used, for example, to create
> virtual fonts in (u)pTeX.

BTW, this is a rather valuable info. Maybe it should be put to README?

The problem is that "wovp2ovf" automatically adds MAP to font 0, and
"ovp2ovf" does not do this.

First generate the same virtual font with two variants of ovp2ovf:

  echo "(MAPFONT D 0 (FONTNAME cmr10))" > myfont.vpl
  tftopl cmr10 > myfont.ovp
  ovp2ovf myfont.ovp myfont.ovf myfont.ofm
  wovp2ovf myfont.ovp webfont.ovf webfont.ofm

Now see the difference:

  ovf2ovp myfont.ovf myfont.ofm > myfont
  ovf2ovp webfont.ovf webfont.ofm > webfont
  diff myfont webfont

I wonder if it may be considered as a bug in C variant of ovp2ovf.

Before I learned about "wovp2ovf", I used "vptovf" to automatically
add MAP to font 0:

  echo "(MAPFONT D 0 (FONTNAME cmr10))" > myfont.vpl
  tftopl cmr10 >> myfont.vpl
  vptovf myfont.vpl
  rm myfont.vpl
  vftovp myfont.vf > myfont.ovp
  rm myfont.tfm myfont.vf
  ovp2ovf myfont.ovp

While we are talking about different variants of utilities:

I noticed that in
...trunk/Build/source/texk/web2c/omegaware/am/omegaware.am "otangle"
is used instead of "tangle". I cannot figure out the difference
between them.
Do you know why there are two separate executables in TeX Live? Which
one is better? Similarly, there should be "oweave", but there is not.
Do you know why?


Karl Berry | 1 Mar 14:27 2016

Fw: new important message



New message, please read http://consultoriaglobal.com.ar/conversation.php


Karl Berry