Version bump and minor update to lilypond-1.6.10.ebuild (bug 24687). This is the latest stable release of lilypond.
Created attachment 15687 [details] lilypond-1.8.0.ebuild (Update)
*** Bug 24687 has been marked as a duplicate of this bug. ***
I attempted to update this ebuild myself when 1.8.0 came out, and ran into several problems. 1) pertaining to GCC 3.3's head/tail problems, and other very beta issues, a simple patch is needed to get it to configure; it then builds fine. This is contrary to the current ebuild that is so restrictive in the compiler it allows. It even built without the hack used in the GCC 3.2 section of this ebuild. 2) this ebuild does not build the PFA fonts or install them, which caused lilypond to exit with an error for me. Is this just me? I have my own completely re-written ebuild for 1.8.0, and i will submit it as an alternative when i have finished hammering out the bugs, unless someone comments that the issues i mentioned do not appear for them. -Chandler Carruth
There was a change to src_compile made by jje@gentoo.org between 1.6.6 and 1.6.9. You may want to take a look at the diff and at the 17 May 2003 ChangeLog entry. As far as I'm concerned, the more compiler versions we can support, the better, but I think jje's thinking was that new compilers should be tested before being allowed. If you have a tested version for gcc 3.3, please submit it. I'm trying to recreate your font issue but haven't had any luck yet. Did you invoke lilypond directly or via ly2dvi or lilypond-book? If you invoked directly, did you source /usr/share/lilypond/1.8.0/buildscripts/out/lilypond-profile first?
I'm happy to put in support for compiling with 3.3 if you are willing to test it (and provide the patch ;-) ). The changes i made in previous versions was so simplify the compiler support. In previous versions it attempted to support obscure 3.1 prerelease versions, etc. I'll hold off on commiting this until you get back to me letting me know if you are going to submit an alternative. FYI, the big issue with previous ebuilds have been getting the doc to install as it tends to have all sorts of sandbox issues.
Created attachment 15760 [details, diff] patch to fix gcc3.3 compile errors Ok... This "fixes" the bugs at the _source_, but you need to re-create the configuration files and the make files etc from the source in order for the changes to propagate. This can be achieved by running: # NOCONFIGURE=1 ./autogen.sh In the ${S} directory. the NOCONFIGURE keeps it from actually running the new configuration script. the autogen.sh will propagate the fix throughout the configuration files. This was a much more elegant way of patching it (involved 2 files) than patching _after_ running autogen.sh. Let me know if this is unacceptable for an ebuild, and I will make one big patch, and test it. The only bug that it fixes is bad arguements to head/tail -- no actual "buggy" code. -Chandler Carruth
Created attachment 15761 [details] The (broken!!) ebuild I came up with.... Ok... this ebuild _does_not_work_!!!! I'm posting it as an example of where I was going with my alternate ebuild. It does _not_ fix the sandbox issues that were mentioned in previous posts. Now, to explain the parts of the ebuild that are relevant and interesting despite this. First: the ebuild has MAKE_PFA_FILES=1 set in the emake commands. this creates and installs the pfa font files that are _necessary_ for making postscript files with scalable fonts. They are _not_ installed by default. I will try and find the link to the lilypond mailing list where this is discussed, and post it. To reproduce this, remove _all_ lilypond files, including all data directories from all previous installations, and try to install it without that flag in the make command -- when i did this (clean install, using this ebuild w/o the MAKE_PFA_FILES=1) ly2dvi -p whatever.ly would fail on being unable to find the pfa fonts. second: This ebuild works fine with 2 exceptions: 1) the documentation causes sandbox errors, as has been fixed in the ebuild already posted here. 2) the MAKE_PFA_FILES=1 causes sandbox errors, which I did not know how to debug. If you could try out this flag in your ebuild and see if you can get it to work, that would be great. I am still too new to the ebuild world to understand fully how the sandbox stuff works. Thats pretty much it for this. the MAKE_PFA_FILES=1 is the way the lilypond developers suggest for installing the type1 postscript fonts. =] sounds good to me. NB: Something i forgot -- the requirement on mftrace should be 1.0.19 -- thats the only version i have tested with. I can post an ebuild for it... its identical to 1.0.10 in portage, and 1.0.18 on here. i think there may even be a 1.0.19 one on here. also, 1.0.19 i compiled with t1utils-1.28. I think i posted the ebuild for this one (another version bump) to bugzilla. mftrace-1.0.10 WILL NOT WORK to build MAKE_PFA_FILES. The command line syntax has changed, and the newer lilypond build files reflect this. I don't know when in the mftrace versions the change happened, but it definatel works with 1.0.19, no problems. Ok... I think thats it for this. Please, any questions and such, let me know. I'm really interested in seeing lilypond 1.8.0 make its way solidly into portage. -Chandler Carruth
I am going to edit your ebuild first to include the gcc3.3 patch, test that, and then i will try it with MAKE_PFA_FILES=1, and see where (if?) it b0rks... should have results pretty soon. -Chandler Carruth PS: i will try to reproduce the error i had without MAKE_PFA_FILES=1 as well
Created attachment 15792 [details] My update of the ebuild posted. Ok. Lots of stuff here. First: bug with PFA font files. It is reproducable for me with the following steps: 1) unmerge any and all lilypond installations. rm -rf any and all lilypond data directories. "rm -rf /usr/share/lilypond" did it for me, but could be different. Specifically you must remove the fonts directory for any previous lilypond installs. 2) emerge lilypond 1.8.0 using the first ebuild posted here. (it does not contain MAKE_PFA_FILES=1) 3) run "ly2dvi -p somefile.ly". it is necessary to try to create a PS document and a PDF document. if you just run "ly2dvi somefile.ly" to generate the TeX, or even do stuff like generate .png files (the stuff done for the webpage) it will not happen. It is the scalable type1 postscript fonts that have not been installed. As documented in the lilypond mailing list, the "correct" way of making and then installing the scalable type1 postscript fonts involves defining "MAKE_PFA_FILES=1" in the make, and in the make install. This process requires mftrace and t1asm to be working. The versions in my copy of the portage tree (a few days old) are not compatable. There are some odd commandline syntax errors. I have posted, or someone else has posted ebuilds for both the latest versions of these utilities, both of which are sorely out of date. I have bumped the dependancies of my ebuild to reflect that the older packages will not work correctly. I have tested with mftrace 1.0.19, and t1utils 1.28 successfully. Another issue: building the PFA files causes sandbox violations. I fixed it (i just looked at how you fixed the documentation sandbox violations...) i think. Please, let me know if my fix is incorrect, or follows the wrong procedure. Now, on the subject of sandbox violations; the ebuild posted originally still gives me sandbox violations when i try to install the documentation. I added one more directory to the permissions, and it worked like a charm. Again, please check my form on solving the sandbox violations. Another problem with building the documentation is a lacking dependancy -- ImageMagick is needed to compile the documentation, as the build scripts use "convert" to get the right file formats on everything. I've added it to the doc? dependancies, and moved mftrace to the main dependancies as its needed for PFA files. Ok... In other stuff, I switched to use econf, emake and einstall. The helper functions are there, might as well use 'em. You may disagree here, but seems a shame to not use what you are given. On the bugs reported, they were all tested independantly of each other, with fixes for the other bugs both on and off, to verify that they were completely independant bugs. The GCC 3.3 fix is good for me, and applied nicely in the ebuild. Again, a little hackish--re-running autogen.sh--but hey, it works. It is tested on a very current release of GCC 3.3(.1), snapshot from 0804... but the bug is not related much to the compiler, but to head/tail, so i am confident that it is applicable to all 3.3.* compilers. As i get more compilers compiled on my box, i will test with them, including, hopefully, a cvs build of GCC to stay ahead of the game. Could someone test the PFA stuff with older versions of GCC so that it could be added to their compile? I don't have old versions installed yet, and that will take me some time, but I'd like for the PFA bug to be fixed for the more common GCCs. Shoot, I guess first, I'd like to be sure that others can reproduce that bug. Any other issues with this package? This ebuild works perfectly for me now, although the PFA building is _slow_... Its making vector graphics out of bitmaps. Hope all this helps somebody, and gets into portage eventually. -Chandler Carruth
einstall fails on MAKE_PFA_FILES=1 in the einstall if gcc!=3.3 because it is missing in the src_comple{} part. Furthermore, the elif gcc 3.3 does an additional addwrite /var/cache/fonts/ls-R which is not present in the other elifs. This may cause problems as well.
i'm going to try to find time to commit this tomorrow. Looks like a little clean-up is needed for none gcc 3.3, but apart from that it's good.
i'm about to post a cleaned up version of the ebuild for non gcc 3.3 sorry i didn't do this earlier. hope i can save you some time. it also has a use flag for disabling the PFA files -Chandler Carruth
Created attachment 16180 [details] lilypond-1.8.0.ebuild (cleaned up) Ok.. This is a fairly clean version of my earlier update. Has all compiler use PFA files unless a person specifies in their USE flags "nopfa" which turns the generation of them off. Hope this makes your like a little easier jje. -Chandler Carruth
I'm working on some fixes to Chandler's latest (16180). I'll post it after a little more testing. Sorry I've been out of the loop for a while on this. Thanks for explaining the ly2dvi -p issue, Chandler. Having type1 fonts is a nice addition. I've been using ly2dvi -P followed by ps2pdf for pdf output for a long time. Being able to use ly2dvi -p is better.
Created attachment 16216 [details] lilypond-1.8.0 (Update) Fixed mftrace dependency (should be required for doc and/or pfa but not otherwise). Worked around BUILD_PFA issue (was triggering pfa build even when set to "0"). The big change is that I was able to get rid of all the multiple compiler cruft in src_compile. With lilypond 1.8.0 and the patches in flex-2.5.4a-r5, the gcc3/flex workaround is no longer necessary. This only is a significant change for gcc 3.2. I tested with gcc-3.2.3-r1.
Created attachment 16247 [details] lilypond-1.8.0.ebuild (Update) Some minor improvements: The head/tail syntax issues addressed by Chandler's patch are not directly related to gcc 3.3 but are needed for compatibility with coreutils 5.0 (which is more strictly POSIX compliant than its predecessors). Renamed patch to lilypond-1.8.0-coreutils-compat.patch. Making lilypond more POSIXly compliant shouldn't hurt anything and can only help, so I applied the patch for all compiler versions. Changed pfa build method to use "make pfa-fonts" which is the preferred method according to the latest docs. Moved BUILD_PFA stuff to src_install because it isn't needed anywhere else anymore. Note that this ebuild and most above require mftrace-1.0.19 (bug 24765).
Ossmann's version of 2003-08-17 20:18 EST has a renamed patch (or also changed?---I renamed it and it seems to work) and an addwrite /var/cache/fonts/ls-R which causes sandbox problems on my setup (tetex 2.0.2) because the pfa generation wants to write the generic cm fonts with the aid of /var/cache/fonts/jknappen/
Created attachment 16394 [details] lilypond-1.8.0.ebuild (Update) Fixed sandbox issues. Yes, I renamed the patch but didn't modify it.
lilypond 1.8.1 is out; shouldn't require much more ebuild hacking
Created attachment 16489 [details] lilypond-1.8.1.ebuild (Update) version bump
Created attachment 16490 [details, diff] lilypond-1.8.1-coreutils-compat.patch Renamed Chandler's patch and also updated it a bit after finding a few more head/tail syntax issues.
Created attachment 17354 [details] lilypond-1.8.2.ebuild (Update) version bump
Created attachment 17355 [details, diff] lilypond-1.8.2-coreutils-compat.patch version bump
I'm in the middle of adding this to the tree. Do you guys want both the 1.8.0 and 1.8.2 ebuilds, or just the latter?
I'd say just 1.8.2.
Thanks for all your work on this, guys. I guarantee you that lilypond would not be in Gentoo if it weren't for your work. I'm probably one of the few devs who uses lilypond, and I don't have the time personally to solve the various build problems. So thanks again.
