Description of problem: Asymptote spec file has errors which cause that after a package installation an attempt to open in emacs (and xemacs likely too) a file like 'new.asy' results in the following: Loading /usr/share/emacs/site-lisp/asy-mode.el (source)... File mode specification error: (file-error "Cannot open load file" "asy-keywords.el") The problem is that asymptote supplied file "asy-keywords.el" is indeed not in a load path; but there is more. First in asy-mode.el the following can be found: ;; Notes: ;; ;; For full functionality the two-mode-mode package should also be installed ;; (http://www.dedasys.com/freesoftware/files/two-mode-mode.el). That file could, and most likely should, be added to asymptote package as an additional source. It is available under "Apache License, Version 2.0" so this does not appear to be a problem. I see why you are doing "the real installation work" in triggers which depend on editors installed. It that whole section in '%install' which starts with "# Emacs/Xemacs mode and init files", and similar for vim, only for a benefit of %ghost? It does not look that this is used otherwise. Absolute symbolic links may turn out to be problematic when something will get, say, mounter over NFS. I would think that 'cp -a' (in %install section and in triggers) would be much safer and files in question are not that big after all. In any case I would suggest something in that style (obviously consistently in all places) for *.el installation: install -dm 755 $RPM_BUILD_ROOT$dir/site-start.d install -dm 755 $RPM_BUILD_ROOT$dir/asymptote ( cd $RPM_BUILD_ROOT$dir/asymptote && \ ln -s %{_datadir}/%{name}/*.el . ## or 'cp -p ...' here cd $RPM_BUILD_ROOT$dir/site-start.d && \ ln -s ../asymptote/asy-init.el . ) Bother with .elc files does not produce nowadays anything which would be here noticeable. Last but not least asymptote provides 'asymptote.info.gz' and 'asy-faq.info.gz' while in '%post' install-info is run with only the first one (with obvious consequences). Version-Release number of selected component (if applicable): asymptote-1.29-1.fc7 and all other releases How reproducible: always
Created attachment 155750 [details] suggested changes to asymptote specs These are spec changes along the lines as suggested in the report. A closer look at compilation record reveals also that the current animation support assumes 'animate.sty' (not included, on CTAN) while there are still references in sources to a removed 'pdfanim_temp.sty'. Also Makefile in asymptote-1.29/doc/FAQ/ seems to have issues ('asy-faq.xrefdb' is used by bfnnconv.pl before it is created) but what is harmed is not immediately obvious.
Sigh! Make this 'mkdir' in triggers into 'mkdir -p'. Clearly I do not have much experience with triggers.
Thanks for the report and the patch (I'm a vim guy ;)). I'll try to update the specfile tomorrow or saturday, and notify one of the upstream authors (at least John Bowman is very responsive). PS - The triggers are very fragile; IIRC I duplicated the triggers from the rpmdevtools specfile.
In asymptote-1.29-2.fc7 emacs support is as broken as it was before. Patches attached to comment #1 are doing that correctly.
(In reply to comment #4) > In asymptote-1.29-2.fc7 emacs support is as broken as it was before. > Patches attached to comment #1 are doing that correctly.. I know. I didn't add time to finish reviewing/testing your patch (IIRC rpmlint was still complaining about the a couple of emacs symbolic links). I also want to change the vim syntax file symbolic links (still to test it). jpo
> I know. Ok. I did not intend to rush you. > rpmlint was still complaining about the a couple of emacs symbolic links I am guessing that complaints were about absolute instead of relative links. If you will mount /usr/share, or /usr/share/emacs, over NFS then absolute links may go to another file system; even worse - these could be links to files in $RPM_BUILD_ROOT tree. Relative links may or may not help with the first problem. They may make rpmlint and builder happier but you have to be careful how they are used (bind mounts may be present). That is why I suggested that just a copy could be simpler. The patch from comment #1 does shave off $RPM_BUILD_ROOT while constructing links but silently assumes that $RPM_BUILD_ROOT does not end with "/". If it does then that can be handled for a price of a bit of ugliness but it is probably not that important as those links are really only placeholders and you create real ones in triggers. Which means that you can replace those in %install with ln -s ../../../asymptote/*.el . anyway without a need to do ln -s ../../../../../usr/share/asymptote/*.el . which is safer. The above assumes a layout like in my patch. If you want links then maybe you should do those in that style both in %install and in triggers. The second variant is preferred.
asymptote 1.30 has already been built (for FC-6, F-7, and devel) and should start appearing soon in the mirrors (already being pushed for rawhide and FC-6; no ETA for F-7). This version should solve the asy-keywords.el problem. I also tried to minimize the code in the triggers by avoiding creating the asymptote subdirectory under the emacs/xemacs owned directories). Still in the TODO list: * shipping the two-mode-mode.el mentioned in the first comment http://www.dedasys.com/freesoftware/files/two-mode-mode.el * maybe package animate.sty as tetex-animate http://www.ctan.org/tex-archive/help/Catalogue/entries/animate.html * look into the documentation building problems reported in comment #1 * try to discover why the documentation fails to build in FC-5 (again; asymptote 1.27 also had a similar problem) jpo
> * try to discover why the documentation fails to build in FC-5 > (again; asymptote 1.27 also had a similar problem) I do not see it. I just tried rebuilding src.rpo package for 1.30 on FC-5 and I got: RPMS/i386/asymptote-1.30-1.fc5.i386.rpm RPMS/i386/asymptote-debuginfo-1.30-1.fc5.i386.rpm 'rpm -qdp RPMS/i386/asymptote-1.30-1.fc5.i386.rpm' gave me this: /usr/share/doc/asymptote-1.30/BUGS /usr/share/doc/asymptote-1.30/CAD.pdf /usr/share/doc/asymptote-1.30/ChangeLog /usr/share/doc/asymptote-1.30/LICENSE /usr/share/doc/asymptote-1.30/README /usr/share/doc/asymptote-1.30/ReleaseNotes /usr/share/doc/asymptote-1.30/TODO /usr/share/doc/asymptote-1.30/asy-faq.ascii /usr/share/doc/asymptote-1.30/asy-faq.html/index.html /usr/share/doc/asymptote-1.30/asy-faq.html/section1.html /usr/share/doc/asymptote-1.30/asy-faq.html/section2.html /usr/share/doc/asymptote-1.30/asy-faq.html/section3.html /usr/share/doc/asymptote-1.30/asy-faq.html/section4.html /usr/share/doc/asymptote-1.30/asy-faq.html/section5.html /usr/share/doc/asymptote-1.30/asy-faq.html/section6.html /usr/share/doc/asymptote-1.30/asy-faq.html/section7.html /usr/share/doc/asymptote-1.30/asy-faq.html/section8.html /usr/share/doc/asymptote-1.30/asy-faq.html/section9.html /usr/share/doc/asymptote-1.30/asymptote.pdf .... ( 192 lines from /usr/share/doc/asymptote-1.30/examples/ skipped) .... /usr/share/info/asy-faq.info.gz /usr/share/info/asymptote.info-1.gz /usr/share/info/asymptote.info-2.gz /usr/share/info/asymptote.info.gz /usr/share/man/man1/asy.1.gz /usr/share/man/man1/xasy.1x.gz I am not sure where could be the problem.
I should likely mention - there is no older asymptote version installed on a machine used for a build from comment #8.
One more minor nit which showed up when going through a compilation record. Something like that is present: mkdir -p asy-faq.html perl bfnnconv.pl asy-faq.bfnn no asy-faq.xrefdb (No such file or directory) at bfnnconv.pl line 43. followed by other complaints dependent on the above. This is of no consequece as BUILD/asymptote-1.30/doc/FAQ/Makefile has now perl bfnnconv.pl asy-faq.bfnn perl bfnnconv.pl asy-faq.bfnn and on this missing file is created on the first run. OTOH if you want to avoid spurious error reports then you may want to change that to perl bfnnconv.pl asy-faq.bfnn >/dev/null 2>&1 perl bfnnconv.pl asy-faq.bfnn
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
I believe that the current asymptote does a correct thing one way or another and simply nobody closed the bug. If I am mistaken then please somebody reopen.