Portage 2.2_rc14 (default/linux/x86/2008.0, gcc-4.1.2-asneeded, glibc-2.8_p20080602-r0, 2.6.27-gentoo-r2 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r2-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-glibc2.0 Timestamp of tree: Fri, 14 Nov 2008 00:37:01 +0000 distcc 3.0 i686-pc-linux-gnu [disabled] ccache version 2.4 [disabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r15, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r8 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/glftpd/etc /opt/glftpd/ftp-data /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb /var/phxd /var/qmail/alias /var/qmail/control /var/spool/torque /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage-distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" INSTALL_MASK=" /usr/share/doc /usr/share/man /usr/share/info" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/usr/portage-packages" PORTAGE_COMPRESS="" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 172976 [details] Build log
Emacs team is out of here; we maintain only the Emacs part.
(In reply to comment #1) > Created an attachment (id=172976) [edit] > Build log Diego, do you have the tex executable in your system?
Probably it was run on the older tinderbox that used -B.
(In reply to comment #4) > Probably it was run on the older tinderbox that used -B. Can you rerun it on your new tinderbox?
Diego, it would be still nice if you could retest the build.
*** Bug 295139 has been marked as a duplicate of this bug. ***
In the case of this bug, the problem is the missing "tex" command. But adding it doesn't solve the problem -- because there are 2 other problems: 1) Setting the use flags to "-doc" still apparently tries to produce the documentation. So there is a problem with the ebuild or the makefile not handling "-doc" correctly. The second problem, when I tried to emerge gri (even with texlive-core, texlive-latexextra, texlive-basic, luatex and jadetex installed is that one still gets an error using tex to build the refcard.tex, the exact error is: make[2]: Entering directory `/media/tmp/portage/sci-visualization/gri-2.12.19/work/gri-2.12.19/doc' /bin/sh ../missing --run tex ./refcard.tex This is TeX, Version 3.1415926 (Web2C 7.5.7) ---! //var/lib/texmf/web2c/tex.fmt doesn't match tex.pool (Fatal format file error; I'm stymied) WARNING: `tex' is needed, and you do not seem to have it handy on your system. You might have modified some files without having the proper tools for further handling them. Check the `README' file, it often tells you about the needed prerequirements for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing `tex' program. make[2]: *** [refcard.ps] Error 1 The problem that it is playing around with the refcard.tex file is due to problem #1 (ignoring -doc). The tex.fmt, tex.pool error puzzles me. I can't find out where tex.fmt comes from. It apparently gets processed by jadetex to make the file smaller, but even after "unmerging" jadetex which makes the file larger, gri will still not build (same error). Thus far the only way I have found to enable the compilation of gri is to entirely remove /var/lib/texmf/web2c/tex.fmt. If anyone can tell me where tex.fmt is coming from (tex.pool?) before jadetex plays with it I'd be interested in knowing.
Created attachment 216532 [details] emerge --info for Jan 2010 problems texlive-core version 2008-r7 gri version 2.12.19
That's hard to get...I cannot reproduce it.
You can't reproduce the first part (-doc still accesses the doc directory?) -- I would think you could reproduce this by simply going to the ebuild doc directory immediately following the extraction/patching part of the ebuild and removing all of the contents of the doc directory (even remove the doc directory entirely). You ought to get an error when it goes to format "refcard.tex" (something it should *not* be doing with the -doc option). If just this part were fixed you could run the ebuild without encountering Problem #2. Problem #2 is more subtle. I do not understand *what* part of running tex on refcard.tex is trying to access "/var/lib/texmf/web2c/tex.fmt". I know that unmerging/reemerging jadetex changes the size of tex.fmt (to be expected due to the fact that jadetex is supposed to remove comments from tex files). But I do not know why "tex.fmt" is being used at all. I identified something like 4-5 ebuilds on my system that implement a functional tex system but did not take the trouble to deinstall all of them, then reinstall all of them one by one, check to see what the minimal set is that is required to format refcard.tex (e.g. in the incompletely compiled +doc ebuild environment). I presume that someplace between a "basic" tex environment and a "rich" tex environment there is a package that adds or munges the tex.fmt file and breaks the processing of refcard.tex. Then the gri ebuild could be modified to prevent attempting +doc when that package is present (i.e. if one want to build gri +doc, one would have to unmerge the questionable tex package, build gri, then reinstall the questionable tex package (presumably present because some other package needs it)). Or one could dig into what the "missing" shell script actually does (sh -x might help) to figure out what is causing the precise error. But I agree that it is a very bizarre error. I'm surprised that I managed to find the work-around that I did.
I think this is a related bug, that I discovered, when I was unable to re-install gri 2.12.19. I tried to compile with USE=-doc and USE=-examples. The same bug regarding *png files popped up. I eventually found that I had to reinstall ghostscript-gpl, following instructions, after that emerge failed, to remove a gs extra fonts package. I'm sorry I didn't record that package name. After I removed the offending package, reinstalled ghostscript-gpl, I was subsequently able to emerge gri-2.12.19. After that I bumped the ebuild for gri to 2.12.20, and that installed ok, but I'm uncertain whether it's working properly, at this point. I apologize for not providing appropriate documentation, but felt that this may be valuable information for those who experience this bug.
fixed in 2.12.23 in the tree
