You are not logged in.
This is a
ME TOO
post
Offline
If the packages are ready, is it possible to put them into AUR? Or will they be moved directly into community? I need a newer version of koma-scripts, so the texlive packages could help me. Thanks a lot.
dante
Last edited by dante (2007-07-13 15:47:01)
"Lasciate ogni speranza, voi ch' entrate"
- Laßt jede Hoffnung hinter euch, ihr, die ihr eintretet -
Dante Alighieri
Offline
If the packages are ready, is it possible to put them into AUR? Or will they be moved directly into community? I need a newer version of koma-scripts, so the texlive packages could help me. Thanks a lot.
They should be in community quite soon. I won't upload them to AUR, for reasons I have already explained, but if you feel in the mood for compiling the whole beast, you can get my buildtree from here. The Koma-scripts are part of texlive-core, so you should not need more than that (with 97MB texlive-core is of course much more than what comes with tetex ).
And PLEASE, do give me your feedback (firmicus÷AT÷gmx÷DOT÷net ) if you encounter any problem, especially during compilation or installation. That would be really useful!
I should add however that I was a bit too quick to declare the packages "ready" a few days ago, since with the continuous help of Attila, I have been able to fix various things until this day. But the final packages should be ready this week-end or early next week, or so I hope.
Offline
Thanks Firmicus for the actual state. I'd really like to compile the stuff, my hardware is not a problem, but my internet connection Really slow here. But I can do this probably next week at the university.
dante
"Lasciate ogni speranza, voi ch' entrate"
- Laßt jede Hoffnung hinter euch, ihr, die ihr eintretet -
Dante Alighieri
Offline
Thanks Firmicus for your good work ! Looks like we are very close to get Tex Live in ArchLinux !
I actually try to compile the texlive-core part, but compilation fail in src/Work/libs/icu-xetex/tools/genrb in linking with a bunch of message like
../../lib/libsicui18n.a(ucol.ao): In function `ucol_close_3_4':
ucol.cpp:(.text+0x59f): undefined reference to `utrace_level_3_4'
ucol.cpp:(.text+0x5af): undefined reference to `utrace_level_3_4'
ucol.cpp:(.text+0x5e2): undefined reference to `utrace_level_3_4'
ucol.cpp:(.text+0x690): undefined reference to `utrace_data_3_4'
ucol.cpp:(.text+0x6ad): undefined reference to `utrace_entry_3_4'
ucol.cpp:(.text+0x6dc): undefined reference to `utrace_data_3_4'
also, I wonder why there are instructions in PKGBUILD to install with write permission for group. .ie lines like
install -d -m 775 $startdir/texmf/doc/man
and
find texmf* -type f -exec install -m664 '{}' $startdir/pkg/opt/texlive/'{}' \; || exit 1
Last edited by vfork_0x00f (2007-07-15 17:47:16)
Offline
Thanks Firmicus for your good work ! Looks like we are very close to get Tex Live in ArchLinux !
Thanks. I think we are very close indeed
I actually try to compile the texlive-core part, but compilation fail in src/Work/libs/icu-xetex/tools/genrb in linking with a bunch of message like
I never encountered that and it should not happen ... Can't help here!
Perhaps: Did you compile for 64bit architecture? Or do you use some non-standard CFLAGS?
also, I wonder why there are instructions in PKGBUILD to install with write permission for group. .ie lines like
install -d -m 775 $startdir/texmf/doc/man
and
find texmf* -type f -exec install -m664 '{}' $startdir/pkg/opt/texlive/'{}' \; || exit 1
You're right. That should not be (even though the group is root). I fixed that.
The PKGBUILDs you have used have since then (again) been improved a bit.
So be patient. We are almost there!
F
Offline
I think there is a conflict with the icu package (this package is installed as a depency by openoffice-base). I tried to add the option --with-system-icu to configure without success. I actually have to unistall icu to be able to build the texlive-core PKGBUILD.
Offline
I think there is a conflict with the icu package (this package is installed as a depency by openoffice-base). I tried to add the option --with-system-icu to configure without success. I actually have to unistall icu to be able to build the texlive-core PKGBUILD.
No. XeTeX builds statically with its own modified version of the icu library. There is no interaction whatsoever with the package icu.
Offline
I actually have to unistall icu to be able to build the texlive-core PKGBUILD.
Strange because my log of building texlive-core (icu 3.6-1 is installed) say that for compiling the shipped icu is used:
checking for ICU version numbers... release 3.4, library 34.0
Perhaps you can try it again with this command to see where the problem starts:
makepkg -c 2>&1 | tee build.log
Offline
I compiled texlive-core without problems Everything is working (at the moment)
dante
"Lasciate ogni speranza, voi ch' entrate"
- Laßt jede Hoffnung hinter euch, ihr, die ihr eintretet -
Dante Alighieri
Offline
First, thanks Firmicus and others for putting in the effort to package this puppy up.
I just built and installed texlive-core and thought you should know that both Bison (or yyac) and Flex (or lex) are build requirements.
Also, the bin files get installed into the directory /opt/texlive/bin, which isn't in the normal path. It's minor but should be fixed in the package build as many programs rely on our favorite tex commands being in the path.
Cheers!
Last edited by PDExperiment626 (2007-07-17 16:37:51)
... and for a time, it was good...
Offline
I just built and installed texlive-core and thought you should know that both Bison (or yyac) and Flex (or lex) are build requirements.
Just for Firmicus: I have bison and flex installed on my machine.
Also, the bin files get installed into the directory /opt/texlive/bin, which isn't in the normal path. It's minor but should be fixed in the package build as many programs rely on our favorite tex commands being in the path.
There is a /etc/profile.d/texlive.sh so i doesn't matter if it is in /usr/bin or in /opt/texlive/bin. It works without any change in kile at example.
Offline
I don't think this is an issue with the texlive-core pkgbuild; but I wasn't sure where else to post this problem. After installing texlive, pdflatex is no longer works. Here is the output corresponding to the problem
Local config file preload.cfg used
=====================================
(/opt/texlive/texmf-dist/tex/latex/base/preload.cfg
(/opt/texlive/texmf-dist/tex/latex/base/preload.ltx*** glibc detected *** pdftex: free(): invalid pointer: 0x0842d869 ***
/opt/texlive/bin/mktexfmt: line 315: 4163 Aborted ${1+"$@"} 1>&2
*** glibc detected *** pdftex: free(): invalid pointer: 0x0842d869 ***
/opt/texlive/bin/mktexfmt: line 315: 4164 Aborted ${1+"$@"}
Error: `pdftex -ini -jobname=pdflatex -progname=pdflatex -translate-file=cp227.tcx *pdflatex.ini' failed
I've tried compiling texlive-core with generic flags and optimized ones for my cpu (a centrino). I've even tried recompiling glibc to no avail. I get this same error regardless. I wasn't sure where else to post this; any help is greatly appreciated.
-------------------
Update: I was able to fix the problem using the information on http://www.computing.net/linux/wwwboard … 27773.html. The long end of the short of it is that the new default for glibc is to call abort() on an invalid free() call. If you are having the issue described above (which I feel may happen as I use standard ARCH binaries), you can add
export MALLOC_CHECK_=1 # Report error and continue
OR
export MALLOC_CHECK_=0 # Ignore error
to your /etc/profile.
I've had some other minor growing pains going to texlive (like the pgf package no longer being need and some changes in bib styles); but overall, the process hasn't been bad.
Last edited by PDExperiment626 (2007-07-18 05:39:34)
... and for a time, it was good...
Offline
There is a /etc/profile.d/texlive.sh so i doesn't matter if it is in /usr/bin or in /opt/texlive/bin. It works without any change in kile at example.
Right, the problem is programs like fig2pdf break when using this PKGBUILD for texlive-core. Also, many people manage compiling/maintaining a document through makefiles which may rely on commands like pdflatex, latex, etc. being in the path for portability.
... and for a time, it was good...
Offline
Right, the problem is programs like fig2pdf break when using this PKGBUILD for texlive-core. Also, many people manage compiling/maintaining a document through makefiles which may rely on commands like pdflatex, latex, etc. being in the path for portability.
But the shell script do nothing else as you want (see the line with PATH=$PATH:/opt/texlive/bin) and so if you login all what is in /opt/texlive/bin will be in your path. What is your result of a "which pdflatex"?
Offline
@PDExperiment626 (pseudos can be so strange! )
Thanks for pointing out the missing dependencies. I'll have to fix that (sigh...)
On my machine, pdf(la)tex runs just fine. I guess I'll have to investigate why!
Firmicus
Offline
I've had some other minor growing pains going to texlive (like the pgf package no longer being need and some changes in bib styles); but overall, the process hasn't been bad.
I don't understand what you mean...
If you want pgf it is part of the package texlive-pictures.
Offline
I don't understand what you mean...
If you want pgf it is part of the package texlive-pictures.
Sorry, my mistake. I did install the texlive-pictures; but I get the following error when I include the pgf package.
(/opt/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsysprotocol.code.tex))
(/opt/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
(/opt/texlive/texmf/tex/latex/config/color.cfg))
(/opt/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex
! I can't find file `pgfmath.code.tex'.
l.14 \input pgfmath.code.tex
... and for a time, it was good...
Offline
I did install the texlive-pictures; but I get the following error when I include the pgf package.
(/opt/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsysprotocol.code.tex)) (/opt/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty (/opt/texlive/texmf/tex/latex/config/color.cfg)) (/opt/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex ! I can't find file `pgfmath.code.tex'. l.14 \input pgfmath.code.tex
You're right. But it's not my fault!
The directory texmf-dist/tex/generic/pgf/math/ is on the TeXLive repo (under http://tug.org/svn/texlive/trunk/Master … pgf/math/), but it is not included in the file
http://tug.org/svn/texlive/trunk/Master … w-list/pgf from which my list of paths to be rsync'ed was generated.
(It seems these lists are not 100% up-to-date, in future I'll have to generate them myself!).
So thanks, I'll fix that. In the meanwhile you can just fetch the missing directory by hand (e.g. with rsync ) and put it into your $TEXMFLOCAL or $TEXMFHOME.
Offline
@PDExperiment626: Fantastic Job and thanks for your hint about MALLOC_CHECK_. It works fine.
Offline
What is your result of a "which pdflatex"?
After the initial texlive-core install I would get a
which: no pdflatex in (/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/bin:/opt/java:/opt/texlive/bin:/opt/eclipse:/opt/java/bin:/opt/java/jre/bin:/opt/mozilla/bin:/opt/qt/bin)
This is curious since there was indeed an /etc/profile.d/texlive.sh installed on my machine. I will try to look into this some more to figure out what may be going on.
So thanks, I'll fix that. In the meanwhile you can just fetch the missing directory by hand (e.g. with rsync ) and put it into your $TEXMFLOCAL or $TEXMFHOME.
^^ I decided to be lazy and just added 'texmf-dist/tex/generic/pgf/math' to the texlive-pictures.paths file and rebuilt the package. Now .tex files using the pgf package compile ^^. Thanks for that.
@PDExperiment626: Fantastic Job and thanks for your hint about MALLOC_CHECK_. It works fine.
No worries; I'm glad it was useful to someone ^^. I honestly don't think this problem has anything to do with how the PKGBUILDS have been made. This is an issue with how glibc 2.6 handles malloc errors and may only happen on certain hardware configurations. Indeed, people have started seeing this error with other programs outside of pdflatex.
Thanks again to those working on these pkgbuilds; after looking them over, I can see a lot of work was put into these files. It's too bad the TeX people have chosen their current scheme for texlive distribution. Ideally, it would have been nice to work the pkgbuilds through the use of svn checkouts; but I can see how rsync is better suited to collecting files from a seemingly arbitrary collection of directories on the tug.org svn servers.
That being said, I think there may be some value to creating a pkgbuild like texlive-all and texlive-doc-all or something like that. Basically, these packages would include all the texlive packages firmicus has put in his build directory excluding the language-specific ones. I.e. texlive-all would be texlive-core + texlive-bibtexextras + texlive-fontsextra + etc. I know this is simply and issue of combining all the *.paths files; but I think some people may just want to deal with one monolithic package as opposed to a bunch of smaller ones. The texlive-doc-all would be the analogous idea for all the texlive-doc packages. This way someone would just need to install texlive-all and their texlive-language pkg and be good to go no matter what packages they were using. Just a suggestion ^^.
Last edited by PDExperiment626 (2007-07-19 09:36:17)
... and for a time, it was good...
Offline
This morning I tried recompiling texlive-core, with updated paths for rsync (and bison and flex added to the makedepends array). Now I encountered the same problem as reported above. This cannot be due to a change in the sources, which are the same, but it could be either a change somewhere in the texmf directory (which is updated during the makepkg process) or a change after some update to the Arch system. I don't know, The important thing is that with export MALLOC_CHECK_=0 it works. So thanks to PDExperiment626!
I have now introduced an important change in the way pkgver is determined, which will make maintainance easier for me. For each texlive-* package, the pkgver will be 2007.$revnr where $revnr is the highest svn revision number on the TeXLive repo for all CTAN packages featured in the package. This is rather easily generated using the information in the TeXLive database (file texlive.tlpdb on the TL server). This means that many packages now have LOWER pkgver than specified in the PKGBUILD some of you have tested over the last few days.
My latest buildtree is available at the usual location
More info will be provided on Archwiki in a few days. I'll inform you here when it's there.
I have regenerated all packages now and will put them on my ISP's MediaCenter. If anybody cannot wait until they go to community, email me and I'll give you access, Same thing for anyone willing to test the packages without the burden of building them
Thanks to all for your help
F
Last edited by Firmicus (2007-07-19 09:35:51)
Offline
No worries; I'm glad it was useful to someone ^^. I honestly don't think this problem has anything to do with how the PKGBUILDS have been made. This is an issue with how glibc 2.6 handles malloc errors and may only happen on certain hardware configurations. Indeed, people have started seeing this error with other programs outside of pdflatex.
See my post below (which I sent before yours showed up). The strange thing is that three days ago it worked without the malloc trick, and today the build failed, without having changed anything on my system (same glibc). Anyway as I said the important thing is that it works. I have now added the line "export MALLOC_CHECK_=0" to the PKGBUILD of texlive-core of course.
Thanks again to those working on these pkgbuilds; after looking them over, I can see a lot of work was put into these files. It's too bad the TeX people have chosen their current scheme for texlive distribution. Ideally, it would have been nice to work the pkgbuilds through the use of svn checkouts; but I can see how rsync is better suited to collecting files from a seemingly arbitrary collection of directories on the tug.org svn servers.
That occured to me too, but frankly I do not know how this could have been done with svn. If you know how to achieve the same with svn as with rsync (esp. the option --files-from <file containing list of paths to retrieve>) please tell me. I am aware that the current rsync mechanism makes it impossible to recreate the package once something has been updated on the TL server, since we have no version control. But I think people should see this particular case as an exception to the rule, and be happy with installing the built packages once they are in community I have invested enough time doing this. I will be glad if many people find the packages useful.
That being said, I think there may be some value to creating a pkgbuild like texlive-all and texlive-doc-all or something like that. Basically, these packages would include all the texlive packages firmicus has put in his build directory excluding the language-specific ones. I.e. texlive-all would be texlive-core + texlive-bibtexextras + texlive-fontsextra + etc. I know this is simply and issue of combining all the *.paths files; but I think some people may just want to deal with one monolithic package as opposed to a bunch of smaller ones. The texlive-doc-all would be the analogous idea for all the texlive-doc packages. This way someone would just need to install texlive-all and their texlive-language pkg and be good to go no matter what packages they were using. Just a suggestion ^^.
Well, couldn't this be done very simply by means of groups entries in the PKGBUILDs?
The groups could be for ex.: texlive-most, texlive-lang, texlive-doc. And we could have a dummy package texlive-complete which depends on all three groups.
Concerning the packages for documentation, I hesitated whether I should provide them, as it is very easy to access the whole documentation online using this webpage! So unless you have to work with TeX while being offline, there is no need to install the doc packages at all
---
EDIT: I realize that the above webpage provides access to the documentation as it stands on the TeXLive 2007 CD/DVD. My Arch packages on the other hand contain the latest updates. In most cases there is no difference, but some packages are actively developed (e.g. the oberdiek bundle) and some more have been added. In those cases one can use the TeX Catalogue to search for up-to-date documentation.
---
Cheers,
F
Last edited by Firmicus (2007-07-19 10:10:24)
Offline
Just wanted to say: thanks for all your work with this. I don't have much else to contribute with, but I'm watching this thread, eager to see a texlive package.
Offline
PDExperiment626 wrote:
This is curious since there was indeed an /etc/profile.d/texlive.sh installed on my machine. I will try to look into this some more to figure out what may be going on.
But you have rebooted or logged out in this time? -)
Firmicus wrote:
I have now added the line "export MALLOC_CHECK_=0" to the PKGBUILD of texlive-core of course.
There is another thing strange with this but this could be only guilty for me kde user: I have to put this in /etc/profile, ~/.bashrc and to replace "kile" in the kde menue with "export MALLOC_CHECK_=0 && kile" to get it work in kile. Not realy nice such a sideeffect and fantastic that PDExperiment626 found it out.
Firmicus wrote:The groups could be for ex.: texlive-most, texlive-lang, texlive-doc. And we could have a dummy package texlive-complete which depends on all three groups.
I find this idea very good and absolut understandable which is still better than "very good".-)
Offline