Lilypond upstream already provides experimental support for using lilypond with Guile 2.0.x, but the lilypond ebuild does not expose the --enable-guile2 flag, yet. An ebuild could expose this flag via the USE flag guile2. Is this the right way to expose it? Should we instead make this conditional on eselect-guile or similar? Reproducible: Always
Slotting guile is not an easy task, fulax tried it some years ago but there were issues. The best thing would be fixing all guile's reverse deps and have a happy guile-2 in the tree. Everything else would be an overkill.
I don’t mean going the full way towards slotting guile, but rather just exposing the guile2 configure option, so those of us who use an unmasked guile-2.0.x can use lilypond.
Created attachment 398742 [details] metadata.xml the attached metadata.xml adds the guile2 USE flag.
Created attachment 398744 [details, diff] lilypond-2.19.15-guile2.patch The attached patch (intended for the files-dir) adapts configure.ac to check for guile < 2.3.0 instead of guile 1.9.0. As such guile 2.0.x and 2.1.x are treated as valid executors for guile scripts.
Created attachment 398746 [details] lilypond-2.19.15-r1.ebuild The attached ebuild for lilypond 2.9.15 makes lilypond build with Guile 2.0, but minimal examples like the ones on http://www.lilypond.org/tiny-examples.de.html still fail: They produce an empty postscript file (with the correct number of pages but no content).
Created attachment 398748 [details] lilypond-9999.ebuild The attached ebuild for lilypond from VCS makes lilypond build with Guile 2.0, but minimal examples like the ones on http://www.lilypond.org/tiny-examples.de.html still fail: They produce an empty postscript file (with the correct number of pages but no content).
The attached ebuilds bail out with error when USE=guile2 is set and the guile version is <2.0.7.
At the lilypond side, the tracking bug for this seems to be https://code.google.com/p/lilypond/issues/detail?id=1055
*** Bug 590534 has been marked as a duplicate of this bug. ***
The problem is here yet
Fixed in the 2.19.46.
Is this really fixed? Yes, lilypond 2.19.46 reportedly works, an it successfully compiled for me as well. But it is package masked. And the lilypond 2.18.2 ebuilds don't make their dependency explicit in the ebuild. Shouldn't they explicitely depend on <dev-scheme/guile-1.9 so that portage knows to keep older guile around if lilypond is in the selected set and lilypond 2.19 is not unmasked? Even more strongly, as long as there is no unmasked and stabilized package for lilypond, I think you need to keep an open ticket blocking #587252 since you can't drop guile-1.8 before that (unless you propose dropping lilypond as well). Personally I'd ignore the fact that lilypond 2.19 is just a development version, and start packaging that for ~arch so that by the time 2.20 comes around we have some experience with the more recent lilypond codebase and can stabilize that more quickly. And if 2.20 takes longer than anticipated, you might even consider stabilizing 2.19 depending on how many bug reports you see for that. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005 is worth reading. It involves details on why 2.18 probably will never work with guile 2, a hint that at least at some point lilypond devs were actually considering skipping guile 2.0 and waiting for 2.1 instead (not sure that's still the case), and that Debian is hoping for a lilypond 2.20 before the Strech freeze at the beginning of 2017. Their main concern is doing a full release cycle with a development version, but Gentoo as a rolling release distro should have fewer concerns shipping 2.19 and upgrading to 2.20 once that is out.
Well, from what I can see lilypond-9999 will *compile* with guile-2.*, but tests I've tried running lily on actual files fail out with errors. Recent (ie, about a month before this post) with devs indicate that there are some unresolved issues with guile upstream, and that they'll likely wait for guile-2.1 before making the switch (which might be "1-2 years", one of them said on the lilypond mailing list). I'll try running lily after the current emerge is done, and report back, but I'd hesitate to call this "resolved".
Update: as expected, trying to run lilypond-2.19.49 (which is what -9999 just installed) with guile-2.* (2.0.12 is what I have installed) returns errors about deprecated functions and fails to run on .ly files. So I wouldn't exactly call this "fixed"; can a dev please re-set this to CONFIRMED until we're sure that lilypond can run with guile-2.*?
(In reply to Martin von Gagern from comment #12) > Is this really fixed? Yes, lilypond 2.19.46 reportedly works, an it > successfully compiled for me as well. But it is package masked. Yes. If there are problems with the implementation, you get to file a new bug report.
