Spec URL: http://people.redhat.com/jnovy/files/texlive/texlive-texmf.spec SRPM URL: http://people.redhat.com/jnovy/files/texlive/texlive-texmf-2007-0.1.20070212rc.src.rpm Description: This is the largest part of TeXLive 2007 formatting system, containing noarch parts -> the texmf tree. For more information: Successfull completion of this review and addition of this package is a blocker of TeXLive inclusion in F7: http://fedoraproject.org/wiki/Releases/FeatureTexLive
I'd like to test texlive packages. You say this is just 1 part of the whole package? Any ETA for the remainder of the packages?
Yes, the whole addition of TeXLive will need inclusion of three separate source packages: texmf (request filed), texmf-errata (request filed) and binaries. I put the WIP SRPM of the binary texlive to: http://people.redhat.com/jnovy/files/texlive/ but I'll file a review request for it as soon as it's fixed. In the meantime you can have a look at the spec if you wish.
I can get started on these.
Any solution for the texlive binaries compilation error (statically freetype linking) ?
The problem with static linking of the freetype library is that texlive requires libttf (which is a part of the freetype project) but is neither a part of freetype nor freetype-devel we have in F7. So that the configure script will fallback to use an internal freetype which contains libttf. I made the TeXLive rpms compilable/installable and some basic testing shows that it works as expected, but some consistency fixes will be definitely needed. The new RPMs are here: http://people.redhat.com/jnovy/files/texlive/texlive-texmf-2007-0.2.fc8.src.rpm http://people.redhat.com/jnovy/files/texlive/texlive-texmf.spec I'm going to file a separate review request for the TexLive binaries and add a dependency to this bug.
Review request for TeXLive binaries is now filed in bug 242416.
How can I test this? I can't easily remove tetex: rpm -e --test tetex-latex error: Failed dependencies: tetex-latex is needed by (installed) xmltex-20020625-8.noarch tetex-latex >= 3.0 is needed by (installed) jadetex-3.12-13.1.1.noarch tetex-latex is needed by (installed) linuxdoc-tools-0.9.21-8.fc7.x86_64 tetex-latex is needed by (installed) a2ps-4.13b-65.fc7.x86_64 Should texlive have provides for tetex-whatever?
The texlive already contains needed Provides to replace tetex, it still doesn't contain hard Obsoletes. The easiest way to go now is to uninstall xmltex/jadetex/linuxdoc-tools/a2ps, remove all tetex packages, install texlive-texmf-* and texlive-* (which actually matches the tetex-* ones) and install the removed apps again. It's a bit ugly, but better than explicit obsoletes for now.
I just uploaded new SRPMS/RPMS/specs to http://people.redhat.com/jnovy/files/texlive/ There are also two new subdirs there. First, "noarch" contains the prebuilt texlive-texmf rpms and "x86_64" contains rpms with texlive binaries. I've done so to let you test the new TeXLive 2007 without need to recompile it from the huge SPRMS if you want to just test it.
I just installed the texlive* packages (see complete list below) on F7, hoping to try them out on some of my LaTeX projects. At my first attempt, pdflatex aborted: $ pdflatex pgh-pm-perl-and-r.ltx This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. kpathsea: Running mktexfmt pdflatex.fmt I can't find the format file `pdflatex.fmt'! $ Is there a dependency or perhaps a bit of %post magic that is missing from the specs? Packages installed: texlive-texmf-dvips-2007-0.3.fc8 texlive-texmf-fonts-2007-0.3.fc8 texlive-dvips-2007-0.3.fc8 texlive-dviutils-2007-0.3.fc8 texlive-texmf-common-2007-0.3.fc8 texlive-texmf-afm-2007-0.3.fc8 texlive-texmf-latex-2007-0.3.fc8 texlive-latex-2007-0.3.fc8 texlive-2007-0.3.fc8 texlive-afm-2007-0.3.fc8 texlive-texmf-2007-0.3.fc8 texlive-fonts-2007-0.3.fc8 P.S. Thanks for packaging TeX Live! Judging from the specs, it couldn't have been easy.
I just uploaded the new texlive packages: http://people.redhat.com/jnovy/files/texlive/ Main features/differences from the previous version: 1. dropped former texjive zip list for the texmf trees and texlive now uses the zips generated from the scheme-tetex.tpm from upstream 2. reintroduced texlive-errata updating scheme Tom, this means the pdflatex will work for you since fmtutil now regenerates all fmt files correctly due to correct dependency resolution. Seems like we have the first functional texlive release based on scheme-tetex now.
Jindrich, I'm confirming that the most-recent build fixed the can't-find-the-format-file problem.
The new version (0.5) of texlive-texmf is now available from: http://people.redhat.com/jnovy/files/texlive/ Main features are that the style list is derived directly from teTeX so no important one should be missing. Also the total size of the texmf srpm is now about 180M.
Nearly final version 0.6 is now available again from: http://people.redhat.com/jnovy/files/texlive/ It now uses bz2'd texmf tree, which now contains more styles and is more consistent. There was a mistake in generation of style list from tetex in the previous release. The contents of the texmf tree are now close to be final (just in case it is not now) So please have a look at this version and focus on contents. Thanks!
Rex, are you planning to do the review? We have not much time if we want to see texlive in F8.
Ugh, life/work/kde4 got in the way, I can't promise anything beyond when I get round-tuit, sorry. Any one else is free to beat me to the punch(review), I'll help where/when I can.
I just tried to install TexLive 2007 on a F7 system which already has tetex following the instructions on this page http://people.redhat.com/jnovy/files/texlive/__README__ I installed teckit and teckit-devel using the Fedora development repo. Then I ran curl http://people.redhat.com/jnovy/files/texlive/packages/list | xargs -n1 curl -O followed by rpm -Uhv *.rpm I got the following error since my arch is x86. error: Failed dependencies: libc.so.6()(64bit) is needed ....... So I just executed rpm -Uhv *noarch.rpm but I get the following error message file /usr/share/texmf/tex/latex/minitoc/estonian.mld from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-latex-3.0-39.fc7 file /usr/share/texmf/tex/latex/minitoc/ethiopia.mld from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-latex-3.0-39.fc7 file /usr/share/texmf/tex/latex/minitoc/ethiopian.mld from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-latex-3.0-39.fc7 ... ... ... The README file indicates that the tetex will be automatically uninstalled "This will install the noarch and x86_64 packages to your system and replace tetex if it's already installed on your system." Also I noticed that running this command curl http://people.redhat.com/jnovy/files/texlive/packages/list | xargs -n1 curl -O downloaded the following rpms texlive-2007-0.7.fc8.x86_64.rpm texlive-afm-2007-0.7.fc8.x86_64.rpm texlive-dvips-2007-0.7.fc8.x86_64.rpm texlive-dviutils-2007-0.7.fc8.x86_64.rpm texlive-fonts-2007-0.7.fc8.x86_64.rpm texlive-latex-2007-0.7.fc8.x86_64.rpm texlive-texmf-2007-0.7.fc8.noarch.rpm texlive-texmf-afm-2007-0.7.fc8.noarch.rpm texlive-texmf-common-2007-0.7.fc8.noarch.rpm texlive-texmf-dvips-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-afm-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-common-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-dvips-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-fonts-2007-0.7.fc8.noarch.rpm texlive-texmf-errata-latex-2007-0.7.fc8.noarch.rpm texlive-texmf-fonts-2007-0.7.fc8.noarch.rpm texlive-texmf-latex-2007-0.7.fc8.noarch.rpm texlive-xdvi-2007-0.7.fc8.x86_64.rpm and this list does not have "texlive-2007*.noarch.rpm". Is there something wrong with my installation procedure. I am also eager to see texlive in F8.
Aravind, I only provided the x86_64 binaries, because of quota on my people.redhat.com account, so the packages won't work on your i?86 arch. It you want to install texlive and test in on i386, you need to rebuild the packages for i386, these instructions are in the section "How to build TeXlive and replace teTeX from a local build" in the README file. teTeX doesn't provide any noarch packages, so it's normal that the noarch part of the texlve texmf tree conflicts with tetex packages providing the same stuff. You need to pass all packages to the RPM transaction to correctly obsolete tetex.
2 problems: 1) conflict: sudo rpm -Uhv *.rpm Preparing... ########################################### [100%] file /usr/share/texmf/tex/latex/eurofont/eurofont.cfg from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-eurofont-1.1.3-6.fc6 file /usr/share/texmf/tex/latex/eurofont/uzmvs.fd from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-eurofont-1.1.3-6.fc6 file /usr/share/texmf/tex/latex/eurofont/uzpeur.fd from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-eurofont-1.1.3-6.fc6 file /usr/share/texmf/tex/latex/eurofont/uzpeuss.fd from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-eurofont-1.1.3-6.fc6 file /usr/share/texmf/tex/latex/eurofont/uzpeutt.fd from install of texlive-texmf-latex-2007-0.7.fc8 conflicts with file from package tetex-eurofont-1.1.3-6.fc6 2) Missing lmodern (this was included with tetex).
Test with trivial file (hello.tex) goes into latex 2.09 compat mode and dies: pdflatex hello.tex This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode (./hello.tex LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, arabic, basque, bulgarian, coptic, welsh, czech, slovak, german, ng erman, danish, esperanto, spanish, catalan, galician, estonian, farsi, finnish, french, greek, monogreek, ancientgreek, croatian, hungarian, interlingua, ibyc us, indonesian, icelandic, italian, latin, mongolian, dutch, norsk, polish, por tuguese, pinyin, romanian, russian, slovenian, uppersorbian, serbian, swedish, turkish, ukenglish, ukrainian, loaded. (/usr/share/texmf/tex/latex/base/latex209.def Entering LaTeX 2.09 COMPATIBILITY MODE ************************************************************* !!WARNING!! !!WARNING!! !!WARNING!! !!WARNING!! This mode attempts to provide an emulation of the LaTeX 2.09 author environment so that OLD documents can be successfully processed. It should NOT be used for NEW documents! New documents should use Standard LaTeX conventions and start with the \documentclass command. Compatibility mode is UNLIKELY TO WORK with LaTeX 2.09 style files that change any internal macros, especially not with those that change the FONT SELECTION or OUTPUT ROUTINES. Therefore such style files MUST BE UPDATED to use Current Standard LaTeX: LaTeX2e. If you suspect that you may be using such a style file, which is probably very, very old by now, then you should attempt to get it updated by sending a copy of this error message to the author of that file. *************************************************************
Sorry my mistake, ignore comment #20
Working, but I have tons of warnings like this: {/home/nbecker/.texlive2007/texmf-var/fonts/map/pdftex/updmap/pdftex.map pdfTeX warning: pdflatex (file /home/nbecker/.texlive2007/texmf-var/fonts/map/p dftex/updmap/pdftex.map): ambiguous entry for `ebbx10': font file present but n ot included, will be treated as font file not present
There's a new version of texlive packages (0.8) downloadable from: http://people.redhat.com/jnovy/files/texlive/ The prebuilt packages are now available also for i386. I removed sources and useless tpms from the tarball what decreased the SRPM size of about 15M. There were missing some pool files that are now added. Neal, I'll remove euro fonts in the next release to avoid this conflict. The warnings seems to be caused by updmap which is likely used to generate the font map files from incorrectly set updmap.cfg. I'm having a look at it.
I installed the latest on a F8Test1 system. Installation was without a glitch. I had to remove tetex which was part of F8Test1, which was strange. I though that teTex would have been at least removed if not replace by TeXLive. I am yet to run LaTeX with my test files. I will do it soon and report if I encounter any problem. The last rpm on the list.noarch is texlive-xdvi-2007-0.8.fc8.x86_64.rpm. I guess if you are installing for i386 it is already included in list.i386 (besides it is for x86_64).
Created attachment 161270 [details] rpm build errors I was thinking about attempting this review, however I cannot build the package (on F7), due to files not being installed. Attached is the pertinent output from rpmbuild.
'mock' is your friend.
(In reply to comment #26) > 'mock' is your friend. Well, last time I tried to setup mock (which was a while ago), setting it up was *not* my friend. Perhaps I'll try again. No promises on getting it set up any time soon. :-(
The license is listed as distributable. Currently this is a no-no. I've already contacted Spot, and he's looking into what label is appropriate.
Setting FE-Legal on this one. It includes LOTS of stuff that is under non-free licenses. Emailed Matthrew, Jindrich, fedora-legal-list, upstream.
Version of 0.9 is now available via the yum repo for i386 and x86_64: http://people.redhat.com/jnovy/files/texlive/texlive.repo just install it to /etc/yum.repos.d/ and yum install texlive (and texlive-latex). The new packages contain updated xpdf-3.02 from upstream to fix CVE-2007-3387, pdftex no more links statically with libstdc++, xdvi.xaw3d is now part of texlive-xdvi and contains other packaging fixes that mostly affects upgrading from tetex. The new texmf packages contain packaging fixes, it obsoletes tetex-eurofont and tetex-tex4ht as it's part of TeXLive. We can add tetex-eurofont and tetex-tex4ht maintainers to comaintainer list so that they can maintain it in TeXLive if they are interested. License audit is now in progress, currently finished for texlive-texmf and some license changes are discussed upstream.
The use of sources isn't right currently. The source urls should be used. The source urls aren't currently versionned, so I think that it would be good to contact upstream to ask for a versionned directory containing the archives (or maybe the whole texlive hierarchy).
This bug looks like it is ASSIGNED but to "nobody". Shouldn't it be ASSIGNED to the package reviewer? (Likewise for bug #242416).
(In reply to comment #32) > This bug looks like it is ASSIGNED but to "nobody". Shouldn't it be ASSIGNED to > the package reviewer? (Likewise for bug #242416). Or otherwise switched back to NEW?
You can't easily switch tickets back to NEW. (It sometimes suffices to close the ticket, then reopen it, then clear the "reopened" keyboard, but it is certainly not worth the trouble.) The current state of this ticket is just fine.
(In reply to comment #30) > Version of 0.9 is now available via the yum repo for i386 and x86_64: > > http://people.redhat.com/jnovy/files/texlive/texlive.repo > > just install it to /etc/yum.repos.d/ and yum install texlive (and texlive-latex). we're running this on an experimental dc7 machine. had problems (so far) with: maps for cm-super family maps for fourier family in both cases, updmap was building maps using dvipdfm components for the family. this produces a corrupt pdftex map (at least). installing the dvips maps for those families from the tex-live dvd solved the problem pfb files for cm-super files absent, so installed from the dvd, too
Another one: texmf.cnf has TEXMFLOCAL = $SELFAUTOPARENT/../texmf-local this results in $ kpsewhich -expand-var "\$TEXMFLOCAL" //../texmf-local which isn't helpful. since all other tree specs in the file are absolute, i guess the local tree ought to be, too.
What's the current licensing situation? Are we going to be stuck with the stale tetex for another Fedora release? :-(
The licensing is now right for the texlive package. For texlive-texmf I think it is right too, unless I am wrong Spot did an audit.
He did an audit, which is how the issues have been found in the first place, my question is whether these are or are being resolved!
(In reply to comment #39) > He did an audit, which is how the issues have been found in the first place, my > question is whether these are or are being resolved! afaik, there are no outstanding licence issues on the tex-live to-do list. there have been one or two packages removed from the repository since the distribution at the beginning of the year. if there are others known, forwarding the details to tex-live would be welcome, otherwise nothing will change. fwiw, debian are already distributing tex-live, having done some pretty rigorous work on licensing. which isn't to say they can't have missed anything...
Have you seen this list? https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00014.html
I propose the following additions to the texmf substitutions: %{__sed} -i 's?^TEXMF =.*?TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}?' %{__sed} -i 's?^TEXMFLOCAL =.*?TEXMFLOCAL = %{_texmf_local}?' Also context.cnf is quite different from texmf.cnf. Is it an issue? I think not, since it is additional to texmf.cnf. There is a -p missing for the first install. in the tkdefaults patch, the defaults should be like in texlive and the appropriate Requires set. Instead of doing a link for the cmap ghostscript resources I think that the texmf.cnf should be changed. Also I think that # move the configuration files and symlink them is wrong. Better leave as is. mktex.cnf should certainly be under the sole user control, and in /etc/texmf/web2c The common package may also be called texlive-common and it should certainly be in Requires for more packages, for example texlive, texlive-fonts, texlive-dvips, xdvi, mendexk, dvipdfmx. The install-info should not have .gz and have || :. The scriptlet commands should be in Requires(...). I hope that rpm can figure out that the binary package has in fact to be installed before the texmf package to be able to run the scriptlet. Also it seems to me that at least updmap should be run as a texmf package scriptlet, and not as the main package scriptlet, since all that updmap needs is in the texmf packages, including the config file. As usual I can do patch for these issues (except for the scriptlets, this needs more discussion).
(In reply to comment #42) > Also it seems to me that at least updmap should be run as a > texmf package scriptlet, and not as the main package scriptlet, > since all that updmap needs is in the texmf packages, including > the config file. why bother? where should one draw the line between applications (like tex) and tools like (texhash)? where should kpsewhich live -- obviously a tool, but implemented as a compiled program?
(In reply to comment #41) > Have you seen this list? > https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00014.html yes, and read the responses to it. it occurs to me to wonder whether the old tetex rpms ought to be subject to the same treatment. (a lot of packages have changed since then, and we try to guide people towards free licences when updates are submitted to the archive.) for sure, two of the packages mentioned (fancybox.sty and multicol.sty) are essentially identical (though i'm with frank mittelbach in thinking that the complaint about multicol.sty is spurious). (fwiw, if you remove multicol, you should remove latex, since the latex team list multicol as a required package.)
Well, spot has apparently cleared the multicol license upon rereading, see: https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00017.html This leaves: * Literat license - what's up with that one? Should the affected files just be removed? * AFPL font files: already removed upstream as per: https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00030.html (they're just old versions of the GPLed GhostScript fonts) but need to be removed downstream (in the Fedora package) too if there isn't yet any new release tarball from upstream without these. * The 2 files (fancybox.sty and pcatcode.sty) under Artistic v1. Spot: Does texlive really have to be blocked for this one? Considering these are both already in the existing tetex packages, keeping texlive on hold won't actually fix the problem. Plus, there are still other packages with Artistic v1 files in them too.
(In reply to comment #45) > Well, spot has apparently cleared the multicol license upon rereading, see: > https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00017.html great. > This leaves: > * Literat license - what's up with that one? Should the affected files just be > removed? i would recommend not bothering with it. it's a small russian foundry (sfaict) and there seems to have been a long history to getting them onto the archive, so we just installed them when they arrived recently. i doubt they'll make the next release of tex-live, with that licence, so as well for redhat to ignore them. > * AFPL font files: already removed upstream as per: > https://www.redhat.com/archives/fedora-legal-list/2007-August/msg00030.html > (they're just old versions of the GPLed GhostScript fonts) but need to be > removed downstream (in the Fedora package) too if there isn't yet any new > release tarball from upstream without these. ah. i wonder if there's something i need to do on the archive... > * The 2 files (fancybox.sty and pcatcode.sty) under Artistic v1. Spot: Does > texlive really have to be blocked for this one? Considering these are both > already in the existing tetex packages, keeping texlive on hold won't actually > fix the problem. Plus, there are still other packages with Artistic v1 files in > them too. there is a copy of fancybox on ctan that has been relicensed under lppl www.tex.ac.uk/tex-archive/macros/latex/contrib/seminar/inputs/fancybox.sty but there are two under artistic v1 as well (presumably) as .doc files. i'll get those sorted out. (the author is incommunicado, but he's told seb rahtz to "deal with his stuff" as necessary, i think.) the present situation is ludicrous, so something needs to be done. pcatcode is weird: everything else published by the ams is under lppl, so it's not clear to me what happened there. i've had recent mail from barb beeton, so she's active in some sense -- will mail her to ask what's going on. (we can't just change pcatcode, since we mirror it from the ams.) (nb, texlive _does_ still need work, even if the licensing is sorted: witness my first two posts to this thread.)
(In reply to comment #45) > * The 2 files (fancybox.sty and pcatcode.sty) under Artistic v1. Spot: Does > texlive really have to be blocked for this one? Considering these are both > already in the existing tetex packages, keeping texlive on hold won't actually > fix the problem. Plus, there are still other packages with Artistic v1 files in > them too. Yes, there are other packages with Artistic v1 licensing, but we're working on getting them relicensed. We're not letting new packages come in with the old Artistic license. Specifically, upstream has removed fancybox.sty and relicensed pcatcode.sty. I think that the texlive folks have handled all of the licensing concerns I found in the audit, it would be for the best if we could ask them to do a fresh tarball release, then rebase on that.
But this is not really a new package, it is a replacement for tetex, with much of the same files, and in fact these 2 files were already in tetex. But if this has been solved upstream, the point is moot anyway, so let's not waste time arguing this. We do need a fresh tarball with the licensing issues fixed though.
(In reply to comment #47) > > * The 2 files (fancybox.sty and pcatcode.sty) under Artistic v1. Spot: Does > > texlive really have to be blocked for this one? Considering these are both > > already in the existing tetex packages, keeping texlive on hold won't > > actually fix the problem. Plus, there are still other packages with > > Artistic v1 files in them too. > > Yes, there are other packages with Artistic v1 licensing, but we're working on > getting them relicensed. We're not letting new packages come in with the old > Artistic license. fair enough, imo. > Specifically, upstream has removed fancybox.sty really? i've just sorted out the confusion created by an earlier re-licensing of fancybox as lppl, and the situation (on ctan) is now completely clear -- only one copy, lppl, catalogued as lppl. > and relicensed pcatcode.sty. I definitely not: that's an ams package. i've approached the ams about it, and they say there's an upcoming release that will have a revised (free) licence statement. the release is scheduled for 2007-10-01; if it arrives (fingers firmly crossed) it will be on ctan by 2007-10-02 (uk time), and probably in the tex-live repository later that day (california time ;-). pcatcode is actually part of the amsrefs bundle, and pro tem i've marked that bundle as artistic v1 licensed, in the catalogue. i hadn't noticed that single file in the bundle that wasn't licensed lppl (i suspect the ams hadn't either). > think that the texlive folks have handled all of the licensing > concerns I found in the audit, good -- even though i think you're slightly confused about it all... > it would be for the best if we could ask them to do a fresh > tarball release, then rebase on that. i had assumed that redhat was working from the repository. tex-live's not supplied me (as ctan mirror of tug.org) with a texmf-tarball for years -- i currently get a disc image and tarballs of sources. if all else fails, i could build a tarball from my copy of the repository, and upload it to redhat, but it seems an awful kerfuffle. preparing a new disc image (including building all the sources for all supported platforms) takes more than a month, i think. i wouldn't recommend waiting for that (next scheduled delivery, ~= 2008-01-15).
> i've just sorted out the confusion created by an earlier re-licensing > of fancybox as lppl, and the situation (on ctan) is now completely > clear -- only one copy, lppl, catalogued as lppl. As far as I can tell, this means it should be safe to get this file back in (in its LPPL version) if it really has been removed. spot? > i've approached the ams about it, and they say there's an upcoming > release that will have a revised (free) licence statement. the > release is scheduled for 2007-10-01; if it arrives (fingers firmly > crossed) it will be on ctan by 2007-10-02 (uk time), and probably in > the tex-live repository later that day (california time ;-). Sounds good (except for the wait). Unfortunately, I don't know who the upstream contact spot (Tom Callaway) spoke to was, I only know what spot posted to this bug and to the mailing lists. As for the tarballs, the current specfile has this to say: # Source0 comes as a result from scripts that look for files in teTeX and assigns appropriate # TeXLive styles to it so that no style present in teTeX will be missing in TeXLive. # it contains expanded packages from ftp://tug.org/texlive/Contents/inst/archive/ # Scripts that are used for that are available at http://people.redhat.com/jnovy/files/texlive/scripts/ Source0: texlive.texmf-%{version}.tar.bz2 # Source1 is http://www.tug.org/texlive/Contents/inst/archive/texmf-var.zip Source1: texlive.texmf-var-%{version}.zip so the canonical sources for the current tarball are the packages in archive/. Since the Fedora tarball is recomposed anyway, I guess this means Jindrich Novy can/should also take care of the updating, right?
(In reply to comment #42) > I propose the following additions to the texmf substitutions: > %{__sed} -i 's?^TEXMF =.*?TEXMF = > {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}?' > %{__sed} -i 's?^TEXMFLOCAL =.*?TEXMFLOCAL = %{_texmf_local}?' Could you be more verbose on these substitutions? > There is a -p missing for the first install. There were two missing '-p's actually, added. > in the tkdefaults patch, the defaults should be like in texlive > and the appropriate Requires set. I don't think so, the defaults there should match Fedora, so that it has to be tuned appropriatelly. > Instead of doing a link for the cmap ghostscript resources > I think that the texmf.cnf should be changed. Please provide a patch for this. > Also I think that > # move the configuration files and symlink them > is wrong. Better leave as is. I don't think so. Storing config files to /etc is perfectly fine IMO. > mktex.cnf should certainly be under the sole user > control, and in /etc/texmf/web2c Moved. > The common package may also be called texlive-common > and it should certainly be in Requires for more packages, for > example texlive, texlive-fonts, texlive-dvips, xdvi, mendexk, > dvipdfmx. I decided to remove the common package as it's useless and moved bits from there to the main package. > The install-info should not have .gz and have || :. Indeed, added. > The scriptlet commands should be in Requires(...). I hope > that rpm can figure out that the binary package has in fact to > be installed before the texmf package to be able to run the > scriptlet. > > Also it seems to me that at least updmap should be run as a > texmf package scriptlet, and not as the main package scriptlet, > since all that updmap needs is in the texmf packages, including > the config file. Seems reasonable, please provide patch.
(In reply to comment #50) > Unfortunately, I don't know who the upstream contact spot (Tom Callaway) spoke > to was, I only know what spot posted to this bug and to the mailing lists. I think the whole conversation can be found in this thread: http://tug.org/mailman/htdig/tex-live/2007-August/014596.html and the upstream person is Karl Berry. > As for the tarballs, the current specfile has this to say: > # Source0 comes as a result from scripts that look for files in teTeX and > assigns appropriate > # TeXLive styles to it so that no style present in teTeX will be missing in > TeXLive. > # it contains expanded packages from > ftp://tug.org/texlive/Contents/inst/archive/ > # Scripts that are used for that are available at > http://people.redhat.com/jnovy/files/texlive/scripts/ > Source0: texlive.texmf-%{version}.tar.bz2 > # Source1 is http://www.tug.org/texlive/Contents/inst/archive/texmf-var.zip > Source1: texlive.texmf-var-%{version}.zip > so the canonical sources for the current tarball are the packages in archive/. > Since the Fedora tarball is recomposed anyway, I guess this means Jindrich Novy > can/should also take care of the updating, right? Yes, I will happily update the tarball as soon the legal things are clear.
(In reply to comment #51) > (In reply to comment #42) > > I propose the following additions to the texmf substitutions: > > %{__sed} -i 's?^TEXMF =.*?TEXMF = > > > {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}?' > > %{__sed} -i 's?^TEXMFLOCAL =.*?TEXMFLOCAL = %{_texmf_local}?' > > Could you be more verbose on these substitutions? The second one is rather logical. The default uses selfautoparent, which is completely inconsistent with the remaining of the packaging. For TEXMF, $TEXMFSYSCONFIG is better without !!, such that even if the user doesn't run mktexlsr his config files are taken into account. Otherwise I have put !!$TEXMFLOCAL before our directories such that the user additions are taken into account. > > in the tkdefaults patch, the defaults should be like in texlive > > and the appropriate Requires set. > > I don't think so, the defaults there should match Fedora, so that it has to be > tuned appropriatelly. I wanted to say like in the texlive Fedora package (xdg-utils, htmlviewer...) > > Instead of doing a link for the cmap ghostscript resources > > I think that the texmf.cnf should be changed. > > Please provide a patch for this. Ok. What about: if [ -d "%{_datadir}/ghostscript/`gs --version| cut -d . -f 1-2`/Resource/CMap" ] ; then cmap_dir="%{_datadir}/ghostscript/"`gs --version| cut -d . -f 1-2`"/Resource/CMap/" elif [ -d "%{_datadir}/ghostscript/Resource/CMap" ] ; then cmap_dir="%{_datadir}/ghostscript/Resource/CMap/" fi if [ z"$cmap_dir" != 'z' ]; then pushd texmf/web2c %{__sed} -i 's?^CMAPFONTS = .*?CMAPFONTS = .;$TEXMF/fonts/cmap//;'"$cmap_dir"'?' texmf.cnf popd fi > > Also I think that > > # move the configuration files and symlink them > > is wrong. Better leave as is. > > I don't think so. Storing config files to /etc is perfectly fine IMO. Once again config files under the packager/upstream control should be in %{_datadir}/texmf..., those under the user control should be in /etc/texmf... In the case of texlive-texmf context.cnf fmtutil.cnf texmf.cnf updmap.cfg should be under the packager/upstream control, but the user should be able to put his own files in /etc/texmf/web2c to augment/override the package files. And mktex.cnf should be in /etc/texmf/web2c under the user control, with %config(noreplace). > I decided to remove the common package as it's useless and moved bits from there > to the main package. Ok. > > The scriptlet commands should be in Requires(...). I hope > > that rpm can figure out that the binary package has in fact to > > be installed before the texmf package to be able to run the > > scriptlet. > > > > Also it seems to me that at least updmap should be run as a > > texmf package scriptlet, and not as the main package scriptlet, > > since all that updmap needs is in the texmf packages, including > > the config file. > > Seems reasonable, please provide patch. I will do later, I am still learning about those utilities/scriptlets and still trying to understand what/when to run them.
0.13 is out, please give it a try :) Changes to texlive-texmf: * Wed Sep 12 2007 Jindrich Novy <jnovy> - 2007-0.13 - move configuration files to the main texlive package - remove useless common subpackage and move its content to main package - increase default texmf.cnf limits so that xmlto works - don't call install-info in scriptlets if it doesn't exist - fix some multiple file ownerships - update ptex-texmf to 2.5 - use xdg-utils and htmlview in tkdefaults
(In reply to comment #54) > 0.13 is out, please give it a try :) > > Changes to texlive-texmf: > > * Wed Sep 12 2007 Jindrich Novy <jnovy> - 2007-0.13 but i note that you have not implemented my suggestion about map files, in comment 30. fwiw, this solves neal becker's problem mentioned in comment 22 (didn't notice that when i originally posted). as distributed (without my suggested change) the distribution is essentially unusable under pdftex. and since people are increasingly switching to pdf(la)tex... :-(
From a quick glance at 0.13, I am still not ok with putting files in /etc/texmf/web2c although they certainly should be modified by you or upstream (the user may still copy them to /etc/texmf/web2c). In my opinion for file in `ls %{buildroot}%{_texmf_conf}/web2c/ | egrep 'c(nf|fg)$'`; do filename="`basename ${file}`" ln -sf %{_texmf_conf}/web2c/${filename} %{buildroot}%{_texmf_main}/web2c/ done should just go away. There is a spurious end of line in the sed cmap substitution (my bad, should have provided a bug instead of a comment in bugzilla). In %files, there is %{_texmf_var}/web2c/mktex.cnf it is a bit suspicious since mktex.cnf seems to be (rightly) in %{_texmf_conf}/web2c. Moreover it should be config(noreplace), like %config(noreplace) %{_texmf_conf}/web2c/mktex.cnf
FYI: On Thu, Sep 20, 2007 at 03:10:26PM -0400, Jeremy Katz wrote: > Based on the discussion during today's FESCo meeting about the fact that > TeXLive still is not present in rawhide, we are moving TeXLive to be a > Fedora 9 feature rather than Fedora 8. > > Jeremy
(In reply to comment #35) > > had problems (so far) with: > maps for cm-super family > maps for fourier family > in both cases, updmap was building maps using dvipdfm components for > the family. this produces a corrupt pdftex map (at least). > > installing the dvips maps for those families from the tex-live dvd > solved the problem Could you please specify which maps exactly have you installed from the DVD to fix the warnings? > pfb files for cm-super > files absent, so installed from the dvd, too > Adding cm-super.zip to the collection set will increase the tarball/srpm size for texlive-texmf by cca 65MB, is it worth it?
(In reply to comment #58) > (In reply to comment #35) > > > > had problems (so far) with: > > maps for cm-super family > > maps for fourier family > > in both cases, updmap was building maps using dvipdfm components for > > the family. this produces a corrupt pdftex map (at least). > > > > installing the dvips maps for those families from the tex-live dvd > > solved the problem > > Could you please specify which maps exactly have you installed from the DVD to > fix the warnings? cm-super-t1.map cm-super-t2a.map cm-super-t2b.map cm-super-t2c.map cm-super-ts1.map cm-super-x2.map fourier.map were all being loaded from the directory texmf-dist/fonts/map/dvipdfm/context changing to copies from fonts/map/dvips/(cm-super|fourier) made things work. those files weren't in the rpm to start with. > > pfb files for cm-super > > files absent, so installed from the dvd, too > > Adding cm-super.zip to the collection set will increase the tarball/srpm size > for texlive-texmf by cca 65MB, is it worth it? they ought to be available, one way or another, but i understand the point. perhaps an adjunct rpm? (for my situation, there's no problem, since all target machines have ridiculously large discs... ;-) if they're not in the base rpm set, the fonts should not be in the map set. so either remove them manually from the configuration, or run a series of "updmap-sys disable Map" commands so that T1/cm family docs don't fail for lack of the .pfb files.
Good news first: installed texlive-* packages on a Fedora 8 system. Seems to work very well, lots of updated LaTeX packages etc. Thanks! The bad: $ yum update after adding texlive repo is not clean if you have tetex-doc installed. Nothing obsolete tetex-doc (don't even find texlive-doc package) and there are file conflicts between tetex-doc and mendexk: /usr/share/texmf/doc/mendexk/COPYRIGHT.jis /usr/share/texmf/doc/mendexk/ChangeLog /usr/share/texmf/doc/mendexk/README and tetex-doc and texlive: /usr/share/texmf/doc/ptex/ptex-src/Changes.txt
Yes, I excluded the texlive-doc package from the repository, because of the limited quota. It should work fine as soon as texlive-texmf is in rawhide. BTW. texlive-texmf-0.14 is now in the repository. The only change is move from htmlview to xdg-open.
Is this installable on f8, or will there be a backport for f8?
I'd like to have Comment #56 addressed. It doesn't seems so from a quick glance at 0.14. A promise to do so after import would be sufficient, though.
Neal, it should work just fine even for F8 as there is no significant difference between F8 and rawhide yet. Patrice, ok, I'm sure we could sort it out after texlive-texmf is imported. Patch is always appreciated ;-)
Ok, APPROVED.
New Package CVS Request ======================= Package Name: texlive-texmf Short Description: Architecture independent parts of the TeX formatting system Owners: jnovy Branches: InitialCC: Cvsextras Commits: yes
Successfully built, closing. Thanks for cooperation!