Talk:Features/TeXLive

To pass review the fonts parts of TEXLive must conform to Packaging:FontsPolicy

NicolasMailhot 20:36, 23 June 2009 (UTC)

texlive-fontspec should Require texlive-xkeyval --Mef 15:27, 20 August 2009 (UTC) DONE

texlive-xepersian should depend on: texlive-bidi, texlive-fontspec, texlive-xetex.noarch (.noarch seems to be required, otherwise yum picks the old texlive-xetex from 2007 package list, which is obsolete by texlive 2009). I guess that there are lots of such dependencies. Isn't there any automatic way to find them?! Also, isn't there any amsalpha.bst file in TexLive 2009?! I have a document which uses amsalpha as its bibstyle. None of the current packages provide this file. What has happened to it?! -- Hedayat 11:04 (updated on 12:40), 21 August 2009 (UTC).

texlive-fontspec dependencies are now fixed. Pulling in the texlive-xetex from the old TL2007 is now fixed as well with the newly added versioned Requires. Virtual provides such as tetex-latex are added for compatibility.

--jnovy 21:04, 23 August 2009 (UTC)

texlive-fontspec still has some issues (as of Jan 2010 -- packages from Nov 2009?). I had to add texlive-euenc and texlive-lm for it to stop complaining. --Mef 15:20, 19 January 2010 (UTC)

Latest upgrade (F14 repo)

After the latest upgrade pdflatex is reporting:

 kpathsea: Running mktexfmt pdflatex.fmt
 I can't find the format file `pdflatex.fmt'!

Edit: the same applies for other compilers (xetex, latex, etc.) as well.

pdflatex version is: texlive-latex-2010-13.svn16172.fc14.noarch --Piksi 21:41, 15 November 2010 (UTC)

SOLVED - I removed all texlive packages and reinstalled them, apparently the upgrade removed some crucial files. I hope this won't happen too often in the future, as it is quite tedious to remove ~2000 packages and reinstall them. --Piksi 12:01, 16 November 2010 (UTC)

'yum update' Dependency Errors

On Fedora 13 the new texlive repo works well! How do we deal with the dependency problem below? --Phil V 29 July 2010

 --> Processing Dependency: libkpathsea.so.4()(64bit) for package: evince-dvi-2.30.3-1.fc13.x86_64
 ---> Package texlive-kpathsea-doc.noarch 0:2010-8.svn19287.fc13 set to be updated
 --> Finished Dependency Resolution
 Error: Package: evince-dvi-2.30.3-1.fc13.x86_64 (@updates)
          Requires: libkpathsea.so.4()(64bit)
          Removing: kpathsea-2007-51.fc13.x86_64 (@updates)
          Available: kpathsea-2007-49.fc13.x86_64 (fedora)

I just installed texlive on Fedora 11 from your repo and I am having problems with dependency resolution. On doing "yum update" I get a dependency issue with kpathsea. The output is as follows,

 # yum update 
 Loaded plugins: keys, presto, refresh-packagekit, verify, versionlock
 Setting up Update Process
 Resolving Dependencies
 --> Running transaction check
 --> Processing Dependency: libkpathsea.so.4()(64bit) for package: evince-dvi-2.26.2-1.fc11.x86_64
 ---> Package texlive-kpathsea-doc.noarch 0:2010-4.17541.fc13 set to be updated
 --> Finished Dependency Resolution
 evince-dvi-2.26.2-1.fc11.x86_64 from installed has depsolving problems
   --> Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed)
 Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed)

I apologise if this is the wrong place to report the problem. --Fatka 15:04, 27 April 2010 (UTC)

hyphenation

The hyphenation for other languages than english is still not working (similarly to TL2009 in F12) unless the config is modified manually. Simply installing the required packages still produces the result below even though all the hyphenation pattern files exist under /usr/share/... :

Babel v3.8l and hyphenation patterns for english, dumylang, nohyphenation, loaded.

The issue seems to have been fixed in the latest TL2010-update. Thanks. --Piksi 15:37, 27 August 2010 (UTC)

This is no more an issue with the latest packages, is it? --jnovy 09:09, 09 October 2010 (UTC)

I confirm, the issue is fixed. --Piksi 21:44, 15 November 2010 (UTC)

Unfortunately the issue has now reappeared after the latest TL-update for F14. --Piksi 14:16, 6 April 2011 (UTC)

This is unfortunately still a problem in F16?

Package babel Warning: No hyphenation patterns were loaded for
(babel)                the language `ngerman'
(babel)                I will use the patterns loaded for \language=0 instead.

I don't exactly know if this is the same problem. What would be a workaround? Enaut 15:54, 4 January 2012 (UTC)

Identifying Package for Missing Font Metrics

Suppose I am rendering a complex LaTeX document. If I am missing a LaTeX style file, it is relatively easy to go from the LaTeX error message to a yum command that installs what I need. Unfortunately, the same is not true for missing font metrics. There is no obvious relationship between the name of the missing TeX font metrics file and the corresponding RPM:

Problem	First Line of LaTeX Error Output	Corrective Command
missing style file	! LaTeX Error: File `rccol.sty' not found.	yum install "tex(rccol.sty)"
missing font	kpathsea: Running mktextfm ptmr8t	yum install texlive-times

Perhaps the TeXLive font packages could add Provides to reflect the font metrics they offer? If texlive-times provided tex-font-metrics(ptmr8t), then one could install the missing font metrics using the command yum install "tex-font-metrics(ptmr8t)".

Is there a better way to manage this?

— Liblit 20:56, 14 September 2010 (UTC)

Good point! I will keep you updated when the font virtual provides will occur in the repository. - jnovy 21:34, 07 October 2010 (UTC)

The new TFM virtual provides are now added. In the example above you can now use yum install 'tex(ptmr8t.tfm)' to install texlive-times. --Jnovy 12:00, 19 October 2010 (UTC)

Unofficial texlive repo and rawhide

The Texlive for Fedora 14 repo (recommended for rawhide too) has fallen behind with the fork for Fedora 14. For example, parts of it use libpoppler.so.7(), while several rawhide packages demand libpoppler.so.8(). For me LaTeX is very much more important than, say, OpenOffice.org, others may disagree... Integrating texlive 2010 would be optimal. What is holding this back? Any way we could help?

- vonbrand 14:05 05 October 2010 (UTC)

I agree, there is no reason not to support a major TeX distribution like TeXLive. I am also willing to assist in getting TL2010 into the official repositories and available. --Piksi 19:50, 5 October 2010 (UTC)

I just created separate F15/rawhide branch containing packages built against new poppler in rawhide so let you test. Please report any problems if noticed :) - jnovy 21:30 07 October 2010 (UTC)

That's great! Is there anything that could be done with the unclear licensing issues in TL packages? --Piksi 15:51, 10 October 2010 (UTC)

Piksi, this page is dedicated to the legal audit: http://fedoraproject.org/wiki/Talk:Features/TeXLiveLegalAudit please feel free to submit comments/clarifications there, especially to packages with unclear licensing, to speed up the process, thanks! --Jnovy 15:51, 17 October 2010 (UTC)

Need PackageKit limit fixed prior to adoption

If the modular TeXLive packaging is going to be adopted for Fedora, PackageKit may need to be updated. It currently only handles 2500 package updates at a time; this limit is easily exceeded with TeXLive updates (I'm updating 3295 now), although more incremental rebuilds (only rebuilding packages changed) will likely mitigate this.

texdoc is essentially useless

Regardless of whether a *-doc package is installed, texdoc can't find any of them.

The only "texdoc" command I've tried that didn't tell me documentation wasn't found was "texdoc pstricks" that produced a single example figure instead of the pstricks manual.

On my Arch Linux distribution, texdoc will load any documentation that's installed. I don't know if there needs to be an ls-lR-type indexing after each doc install. If so, it should be done automatically.

Please fix this. It's annoying having to consult a web browser whenever I need a syntax refresher (especially because most TeX documentation is in PDF form, and opening PDF's in browsers is not necessarily the most reliable thing you can do on a Linux machine).