A suggestion for a new ebuild: MikTex Package Manager automates the downloading of latex packages. (from http://dojo.miktex.org/blogs/christian_schenk/articles/mpmunix.aspx) " How to use the package manager on GNU/Linux systems MPM (MiKTeX Package Manager) was originally intended to be a tool for MiKTeX/Windows users. But the program can be helpful for users of other TeX systems too, because many of the MiKTeX packages are system-independent. Installing the package database First of all you should install the package database files on your computer. To do this, run > mpm --update-db This command retrieves the package database files from a remote package repository and installs them in the installation directory. To list the contents of the just installed package database, run > mpm --list To get datailed information about a package, run > mpm --print-package-info=PACKAGE Setting the installation directory The installation directory is the root of a TDS-compliant TEXMF directectory hierarchy. The location of the installation directory is determined by the configure script. The --install-root option lets you set the installation directory at run-time. For example, the following command installs the package database files in your home TEXMF: > mpm --install-root=~/texmf --update-db Installing and updating packages Use the --install option to install a package. For example, run > mpm --install=a0poster to install the a0poster package. The --update option can be used to update installed packages. Run > mpm --update to update all installed packages. Run > mpm --update=PACKAGE to update a certain package. " (from http://dojo.miktex.org/forums/133/ShowPost.aspx) I am pleased to announce the release of the MiKTeX 2.5 Beta 1 source code. The source code is meant to be compiled on GNU systems. Please note that MiKTeX 2.5 Beta 1 does not comprimise a TeX system. It should be regarded as an addition to the TeX system installed on your system. MiKTeX 2.5 Beta 1 for GNU systems includes the MiKTeX package manager (MPM). Prerequisites MiKTeX is mostly written in C++. It should work with any ANSI-compliant C++ compiler. MiKTeX depends on the availability of pthreads libraries and header files. MiKTeX requires that libCURL is installed and usable, i.e., > curl-config --version should output a line similar to this: libcurl 7.11.1 Download link http://prdownloads.sourceforge.net/miktex/miktex-2.5.2064-beta-1.tar.gz?download Reproducible: Always Steps to Reproduce: 1. 2. 3.
I have no real in experience in creating an ebuild, but I will try to do it. Dependencies seem to be libcurl (what ebuild?) and pthreads (that's pth?).
Created attachment 76029 [details] Working ebuild of MiKTeX Tools Beta 3, note comment The plain source code compiled on my system but when used with an ebuild several errors with not-found files appeared. As I know little about programming in C++ (simple shell scripts is all I know) I just did some dirty hacks (namely "hardcoding" some includes) and patched the source (see other attachment). It will be sorted out together with Christian Schenk (author of MiKTeX). My test went with CFLAGS="-g -O2", so testing for other flags on x86 (or even other platforms) is appreciated. Please comment on other depends than net-misc/curl and dev-libs/pth and USE flags...the ebuild is marked ~x86
Created attachment 76030 [details] collection of patches for beta 3 Patches are necessary for beta 3
(In reply to comment #2) > The plain source code compiled on my system but when used with an ebuild > several errors with not-found files appeared. As I know little about > programming in C++ (simple shell scripts is all I know) I just did some dirty > hacks (namely "hardcoding" some includes) and patched the source (see other > attachment). Ideally, another ebuild maker adds his experience, I'll post a message in the forums requesting help on this issue. I myself have no ebuild creation experience. > My test went with CFLAGS="-g -O2", so testing for other flags on x86 > (or even other platforms) is appreciated. I'm using an amd64 system, and the sources compiled fine (with a minor action from my side, see <http://dojo.miktex.org/blogs/christian_schenk/archive/2005/12/16/225.aspx>). I would really like to help test, but have no experience using ebuilds not in portage (where do I put the ebuild and patches?) and am very concerned about the possibility of a clean removal of the package.
http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds describes an overlay
The next version will have ~amd64 as a flag and teTeX as dependency, and the name of the ebuild will change to mpm-2.5b3. There's a thread about this in the Gentoo forums: http://forums.gentoo.org/viewtopic-t-419081.html "man 5 ebuild" has more information on the format Short description what happens (as far as I understand) and what the problems are. There are two paths that are relevant for building: /var/tmp/portage/mpm-2.5-r3/ called $tmpdir /var/tmp/portage/mpm-2.5-r3/work called $workdir Normal unpatched version: 1.) The source is unpacked into $workdir 2.) ./config with options --prefix=/usr --libdir=/usr/lib --datadir=/share/${PN}--mandir=/share/man is executed and creates *.am in $workdir 3.) make is called and creates Makefiles in $tmpdir using the files in $workdir then stops because header files that are included by other files and not resident in the same directory as the including ones cannot be found, causing a lot of errors (scroll a bit upwards to see the cause) Patched version: 1.) The source is unpacked into $workdir 2.) patches are applied, which means that all relevant #includes have hardcoded relative paths for the files to be included, dirty hacking, directory changing is made by hand (in the ebuild) 3.) ./config with options --prefix=/usr --libdir=/usr/lib --datadir=/share/${PN}--mandir=/share/man is executed and creates *.am in $workdir 4.) make is called and creates Makefiles in $tmpdir using the files in $workdir, compiles fine 5.) make install is called and the files are properly installed, though a manual cd to $tmpdir is necessary (other ebuild do it automatically) I suppose that the problem is in the config run, but I don't know where to look. So maybe other testers should try to leave the patches away [by commenting them with # in the ebuild and don't forget to digest them (see http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds)] and then again with them...I am no programmer so help is really needed to avoid such dirty hacks as my ebuild.
Created attachment 76182 [details] mpm-2.5_beta3.ebuild Works fine with CFLAGS="-O2 -pipe -march=athlon-xp", more testing still appreciated, so even deps and uses. Information gathering and installation status are working ok, still some crashes when updating specific packages (like multido). The new ebuild fixes all problems described in comment #6, last problem: the man page is located in the wrong directory although configure has the correct option. It is "hacked" with the pkg_postinst and pkg_postrm functions. Changes: - header according to Gentoo standard (see guide in http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 ) - redefined variable S to meet our purposes - manual configure call substituted by econf - manual make call substitued by emake - first two changes eliminate problem with not found header files, so no patches needed anymore - added ~amd64 to keywords - added app-text/tetex as dependency - changed description to "MiKTeX Tools -- package manager for a TeX distribution" - changed file name according to Gentoo rules to mpm-2.5_beta3.ebuild - added function pkg_postinst to move man page around and remove unnecessary directories - added function pkg_postrm to remove man page wenn unemerging
The emerge is not successful here; seems to be a probleme with make install. [...] >>> Test phase [not enabled]: dev-tex/mpm-2.5_beta3 >>> Install mpm-2.5_beta3 into /var/tmp/portage/mpm-2.5_beta3/image/ category dev-tex make: *** Keine Regel, um
The emerge is not successful here; seems to be a probleme with make install. [...] >>> Test phase [not enabled]: dev-tex/mpm-2.5_beta3 >>> Install mpm-2.5_beta3 into /var/tmp/portage/mpm-2.5_beta3/image/ category dev-tex make: *** Keine Regel, um »install« zu erstellen. Schluss. !!! ERROR: dev-tex/mpm-2.5_beta3 failed. !!! Function src_install, Line 34, Exitcode 2 !!! install failed !!! If you need support, post the topmost build error, NOT this status message. satux ~ # emerge --info Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-suspend2-r7 i686) ================================================================= System uname: 2.6.14-suspend2-r7 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/bin/texdoc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium-m -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apm auctex audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdparanoia cdr cjk crypt cups curl doc dvd dvdr dvdread emacs emboss encode exif expat fam ffmpeg flac foomaticdb fortran gd gdbm gif glut gmp gphoto2 gpm gstreamer gtk gtk2 icq idn imagemagick imlib ipv6 ithreads jack java javascript jpeg kde kdeenablefinal lcms libg++ libwww lm_sensors lua mad mikmod mime mmx mng motif mp3 mpeg ncurses nls nocd nptl ogg oggvorbis openal opengl oss pam pcre pdflib perl pic plotutils png python qt quicktime readline recode samba sdl spell sse sse2 ssl svg svga tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vcd visualization vorbis win32codecs wmf xine xml2 xmms xv xvid zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
Created attachment 76234 [details] mpm-2.5_beta3-r1.ebuild Sebastian, test this one. Could you please emerge, check if "man mpm" works (if not, look where the file mpm.1 is), then unmerge und have a look if mpm.1 is still there. And report, of course! :) Changes: - remove cd command from src_install function
It emerged. There is an error though: [...] >>> /usr/lib/miktex/libmiktex-bz2.so.1 -> libmiktex-bz2.so.1.0.0 mv: Aufruf von stat f
It emerged. There is an error though: [...] >>> /usr/lib/miktex/libmiktex-bz2.so.1 -> libmiktex-bz2.so.1.0.0 mv: Aufruf von stat für /share/man/man1/mpm.1 nicht möglich: Datei oder Verzeichnis nicht gefunden rmdir: /share/man/man1: Datei oder Verzeichnis nicht gefunden rmdir: /share/man: Datei oder Verzeichnis nicht gefunden rmdir: /share: Datei oder Verzeichnis nicht gefunden >>> Regenerating /etc/ld.so.cache... >>> dev-tex/mpm-2.5_beta3-r1 merged. [...] man mpm works (/usr/share/man/man1/mpm.1.gz)! However, unmerging it: [...] --- !empty dir /usr rm: Entfernen von /usr/share/man/man1/mpm.1 nicht möglich: Datei oder Verzeichnis nicht gefunden >>> Regenerating /etc/ld.so.cache... although /usr/share/man/man1/mpm.1.gz is removed as well. man mpm still works but I guess that's some kind of caching feature as I found the file /var/cache/man/cat1/mpm.1.bz2 The problem is that I cannot update the data base. satux ~ # mpm --update-db mpm: a timeout was reached However, that should be temporary or a mpm thing...
Just what I wanted to know...thank you. You must find a package repository first via mpm --pick-repository-url then you can update, by mpm --find-updates is safest, because no files are overriden
Hi, This looks to become a much needed package. I just tried it on my system, it compiled without problems, but I experience the following: 1. I cannot run mpm as a normal user rose ~ # mpm --list mpm: C/C++ runtime error 13: Permission denied 2. I cannot figure out, how to use it to update the standard tetex packages, i.e. as root I tried rose ~ # mpm --pick-repository-url ftp://ftp.jaist.ac.jp/pub/TeX/tex-archive/systems/win32/miktex/tm/packages/ rose ~ # mpm --install-root=/usr/share/texmf/tex/latex/ rose ~ # mpm --list | grep ^i rose ~ # other commands doesn't either update packages in the standart tetex tree. What did I miss? Thanks, Jon
http://dojo.miktex.org/blogs/christian_schenk/articles/mpmunix.aspx and comment #1 explain the usage: mpm needs to build a database of your installed packages, so use mpm --update-db then mpm --list should work, all perhaps combined with --install-root What are your CFLAGS, Jon?
Created attachment 76599 [details] mpm-2.5_beta4.ebuild New updated version, see http://dojo.miktex.org/forums/265/ShowPost.aspx Please test, we need feedback! Changes in ebuild: -removed functions for man page handling, not necessary anymore -readded dependency for app-text/tetex, it got lost in the last version
Hi, (In reply to comment #13) > http://dojo.miktex.org/blogs/christian_schenk/articles/mpmunix.aspx and comment > #1 explain the usage: > mpm needs to build a database of your installed packages, so use > mpm --update-db Sorry I wasn't clear, but I had already done that. > then > mpm --list > should work, all perhaps combined with --install-root I'm a little uncertain, where the --install-root should point to: /usr/share/texmf or perhaps /usr/share/texmf/tex/latex. I've tried without, and the two mentionen in the previous sentence, and neither recognizes the already installed packages, see below... > > What are your CFLAGS, Jon? The top part of my make.conf looks like: CFLAGS="-O2 -mcpu=i686 -pipe -fomit-frame-pointer" CHOST="i386-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j2" USE="alsa bzlib cdr divx4linux dvd dvdr fftw imagemagick mozilla mule ppds tetex tiff xine apache2 pda -ipv 6 -oss fortran -f77 -gnome dga divx4linux emacs gimpprint live lzw-tiff maildir mmap mmx mmx2 mng nptl pic ppds real sse sse2 svg unicode xvid Xaw3d network" > Anyway, the reason I'm looking for updates to my tetex installation is, that I want to use powerdot, and this requires many updated packages such as pstricks. I.e., latex powerdot-example1.tex This is TeX, Version 3.14159 (Web2C 7.4.5) (./powerdot-example1.tex LaTeX2e <2001/06/01> ... (/usr/share/texmf/tex/generic/pstricks/pstricks.con))) LaTeX Warning: You have requested, on input line 153, version `2004/05/12' of package pstricks, but only version `1997/03/25 package wrapper for PSTricks pstricks.tex' is available. ... I will try to be absolutely specific about what I did this time. To install the new 2.5-beta4 ebuild I did the following: As root I downloaded mpm-2.5_beta4.ebuild to /var/tmp/ mkdir /usr/local/portage/app-text/mpm/ cp /var/tmp/mpm-2.5_beta4.ebuild /usr/local/portage/app-text/mpm/ cd /usr/local/portage/app-text/mpm/ ebuild mpm-2.5_beta4.ebuild digest emerge -v mpm Everything worked well, I did not notice any warnings etc. Then I wanted to update the packages already in tetex: mpm --update-db mpm --list | grep pstricks - 344 5903084 pstricks - 23 1696811 pstricks-add which is in contrast to the latex run above, which clearly has pstricks available. Anycase I install it using mpm: mpm --install=pstricks Package "pstricks" has been successfully installed. mpm --list | grep pstricks i 344 5889287 pstricks - 23 1696811 pstricks-add For safety I Rehash with texconfig (rose:~/powerdot/doc) sporring% latex powerdot-example1.tex This is TeX, Version 3.14159 (Web2C 7.4.5) (./powerdot-example1.tex LaTeX2e <2001/06/01> ... (/usr/local/share/texmf/tex/generic/pstricks/pstricks.tex `PSTricks' v1.14 <2005/12/22> (tvz) (/usr/local/share/texmf/tex/generic/pstricks/pstricks.con)) (/usr/local/share/texmf/tex/generic/pstricks/pstricks.con)) (/usr/share/texmf/tex/latex/xcolor/xcolor.sty (/usr/share/texmf/tex/latex/config/color.cfg))) ! LaTeX Error: File `enumitem.sty' not found. Type X to quit or <RETURN> to proceed, or enter new name. (Default extension: sty) Enter file name: x Good sign so I mpm --install=enumitem Package "enumitem" has been successfully installed. Then I Rehash'ed with texconfig. Ran Latex with success! So it appears that I can install new packages, I can replace old ones, but mpm does not recognize the packages already in tetex, which means that I cannot update what I've gotten as part of the gentoo installation of tetex. But maybe mpm is not intended to do that? In any case, I'm up and running with powerdot in a much simpler way than package-installation by hand. Thanks, Jon
That's clear, because you can only use an already installed MiKTeX repository (I used as main tree even under Linux but updated it via Windows). I am not quite sure, how mpm recognises it, but it certainly does not search the whole TeXMF tree to determine installed packages, it uses a metafile or (metadirectory) to keep track of installed packages. <five minutes later> mpm downloads the information of available packages for MiKTeX and looks if there is a <packagename>.tpm in texmf/tpm/packages/ and regards a package installed if this file is present. I compares the stored in the tpm file and compares it to the available version, such a need to update is determined. You can create this list by yourself, that should be a lot of work....
(In reply to comment #14) > Please test, we need feedback! I tested this ebuild on an amd64 system. All (unpack, compile, install, qmerge) went well. "man mpm" works, "mpm --update-db" seems to work,... I managed to install a new package (srcltx) and after doing a texhash, it was available. Everything seems ok. You can ask me to test specific things (no promises, however).
So just use it an report problems either here or in the bug database of MiKTeX, at the moment there's no specific need for things to be tested in the ebuild. But if you think of some features for the ebuild just tell here, maybe I can implement it. (For example how to use a user-defined TeXMF tree). It would be good, if you always could state your CFLAGS
Emerged fine (no error concerning man page) and installed the package microtype which it did well too. CFLAGS="-march=pentium-m -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-iden CXXFLAGS="-march=pentium-m -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -pipe -fvisibility-inlines-hidden"
E-Mail to text-markup@gentoo.org In bug #110494 I submitted ebuilds for MiKTeX tools, which contains the MiKTeX package manager. Is it possible to include the ebuilds in the official portage tree? Maybe it is an idea to use this tool similar to the installation of modules from CPAN for Perl. So all the individual ebuilds for LaTeX packages could be abandoned, people could just use mpm to add new packages to their tree.
(In reply to comment #20) On Tue, Jan 10, 2006 at 11:36:18 +0100, Christian Faulhammer wrote: > Hi, > > In bug #110494 I submitted ebuilds for MiKTeX tools, which contains the > MiKTeX package manager. Is it possible to include the ebuilds in the > official portage tree? Hi, this seems to be a very nice piece of software that could prove very useful, but tetex is so complicated that I'd like much more testing before adding it to the tree. I'll try to test it in the next few days and tell you how it is going. > Maybe it is an idea to use this tool similar to the installation of > modules from CPAN for Perl. So all the individual ebuilds for LaTeX > packages could be abandoned, people could just use mpm to add new packages > to their tree. Well, then vanilla way for now is to have tetex as main tex distribution and then install/add extra packages through ebuilds. As I don't know mpm at all, I have no idea of how well it scales to a full texmf tree and using it "officially" would be a very important change that would require much planification and documentation. But, if handled carefully, why not? By the way, I think that communicating through your bug is better, as it is public and archived. Thanks Alexandre
(In reply to comment #21) Tach Alexandre, 0x2B859DE3 (PGP-PK-ID) >> In bug #110494 I submitted ebuilds for MiKTeX tools, which contains the >> MiKTeX package manager. Is it possible to include the ebuilds in the >> official portage tree? > this seems to be a very nice piece of software that could prove very > useful, but tetex is so complicated that I'd like much more testing > before adding it to the tree. I'll try to test it in the next few days > and tell you how it is going. Not even hard masked to attract a little more attention? >> Maybe it is an idea to use this tool similar to the installation of >> modules from CPAN for Perl. So all the individual ebuilds for LaTeX >> packages could be abandoned, people could just use mpm to add new >> packages to their tree. > Well, then vanilla way for now is to have tetex as main tex distribution > and then install/add extra packages through ebuilds. Yes, I know. > As I don't know mpm at all, I have no idea of how well it scales to a > full texmf tree It is used by the MiKTeX distribution which is the most popular distribution on Windows (mpm works with an graphical interface there) and handles more than 1000 packages. MiKTeX and teTeX 3.x use the same standard for building the tree (TDS) so the TeXMF trees are interchangeable (on my system the TeX directory from my Windows partition is incorporated by teTeX and I used Windows for updating only). > and using it "officially" would be a very important change that would > require much planification and documentation. But, if handled carefully, > why not? That is for sure, just a proposition for future plans. > By the way, I think that communicating through your bug is better, as it > is public and archived. There has no feedback from any official (maybe because it is assigned to maintainer-wanted), so I thought contacting the text-markup herd is the best way. Should I cc text-markup@gentoo.org or can someone reassign it? This discussion will be included in the bug. V-Li
(In reply to comment #18) > It would be good, if you always could state your CFLAGS > CFLAGS="-march=athlon64 -O3 -ftracer -funit-at-a-time -fforce-addr -fpeel-loops -funswitch-loops -pipe" CXXFLAGS="${CFLAGS}"
Just some more hints how to use mpm (maybe you should not forget to specify --install-root) 1.) You have to choose an CTAN mirror via --pick-repository-url after every system start 2.) Find all packages that are not installed in your TeXMF tree $ mpm --list|grep -v "i " 3.) Automatically install all not installed packages $ mpm --list|grep -v "i "|cut --bytes=22- > /tmp/tmpnotinstalled $ cat tmpnotinstalled $ mpm --update-some=tmpnotinstalled You can use this in a shell script to have the functionality of the graphical MPM from Windows.
(In reply to comment #24) > $ cat tmpnotinstalled > $ mpm --update-some=tmpnotinstalled correction $ cat /tmp/tmpnotinstalled $ mpm --update-some=/tmp/tmpnotinstalled
A slightly edited version of your ebuild is now in the portage tree, but hard masked for now. I'd like it to receive a lot more testing before going to ~arch, as the texmf tree can be quite sensitive... Thanks
(In reply to comment #26) > A slightly edited version of your ebuild is now in the portage tree, but hard > masked for now. > Can you also add the appropriate amd64 keyword? It works fine on my amd64 system (as reported above).
Please add ~amd64, we have a successful compilation. The official ebuild worked just fine, thank you very much. For next betas I will use your version and commit it here.
Maybe a rename is logical, because officially they are called "MiKTeX Tools" and now includes two more utilities: mthelp and initexmf Proposal: mpm -> miktex-tools This should also be reflected in the title of this bug report and in the description of the ebuild I asked for more testers in the German and international TeX newsgroups.
I can't keyword directly ~amd64, even if users reported success, it has to go through the relevant arch teams. amd64: can you keyword this package, please?
The activity seems rather low on this bug ? Compiles and works fine on my system ! (pretty standard x86 gentoo installation with tetex-2).
Do the tests work on x86? For my amd64, the tests error. Are there any other tests you guys would like me to perform for amd64? x86_64-pc-linux-gnu-g++ -march=athlon64 -O3 -pipe -fomit-frame-pointer -funroll-loops -o .libs/1 1.o -pthread ../../.libs/libmiktex-core.so /var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/libmd5/.libs/libmiktex-md5.so ../../../libpopt/.libs/libmiktex-popt.so -Wl,--rpath -Wl,/usr/lib64/miktex creating 1 make[4]: Leaving directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib/test/thread' make check-TESTS make[4]: Entering directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib/test/thread' /bin/sh: line 4: 10573 Segmentation fault ${dir}$tst FAIL: 1 =================== 1 of 1 tests failed =================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib/test/thread' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib/test/thread' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/mpm-2.5.2199_beta4/work/miktex-tools-2.5.2199-beta-4/lib' make: *** [check-recursive] Error 1
dev-tex/mpm-2.5.2199_beta4 compiled successfully and is working very nice here on and ~amd64 system. (Linux mars 2.6.16-gentoo-r9-twam #2 SMP PREEMPT Tue Jun 13 18:19:24 CEST 2006 x86_64 Intel(R) Pentium(R) D CPU 3.20GHz GNU/Linux)
The ebuild has been added to the tree, unhappily AMD64 hasn't keyworded it.
