Bug 26136 - lilypond-1.8.2.ebuild (Update)
Bug#: 26136 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: enhancement Priority: P2
Resolution: FIXED Assigned To: agriffis@gentoo.org Reported By: mike@ossmann.com
Component: Ebuilds
URL: 
Summary: lilypond-1.8.2.ebuild (Update)
Keywords:  EBUILD
Status Whiteboard: 
Opened: 2003-08-07 10:20 0000
Description:   Opened: 2003-08-07 10:20 0000
Version bump and minor update to lilypond-1.6.10.ebuild (bug 24687).

This is the latest stable release of lilypond.

------- Comment #1 From Mike Ossmann 2003-08-07 10:21:59 0000 -------
Created an attachment (id=15687) [details]
lilypond-1.8.0.ebuild (Update)

------- Comment #2 From Martin Holzer (RETIRED) 2003-08-07 11:26:41 0000 -------
*** Bug 24687 has been marked as a duplicate of this bug. ***

------- Comment #3 From Chandler Carruth 2003-08-07 18:51:31 0000 -------
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

------- Comment #4 From Mike Ossmann 2003-08-07 22:20:49 0000 -------
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?

------- Comment #5 From J. Ellis 2003-08-08 00:38:05 0000 -------
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.

------- Comment #6 From Chandler Carruth 2003-08-08 09:29:03 0000 -------
Created an attachment (id=15760) [details]
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

------- Comment #7 From Chandler Carruth 2003-08-08 09:41:12 0000 -------
Created an attachment (id=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

------- Comment #8 From Chandler Carruth 2003-08-08 09:56:21 0000 -------
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

------- Comment #9 From Chandler Carruth 2003-08-09 01:33:50 0000 -------
Created an attachment (id=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

------- Comment #10 From Maarten Wisse 2003-08-11 07:50:06 0000 -------
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. 


------- Comment #11 From J. Ellis 2003-08-16 02:30:50 0000 -------
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.

------- Comment #12 From Chandler Carruth 2003-08-16 08:53:45 0000 -------
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

------- Comment #13 From Chandler Carruth 2003-08-16 09:20:05 0000 -------
Created an attachment (id=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

------- Comment #14 From Mike Ossmann 2003-08-17 09:27:20 0000 -------
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.

------- Comment #15 From Mike Ossmann 2003-08-17 11:38:23 0000 -------
Created an attachment (id=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.

------- Comment #16 From Mike Ossmann 2003-08-17 20:18:40 0000 -------
Created an attachment (id=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).

------- Comment #17 From Maarten Wisse 2003-08-20 06:29:51 0000 -------
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/ 

------- Comment #18 From Mike Ossmann 2003-08-20 16:35:06 0000 -------
Created an attachment (id=16394) [details]
lilypond-1.8.0.ebuild (Update)

Fixed sandbox issues.

Yes, I renamed the patch but didn't modify it.

------- Comment #19 From Jon Hood (RETIRED) 2003-08-22 16:36:10 0000 -------
lilypond 1.8.1 is out; shouldn't require much more ebuild hacking

------- Comment #20 From Mike Ossmann 2003-08-22 20:54:55 0000 -------
Created an attachment (id=16489) [details]
lilypond-1.8.1.ebuild (Update)

version bump

------- Comment #21 From Mike Ossmann 2003-08-22 20:58:38 0000 -------
Created an attachment (id=16490) [details]
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.

------- Comment #22 From Mike Ossmann 2003-09-09 11:47:43 0000 -------
Created an attachment (id=17354) [details]
lilypond-1.8.2.ebuild (Update)

version bump

------- Comment #23 From Mike Ossmann 2003-09-09 11:48:42 0000 -------
Created an attachment (id=17355) [details]
lilypond-1.8.2-coreutils-compat.patch

version bump

------- Comment #24 From Aron Griffis (RETIRED) 2003-09-12 09:59:58 0000 -------
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?

------- Comment #25 From Mike Ossmann 2003-09-12 10:06:17 0000 -------
I'd say just 1.8.2.

------- Comment #26 From Aron Griffis (RETIRED) 2003-09-12 10:34:58 0000 -------
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.