Re: 2.99.9: 3rd (and last?) release candidate

[Frank Küster]

Thomas Esser <[EMAIL PROTECTED]> schrieb:

> The same is true for "texconfig font ro/rw". I think that of
> all trees, it would only make sense to change the permissions of
> $TEXMFVAR/fonts/{source,pk,tfm}. By default, only the owner of these
> directories might write there, all other fonts go to $VARTEXFONTS.
> That should work for all/most people, that is why I have removed the
> relevant options from texconfig. What do other people think about this?

Debian doesn't care. We usually make the subdirectories of $VARTEXFONTS
word-writeable with the sticky bit set, and this is configurable through
a Debian-specific interface.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: 2.99.9: 3rd (and last?) release candidate

[Thomas Esser]

> Works on MacOS 10.3.7

Thanks.

> There are no more detailed instructions for generating fonts in
> batch job

Hm... I have put it back, thanks.

> and things like texconfig font ro (still there?) in
> tetex-src/INSTALL. Is this intended?

That (currently) does not exist in texconfig. I might still put it back.
Currently, there is a default of /var/tmp/texfonts which should always
be writable by everyone (even if it does not exist, /var/tmp should be
writable by everyone), so the current (default) situation is as follows:

  if ($TEXMFVAR/fonts is writable)
use $TEXMFVAR/fonts
  else
if ($VARTEXFONTS is writable or can be created)
  use $VARTEXFONTS
else
  use the current directory

By setting the varfonts feature (only "by hand" at the moment) in
mktex.cnf, $TEXMFVAR/fonts is no longer considered, so only $VARTEXFONTS
is checked/used.

I don't know is setting/unsetting these MT_FEATURES in mktex.cnf is still
needed. Comments?

The same is true for "texconfig font ro/rw". I think that of
all trees, it would only make sense to change the permissions of
$TEXMFVAR/fonts/{source,pk,tfm}. By default, only the owner of these
directories might write there, all other fonts go to $VARTEXFONTS.
That should work for all/most people, that is why I have removed the
relevant options from texconfig. What do other people think about this?

> At the moment I just set up a vardir for fonts with general write
> permissions after editing tetex-src/texk/kpathsea/texmf.in
> accordingly and it seems to work.

Right, that's how it is supposed to work. If you don't change anything,
/var/tmp/texfonts would be created (world writable) on the first use
(i.e. the first file which cannot be installed in $TEXMFVAR/fonts.

Thomas

Re: 2.99.9: 3rd (and last?) release candidate

[Christian Ebert]

* Thomas Esser on Tue, Jan 11, 2005:
> This 2.99.9 is the third (and hopefully last) release candidate of
> teTeX-3.0. "texconfig hyphen" is now back...
> 
> As usual: please, send me feedback, even if it all just works :-)

Works on MacOS 10.3.7

There are no more detailed instructions for generating fonts in
batch job and things like texconfig font ro (still there?) in
tetex-src/INSTALL. Is this intended?

At the moment I just set up a vardir for fonts with general write
permissions after editing tetex-src/texk/kpathsea/texmf.in
accordingly and it seems to work.

c
-- 
   --->> 

Re: 2.99.9: 3rd (and last?) release candidate

[Benedikt Birkenbach]

Hi there,
Compiled fine under SGI's IRIX6.5 (with the problems hint) and under 
Solaris 6 (CC 5.5 ) with one small Problem:

/opt/SUNWspro/bin/cc -o xdvi-motif.bin browser.o dvi-draw.o dvi-init.o 
dvisel.o encodings.o events.o filehist.o font-open.o gf.o hypertex.o 
image-magick.o mime.o my-snprintf.o my-vsnprintf.o pagehist.o pk.o 
print-internal.o psdps.o psgs.o psheader.o psnews.o read-mapfile.o 
search-internal.o special.o string-utils.o tfmload.o util.o vf.o xdvi.o 
xserver-info.o x_util.o  ./gui/libgui.a ../../libs/t1lib/libt1.a 
../../libs/t1lib/../type1/libtype1.a -L/usr/openwin/lib -lXm -lXmu -lXt 
-lSM -lICE -lXext -lX11 -lsocket -lnsl

>>> /vol/gnu/lib/.libs/libiconv.so  <
 ../kpathsea/.libs/libkpathsea.a -lm -R/vol/gnu/lib/.libs 
-R/vol/gnu/lib -R/usr/openwin/lib

The marked library does not exist, because the directory doesn't, I 
don't know why make trys to find it in /vol/gnu/lib/.libs . The library 
is in /vol/gnu/lib ..

But I just fixed it by running the command by hand with the right path...
Benedikt

As usual: please, send me feedback, even if it all just works :-)


--
       _  
/ __ \/ __ \|__  || |/ /  Benedikt Birkenbach |
|  __/|  __/  / / |   /   RRZK/ZAIK der Universitaet zu Koeln |
| | \ | | \  / /_ |   \   |
|_|\_\|_|\_\|||_|\_\  http://www.uni-koeln.de/RRZK/   |
__/

Re: 2.99.9: 3rd (and last?) release candidate

[Thomas Esser]

> This is why dvipng.h does not read stdint.h. Am I wrong in following
> this advice?

No, it seems just right not to include stdint.h in dvipng.h. On the
other hand, I wonder why stdint.h should be included in the autoconf
test... That seems wrong to me.

> (Actually, the dvipng distribution uses autoconf 2.5x,
> but tetex does not. And I don't suppose Thomas wants to change this
> close to release.)

Right, I am not going to change this now.

Thomas

Re: 2.99.9: 3rd (and last?) release candidate

[Jan-Ake Larsson]

Thomas Esser wrote:
> > In newer versions of autoconf - the following is added:
> > 
> > #if HAVE_INTTYPES_H
> > # include 
> > #else
> > # if HAVE_STDINT_H
> > #  include 
> > # endif
> > #endif
> 
> Thanks for your analysis and your suggested fix.
> 
> The problem with the suggested fix, however, is that dvipng.h does not
> read stdint.h. So, I'd prefer just to have that additional inttypes.h
> in the check, to bring it in sync with dvipng.h.
> 
> Thomas

I might add the following (from the autoconf 2.59 manual):

---8<---
Portability of Headers
--

<...>

`inttypes.h' vs. `stdint.h'
 Paul Eggert notes that: ISO C 1999 says that `inttypes.h'
 includes `stdint.h', so there's no need to include `stdint.h'
 separately in a standard environment. Many implementations have
 `inttypes.h' but not `stdint.h' (e.g., Solaris 7), but I don't
 know of any implementation that has `stdint.h' but not
 `inttypes.h'. Nor do I know of any free software that includes
 `stdint.h'; `stdint.h' seems to be a creation of the committee.
8<--

This is why dvipng.h does not read stdint.h. Am I wrong in following
this advice? (Actually, the dvipng distribution uses autoconf 2.5x,
but tetex does not. And I don't suppose Thomas wants to change this
close to release.)

/JÅ


-- 
[ This .signature intentionally left blank ]

Re: 2.99.9: 3rd (and last?) release candidate

[Thomas Esser]

> In newer versions of autoconf - the following is added:
> 
> #if HAVE_INTTYPES_H
> # include 
> #else
> # if HAVE_STDINT_H
> #  include 
> # endif
> #endif

Thanks for your analysis and your suggested fix.

The problem with the suggested fix, however, is that dvipng.h does not
read stdint.h. So, I'd prefer just to have that additional inttypes.h
in the check, to bring it in sync with dvipng.h.

Thomas

Re: 2.99.9: 3rd (and last?) release candidate

[Helmut Jarausch]

Hi,

something must have changed in the very recent
release candidates.
My old recipe to add my own format files doesn't work
anymore.
Here's what I am doing

I have appended lines like
ETeXpdfetex language.def-translate-file=cp227.tcx 
*ETeX.ini

to fmtutil.cnf

and I have created corresponding ETeX.ini files
in share/texmf/tex/plain/config

now fmtutil --missing
does not create the new (missing) formats
anymore.
But if I cd to share/texmf/web2c
and do
pdfetex -ini -jobname=ETeX '*ETeX.ini'

the format gets created.

What am I missing?

Many thanks for a hint,

Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: 2.99.9: 3rd (and last?) release candidate

[ezra peisach]

I decided to test out the snapshots of GCC 4 that are available to see if 
tetex would compile... There is one failure in dvipng - and it stems from the
use of autoconf-2.13 that is used in the tree..

It appears in the dvipng directory, there is a shipped
configure.ac.orig - which is probably from the dvipng maintainers and
an configure.in - that looks like one writtern for tetex.

The failure is in the test for uint64_t. AC_CHECK_TYPE is used. In autoconf 
2.13 this essentially does includes

#if STDC_HEADERS
#include 
#include 
#endif

In newer versions of autoconf - the following is added:

#if HAVE_INTTYPES_H
# include 
#else
# if HAVE_STDINT_H
#  include 
# endif
#endif

So under linux, in which inttypes.h is present, the inttypes.h file is
not included by configure to test if uint64_t is defined... So a
define is placed in dvipng.h... This define then causes a conflict
when inttypes.h is included and we get a line that reads a "long long
long" GCC 4.0 complains that it cannot honor this width and errors out...

So, my fix is to configure.in... Instead of using AC_CHECK_TYPE, I
have written MY_CHECK_TYPE which is identical to the autoconf 2.13
code - with the extra includes added in...  With this change, tetex compiles
and runs under linux with GCC 4.0.


*** configure.in2005/01/12 15:20:40 1.1
--- configure.in2005/01/12 15:32:17
***
*** 7,12 
--- 7,39 
  AC_DEFINE(PACKAGE_VERSION, ["1.4"])
  AC_DEFINE(PACKAGE_STRING, ["dvipng 1.4"])
  
+ # We need a special form of AC_CHECK_TYPE that will include inttypes.h if
+ # present.  This is done in newer acutoconfs.
+ AC_DEFUN(MY_CHECK_TYPE,
+ [AC_REQUIRE([AC_HEADER_STDC])dnl
+ AC_MSG_CHECKING(for $1)
+ AC_CACHE_VAL(ac_cv_type_$1,
+ [AC_EGREP_CPP(dnl
+ changequote(<<,>>)dnl
+ <<(^|[^a-zA-Z_0-9])$1[^a-zA-Z_0-9]>>dnl
+ changequote([,]), [#include 
+ #if STDC_HEADERS
+ #include 
+ #include 
+ #endif
+ #if HAVE_INTTYPES_H
+ # include 
+ #else
+ # if HAVE_STDINT_H
+ #  include 
+ # endif
+ #endif], ac_cv_type_$1=yes, ac_cv_type_$1=no)])dnl
+ AC_MSG_RESULT($ac_cv_type_$1)
+ if test $ac_cv_type_$1 = no; then
+   AC_DEFINE($1, $2)
+ fi
+ ])
+ dnl
  # Checks for programs.
  AC_SET_MAKE
  AC_PROG_CC
***
*** 41,49 
# is present in most modern compilers. Using a #define rather than a
# typedef can be a problem, but in dvipng int64_t only is used as
# typecast, and there are no problems.
! 
!   AC_CHECK_TYPE(int64_t, long long)
!   AC_CHECK_TYPE(uint64_t, unsigned long long)
  fi
  
  # Checks for library functions.
--- 68,77 
# is present in most modern compilers. Using a #define rather than a
# typedef can be a problem, but in dvipng int64_t only is used as
# typecast, and there are no problems.
!   # Note... AC_CHECK_TYPE in autoconf does not include inttypes_h if present.
!   # This is present in newer versions of autoconf, so we use our own macro
!   MY_CHECK_TYPE(int64_t, long long)
!   MY_CHECK_TYPE(uint64_t, unsigned long long)
  fi
  
  # Checks for library functions.

Re: 2.99.9: 3rd (and last?) release candidate

[Thomas Esser]

Hi Willi,

> everything works ok on Sparc Solaris 9 (Sun C 5.5)

Thanks for the quick response.

> P.S. what about creating an empty 'texmf-local' during install
>  just to make clear it's the default place for local addons

That's not straight forward to do (the user might have changed the setting
in texk/kpathsea/texmf.in). I have mentioned TEXMFLOCAL in INSTALL and
TETEXDOC (section 2.2), so that should be enough... And TEXMFLOCAL is
not even a new feature in 3.0 (that concept already exists in teTeX-2).

Thomas

Re: 2.99.9: 3rd (and last?) release candidate

[Willi Burmeister]

Hi Thomas,

> This 2.99.9 is the third (and hopefully last) release candidate of
> teTeX-3.0. "texconfig hyphen" is now back...
> 
> As usual: please, send me feedback, even if it all just works :-)

everything works ok on Sparc Solaris 9 (Sun C 5.5)

Willi

P.S. what about creating an empty 'texmf-local' during install
 just to make clear it's the default place for local addons

Re: 2.99.9: 3rd (and last?) release candidate

[Frank Küster]

Thomas Esser <[EMAIL PROTECTED]> schrieb:

> This 2.99.9 is the third (and hopefully last) release candidate of
> teTeX-3.0. "texconfig hyphen" is now back...
>
> As usual: please, send me feedback, even if it all just works :-)
>
> Files (to appear soon):
>   
> ftp://cam.ctan.org/tex-archive/systems/unix/teTeX-beta/tetex-src-2.99.9.20050111-beta.tar.gz

It seems you only uploaded the md5sum files - I cannot find the tar.gz's
themselves, and the symlinks still point to 2.99.8

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: 2.99.9: 3rd (and last?) release candidate

[Thomas Esser]

> > Files (to appear soon):
> >   
> > ftp://cam.ctan.org/tex-archive/systems/unix/teTeX-beta/tetex-src-2.99.9.20050111-beta.tar.gz
> 
> It seems you only uploaded the md5sum files - I cannot find the tar.gz's
> themselves, and the symlinks still point to 2.99.8

I have put the files to a local machine from which the CTAN machines
will pick up the files. Just wait...

Thomas