ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* ConTeXt on Debian: The wiki entry
@ 2006-10-23  8:35 Frank Küster
  2006-10-23 10:25 ` Renaud AUBIN
                   ` (3 more replies)
  0 siblings, 4 replies; 24+ messages in thread
From: Frank Küster @ 2006-10-23  8:35 UTC (permalink / raw)


Hi everybody,

this mail has a double purpose.  At the end, there's a call for testers
of a new (planned) Debian ConTeXt package that would be updated more
frequently than now (at least in unstable and testing), where ConTeXt is
tied to teTeX's or TeXlive's release cycles.  But first, I'd like to
talk about 

http://wiki.contextgarden.net/Debian_installation

Are some of the people around who wrote this?  I found some information
in it misleading and in part just wrong (this has already been pointed
out two weaks ago by "plink"), and have started to edit the page to
change the parts that give us, the Debian TeX maintaines, most
headache.  But in the lower part, "Steps to finish a first context
upgrade", I felt lost.  If these steps are really needed, then there's
something seriously wrong in Debian's (and probably upstream's)
packaging of ConTeXt.  Therefore I didn't just change the text to
reflect how I think it should work.  Instead, we should try to figure
out together whether it in fact does not work as it should, and then fix
the Debian packages (hopefully still possible for etch).

So the specific question I have are:

- Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
  If yes, why is that so?  If not, we should rather find out why it
  happens and fix it.

- Why does it make a difference if the formats are created by fmtutil
  instead of texexec (Except for the output directory)?  Should the
  upstream packaging be changed so that fmtutil is never used, but
  texexec, or should fmtutil be fixed to produce the same as texexec?  



Finally, here comes Norbert Preining's Call for Testers:

Dear all!

We = Debian TeX maintainers searching for users of the Debian Operating
Systems which are also using ConTeXt.

Currently Debian etch (testing) and sid (unstable) contains packages for
TeX live 2005. But this contains a bit old ConTeXt version, so users are
asking us to update ConTeXt.

We have prepared a updated ConTeXt package for Debian, based on the
latest released version (2006.08.08), and would ask you to help use
testing, as we are not experienced in ConTeXt type settings. I checked
some simple documents from the ConTeXt Garden, and they worked, but more
detailed testing would be nice.

If you have interest, please contact us at
	debian-tex-maint@lists.debian.org
or, if you have a bit experience, you can straight away add
	deb http://www.tug.org/texlive/Debian/ context/
to your /etc/apt/sources.list file and install context. After this,
please tell us our experiences/failures/suggestions.

Thanks a lot and all the best


Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23  8:35 ConTeXt on Debian: The wiki entry Frank Küster
@ 2006-10-23 10:25 ` Renaud AUBIN
  2006-10-23 10:58 ` Taco Hoekwater
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 24+ messages in thread
From: Renaud AUBIN @ 2006-10-23 10:25 UTC (permalink / raw)


Hi Frank,

A ConTeXt's package for debian will be great !

Frank Küster a écrit :

>Hi everybody,
>
>this mail has a double purpose.  At the end, there's a call for testers
>of a new (planned) Debian ConTeXt package that would be updated more
>frequently than now (at least in unstable and testing), where ConTeXt is
>tied to teTeX's or TeXlive's release cycles.  But first, I'd like to
>talk about 
>
>http://wiki.contextgarden.net/Debian_installation
>
>Are some of the people around who wrote this?  I found some information
>in it misleading and in part just wrong (this has already been pointed
>out two weaks ago by "plink"), and have started to edit the page to
>change the parts that give us, the Debian TeX maintaines, most
>headache.  But in the lower part, "Steps to finish a first context
>upgrade", I felt lost.  If these steps are really needed, then there's
>something seriously wrong in Debian's (and probably upstream's)
>packaging of ConTeXt.  Therefore I didn't just change the text to
>reflect how I think it should work.  Instead, we should try to figure
>out together whether it in fact does not work as it should, and then fix
>the Debian packages (hopefully still possible for etch).
>
>  
>
My contributions was to copy "Install a Metapost update" and "Install a
pdfTeX update" from tetex 3.0 Install to Debian Install...
>From my pov, ConTeXt is really great because of the reactivity of the
devs. As a consequence, new astonishing features are often added... but
there is a price: update often to the latest realease + install the
latest metapost and the latest pdfTeX (moreover, here I need the latest
beta of pdfTeX).

IMHO, it will be nice if the deb provides debian's specifics +
interactiv cont-tmf.zip download + install according debian specifics...
but there will be dependencies problems... Maybe a full standalone
context is the solution (with metapost, pdfTeX and all the binaries we
need coexisting with the tetex's one) ? Dunno...

Last point, it could be nice to have beta packages for ConTeXt an m-bib
(separated)...

>So the specific question I have are:
>
>- Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
>  If yes, why is that so?  If not, we should rather find out why it
>  happens and fix it.
>  
>
It's the way ConTeXt does... ConTeXt's gurus have surely good reasons so
I let them answer...

>- Why does it make a difference if the formats are created by fmtutil
>  instead of texexec (Except for the output directory)?  Should the
>  upstream packaging be changed so that fmtutil is never used, but
>  texexec, or should fmtutil be fixed to produce the same as texexec?  
>  
>
idem

>Finally, here comes Norbert Preining's Call for Testers:
>
>Dear all!
>
>We = Debian TeX maintainers searching for users of the Debian Operating
>Systems which are also using ConTeXt.
>
>Currently Debian etch (testing) and sid (unstable) contains packages for
>TeX live 2005. But this contains a bit old ConTeXt version, so users are
>asking us to update ConTeXt.
>
>We have prepared a updated ConTeXt package for Debian, based on the
>latest released version (2006.08.08), and would ask you to help use
>testing, as we are not experienced in ConTeXt type settings. I checked
>some simple documents from the ConTeXt Garden, and they worked, but more
>detailed testing would be nice.
>
>If you have interest, please contact us at
>	debian-tex-maint@lists.debian.org
>or, if you have a bit experience, you can straight away add
>	deb http://www.tug.org/texlive/Debian/ context/
>to your /etc/apt/sources.list file and install context. After this,
>please tell us our experiences/failures/suggestions.
>
>Thanks a lot and all the best
>
>  
>
OK, thanks, I'll do it as soon as I have a little more time (after my
PhD defense... ;) )

>Regards, Frank
>  
>

Renaud

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23  8:35 ConTeXt on Debian: The wiki entry Frank Küster
  2006-10-23 10:25 ` Renaud AUBIN
@ 2006-10-23 10:58 ` Taco Hoekwater
  2006-10-23 11:39   ` Frank Küster
  2006-10-23 20:47 ` Sanjoy Mahajan
  2006-10-25  6:52 ` Gerhard Kugler
  3 siblings, 1 reply; 24+ messages in thread
From: Taco Hoekwater @ 2006-10-23 10:58 UTC (permalink / raw)



Hi Frank,

Frank Küster wrote:
> 
> Are some of the people around who wrote this?  I found some information

I do not use Debian and did not write that page, but I can answer your
questions partially, at least.

> - Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
>   If yes, why is that so?  If not, we should rather find out why it
>   happens and fix it.

Yes, it is. ConTeXt does not support only pdfetex, but all major
engines, like XeTeX and Aleph. I have formats in:
	
   $TEXMF/web2c/aleph/
   $TEXMF/web2c/luatex/
   $TEXMF/web2c/pdfetex/
   $TEXMF/web2c/xetex/

> - Why does it make a difference if the formats are created by fmtutil
>   instead of texexec (Except for the output directory)?  Should the
>   upstream packaging be changed so that fmtutil is never used, but
>   texexec, or should fmtutil be fixed to produce the same as texexec?  

It is almost certainly better to ignore/block fmtutil and use texexec
instead. Properly setting up a ConTeXt update is not necesarily limited
to format generation only.

Greetings, Taco

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 10:58 ` Taco Hoekwater
@ 2006-10-23 11:39   ` Frank Küster
  2006-10-23 18:15     ` Taco Hoekwater
  2006-10-25 13:37     ` ConTeXt on Debian: The wiki entry Hans Hagen
  0 siblings, 2 replies; 24+ messages in thread
From: Frank Küster @ 2006-10-23 11:39 UTC (permalink / raw)


Taco Hoekwater <taco@elvenkind.com> wrote:

> Hi Frank,
>
> Frank Küster wrote:
>> 
>> Are some of the people around who wrote this?  I found some information
>
> I do not use Debian and did not write that page, but I can answer your
> questions partially, at least.

Thank you - yes, this helps.

>> - Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
>>   If yes, why is that so?  If not, we should rather find out why it
>>   happens and fix it.
>
> Yes, it is. ConTeXt does not support only pdfetex, but all major
> engines, like XeTeX and Aleph. I have formats in:
> 	
>    $TEXMF/web2c/aleph/
>    $TEXMF/web2c/luatex/
>    $TEXMF/web2c/pdfetex/
>    $TEXMF/web2c/xetex/

Ah, okay, that's clear.  Has this already been this way one year ago
when texlive2005 was released?  Do you know whether the TeXlive
developers are aware of that?

>> - Why does it make a difference if the formats are created by fmtutil
>>   instead of texexec (Except for the output directory)?  Should the
>>   upstream packaging be changed so that fmtutil is never used, but
>>   texexec, or should fmtutil be fixed to produce the same as texexec?  
>
> It is almost certainly better to ignore/block fmtutil and use texexec
> instead. Properly setting up a ConTeXt update is not necesarily limited
> to format generation only.

Hm.  What are the other things that need to be done?

This is in fact an issue that affects not only Debian, but TeXlive and
probably most TeX distributions.  They currently assume that after an
update of some files and/or executables, it's sufficient to run mktexlsr
(possibly more than once), updmap(-sys) and "fmtutil(-sys) --all".  If
this is not sufficient for ConTeXt, there are two possibilities:

- fix fmtutil and updmap so that they do the right thing for ConTeXt

- or implement a way to automate calling texexec.  This would include
  using some configuration file, since not everybody who has aleph or
  xetex installed also wants a context format for this engine.

To me, as a TeXlive and teTeX guy, it seems preferrable to choose option
1 and fix the existing distribution scripts.  However, I don't know yet
what else is needed when ConTeXt is updated, therefore I might be wrong,
and switching to texexec might actually be better.  But then this should
be done consistently, and fmtutil should drop context handling
completely (or just call texexec).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 11:39   ` Frank Küster
@ 2006-10-23 18:15     ` Taco Hoekwater
  2006-10-23 19:01       ` Frank Küster
  2006-10-25 13:37     ` ConTeXt on Debian: The wiki entry Hans Hagen
  1 sibling, 1 reply; 24+ messages in thread
From: Taco Hoekwater @ 2006-10-23 18:15 UTC (permalink / raw)


Frank Küster wrote:
> 
>>>- Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
>>>  If yes, why is that so?  If not, we should rather find out why it
>>>  happens and fix it.
>>
>>Yes, it is. ConTeXt does not support only pdfetex, but all major
>>engines, like XeTeX and Aleph. I have formats in:
>>	
>>   $TEXMF/web2c/aleph/
>>   $TEXMF/web2c/luatex/
>>   $TEXMF/web2c/pdfetex/
>>   $TEXMF/web2c/xetex/
> 
> Ah, okay, that's clear.  Has this already been this way one year ago
> when texlive2005 was released?  Do you know whether the TeXlive
> developers are aware of that?

Yes, it was, Yes, 'they' were aware, and no, 'they' did not want to
fix fmtutil. 'They' only dropped the separate format extensions and
then decided that implementing a replacement was too much effort.

>>>- Why does it make a difference if the formats are created by fmtutil
>>>  instead of texexec (Except for the output directory)?  Should the
>>>  upstream packaging be changed so that fmtutil is never used, but
>>>  texexec, or should fmtutil be fixed to produce the same as texexec?  
>>
>>It is almost certainly better to ignore/block fmtutil and use texexec
>>instead. Properly setting up a ConTeXt update is not necesarily limited
>>to format generation only.
> 
> Hm.  What are the other things that need to be done?

Nothing at the moment, AFAIK. But potentially lots of things.

For instance: the next version of context will support non-kpathsea
file searching, so it will have to initialize its database somewhere.
It may want to/have to delete obsolete files  and/or merge local
configuration files with new released version. Or precompile patterns
files or lua scripts, strip and optimize source files, and perhaps
generate font metrics in one format or another.

ConTeXt comes with its own font map files, so there is no real
reason to fix updmap but if you want to the main problem is this:
you have to extend it so that it does not treat dvips and pdftex
map files as identical.


> To me, as a TeXlive and teTeX guy, it seems preferrable to choose option
> 1 and fix the existing distribution scripts.  However, I don't know yet
> what else is needed when ConTeXt is updated, therefore I might be wrong,
> and switching to texexec might actually be better.  But then this should
> be done consistently, and fmtutil should drop context handling
> completely (or just call texexec).

I am very much in favor of using texexec for everything related to
ConTeXt.

Greetings, Taco

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 18:15     ` Taco Hoekwater
@ 2006-10-23 19:01       ` Frank Küster
  2006-10-24  7:22         ` Taco Hoekwater
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Küster @ 2006-10-23 19:01 UTC (permalink / raw)


Taco Hoekwater <taco@elvenkind.com> wrote:

>> To me, as a TeXlive and teTeX guy, it seems preferrable to choose option
>> 1 and fix the existing distribution scripts.  However, I don't know yet
>> what else is needed when ConTeXt is updated, therefore I might be wrong,
>> and switching to texexec might actually be better.  But then this should
>> be done consistently, and fmtutil should drop context handling
>> completely (or just call texexec).
>
> I am very much in favor of using texexec for everything related to
> ConTeXt.

Can you point me to the place where it is documented which calls are
needed to be called

- when ConTeXt is updated

- when any of the engines is updated?

I don't use ConTeXt myself, and I always have problems finding the
relevant places in the documentation, sorry...

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23  8:35 ConTeXt on Debian: The wiki entry Frank Küster
  2006-10-23 10:25 ` Renaud AUBIN
  2006-10-23 10:58 ` Taco Hoekwater
@ 2006-10-23 20:47 ` Sanjoy Mahajan
  2006-10-23 21:48   ` Hans Hagen
  2006-10-25  6:52 ` Gerhard Kugler
  3 siblings, 1 reply; 24+ messages in thread
From: Sanjoy Mahajan @ 2006-10-23 20:47 UTC (permalink / raw)


> http://wiki.contextgarden.net/Debian_installation

> Are some of the people around who wrote this? 

I wrote some of it (hangs head in shame) by typing in all the steps I
had to use on my Debian stable/testing system to get a newer ConTeXt
to work with tetex 3.0 as the basis.  I agree, it is confusing and I
hope it can be improved.

In the previous discussion, the issue came up of whether ConTeXt
should be installed per user or for the whole system.  The
Debian_installation instructions on the wiki are for a per-user
install, because I couldn't figure out a robust way of having an
easily updatable installation that goes in TEXMFLOCAL.  

A system-wide installation, if done cleanly, would be much easier (as
plink pointed out).  If you (or 'texexec --make' to generate the
formats) ask kpathsea where to put the format files, it'll give you a
directory in TEXMFHOME, so a per user install.  But how do you ask
kpathsea the correct question so that it'll tell you where they should
go for a system-wide install?

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 20:47 ` Sanjoy Mahajan
@ 2006-10-23 21:48   ` Hans Hagen
  2006-10-24  5:53     ` Frank Küster
  0 siblings, 1 reply; 24+ messages in thread
From: Hans Hagen @ 2006-10-23 21:48 UTC (permalink / raw)


Sanjoy Mahajan wrote:
> A system-wide installation, if done cleanly, would be much easier (as
> plink pointed out).  If you (or 'texexec --make' to generate the
> formats) ask kpathsea where to put the format files, it'll give you a
> directory in TEXMFHOME, so a per user install.  But how do you ask
> kpathsea the correct question so that it'll tell you where they should
> go for a system-wide install?
>   
you can't and i remember asking for such a feature but ... ; the only way to figure that out is to check all format paths and take the first one that fits; unfortunalty the tetex paths are rather messy so it's hard to predict in what permutation of home, usr, share, sys, opt * local * tex, TeX, teTeX, whatever * texmf, texmflocal, texmf-local, texmf-teTeX, texmf-dis, texmf.local, texmf-whocares * web2c, web2c/engine etc etc a format may end up; this is further complicated by the fact that kpse has to do some guessing about where it's configuration files are (web2c, etc, home, nowhere), what trees make sense, etc etc; and, yes, some of the paths are hard coded in the binaries, so relocating is tricky ... isn't it magic that tex still runs -) 

but luatex will make thinsg better (we hope) 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 21:48   ` Hans Hagen
@ 2006-10-24  5:53     ` Frank Küster
  2006-10-24  8:18       ` Hans Hagen
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Küster @ 2006-10-24  5:53 UTC (permalink / raw)


Hans Hagen <pragma@wxs.nl> wrote:

> Sanjoy Mahajan wrote:
>> A system-wide installation, if done cleanly, would be much easier
>> (as plink pointed out).  If you (or 'texexec --make' to generate the
>> formats) ask kpathsea where to put the format files, it'll give you
>> a directory in TEXMFHOME, so a per user install.  But how do you ask
>> kpathsea the correct question so that it'll tell you where they
>> should go for a system-wide install?
>>   
> you can't and i remember asking for such a feature but ... ;

Can you point me to this discussion?  I think it doesn't need more as
what fmtutil-sys, updmap-sys and texconfig-sys do before calling
fmtutil, updmap or texconfig, respectively:

v=`kpsewhich -var-value TEXMFSYSVAR`
c=`kpsewhich -var-value TEXMFSYSCONFIG`

TEXMFVAR="$v"
TEXMFCONFIG="$c"
export TEXMFVAR TEXMFCONFIG

exec updmap ${1+"$@"}

However, it would be probably more elegant and context-like to not have
texexec and texexec-sys, but rather a commandline switch - in this case
the handling would have to be done in the perl (or ruby?) scripts, which
is somewhat trickier.

> the only
> way to figure that out is to check all format paths and take the first
> one that fits; unfortunalty the tetex paths are rather messy so it's
> hard to predict in what permutation of home, usr, share, sys, opt *
> local * tex, TeX, teTeX, whatever * texmf, texmflocal, texmf-local,
> texmf-teTeX, texmf-dis, texmf.local, texmf-whocares * web2c,
> web2c/engine etc etc a format may end up; 

I'm not sure what you mean.  The default TEXMF path for teTeX (and I
think also for TeXlive) is

TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}

where the first three are per-user, the others are system trees.  An
explanation about installing does not need to know whether, for example,
TEXMFLOCAL is called texmf.local or texmf-local or
/usr/local/share/texmf.  The only problem might be that some users
change the order or the trees, but that's not a big problem if we
suggest to use the default path.

> this is further complicated
> by the fact that kpse has to do some guessing about where it's
> configuration files are (web2c, etc, home, nowhere),

This is only a problem if people have more than one texmf.cnf - is this
actually the case?  I don't think I ever heard of that.

> what trees make
> sense, etc etc; and, yes, some of the paths are hard coded in the
> binaries, so relocating is tricky ... isn't it magic that tex still
> runs -)

AFAIK only the search path for texmf.cnf is hard-coded, and that can't
be avoided.  On the other hand, no one ever approached me and requested
a relocation:  What would you want, and in which cases?

TIA, Frank

-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 19:01       ` Frank Küster
@ 2006-10-24  7:22         ` Taco Hoekwater
  2006-10-24  8:24           ` Frank Küster
  2006-11-01 21:30           ` ctxtools unix puzzles plink
  0 siblings, 2 replies; 24+ messages in thread
From: Taco Hoekwater @ 2006-10-24  7:22 UTC (permalink / raw)


Frank Küster wrote:
> 
> Can you point me to the place where it is documented which calls are
> needed to be called

I was going to say: on the wiki, but that clearly wouldn't work
this time.

To actually update ConTeXt, assuming you already have a relatively
modern context installed, you say
	
   # ctxtools --update

and that fetches the zip file(s) from the pragma site (or a mirror),
unpacks them, and updates the various perl and ruby scripts that come
with ConTeXt.

You have to be root for this when you want to update the global install,
otherwise you have a few extra caveats, see below.

After a succesful update, you have to run
	
  # texexec --make --all [--xetex | --aleph | --pdftex] <formats>

Where <formats> are the desired formats to run. The accepted list
at the moment is: the eight ConTeXt formats, in both long
("cont-en" etc.) and  short from ("en","nl","de","it","fr","cz",
"ro","uk"), and "mptopdf", and the metapost mems "mpost" and "metafun".


This works fine if you are root, and had a previous context update
done already. If you have not already and/or are not root, then you
have two big problems:

* TEXFORMATS as shipped with teTeX/TL is uncomplete: there is that
   missing format-specific subdirectory. If you are not root, then
   you have to create a local texmf.cnf to overrule the default
   texmf.cnf. I have:

   TEXFORMATS    = .;$TEXMF/web2c/{$engine,}

   because context's texexec pushes the $engine setting to the
   environment, this works fine (Originally this was supposed to
   be handled by kpathsea, but like I said, that never got off
   the ground)

   If you don't make this change, you cannot use texexec for the
   format regeneration, at all. (Formats created by texexec will
   never be used because the fmtutil-generated old one is always
   discovered first).

   Not using texexec is not a big deal in itself, as long as you
   restrict yourself to using pdfetex and know how to edit the
   fmtutil config file, I guess. That's why you sometimes see that
   approach promoted on the wiki.


* TEXFONTMAPS is also wrong: it makes pdftex (and dvipdfmx as well,
   I guess) find the mapfiles for dvips before their own mapfiles
   (those are shipped with ConTeXt).

   I have:

   TEXFONTMAPS.dvipdfm  = .;$TEXMF/fonts/map/{dvipdfm,dvips,}//
   TEXFONTMAPS.dvipdfmx = .;$TEXMF/fonts/map/{dvipdfm,dvips,}//
   TEXFONTMAPS.pdftex   = .;$TEXMF/fonts/map/{pdftex,dvips,}//
   TEXFONTMAPS.pdfetex  = .;$TEXMF/fonts/map/{pdftex,dvips,}//
   TEXFONTMAPS.xetex    = .;$TEXMF/fonts/map/{xetex,pdftex,dvips,}//
   TEXFONTMAPS.dvips    = .;$TEXMF/fonts/map/{dvips,pdftex,}//
   TEXFONTMAPS          =.;$TEXMF/fonts/map/{$progname,pdftex,dvips,}//;\
                           $TEXMF/{$progname,pdftex,dvips}/{config,}//

   this works fine (but it is perhaps a bit too verbose).

* Lastly, ctxtools --update does a kpsewhich on context.tex to find
   where to install the updated files. That only works if  you have
   write permission for that directory (i.e. you are root),  or if you
   have done a private install already.

I think that is all, but I may have missed something, so if you read
this message and know a thing or two about updating, please double
check my text. Thanks in advance.

Cheers,
Taco

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  5:53     ` Frank Küster
@ 2006-10-24  8:18       ` Hans Hagen
  2006-10-24  9:01         ` Frank Küster
  0 siblings, 1 reply; 24+ messages in thread
From: Hans Hagen @ 2006-10-24  8:18 UTC (permalink / raw)


Frank � wrote:
> Hans Hagen <pragma@wxs.nl> wrote:
>
>   
>> Sanjoy Mahajan wrote:
>>     
>>> A system-wide installation, if done cleanly, would be much easier
>>> (as plink pointed out).  If you (or 'texexec --make' to generate the
>>> formats) ask kpathsea where to put the format files, it'll give you
>>> a directory in TEXMFHOME, so a per user install.  But how do you ask
>>> kpathsea the correct question so that it'll tell you where they
>>> should go for a system-wide install?
>>>   
>>>       
>> you can't and i remember asking for such a feature but ... ;
>>     
>
> Can you point me to this discussion?  I think it doesn't need more as
> what fmtutil-sys, updmap-sys and texconfig-sys do before calling
> fmtutil, updmap or texconfig, respectively:
>
> v=`kpsewhich -var-value TEXMFSYSVAR`
> c=`kpsewhich -var-value TEXMFSYSCONFIG`
>
> TEXMFVAR="$v"
> TEXMFCONFIG="$c"
> export TEXMFVAR TEXMFCONFIG
>
> exec updmap ${1+"$@"}
>
> However, it would be probably more elegant and context-like to not have
> texexec and texexec-sys, but rather a commandline switch - in this case
> the handling would have to be done in the perl (or ruby?) scripts, which
> is somewhat trickier.
>   
concerning fmtutil: there was a time that texexec could call fmtutil, 
but the lack of engine support (as taco explained, it was a trade off 
for simplifying the fmt suffix but part of the bargain was nog kept) as 
well as all kind of messy 'aliasing' going on in tex distributions 
(leading to dropped patterns and fonts) made us decide to drop that; 
another reason is that distrubutions like texlive more or less assume 
a'wipe your system clean and install new' policy which is not possible 
if you have aditional trees, run older binaries with newer trees, etc, 
which is why texmfstart came around: relocating script paths and enc/map 
paths was done in not downward compaible ways (which in turn is the 
reason why context ships with all kind of tools to clean up and 
reorganize trees etc).

i have no problem with adding a commandline switch which tells texexec 
where to put the formats although, since your scripts already set 
variables, the most natural way would be to adapt

TEXFORMATS=someplace/web2c/{$engine,}

to which texexec already listens, but if some additional switch/feature 
is needed it can be done

Concerning updmap, as Taco explains in another mail, context does not 
use updmap output; this has a long history:

- context had runtime map loading before updmap was around
- we never used the 'huge map files' because it was real slow (this was 
fixed at some point, hash instead of linear search)
- merging  map entries in to one big file is dangerous  (there can be 
multiple instances of fonts,  same name, different metrics, same 
longname, different font etc)
- we want clean and easy ways to add support for commercial fonts (which 
is the majority)
- pdftex and dvipdfmx were adapted to do run time loading

so, there is no need to spend time on updmap for context.

I have no idea what texconfig does but i don't think context needs it (i 
may be wrong).

>   
>> the only
>> way to figure that out is to check all format paths and take the first
>> one that fits; unfortunalty the tetex paths are rather messy so it's
>> hard to predict in what permutation of home, usr, share, sys, opt *
>> local * tex, TeX, teTeX, whatever * texmf, texmflocal, texmf-local,
>> texmf-teTeX, texmf-dis, texmf.local, texmf-whocares * web2c,
>> web2c/engine etc etc a format may end up; 
>>     
>
> I'm not sure what you mean.  The default TEXMF path for teTeX (and I
> think also for TeXlive) is
>
> TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
>   
the problem with texmf is that there can be many variants, and there 
have been in the past; here i now have:

TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}

texmfproject : a tree for project related files, these will not be wiped 
out with an update
texmffonts    : a safe place for commercial fonts, also not being wiped 
out (may have older tds structures)
texflocal        : the place for updates and specific user settings
texmfextras  : introduced a few years ago in texlive for non free stuff 
(first dvd productions)
texmfmain   : on my system a mere copy of the latest tex live, just the 
whole lot

parallel this i have  texmf-mswin, texmf-linux, texmf-.... with web2c 
and bin paths

interesting is that a request for texmfproject and texmffonts on the tex 
live list was rejected by tetex folks because they didn't want extra 
paths, but see what extra paths tetex adds -)

concerning tex live: i must admit that i only copy the tree and use a 
much simplified texmf.cnf file which as a side effect makes tex run faster

anyhow, texexec cum suis just expand the texmf var so any setup should 
work but i rely on other context users to report problems;
> where the first three are per-user, the others are system trees.  An
> explanation about installing does not need to know whether, for example,
> TEXMFLOCAL is called texmf.local or texmf-local or
> /usr/local/share/texmf.  The only problem might be that some users
> change the order or the trees, but that's not a big problem if we
> suggest to use the default path.
>   
sure, but the fact that the 'real' names change every now and then makes 
it hard for users to cary a history around without renaming; also, one 
of the ideas behind tds and web2c was that platforms could share trees, 
which is what i like: i have one set of trees for running all platforms 
(so, texmf-local it is here)
>   
>> this is further complicated
>> by the fact that kpse has to do some guessing about where it's
>> configuration files are (web2c, etc, home, nowhere),
>>     
>
> This is only a problem if people have more than one texmf.cnf - is this
> actually the case?  I don't think I ever heard of that.
>   
i dunno, but since tex distributions tend to be non-downward compatible, 
i would not be surprised if users at least patch their local one
>   
>> what trees make
>> sense, etc etc; and, yes, some of the paths are hard coded in the
>> binaries, so relocating is tricky ... isn't it magic that tex still
>> runs -)
>>     
>
> AFAIK only the search path for texmf.cnf is hard-coded, and that can't
> be avoided.  On the other hand, no one ever approached me and requested
> a relocation:  What would you want, and in which cases?
>   
i think that there are a few more paths in there (you sometimes see them in var expansions, but normally they don't hurt) ; life would be easier if texmfcnf was always taken from an env var; actually, i set all important env vars anyway, if only because it isolates tex distrubutions (after all we're talking about a only a few vars than determins all); 

which brings me to the format again ... maybe it makes sense to set TEXFORMATS after all but i can let texexec listen to an extra --key if needed 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  7:22         ` Taco Hoekwater
@ 2006-10-24  8:24           ` Frank Küster
  2006-10-24  8:57             ` Hans Hagen
  2006-10-24  8:57             ` Taco Hoekwater
  2006-11-01 21:30           ` ctxtools unix puzzles plink
  1 sibling, 2 replies; 24+ messages in thread
From: Frank Küster @ 2006-10-24  8:24 UTC (permalink / raw)


Taco Hoekwater <taco@elvenkind.com> wrote:

> Frank Küster wrote:
>> 
>> Can you point me to the place where it is documented which calls are
>> needed to be called
>
> I was going to say: on the wiki, but that clearly wouldn't work
> this time.
>
> To actually update ConTeXt, assuming you already have a relatively
> modern context installed, you say
> 	
>    # ctxtools --update
>
> and that fetches the zip file(s) from the pragma site (or a mirror),
> unpacks them, and updates the various perl and ruby scripts that come
> with ConTeXt.

When this is done on a system where ConTeXt first came with a TeXlive or
teTeX installation, will this replace existing files, or will it put the
updated new files in TEMXFLOCAL or TEXMFHOME, respectively?  Ah, I think
you have answered this already below.

> You have to be root for this when you want to update the global install,
> otherwise you have a few extra caveats, see below.
>
> After a succesful update, you have to run
> 	
>   # texexec --make --all [--xetex | --aleph | --pdftex] <formats>
>
> Where <formats> are the desired formats to run. The accepted list
> at the moment is: the eight ConTeXt formats, in both long
> ("cont-en" etc.) and  short from ("en","nl","de","it","fr","cz",
> "ro","uk"), and "mptopdf", and the metapost mems "mpost" and "metafun".

So I guess this is the call that would also be needed if the update
itself goes via a package management, i.e. if one installs a new version
of the Debian ConTeXt package.

> This works fine if you are root, and had a previous context update
> done already. If you have not already and/or are not root, then you
> have two big problems:
>
> * TEXFORMATS as shipped with teTeX/TL is uncomplete: there is that
>    missing format-specific subdirectory. 

So I guess TeXlive (and the existing teTeX packages within
Linux/BSD/... distributions) should do that, so that modern ConTeXt just
works. 


If you are not root, then
>    you have to create a local texmf.cnf to overrule the default
>    texmf.cnf. I have:
>
>    TEXFORMATS    = .;$TEXMF/web2c/{$engine,}
>
>    because context's texexec pushes the $engine setting to the
>    environment, this works fine (Originally this was supposed to
>    be handled by kpathsea, but like I said, that never got off
>    the ground)

It might be possible by setting, in texmf.cnf,

TEXFORMATS.xetex = .;$TEXMF/web2c{xetex,}
TEXFORMATS.pdftex = .;$TEXMF/web2c{pdftex,}

and so on.  I'm not sure, however; this of course depends on which
progname ConTeXt uses (so it might need to be TEXFORMATS.cont-xetex or
whatever). 

>    Not using texexec is not a big deal in itself, as long as you
>    restrict yourself to using pdfetex and know how to edit the
>    fmtutil config file, I guess. That's why you sometimes see that
>    approach promoted on the wiki.

I think, with the TEXFORMATS.$engine setup working, it should be
possible to use both, fmtutil and texexec, and get the same formats -
texexec might still be better in doing other update tasks.

> * TEXFONTMAPS is also wrong: it makes pdftex (and dvipdfmx as well,
>    I guess) find the mapfiles for dvips before their own mapfiles
>    (those are shipped with ConTeXt).

This also sounds like a bug in TeXlive/teTeX.

> * Lastly, ctxtools --update does a kpsewhich on context.tex to find
>    where to install the updated files. That only works if  you have
>    write permission for that directory (i.e. you are root),  or if you
>    have done a private install already.

So this means -update will always try to overwrite an existing
installation, and not automatically search for a writable directory
that's earlier in the TEXMF path?  Even not as a fallback?  This sounds
as if this tool could be improved.

> I think that is all, but I may have missed something, so if you read
> this message and know a thing or two about updating, please double
> check my text. Thanks in advance.

I think it does help a lot, and we can work from there, testing with the
Debian ConTeXt package.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  8:24           ` Frank Küster
@ 2006-10-24  8:57             ` Hans Hagen
  2006-10-24  8:57             ` Taco Hoekwater
  1 sibling, 0 replies; 24+ messages in thread
From: Hans Hagen @ 2006-10-24  8:57 UTC (permalink / raw)


Frank � wrote:
>   
>> After a succesful update, you have to run
>> 	
>>   # texexec --make --all [--xetex | --aleph | --pdftex] <formats>
>>
>> Where <formats> are the desired formats to run. The accepted list
>> at the moment is: the eight ConTeXt formats, in both long
>> ("cont-en" etc.) and  short from ("en","nl","de","it","fr","cz",
>> "ro","uk"), and "mptopdf", and the metapost mems "mpost" and "metafun".
>>     
>
> So I guess this is the call that would also be needed if the update
> itself goes via a package management, i.e. if one installs a new version
> of the Debian ConTeXt package.
>   
i think that it depends on what users want to use (pdftex, aleph, xetex, 
luatex, a combination)

ok, one can play safe and just generate them all for the english user 
interface
>
> So I guess TeXlive (and the existing teTeX packages within
> Linux/BSD/... distributions) should do that, so that modern ConTeXt just
> works. 
>
>
> If you are not root, then
>   
just curious: how many tex users or people updating tex don't have root 
permissions

> and so on.  I'm not sure, however; this of course depends on which
> progname ConTeXt uses (so it might need to be TEXFORMATS.cont-xetex or
> whatever). 
>   
the progname is always 'context'

there is no functional difference between context's, only user interface 
languages may differ, so for pdftex, xetex etc the same context is used; 
backend support is loaded runtime; so, there is not, as with latex, a 
pdfcontext or so: backend support has always been isolated in driver 
files; the TEXFORMATS variable should have an /{engine,} appended which 
makes the engine specific formats end up the and be searched there 
(because formats are always generated in a current path, texexec will 
chdir to an engine path when making a format)

so, pdftex, xetex, aleph, ... all use cont-en.fmt for the english user 
interface (used to be cont-en.efmt, cont-en.ofmt, etc);  using 
different  names for the formats does not make sense since the 
functionality is mostly the same
>
> I think, with the TEXFORMATS.$engine setup working, it should be
> possible to use both, fmtutil and texexec, and get the same formats -
> texexec might still be better in doing other update tasks.
>   
the problem with this is that there is only one dimensions: progname, so 
TEXFORMATS.context is ok, and TEXFORMATS.xetex is undefined (actually 
$engine is unset in many cases)
>   
>> * TEXFONTMAPS is also wrong: it makes pdftex (and dvipdfmx as well,
>>    I guess) find the mapfiles for dvips before their own mapfiles
>>    (those are shipped with ConTeXt).
>>     
>
> This also sounds like a bug in TeXlive/teTeX.
>   
if i'm right Karl added it after we discussed this feature but i didn't 
check it
>   
>> * Lastly, ctxtools --update does a kpsewhich on context.tex to find
>>    where to install the updated files. That only works if  you have
>>    write permission for that directory (i.e. you are root),  or if you
>>    have done a private install already.
>>     
>
> So this means -update will always try to overwrite an existing
> installation, and not automatically search for a writable directory
> that's earlier in the TEXMF path?  Even not as a fallback?  This sounds
> as if this tool could be improved.
>   
 def locatedlocaltree
            tree = Kpse.used_path('TEXMFLOCAL')
            unless tree && FileTest.directory?(tree) then
                tree = Kpse.used_path('TEXMF')
            end
            return tree
        end

so, it prefers texmflocal; so far no one asked for different methods but 
it can always be improved (and will be on request)
>   
>> I think that is all, but I may have missed something, so if you read
>> this message and know a thing or two about updating, please double
>> check my text. Thanks in advance.
>>     
>
> I think it does help a lot, and we can work from there, testing with the
> Debian ConTeXt package.
>   
ok, thanks. there are debian users on this list so testing should be no problem 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  8:24           ` Frank Küster
  2006-10-24  8:57             ` Hans Hagen
@ 2006-10-24  8:57             ` Taco Hoekwater
  1 sibling, 0 replies; 24+ messages in thread
From: Taco Hoekwater @ 2006-10-24  8:57 UTC (permalink / raw)



Frank Küster wrote:
> 
>>After a succesful update, you have to run
>>	
>>  # texexec --make --all [--xetex | --aleph | --pdftex] <formats>
>>
..
> So I guess this is the call that would also be needed if the update
> itself goes via a package management, i.e. if one installs a new version
> of the Debian ConTeXt package.

Yes.

>>This works fine if you are root, and had a previous context update
>>done already. If you have not already and/or are not root, then you
>>have two big problems:
>>
>>* TEXFORMATS as shipped with teTeX/TL is uncomplete: there is that
>>   missing format-specific subdirectory. 
> 
> 
> So I guess TeXlive (and the existing teTeX packages within
> Linux/BSD/... distributions) should do that, so that modern ConTeXt just
> works. 

Yes. But Hans and I gave up trying to convince the teTeX maintainers
a while back, and we are not any more willing to spend even more time
on doing that (even though the situation may have improved).

> 
> 
> It might be possible by setting, in texmf.cnf,
> 
> TEXFORMATS.xetex = .;$TEXMF/web2c{xetex,}
> TEXFORMATS.pdftex = .;$TEXMF/web2c{pdftex,}
> 
> and so on.  I'm not sure, however; this of course depends on which
> progname ConTeXt uses (so it might need to be TEXFORMATS.cont-xetex or
> whatever). 

It is not the user-supplied progname, but the executable engine name.

The progname is always set to 'context' for ConTeXt, otherwise
variables like TEXINPUTS and the memory sizes would need many
more entries

    main_memory.cont-en-xetex
    main_memory.cont-de-xetex
    etc.

That is why there is a separate $engine.

>>   Not using texexec is not a big deal in itself, as long as you
>>   restrict yourself to using pdfetex and know how to edit the
>>   fmtutil config file, I guess. That's why you sometimes see that
>>   approach promoted on the wiki.
> 
> I think, with the TEXFORMATS.$engine setup working, it should be
> possible to use both, fmtutil and texexec, and get the same formats -

Agreed.

> texexec might still be better in doing other update tasks.

Also agreed.

>>* TEXFONTMAPS is also wrong: it makes pdftex (and dvipdfmx as well,
>>   I guess) find the mapfiles for dvips before their own mapfiles
>>   (those are shipped with ConTeXt).
> 
> This also sounds like a bug in TeXlive/teTeX.

Yes, I think so: it needs a few more TEXFONTMAPS lines in texmf.cnf.

>>* Lastly, ctxtools --update does a kpsewhich on context.tex to find
>>   where to install the updated files. That only works if  you have
>>   write permission for that directory (i.e. you are root),  or if you
>>   have done a private install already.
> 
> 
> So this means -update will always try to overwrite an existing
> installation, and not automatically search for a writable directory
> that's earlier in the TEXMF path?  Even not as a fallback?  This sounds
> as if this tool could be improved.

That is true, ctxtools is very new tool that could definately be
improved.

Cheers, Taco

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  8:18       ` Hans Hagen
@ 2006-10-24  9:01         ` Frank Küster
  2006-10-24 11:33           ` Hans Hagen
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Küster @ 2006-10-24  9:01 UTC (permalink / raw)
  Cc: mailing list for ConTeXt users

Hans Hagen <pragma@wxs.nl> wrote:

> concerning fmtutil: there was a time that texexec could call fmtutil,
> but the lack of engine support (as taco explained, it was a trade off
> for simplifying the fmt suffix but part of the bargain was nog kept)
> as well as all kind of messy 'aliasing' going on in tex distributions
> (leading to dropped patterns and fonts) 

Uups, what kind of aliasing?  Can you point me to a place where this is
discussed? 

> made us decide to drop that;
> another reason is that distrubutions like texlive more or less assume
> a'wipe your system clean and install new' policy which is not possible
> if you have aditional trees, run older binaries with newer trees, etc,

I know that TeXlive has such an approach, but as I understood it this
only extends to the TeXlive system itself:  TEXMFLOCAL, TEXMFHOME and
any other user-added tree should continue to work.

Pool files are a problem, but if ConTeXt has found a way to use for
example different versions of pdftex and let each one find its correct
pool file, I think this feature should be implemented in TeXlive, too.

> which is why texmfstart came around: relocating script paths and
> enc/map paths was done in not downward compaible ways (which in turn
> is the reason why context ships with all kind of tools to clean up and
> reorganize trees etc).

Hm, it seems I really need to actually dig into what texmfstart and
other ConTeXt scripts do before I can continue.  I thought everybody was
happy with current TDS, and also that it didn't leave important things
unspecified. 

> Concerning updmap, as Taco explains in another mail, context does not
> use updmap output; this has a long history:
>
> - context had runtime map loading before updmap was around
> - we never used the 'huge map files' because it was real slow (this
> was fixed at some point, hash instead of linear search)
> - merging  map entries in to one big file is dangerous  (there can be
> multiple instances of fonts,  same name, different metrics, same
> longname, different font etc)
> - we want clean and easy ways to add support for commercial fonts
> (which is the majority)
> - pdftex and dvipdfmx were adapted to do run time loading
>
> so, there is no need to spend time on updmap for context.

But maybe other formats could profit from ConTeXt's way to do it, too:
These arguments seem to apply to LaTeX and whatever else, too.

> I have no idea what texconfig does but i don't think context needs it
> (i may be wrong).

I never need it...  It's just a textmode-menu interface to things like
editing language.dat (hyphenation patterns for latex and relatives),
calling updmap, changing dvips defaults, etc.

>> I'm not sure what you mean.  The default TEXMF path for teTeX (and I
>> think also for TeXlive) is
>>
>> TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
>>   
> the problem with texmf is that there can be many variants, and there
> have been in the past; here i now have:
>
> TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}
>
> texmfproject : a tree for project related files, these will not be
> wiped out with an update
> texmffonts    : a safe place for commercial fonts, also not being
> wiped out (may have older tds structures)
> texflocal        : the place for updates and specific user settings
> texmfextras  : introduced a few years ago in texlive for non free
> stuff (first dvd productions)
> texmfmain   : on my system a mere copy of the latest tex live, just
> the whole lot

So you don't use TEXMFVAR and user-specific trees?  Anyway, I still fail
to see how that's a problem for context updates.  The natural approach
seems to be

- check whether context already exists anywhere except texmfmain (where
  the update can't go because of the wiping out)

- if yes, check whether the directory is writable

- if one answer was no, ask the user where to put it.

> interesting is that a request for texmfproject and texmffonts on the
> tex live list was rejected by tetex folks because they didn't want
> extra paths, but see what extra paths tetex adds -)

The extra paths that teTeX (and TeXlive too) add are paths with a
particular role for each.  From what you told me so far, I don't see
what the difference between TEXMFPROJECT, TEXMFFONTS, TEXMFEXTRA and
TEXMFLOCAL is, and why it is a problem for ConTeXt updates that
individual admins might add trees.

> concerning tex live: i must admit that i only copy the tree and use a
> much simplified texmf.cnf file which as a side effect makes tex run
> faster

That's an interesting point, in particular for us Debian people:  We
have split up texmf.cnf in individual parts (for reasons that don't
matter here), and we might be able to provide a minimal texmf.cnf like
yours if texlive-latex is not installed, but texlive-context is.

> sure, but the fact that the 'real' names change every now and then
> makes it hard for users to cary a history around without renaming;
> also, one of the ideas behind tds and web2c was that platforms could
> share trees, which is what i like: i have one set of trees for running
> all platforms (so, texmf-local it is here)

That's not so much of a problem in Debian, because the package managment
system will respect your changes and always keep texmf-local if you
like.  But generally I agree that this is suboptimal.

>> AFAIK only the search path for texmf.cnf is hard-coded, and that can't
>> be avoided.  On the other hand, no one ever approached me and requested
>> a relocation:  What would you want, and in which cases?
>>   
> i think that there are a few more paths in there (you sometimes see
> them in var expansions, but normally they don't hurt) ; life would be
> easier if texmfcnf was always taken from an env var; actually, i set
> all important env vars anyway, if only because it isolates tex
> distrubutions (after all we're talking about a only a few vars than
> determins all); 

I trust you to do it right, but we've had a couple of bogus bugreports
from people who set env vars wrongly, or completely forgot they ever
had... 


I'll see that I or Norbert Preining look into this and come back with a
more constructive proposal.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24  9:01         ` Frank Küster
@ 2006-10-24 11:33           ` Hans Hagen
  2006-10-24 13:34             ` Frank Küster
  0 siblings, 1 reply; 24+ messages in thread
From: Hans Hagen @ 2006-10-24 11:33 UTC (permalink / raw)


Frank � wrote:
> Hans Hagen <pragma@wxs.nl> wrote:
>
>   
>> concerning fmtutil: there was a time that texexec could call fmtutil,
>> but the lack of engine support (as taco explained, it was a trade off
>> for simplifying the fmt suffix but part of the bargain was nog kept)
>> as well as all kind of messy 'aliasing' going on in tex distributions
>> (leading to dropped patterns and fonts) 
>>     
>
> Uups, what kind of aliasing?  Can you point me to a place where this is
> discussed? 
>   
the problem is that it is not really discussed

we accidentally stumbled into this when at a tug conference workshop 
attendents could not hyphenate; the problem was that pattern files were 
renamed, but aliased in an 'alias' file in one of the texmf roots; when 
looking at this file, more funny aliasing was taking place and i found 
out that quite some font problems were resulting from this, i.e. if one 
refers to font 'abc' which is aliased on one system but not on another 
... ; normally such things are (off list) discussed with karl who then 
sort things out in tex live;  when, at user group meetings, i had talks 
about 'contexts way of dealing with patterns and pattern files' and 
mentioned this alias mess, it was interesting to see tex experts 
launching up their laptops and scratching their heads over this unknown 
obscure aliasing feature ; in the end we found out that it was also the 
cause of some 'hyphen.tex' not being the real 'hyphen.tex' problem; 
anyhow, by now, no alias file should be present in any tex root any 
more; it was a bad idea anyway
>   
>> made us decide to drop that;
>> another reason is that distrubutions like texlive more or less assume
>> a'wipe your system clean and install new' policy which is not possible
>> if you have aditional trees, run older binaries with newer trees, etc,
>>     
>
> I know that TeXlive has such an approach, but as I understood it this
> only extends to the TeXlive system itself:  TEXMFLOCAL, TEXMFHOME and
> any other user-added tree should continue to work.
>
> Pool files are a problem, but if ConTeXt has found a way to use for
> example different versions of pdftex and let each one find its correct
> pool file, I think this feature should be implemented in TeXlive, too.
>   
pool files normally are in web2c paths; future versions of pdftex and 
mpost have the pool file embedded so this problem will (hopefully) disappear
>   
>> which is why texmfstart came around: relocating script paths and
>> enc/map paths was done in not downward compaible ways (which in turn
>> is the reason why context ships with all kind of tools to clean up and
>> reorganize trees etc).
>>     
>
> Hm, it seems I really need to actually dig into what texmfstart and
> other ConTeXt scripts do before I can continue.  I thought everybody was
> happy with current TDS, and also that it didn't leave important things
> unspecified. 
>   
texmfstart somefile

will launch somefile, i.e. it is the script launcher; by using 
texmfstart, one can be sure that the right one is found (it also passes 
some info to underlying progs/scripts so that redundant kpsewhich calls 
don't take place; it's teh context way of dealing with non-downward 
compatible texlives; (it has an embedded kpsewhich written in ruby but 
this is disabled by default; it can also act as kpse servlet [serving 
multiple independent trees]; yet another feature is that it can be uses as:

texmfstart --tree=sometree somescript .....

which us handy when running from cgi scripts (for that purpose it can 
initialize independent trees based on simple cross platform env var 
definiton files)

well, it can do a bit more, like launching documentation and so

(context ships with more tools: textools, tmftools, ctxtools, etc and 
when seldomly used, starting them with "texmfstart ctxtools" instead of 
stubs makes sense; the tex bin trees ship with potentially 
name-conflicting stuff, like 'access' and by launching scripts this way 
there is less danger of clashing names)
>   
>> Concerning updmap, as Taco explains in another mail, context does not
>> use updmap output; this has a long history:
>>
>> - context had runtime map loading before updmap was around
>> - we never used the 'huge map files' because it was real slow (this
>> was fixed at some point, hash instead of linear search)
>> - merging  map entries in to one big file is dangerous  (there can be
>> multiple instances of fonts,  same name, different metrics, same
>> longname, different font etc)
>> - we want clean and easy ways to add support for commercial fonts
>> (which is the majority)
>> - pdftex and dvipdfmx were adapted to do run time loading
>>
>> so, there is no need to spend time on updmap for context.
>>     
>
> But maybe other formats could profit from ConTeXt's way to do it, too:
> These arguments seem to apply to LaTeX and whatever else, too.
>   
sure, one can use \pdfmapfile{somename} in any package

we can even do without map files for pdftex, just use \pdfmapline
>   
>> I have no idea what texconfig does but i don't think context needs it
>> (i may be wrong).
>>     
>
> I never need it...  It's just a textmode-menu interface to things like
> editing language.dat (hyphenation patterns for latex and relatives),
> calling updmap, changing dvips defaults, etc.
>   
ah, i see
>   
>>> I'm not sure what you mean.  The default TEXMF path for teTeX (and I
>>> think also for TeXlive) is
>>>
>>> TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
>>>   
>>>       
>> the problem with texmf is that there can be many variants, and there
>> have been in the past; here i now have:
>>
>> TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}
>>
>> texmfproject : a tree for project related files, these will not be
>> wiped out with an update
>> texmffonts    : a safe place for commercial fonts, also not being
>> wiped out (may have older tds structures)
>> texflocal        : the place for updates and specific user settings
>> texmfextras  : introduced a few years ago in texlive for non free
>> stuff (first dvd productions)
>> texmfmain   : on my system a mere copy of the latest tex live, just
>> the whole lot
>>     
>
> So you don't use TEXMFVAR and user-specific trees?  Anyway, I still fail
> to see how that's a problem for context updates.  The natural approach
> seems to be
>   
no var indeed; but indeed it should make no difference
> - check whether context already exists anywhere except texmfmain (where
>   the update can't go because of the wiping out)
>
> - if yes, check whether the directory is writable
>
> - if one answer was no, ask the user where to put it.
>   
i could add that feature to ctxtools --update
>   
>> interesting is that a request for texmfproject and texmffonts on the
>> tex live list was rejected by tetex folks because they didn't want
>> extra paths, but see what extra paths tetex adds -)
>>     
>
> The extra paths that teTeX (and TeXlive too) add are paths with a
> particular role for each.  From what you told me so far, I don't see
> what the difference between TEXMFPROJECT, TEXMFFONTS, TEXMFEXTRA and
> TEXMFLOCAL is, and why it is a problem for ConTeXt updates that
> individual admins might add trees.
>   
they serve different purposes just like the tetex sys ones do ; for sure 
admins can add trees, but it would be handy if the fonts and project 
vars would be in the texmf list -)
>   
>> concerning tex live: i must admit that i only copy the tree and use a
>> much simplified texmf.cnf file which as a side effect makes tex run
>> faster
>>     
>
> That's an interesting point, in particular for us Debian people:  We
> have split up texmf.cnf in individual parts (for reasons that don't
> matter here), and we might be able to provide a minimal texmf.cnf like
> yours if texlive-latex is not installed, but texlive-context is.
>   
hm, interesting; lean and mean texmf.cnf files can speed up things a lot

when playing with luatex (where i intend to replace kpse completely with 
a lua based variant) it is possible to have format specific file 
databases; this runs much faster; this whole ls-r stuff is pretty outdated
>   
>> sure, but the fact that the 'real' names change every now and then
>> makes it hard for users to cary a history around without renaming;
>> also, one of the ideas behind tds and web2c was that platforms could
>> share trees, which is what i like: i have one set of trees for running
>> all platforms (so, texmf-local it is here)
>>     
>
> That's not so much of a problem in Debian, because the package managment
> system will respect your changes and always keep texmf-local if you
> like.  But generally I agree that this is suboptimal.
>   
ok
>   
>>> AFAIK only the search path for texmf.cnf is hard-coded, and that can't
>>> be avoided.  On the other hand, no one ever approached me and requested
>>> a relocation:  What would you want, and in which cases?
>>>   
>>>       
>> i think that there are a few more paths in there (you sometimes see
>> them in var expansions, but normally they don't hurt) ; life would be
>> easier if texmfcnf was always taken from an env var; actually, i set
>> all important env vars anyway, if only because it isolates tex
>> distrubutions (after all we're talking about a only a few vars than
>> determins all); 
>>     
>
> I trust you to do it right, but we've had a couple of bogus bugreports
> from people who set env vars wrongly, or completely forgot they ever
> had... 
>   
sure, but (i'm not sure if this is still true) running tex live 
alongside a tetex was always kind of problematic due to path settings 
and this autoparent mess then deriving locations of texmf.cnf from it

luckilly the number of vars that one needs to set to get a nicely 
isolated tree is not that large (texmf, texmfcnf, texformats, and a few 
more)
>
> I'll see that I or Norbert Preining look into this and come back with a
> more constructive proposal.
>   
ok, thanks, 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24 11:33           ` Hans Hagen
@ 2006-10-24 13:34             ` Frank Küster
  2006-10-24 14:33               ` Hans Hagen
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Küster @ 2006-10-24 13:34 UTC (permalink / raw)


Hans Hagen <pragma@wxs.nl> wrote:

[ horror story snipped ]
> anyhow, by now, no alias file should be present in any tex root any 
> more; it was a bad idea anyway

I always thought that the purpose of the aliases file was that a
non-existent (no, nay, never, nowhere ever) filename was aliased to an
existent one, like in the documentation part:

% documentation
TETEXDOC.pdf teTeX.pdf
etex-man.pdf etex.pdf
pdftex-a.pdf pdftex.pdf
testeuro.dvi eurosym.dvi

If the rest of the aliases covers files that might exist as real files
on some systems - I agree, what a bad idea.

> pool files normally are in web2c paths; future versions of pdftex and 
> mpost have the pool file embedded so this problem will (hopefully) disappear

Ah, I didn't know that.  pdftex 1.40 doesn't have this already, has it?

> hm, interesting; lean and mean texmf.cnf files can speed up things a lot
>
> when playing with luatex (where i intend to replace kpse completely with 
> a lua based variant) it is possible to have format specific file 
> databases; this runs much faster; this whole ls-r stuff is pretty outdated

Oh, yes, it is.  Current kpse also has the "side effect" that on most
systems, users are able to fill up the /var/ partition by generating
pixel fonts...  

Karl (or was it Olaf?) once said there are plans for a complete
replacement of libkpathsea, named kpse - would that be obsolete with
luatex?  Could there be a C wrapper about lua's kpse?

> sure, but (i'm not sure if this is still true) running tex live 
> alongside a tetex was always kind of problematic due to path settings 
> and this autoparent mess then deriving locations of texmf.cnf from it

This is probably still a problem in standard-setup systems.  

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-24 13:34             ` Frank Küster
@ 2006-10-24 14:33               ` Hans Hagen
  0 siblings, 0 replies; 24+ messages in thread
From: Hans Hagen @ 2006-10-24 14:33 UTC (permalink / raw)


Frank � wrote:
>
> Ah, I didn't know that.  pdftex 1.40 doesn't have this already, has it?
>   
not that i know, but the latest mp may do it already (esp mp is tricky 
because binary and pool have different names)
>
> Karl (or was it Olaf?) once said there are plans for a complete
> replacement of libkpathsea, named kpse - would that be obsolete with
> luatex?  Could there be a C wrapper about lua's kpse?
>
>   
i have (an experimental) luatools.lua which acts like kpsewhich and is 
just as fast as kpsewhich

at some point it may end up in the context distribution as playground;

Hans


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23  8:35 ConTeXt on Debian: The wiki entry Frank Küster
                   ` (2 preceding siblings ...)
  2006-10-23 20:47 ` Sanjoy Mahajan
@ 2006-10-25  6:52 ` Gerhard Kugler
  2006-10-25  8:55   ` Frank Küster
  3 siblings, 1 reply; 24+ messages in thread
From: Gerhard Kugler @ 2006-10-25  6:52 UTC (permalink / raw)


On Mon, Oct 23, 2006 at 10:35:30AM +0200, Frank Küster wrote:
> or, if you have a bit experience, you can straight away add
> 	deb http://www.tug.org/texlive/Debian/ context/
> to your /etc/apt/sources.list file and install context. After this,
> please tell us our experiences/failures/suggestions.
> 

Frank,

is this truely a valid line for sources.list?

My apt shows errors with this line.

Gerhard

-- 
Gerhard Kugler
Psychotherapeut
Bensheim (Germany)
http://www.psychotherapie-kugler.de

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-25  6:52 ` Gerhard Kugler
@ 2006-10-25  8:55   ` Frank Küster
  0 siblings, 0 replies; 24+ messages in thread
From: Frank Küster @ 2006-10-25  8:55 UTC (permalink / raw)


Gerhard Kugler <praxis@psychotherapie-kugler.de> wrote:

> On Mon, Oct 23, 2006 at 10:35:30AM +0200, Frank Küster wrote:
>> or, if you have a bit experience, you can straight away add
>> 	deb http://www.tug.org/texlive/Debian/ context/
>> to your /etc/apt/sources.list file and install context. After this,
>> please tell us our experiences/failures/suggestions.
>> 
>
> Frank,
>
> is this truely a valid line for sources.list?

Yes, I've got plenty of those.

> My apt shows errors with this line.

which errors?

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ConTeXt on Debian: The wiki entry
  2006-10-23 11:39   ` Frank Küster
  2006-10-23 18:15     ` Taco Hoekwater
@ 2006-10-25 13:37     ` Hans Hagen
  1 sibling, 0 replies; 24+ messages in thread
From: Hans Hagen @ 2006-10-25 13:37 UTC (permalink / raw)


Frank � wrote:
>> Yes, it is. ConTeXt does not support only pdfetex, but all major
>> engines, like XeTeX and Aleph. I have formats in:
>> 	
>>    $TEXMF/web2c/aleph/
>>    $TEXMF/web2c/luatex/
>>    $TEXMF/web2c/pdfetex/
>>    $TEXMF/web2c/xetex/
>>     
>
> Ah, okay, that's clear.  Has this already been this way one year ago
> when texlive2005 was released?  Do you know whether the TeXlive
> developers are aware of that?
>   
sure, but as taco explained in a previous mail, it was considered to be 
to complicated to adapt fmtutil to this which is why texexec tries to 
take care of it
>
>> It is almost certainly better to ignore/block fmtutil and use texexec
>> instead. Properly setting up a ConTeXt update is not necesarily limited
>> to format generation only.
>>     
>
> Hm.  What are the other things that need to be done?
>   
texexec can instruct context in ini mode what patterns to preload, which 
font/encoding to default to, which combination of interface and message 
interface to use, etc

in the case of luatex (we're experimenting with that now) it may also 
involve preparing lua startup scripts in the case of kpse overloading 
and such
>
> - fix fmtutil and updmap so that they do the right thing for ConTeXt
>   
i cannot answer that bacuse i don't use updmap but others on this list 
may know
> - or implement a way to automate calling texexec.  This would include
>   using some configuration file, since not everybody who has aleph or
>   xetex installed also wants a context format for this engine.
>   
indeed; for now you can safely assume that those using aleph of xetex 
will make formats with "texexec --make --xetex | --aleph" if only 
because they need to be able to tweak their system to the latest 
features in those systems anyway (esp xetex involves  more than just the 
xetex binary)
> To me, as a TeXlive and teTeX guy, it seems preferrable to choose option
> 1 and fix the existing distribution scripts.  However, I don't know yet
> what else is needed when ConTeXt is updated, therefore I might be wrong,
> and switching to texexec might actually be better.  But then this should
> be done consistently, and fmtutil should drop context handling
> completely (or just call texexec).
>   
just calling texexec may be a safe option; handling context directly is ok, but then it should be able to handle engine paths (but that has been fixed by now, if i understood the other mails right) 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 24+ messages in thread

* ctxtools unix puzzles
  2006-10-24  7:22         ` Taco Hoekwater
  2006-10-24  8:24           ` Frank Küster
@ 2006-11-01 21:30           ` plink
  2006-11-01 22:13             ` Hans Hagen
  2006-12-25 23:54             ` mkiv files plink
  1 sibling, 2 replies; 24+ messages in thread
From: plink @ 2006-11-01 21:30 UTC (permalink / raw)


Hi,

is it possible that the ruby script version numbers are not always updated?

I am getting a 648 line diff file when I compare two different 1.3.3 
versions of the ctxtools.rb file.

One of them, the smaller and older one, had some problems with quotes 
around environment variables, and it couldn't really upgrade the system 
because of a problem with unzip and execute permissions on texmfstart.rb

The other one has the same problem with execute permissions on 
texmfstart.rb, ending in the *slightly* dutchified report():

unable to remak formats

Or is there a way to call texmfstart.rb from the unix stub files without 
giving it execute permissions?


Jak.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: ctxtools unix puzzles
  2006-11-01 21:30           ` ctxtools unix puzzles plink
@ 2006-11-01 22:13             ` Hans Hagen
  2006-12-25 23:54             ` mkiv files plink
  1 sibling, 0 replies; 24+ messages in thread
From: Hans Hagen @ 2006-11-01 22:13 UTC (permalink / raw)


plink@veribox.net wrote:
> I am getting a 648 line diff file when I compare two different 1.3.3 
> versions of the ctxtools.rb file.
>
>   
indeed, i only change numbers when i feel that there is are real changes (

> One of them, the smaller and older one, had some problems with quotes 
> around environment variables, and it couldn't really upgrade the system 
> because of a problem with unzip and execute permissions on texmfstart.rb
>
> The other one has the same problem with execute permissions on 
> texmfstart.rb, ending in the *slightly* dutchified report():
>
> unable to remak formats
>
> Or is there a way to call texmfstart.rb from the unix stub files without 
> giving it execute permissions?
>   
i dunno, but "ruby pathtotexmfstart ... " should work since then we're talking about text files

Hans 
 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 24+ messages in thread

* mkiv files
  2006-11-01 21:30           ` ctxtools unix puzzles plink
  2006-11-01 22:13             ` Hans Hagen
@ 2006-12-25 23:54             ` plink
  1 sibling, 0 replies; 24+ messages in thread
From: plink @ 2006-12-25 23:54 UTC (permalink / raw)


Hi,

I am wondering if there are some of the mkiv files available anywhere? 
It would make luatex experiments so much more ConTeXish ...

Thanks.

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2006-12-25 23:54 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-23  8:35 ConTeXt on Debian: The wiki entry Frank Küster
2006-10-23 10:25 ` Renaud AUBIN
2006-10-23 10:58 ` Taco Hoekwater
2006-10-23 11:39   ` Frank Küster
2006-10-23 18:15     ` Taco Hoekwater
2006-10-23 19:01       ` Frank Küster
2006-10-24  7:22         ` Taco Hoekwater
2006-10-24  8:24           ` Frank Küster
2006-10-24  8:57             ` Hans Hagen
2006-10-24  8:57             ` Taco Hoekwater
2006-11-01 21:30           ` ctxtools unix puzzles plink
2006-11-01 22:13             ` Hans Hagen
2006-12-25 23:54             ` mkiv files plink
2006-10-25 13:37     ` ConTeXt on Debian: The wiki entry Hans Hagen
2006-10-23 20:47 ` Sanjoy Mahajan
2006-10-23 21:48   ` Hans Hagen
2006-10-24  5:53     ` Frank Küster
2006-10-24  8:18       ` Hans Hagen
2006-10-24  9:01         ` Frank Küster
2006-10-24 11:33           ` Hans Hagen
2006-10-24 13:34             ` Frank Küster
2006-10-24 14:33               ` Hans Hagen
2006-10-25  6:52 ` Gerhard Kugler
2006-10-25  8:55   ` Frank Küster

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).