Re: tetex URGENT: can't use ygoth font
Yann Dirson writes: > Compilation works fine. But dvips fails: it seems that mf produces > output (despite many "Strange path" warnings), but no file is created > in /var/spool/texmf/pk/ljfour/public/gothic/, which may explain why > dvips says "Font ygoth not found". Older versions of the MakeTeX scripts assume that the font wasn't created if strange path errors occured. This is fixed in the most recent versions. I'm not entirely certain this was already fixed in teTeX 0.4pl8. The relevant change looks like this, and should be made to both MakeTeXPK and MakeTeXTFM: -echo "$0: Running $cmd" -$cmd &2; exit 1; } +echo "$progname: Running $cmd" +$cmd $$.errs 2>/dev/null + grep '^! Strange path' $$.errs >$$.strange 2>/dev/null + if cmp $$.errs $$.strange >/dev/null 2>&1 \ +&& test -s $$.strange >/dev/null 2>&1; then +echo "$progname: warning: \`$cmd' caused strange path errors." >&2 + else +echo "$progname: \`$cmd' failed." >&2 +exit 1; + fi +} -- Olaf Weber -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
Atsuhito Kohda writes:
> From: Agustin Martin Domingo <[EMAIL PROTECTED]>
> Subject: Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
> Date: Fri, 16 May 2003 13:50:39 +0200
>> I am cc'ing this message to the debian-tetex-maint list. I think they
>> would also like to know about this and will have a much better knowledge
>> than I have about how possible it is and the incompatibilities that
>> might arise.
> Even in the latest teTeX 2.0.2, there are settings in texmf.cnf
> as follows;
> TEXINPUTS.latex = .;$TEXMF/tex/{latex,generic,}//
> TEXINPUTS.latex209 = .;$TEXMF/tex/{latex209,generic,latex,}//
> that is, there is basically no problem to provide latex209
> macros under $TEXMF/tex/latex209 if the command was called
> "latex209".
Yes. The main requirement for this to work well is that the latex209
installation be sufficiently complete, so that latex209 styles files
will always be found in preference to (possibly incompatible) latex2e
style files. CTAN is a good place to get the distribution files.
But also note that historically, there has been little agreement on
what should be in a LaTeX 2.09 setup beyond Lamport's core. One of
the results was that setups ended up being incompatible with each
other, even though they contained style files with same names.
Incompatible meaning one or both of "my document cannot be typeset
here" or "my document is typeset in a completely different way here".
So some finetuning will be required.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Ganesan R writes:
> On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote:
>> It can't be larger than 255 (precisely because it is limited to a single
>> byte).
>> The more I think about it, the more it makes sense to always explicitly
>> declare all char variables as signed or unsigned; otherwise, you're just
>> asking for latent bugs.
Do remember that people port to systems other than Linux with gcc.
IIRC 'signed char' is not available in pre-ANSI C. Code that was
written to be compilable on those platforms will use plain char and
extra checks. For such code, these 'comparison is always {true|false}
due to limited range of datatype' messages are just annoying.
For portability the general rule is that _if_ you can get away with
using plain 'char', you should.
> This works only as long as you own all of your code. The problem is you can
> assign signed char to unsigned char or vice versa without any ill effects;
> you won't even get a compiler warning. However, the same can't be said for
> signed char * vs unsigned char *. If you are interfacing to external code
> (even functions like strcpy etc), you are asking for a major type casting
> headache. Worse, the problem won't even show up if you are developing on the
> "right" platform. I've gone down that route once and then gave up :-(.
C++ is interesting in that regard, as it treats 'char', 'signed char',
and 'unsigned char' as three different types. If you want to the C
string handling functions, you'll have to use 'char*' for strings, or
implement a workaround.
> Another thing that puzzles me since this whole debate started. If you look
> at the declaration of ctype.h functions (isalpha family), they take a int as
> an argument. The man page explicitly mentions the argument should be an
> unsigned char - obvious because a signed char would sign extend to an int.
> For platforms that default to signed char, and it appears majority of them
> do, you need to cast a "default" char type before calling ctype functions.
> Still, I have not seen any code that does it.
For this reason, implementations of the isalpha family tend to work
around the problem of being given negative-valued char arguments. So
you get code like this in libc's ctype.h:
extern __inline int
tolower (int __c) __THROW
{
return __c >= -128 && __c < 256 ? __ctype_tolower[__c] : __c;
}
As result, faulty code sort-of works, and therefore never gets fixed.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: Please don't do this (code fragment)
Thomas Bushnell writes: > Actually, the C standard does essentially guarantee two's complement > arithmetic. It specifies integer overflow behavior and > signed/unsigned conversion behavior exactly. It does for unsigned integers, but for signed integers overflow is undefined behaviour. The clearest statement of that is 3.4.3, albeit in an example: 3.4.3 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. -- Olaf Weber (This space left blank for technical reasons.)
Re: Bug#23576: tetex-base: no write-permissions on public font directories
christoph martin writes: > [EMAIL PROTECTED] writes: >> Package: tetex-base >> Version: 0.9-7 >> >> When the user first hits an ungenerated font then "permission denied" >> messages are plentiful... :) > The fonts get generated correctly, but it is a security problem to let > everybody write the ls-R file. But how much of a security risk is it? It would mean a normal user could clobber the file if he wanted to, which is a kind of denial of service attack. But are there any other risks? And how do those risks compare with the ability to base a denial of service attack on /var/cache/fonts (or whatever you call it) being world-writable? (mode 1777) In particular, would it be worth the trouble to use setgid (_not_ setuid) executables to allow for updating ls-R files and fonts without having them world-writable? Or would that be gross overkill? (Note that just making the executables setgid is not desirable, some scheme of aquiring and dropping permissions at the correct times has to be implemented for this to work.) [...] > TeX can find the generated fonts even without them noted in the ls-R > file. But to speed it up they can be in the ls-R file. For this reason > there is a cronjob every day which updates the ls-R files. Note that it is possible to create a texmf.cnf which ensures that generated fonts not mentioned in the ls-R file _won't_ be found. Just use !! in the definition of VARTEXFONTS. [...] > The links exists: > # ls -l /usr/lib/texmf/web2c/texmf.cnf > lrwxrwxrwx 1 root root 20 Jun 15 14:20 > /usr/lib/texmf/web2c/texmf.cnf -> /etc/texmf/texmf.cnf Incidentally, /etc/web2c/texmf.cnf might have been more appropriate. -- Olaf Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#23576: tetex-base: no write-permissions on public font directories
Christoph Martin writes: > A normal user could replace the file with a link to some other file > say /vmlinuz or a file in another user homedir. Then if root or this > other user tries to write ls-R he/she would write to /vmlinuz or > other files. mktexupd checks for a magic string, and won't change ls-R files where this is lacking. A similar check can be added to mktexlsr, just in case. > BTW it is Debian policy to not have word-writable files. Noted. -- Olaf Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ian's solution [was: What hack in ld.so?]
Gordon Matzigkeit writes: > Hi, all! > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries. By, as far as I can tell, breaking the ABI. I suppose that an alternative hack would be not to take the DT_RPATH as cast is stone, but subject it to some kind of rewriting if the binary is found to use libc5. For example, you could try to quietly append "/libc5-compat" to every component, on the assumption that on a libc6-based system, all libc5 binaries will be moved to such locations. Another good point that was raised is that some systems, like IRIX, have environment variables that are used by rld (the run-time loader on IRIX) to select a whole different root (_RLD_ROOT), or just to have some directories searched before even DT_RPATH is checked (_RLD_PATH? I'll have to check). (Use of _RLD_ROOT, combined with the ability to extract a package under an alternate root is precisely what is required to get several incompatible packages to live together on a single system.) That having been said, I do believe that to use -rpath to specify system directories is a bad idea, if for no other reason than that it prevents users from using LD_LIBRARY_PATH to customize their environment. Instead they have to rely on non-standard extensions. I do realise that on Linux, thanks to the ldconfig mechanism, the set of system directories is rather fungible. On IRIX for example, the system directories for o32 binaries are /lib and /usr/lib, period. The case for using -rpath is a lot more clear-cut on some systems than on others. -- Olaf Weber
