When running mpm-2.5.2398_beta14 the following happens: # mpm --trace --update-db core: The MiKTeX function SessionImpl::InitializeRootDirectories fails for the following reason: Unexpected condition. Info: Source: texmfroot.cpp Line: 235 mpm: Unexpected condition. This thread also discusses the problem: http://dojo.miktex.org/forums/thread/685.aspx They suggest that the problem is the duplication of paths in kpsewhich --expand-path \$TEXMF However the person reporting the problem states that even elimination of duplicates does not solve it.
This is a bug in mpm not for Gentoo...so they will fix it...apart from that mpm is still hard masked.
(In reply to comment #0) > > This thread also discusses the problem: > http://dojo.miktex.org/forums/thread/685.aspx > > They suggest that the problem is the duplication of paths in > kpsewhich --expand-path \$TEXMF > > However the person reporting the problem states that even elimination of > duplicates does not solve it. That's me. I'll file a bug asking for a version bump when an update correcting this is made available upstream. The reason for getting this new version in the first place was that the MikTeX repository layout changed, so the old ebuild also doesn't work (on fresh installs; what about others?). What could help is trying to do a manual compile and see what that gives (as the environment does not change, possibly nothing). I have been too lazy/buzy to do that yet. If anybody tries, I suggest you report your findings here. I suggest that the reporter changes the severity to 'major', as not working can be considered a "major loss of function".
I still think of this as RESOLVED:UPSTREAM, we won't get it working and even when patching it is not worth the work for a new release should arrive soon and this hard masked beta (!) software...
(In reply to comment #3) > I still think of this as RESOLVED:UPSTREAM, [...] We don't know that. Up until now, we've only seen this problem reported on 2 Gentoo systems (Nik's and mine), and we know it works on other systems (CShenk's and hoegholm's at least, see http://dojo.miktex.org/forums/thread/685.aspx ). I think more testing wouldn't hurt. And as long as we're not sure this is not a Gentoo problem, I'd keep this bug open and mark it MAJOR. It's not because somethings beta/hardmasked we shouldn't keep bugreports that are a good description of what we (currently) know about the problems encountered with the package.
Now really, let's not get into a fight about technicalities (like a major marking). I submitted this bug because I think that we should try to get packages in portage working. Even hard masked ones. However, I am not a gentoo developer myself and I respect Christian's opinion when he says it's business for upstream. I'd propose that Erik or I do some more testing (i.e. a manual install and eliminate the duplicates from the $TEXMF path (any idea how that is done?)) and then supply the information we obtain here to maybe get a clearer picture. Possibly we find something new to report to upstream or possibly we find a problem with the gentoo setup. In any case it will be good to have more detailed information. I'll have to say though that it may take week or two until I get around to this, being quite busy with work.
When I try to locally configure the package, I get $ ./configure MIKTEX_INSTALLROOT=/home/equaeghe/texmf bash: ./configure: /bin/sh: bad interpreter: Permission denied (Idem without the MIKTEX_INSTALLROOT set.) There must be something trivial I'm doing wrong. Any ideas? BTW: Nik and Christian, I did not mean to come accross agressive; I just wanted to be firm. ;-)
I don't hit that bug. But I am using TeXLive (not supplied with that broken ebuild) and so this really seems to be a Gentoo bug, I misunderstood the thread in the MiKTeX forum. Still agains Severity change, because noone pays attention to that.
(In reply to comment #7) > I don't hit that bug. > What does kpsewhich --expand-path \$TEXMF give you? >But I am using TeXLive (not supplied with that broken ebuild) > You mean the current one in portage? > Still agains Severity change, because noone pays attention to that. > Perhaps true, but it would nevertheless better reflect the severity for us teTeX users.
(In reply to comment #8) > (In reply to comment #7) > > I don't hit that bug. > What does kpsewhich --expand-path \$TEXMF give you? /home/fauli/.texlive2005/texmf-config:/home/fauli/.texlive2005/texmf-var:/usr/local/texlive/2005/texmf-var:/usr/local/texlive/2005/texmf:/mnt/winb/localtexmf:/usr/local/texlive/2005/../texmf-local:/mnt/winb/texmf:/usr/local/texlive/2005/texmf-dist > >But I am using TeXLive (not supplied with that broken ebuild) > You mean the current one in portage? I thought I already had the lesson "Express yourself clearly and people will understand you.": I installed TeXLive 2005 from DVD some time ago and abandoned Gentoo teTeX, this is supported by a MiKTeX tree. > > Still agains Severity change, because noone pays attention to that. > Perhaps true, but it would nevertheless better reflect the severity for us > teTeX users. As you wish.
Since the change to gcc 4.1.1 (system rebuild), I now have the following problem. This seems to be for upstream (already informed), but I thought it wouldn't be bad to share this. # curl-config --version libcurl 7.15.1 # mpm --version MiKTeX Package Manager 2.5.2392 (MiKTeX Tools 2.5 Beta 14) Copyright (C) 2005-2006 Christian Schenk This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # mpm --trace --update-db core: initializing MiKTeX core library version 2.5.2395 core: operating system: Linux 2.6.17-gentoo-r8 #1 PREEMPT Mon Sep 11 23:53:29 CEST 2006 x86_64 core: program file: /usr/bin/mpm libmpm: initializing MPM library version 2.5.2392 core: The MiKTeX function Unknown fails for the following reason: Server was unable to process request. ---> Index was outside the bounds of the array. Info: Source: mpm.cpp Line: 1273 core: uninitializing core library mpm: Server was unable to process request. ---> Index was outside the bounds of the array.
(In reply to comment #10) > Since the change to gcc 4.1.1 (system rebuild), I now have the following > problem. [...] It seems the problem was on my end. After re-emerging, it works fine. I've got mpm back! If the upgrade to gcc 4.1.1 had the same positive effect for the other people affected, we could close this bug.
(In reply to comment #11) > It seems the problem was on my end. After re-emerging, it works fine. I've got > mpm back! If the upgrade to gcc 4.1.1 had the same positive effect for the > other people affected, we could close this bug. At last, I managed to make mpm-2.5.2398_beta14 work. So: 1 - Configure /etc/texmf/texmf.d/00texmf.cnf so you don't have duplicate entries in `kpsexpand \$TEXMF`; 2 - Regenerate texmf.cnf launching 'tetex-update'; 3 - Unmask and emerge mpm-2.5.2398_beta14. I have emerged it with gcc-4.1.1-r4 but I don't think that gcc version is influent. Thanks, HTH.
Created attachment 108948 [details, diff] Patch for duplicate checking in $TEXMF for mpm-2.5.2398_beta14 Since it's necessary that there aren't any duplicates in the $TEXMF kpathsea variable, I think it's a good idea implement a check in the ebuild to let the user know about the bug in the MiKTeX tools distribution. So, here's a patch for the ebuild in portage. I would like to implement it in awk, but I didn't. HTH, please feedback.
(In reply to comment #12) > (In reply to comment #11) > > It seems the problem was on my end. After re-emerging, it works fine. I've got > > mpm back! If the upgrade to gcc 4.1.1 had the same positive effect for the > > other people affected, we could close this bug. > > At last, I managed to make mpm-2.5.2398_beta14 work. So: > > 1 - Configure /etc/texmf/texmf.d/00texmf.cnf so you don't have duplicate > entries in `kpsexpand \$TEXMF`; > 2 - Regenerate texmf.cnf launching 'tetex-update'; What did you change in /etc/texmf/texmf.d/00texmf.cnf? This file is a hell :S and I don't understand anything in it.
> > At last, I managed to make mpm-2.5.2398_beta14 work. So: > > > > 1 - Configure /etc/texmf/texmf.d/00texmf.cnf so you don't have duplicate > > entries in `kpsexpand \$TEXMF`; > > 2 - Regenerate texmf.cnf launching 'tetex-update'; > > What did you change in /etc/texmf/texmf.d/00texmf.cnf? This file is a hell :S > and I don't understand anything in it. Cruzki, I guess you already know which entries are duplicates (using the command step 1. above, or via the equivalent kpsewhich --expand-path \$TEXMF). Then, in 00texmf.cnf, search for those duplicate paths and change all but one of them to one of the other suggestions given in the file (right above the entry defining the duplicate). Then, do step 2. above. If you do not manage to eliminate the duplicates with this info, you may contact me personally by e-mail, and I'll send you my 00texmf.cnf for comparison.
(In reply to comment #14) > What did you change in /etc/texmf/texmf.d/00texmf.cnf? This file is a hell :S > and I don't understand anything in it. Well, in my case (which I think it is the most obiquitous, since I didn't touched at all the original file) all the modifications I did were to uncomment some lines and to comment some other, in particular: 77,78c77,78 < % TEXMFSYSVAR = /var/lib/texmf-var < TEXMFSYSVAR = $TEXMFMAIN --- > TEXMFSYSVAR = /var/lib/texmf-var > % TEXMFSYSVAR = $TEXMFMAIN 85,86c85,86 < % TEXMFSYSCONFIG = /var/lib/texmf-config < TEXMFSYSCONFIG = $TEXMFMAIN --- > TEXMFSYSCONFIG = /var/lib/texmf-config > % TEXMFSYSCONFIG = $TEXMFMAIN HTH.
Thanks, for your replies. I made the changes suggested by Emiliano Vavassori in comment 16 but... I don't have tetex-update!!!!!!! I have texmf-update, and when I run these I optain: Generating /etc/texmf/web2c/texmf.cnf from /etc/texmf/texmf.d ... Generating /etc/texmf/web2c/fmtutil.cnf from /etc/texmf/fmtutil.d ... Generating /etc/texmf/web2c/updmap.cfg from /etc/texmf/updmap.d ... Configuring teTeX ... Generating format files ... Use 'texconfig font ro' to disable font generation for users but no luck.
O.o This is very strange. When I run: cruzki@circe ~ $ kpsewhich --expand-path \$TEXMF /var/lib/texmf-config:/var/lib/texmf-var:/var/lib/texmf:/usr/share/texmf-site:/usr/share/texmf So, the configure step it's done, but if I run mpm I have: cruzki@circe ~ $ mpm --trace core: The MiKTeX function SessionImpl::InitializeRootDirectories fails for the following reason: Unexpected condition. Info: Source: texmfroot.cpp Line: 235 mpm: Unexpected condition. What happens?
(In reply to comment #17) > I don't have tetex-update!!!!!!! I have texmf-update Sorry, it was a mistake. I meant 'texmf-update'. (In reply to comment #18) > cruzki@circe ~ $ mpm --trace > core: The MiKTeX function SessionImpl::InitializeRootDirectories fails for the > following reason: > Unexpected condition. > Info: > Source: texmfroot.cpp > Line: 235 > mpm: Unexpected condition. Have you configured the root installation directory before the first use with: # mpm --install-root=/usr/local/share/texmf ?
They give me the same problem: cruzki@circe ~ $ mpm --install-root=/usr/local/share/texmf --trace core: The MiKTeX function SessionImpl::InitializeRootDirectories fails for the following reason: Unexpected condition. Info: Source: texmfroot.cpp Line: 235 mpm: Unexpected condition. I'm now recompiling the package... only for be sure.
well, after recompile an run cruzki@circe ~ $ sudo mpm --update-db it's appears to works. In linux it's possible to use the grafical front-end or only can use the command-line tools?
(In reply to comment #21) > it's appears to works. In linux it's possible to use the grafical front-end or > only can use the command-line tools? This is not a forum, please read some documentation. And the answer is clearly "no, mpm for *nix for now it's only a CLI tool."
At the risk of getting my head bitten off, I have tested the following patch and the program still works as expected despite my $TEXMF variable having /var/lib/texmf in it three times. The check *may* have an internal effect that I have not found though. I also do not get the other bug that is listed here, I am using gcc-4.1.2 though so there may be a difference there. # kpsewhich --expand-path \$TEXMF /var/lib/texmf:/var/lib/texmf:/var/lib/texmf:/usr/local/share/texmf:/usr/share/texmf-site:/usr/share/texmf # gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2)
Created attachment 112766 [details, diff] Patch to texmfroot.cpp to avoid checking for multiple root directories The patch avoids a check that is made for each root directory to determine whether it has already been initialised as a root directory, and fails the entire program if it has.
I get this "mpm: Unexpected condition" error, too, with a fairly fresh Gentoo install & app-text/tetex-3.0_p1-r3 I'm sure that mpm worked with tetex 3 on a previous system, but it was quite possibly an earlier version of mpm - as others have observed the previous version in the portage tree (mpm-2.5.2199_beta4) now doesn't find valid repositories. I have two comments to add to this "thread": 1) is it really valid for Gentoo's (or TeTeX's??) /etc/texmf/texmf.d/00texmf.cnf to set the same directory in the path 3 times? It seems to me that the path is defined as "look in /var/lib/texmf and if you don't find it there look in /var/lib/texmf again and if you don't find it there look in the same place again(!!) before looking somewhere else" I can't entirely blame mpm for complaining about this!! 2) I'm not really sure it's a good "patch" if all it does is comment out one section of code. I mean, if that code is worthless then remove it completely; if the code is valid but buggy then correct it. If you're saying "a hack to work around the problem is to comment out this section of code" then just say that - don't try to pretend it's a real patch!! (which is generally assumed to fix something) Stroller.
(In reply to comment #25) > 1) is it really valid for Gentoo's (or TeTeX's??) > /etc/texmf/texmf.d/00texmf.cnf to set the same directory in the path 3 times? It doesn't seem to be invalid to me, however useless and inefficient it is. The author seems to think he is being "pedantic" doing the check, possibly for no reason. http://dojo.miktex.org/forums/permalink/1121/687/ShowThread.aspx#687 If it is less of a hassle to change the way the texmf path is generated in order to check for duplicates then the diff I contributed may be ignored. > 2) I'm not really sure it's a good "patch" if all it does is comment out one > section of code. I mean, if that code is worthless then remove it completely; > if the code is valid but buggy then correct it. If you're saying "a hack to > work around the problem is to comment out this section of code" then just say > that - don't try to pretend it's a real patch!! (which is generally assumed to > fix something) Whether this is a patch or a hack depends on the answer to question 1. I was not pretending it was a solution, but it does enable the program to work correctly. The patched/hacked program installs packages in the correct repository and updates the already installed packages from the repository as needed. Sorry for causing a fuss if thats not enough but the package maintainer hasn't commented on the issue > Stroller. >
patch added, thanks
Created attachment 123526 [details] mpm-2.5.2719_beta15.ebuild (version bump) the bug with multiple root is persist in this version, everything else seems to work
