bugDenemo - Bugs: bug #54821, support for guile-2.2

 
 

bug #54821: support for guile-2.2

Submitter:  Bernd Waibel <waebbl>
Submitted:  Thu 11 Oct 2018 01:38:27 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 10 Mar 2020 10:10:18 AM UTC, comment #14: 

I've tagged the latest release 2.3.0
I hadn't read up on this tag stuff until now, but from what I read the tag "stable" should not be there - it violates the very idea of a tag, because it was presumably created with the idea of moving what it tagged to the latest release. So if no-one disagrees I'll try to delete it.

Richard Shann <rshann>
Group administrator
Tue 10 Mar 2020 12:59:30 AM UTC, comment #13: 

Thank you very much for applying the patch!  :-)

I am happy to report that Denemo 2.2.0 builds fine with Guile 2.2:


and seems to run fine locally too under Gnome on my Debian sid system, and I was able to enter notes normally and can hear sound back, etc.  (though I must admit that my local test was far from comprehensive.)

I did not upload Denemo 2.3.0 because I ran into a test failure due to Debian's build daemons, using sbuild, setting HOME=/sbuild-nonexistent in the build chroot.  I think I have found a workaround by setting HOME to a temporary writable directory in override_dh_auto_test in debian/rules, but I wanted to wait the normal 5 days Denemo to enter Debian testing first before making further uploads to Debian.  :-)

By the way, could you please consider tagging releases?  I see that you do have "branches" like stable-2.3.0, but would be nice to have "tags" like "v2.3.0" or "2.3.0" too.  Otherwise, even it is just a mirror, https://github.com/denemo/denemo/releases only show really old releases from 2013; and likewise on http://git.savannah.gnu.org/cgit/denemo.git where the only tags and hence .tar.gz shown for download are from 6 years ago.

Many thanks!

Cheers,
Anthony

Anthony Fok <foka>
Mon 09 Mar 2020 08:38:58 AM UTC, comment #12: 

Thank you very much for the patch - I've applied it to the main branch. I haven't got a system with Guile 2.2 to test, but will test when I have.

Richard Shann <rshann>
Group administrator
Fri 06 Mar 2020 11:38:32 PM UTC, comment #11: 

Hi, I have uploaded a new patch:

  denemo-2.3.0-and-master--support-guile-2.2-in-configure-ac--2020-03-04.patch

which adds support for guile-2.2 to configure.ac, and falls back to guile-2.0 and finally to guile-1.8 as necessary.

As shown in https://travis-ci.org/anthonyfok/denemo/builds/659362180, it still builds fine in Travis CI test where guile-2.0-dev is used.

This is also my solution to https://bugs.debian.org/885190

Thanks!

Anthony Fok

Anthony Fok <foka>
Wed 04 Mar 2020 11:58:29 PM UTC, comment #10: 

Hello,

Adding support to Guile 2.2 is now becoming urgent, including for Debian:

Debian Bug#885190: denemo: please migrate to guile-2.2
https://bugs.debian.org/885190


From: rlb@defaultvalue.org (Rob Browning)
To: maintonly@bugs.debian.org
Subject: denemo: please migrate to guile-2.2
Date: Mon, 25 Dec 2017 16:17:34 -0600 (CST)
Source: denemo
Severity: normal

I'd like to remove guile-2.0 before the buster release, so please
migrate to guile-2.2 when you can.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


Anthony Fok <foka>
Sat 27 Oct 2018 05:16:09 PM UTC, comment #9: 

Thank you for your thorough testing.
Failure type 1) I have fixed with commit
3a315f256951889adab8d6622291daa372ad0f39 on the master branch.
Failure tyoe 2) I hope is fixed by commit
ca0001a883131ce61ad2e693356df88de44c5090
although I haven't been able to test it very much.

I did try your patch (*) at commit
1a280684b572f43e298dc0e18fe2e87a5314fc52
reverted at the next commit
a2f85b920244fe698d2182a0022ec7b7886cf878

which unfortunately broke the (complicated) build for Windows - I suspect this was because that builds for guile-1.8 on a machine that has guile-2.0 installed. So I'm guessing that it selected the later version. However, before I could explore this further my version of the build script stopped working in a quite inexplicable manner and I haven't managed to revive it. The infrastructure for this (nightly) cross-build is at http://www.denemo.org/~jjbenham/mxe/
and my build was adapted from this.

(*) when I say "your patch" this is not strictly the case as the patch did not apply directly to the current development version (I guess it is for the last release), but I think I got it right.

Richard Shann <rshann>
Group administrator
Fri 26 Oct 2018 08:07:59 AM UTC, comment #8: 

I have now finished testing the build. For some combinations it fails to compile, for some it compiled but failed the test and for yet some other combinations it compiles and passes test.
But to my knowledge it never failed to compile due to guile support or the related patch.
I upload a tar ball containing all build logs here, if you want to take a look at them. I also compiled a google table at https://drive.google.com/open?id=1sQ8QycUNdd-81fN_2hiYyFfCduleJdPqOVCI6bdqkDs to help analyze the causes of failures. The last sheet contains some info about the combinations of flags.

I had three types of failures during compile or link phases:

1. The package always failed when using --enable-gtk2, with the error:
command/object.c: In function 'place_directives':
command/object.c:1345:15: error: 'color' undeclared (first use in this function); did you mean 'calloc'?
   get_color (&color, 0.0, 0.0, 0.5, 1.0);

If this isn't known yet, please tell me, if I should open a separate bug report.

2 The other two compile failures are linker errors and tied to the portaudio patch you provided in bug #52741 (https://github.com/gentoo/gentoo/blob/master/media-sound/denemo/files/denemo-2.2.0-no-portaudio-fix.patch) and interconnected to each other.
a) If the patch was not applied, in all four cases it failed when alsa, evince, nls, portmidi, rubberband and gtk3 are enabled and the other flags disabled. Maybe this makes some more sense to you than it does to me. The error was:

audio/midi.o: In function `start_playing':
midi.c:(.text+0x132d): undefined reference to `get_playback_speed'
core/view.o: In function `set_speed':
view.c:(.text+0x7ce): undefined reference to `set_playback_speed'
display/draw.o: In function `draw_staff':
draw.c:(.text+0xdc2): undefined reference to `get_playback_speed'
draw.c:(.text+0xdec): undefined reference to `get_playback_speed'
display/draw.o: In function `draw_score.part.7':
draw.c:(.text+0x38c7): undefined reference to `get_playback_speed'
display/draw.o: In function `set_start_and_end_objects_for_draw':
draw.c:(.text+0x5051): undefined reference to `get_playback_speed'
draw.c:(.text+0x50b9): undefined reference to `get_playback_speed'
scripting/scheme-callbacks.o:scheme-callbacks.c:(.text+0x59cd): more undefined references to `get_playback_speed' follow
collect2: error: ld returned 1 exit status

b) If your patch was applied, it fails always when static and gkt3 are enabled. The other cases are not so clear, as it fails always with those options enabled and disabled. The error here was:

libaudiobackend.a(libaudiobackend_a-audiointerface.o): In function `get_playback_speed':
audiointerface.c:(.text+0x450): multiple definition of `get_playback_speed'
audio/midi.o:midi.c:(.text+0x1f0): first defined here
collect2: error: ld returned 1 exit status


The failing tests naturally all happened when gtk3 was enabled. The data says here, that in all cases evince was not enabled, and fluidsynth was enabled. The other cases have mixed options and don't show a clear pattern for me.

Hope this will help in the task to add support for guile-2.2.3 as well as to catch the other issues. If you have any questions regarding this, don't hesitate to ask.

(file #45305)

Bernd Waibel <waebbl>
Thu 18 Oct 2018 07:03:34 PM UTC, comment #7: 

I'm not the maintainer of the lilypond package, I only know we have lilypond-2.19.80 with support for guile-2. Because test is currently restricted, I don't think the build passes the tests. A comment in the build file says, correct data for tests being not bundled yet (c.f. https://github.com/gentoo/gentoo/blob/master/media-sound/lilypond/lilypond-2.19.80-r1.ebuild#L55). For lilypond-2.18.2 Gentoo also doesn't support guile-2. It's one of the reasons guile-1.8.8 is still in the repository.

I reworked the patch a bit and tried it inside a clean docker container using

  • guile-1.8.8 / lilypond-2.18.2
  • guile-1.8.8 / lilypond-2.19.80
  • guile-2.0.14 / lilypond-2.19.80 and
  • guile-2.2.3 / lilypond-2.19.80

and it compiled successfully in all four cases.

However, I only used a minimal configuration for denemo to keep number of packages pulled in and compile time limited. Only --enable-x11, --enable-gtk3 and --enable-nls were used in my tests.

An excessive test run with this four setups, testing all combinations of configure options is in the pipeline, but will take some time.

What I found so far is, the guile-2.0 and guile-2.2 versions of the M4 include file (stored under /usr/share/aclocal/guile.m4 in Gentoo) differ only in implementation details, the both provide the same macros to use. The guile-1.8 M4 file is different, as it provides a different set of macros. It doesn't have a GUILE_PKG macro, which was introduced in guile-2. All three however provide the GUILE_FLAGS, GUILE_PROGS and GUILE_SITE_DIR macros. GUILE_PROGS is called from GUILE_FLAGS and I also added a call to GUILE_SITE_DIR, though I'm not sure if it's necessary. Adding the CFLAGS and LDFLAGS to the CFLAGS and LIBS variables for substitution makes denemo compile in all of my tested combinations.

I attach the patch here, so you can test it and see if it works.

Another thing which popped up during my test, belongs to bugs #52741 resp. #53804. For this we were applying the patch you provided. In one of the cases, it happened what comment #4 of bug #53804 is stating. I hope to get more data for this during my test runs.


(file #45236)

Bernd Waibel <waebbl>
Sun 14 Oct 2018 04:57:40 PM UTC, comment #6: 


I'm curious to hear that you are building Lilypond with guile-2 as I have seen traffic on the lilypond-dev mailing list only today about problems getting Lilypond working with guile-2. Do you get the Lilypond regression tests to pass? I have Debian stable which does not have guile 1.8 any more and the lilypond package includes guile 1.8 (e.g. I see this directory in my installation

 /usr/share/lilypond/2.18.2/guile/1.8/

I think it is what's called a backport.

I've spent some time looking at configure.ac but I can't make much sense of it - clearly you couldn't usefully disable both guile 1.8 and 2.0, but I am wondering if the problem with 2.2 is because it is a change of the minor not micro version. If configure.ac only referred to guile 2 perhaps it would allow all minor versions? What I don't at all understand is that in places in configure.ac there appears GUILE 2 0 and elsewhere GUILE_2_0 ...



Richard Shann <rshann>
Group administrator
Sun 14 Oct 2018 10:14:26 AM UTC, comment #5: 

Unfortunately I don't have the choice of using guile-1.8, as this is going to be removed from gentoo repository. See https://bugs.gentoo.org/587252 if you're interested why it is like this. We're also using lilypond-2.19.80 with guile-2.

Your proposed patch doesn't work here. It first finds guile-2.2, I'm assuming this is through the GUILE_FLAGS macro at the top of the configure.ac, but then it searches again at the lines with the changes and fails to find guile.

I also tried to use PKG_CHECK_MODULES([GUILE_2], [guile-2.0 guile-2.2]) but this also fails.

Another thing I tried was to add both of these variants to the block after the AC_ARG_ENABLE, that is, the one starting like

if [test "x$useguile_1_8" = "xno"] && [test "x$useguile_2_0" = "xno"]; then

and don't pass any --enable-guile_* option to configure, i.e. trigger the default behaviour of the script, with the same result.

I'm wondering, why there's two --enable-guile-* options? Doesn't the call to the GUILE_FLAGS macro return all the needed information already? Why search two times for guile? Guile is a mandatory package after all, so a user doesn't even have a choice to use --diable-guile_1_8 and --disable-guile_2_0, which would be  perfectly legal according to the output of ./configure --help, plus it is the default behaviour. The configure script shouldn't even search for any guile then. That's the reason, why I removed these options in the first place. See https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies for an article why options for mandatory packages are a problem on source based distributions.

I'm going to review and try to fix my patch, so it works with guile-1.

Please see attached the output of the build, where you can see, guile-2.2 is being found first, but later on it's not found anymore, as well as, for reference, the config.log file.


(file #45194, file #45195)

Bernd Waibel <waebbl>
Sat 13 Oct 2018 09:10:45 PM UTC, comment #4: 

" ...like it must work for any 2.0.x versions"

sorry, I meant 2.x versions of course.

Richard Shann <rshann>
Group administrator
Sat 13 Oct 2018 06:23:19 PM UTC, comment #3: 

I've looked a bit closer at configure.ac and it seems to me that a simple change should do what you want - I've pushed this to the master branch of git so it will be in the upcoming 2.3 release. I can't actually test on anything other than 1.8 and 2.0.13 but it looks like it must work for any 2.0.x versions. (By the way, if you have the choice, then package for Guile 1.8 as it works better and is anyway required by LilyPond). Please let me know if this works for you.

diff --git a/configure.ac b/configure.ac
index e2399de6d..2d446b577 100644
--- a/configure.ac
+++ b/configure.ac
@@ -81,7 +81,7 @@ AC_ARG_ENABLE(
   [
     if test "x$enableval" != "xno"; then
       useguile_2_0=yes
-      PKG_CHECK_MODULES([GUILE_2], [guile-2.0])
+      PKG_CHECK_MODULES(GUILE_2, guile-2.0 >= 2.0)
       LIBS="$LIBS $GUILE_2_LIBS"
       CFLAGS="$CFLAGS $GUILE_2_CFLAGS"
     fi


Richard Shann <rshann>
Group administrator
Sat 13 Oct 2018 02:35:48 PM UTC, comment #2: 

Thanks for your feedback.
Isn't there anyone in your team, who maintains the configure file and could help with getting it generally usable.

My intention with this bug, was not to provide a generally working configure.ac. I know almost nothing of autotools, so this can only be a first step in adding support for guile-2.2. Instead I only wanted to inform the denemo team, of the incompatibility with guile-2.2 in the current configure.ac. On gentoo boxen, this patch works fine, as we require to have guile-2 installed for denemo.

You're partially right with guile-1.8. I just tested it, and it won't compile denemo with guile-1.8 installed when using the patch, but with the unpatched configure.ac it will do. But it doesn't disable support for guile-1.8. It actually finds it, but setting the CFLAGS and LIBS seems not be enough. I guess there needs to be a check for guile version and set additional things beyond that, like some GUILE_1_8* variables which I noticed in one of the makefiles. It also gives a warning about unknown GUILE_PKG, which I checked and this was not known with guile-1.8, rather it had a GUILE_PROGS macro. Unfortunately, I too don't understand enough of autotools and of the code, to go much further into this. I'm happy though to help in getting the file ready for general use with some help of upstream maintainers.

As for guile-2 < 2.2 it works just fine on my machine using guile-2.0.14, so why shouldn't it work with Debian?

Bernd Waibel <waebbl>
Sat 13 Oct 2018 08:33:12 AM UTC, comment #1: 

It looks like this patch disables support for guile 1.8 (and for versions <2.2 such as in Debian Stable 2.0.3 ?) so it couldn't be used generally. I don't know enough about configure.ac to modify it to allow any version unfortunately.

Richard Shann <rshann>
Group administrator
Thu 11 Oct 2018 01:38:27 PM UTC, original submission:  

Hello, I'm maintainer of the denemo package for Gentoo Linux. Currently there's an issue with users who have installed guile-2.2 already, as configure won't find a valid guile installation and therefore stops with an error.

I found the patch https://github.com/waebbl/gentoo/blob/denemo/media-sound/denemo/files/denemo-2.2.0-find-guile-2.2.patch solves the issue, at least for gentoo. I'm using autoconf-2.69 and automake-1.15.1 here.

Bernd Waibel <waebbl>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48559:  denemo-2.3.0-and-master--support-guile-2.2-in-configure-ac--2020-03-04.patch added by foka (2KiB - text/x-patch - Add support for guile-2.2 in configure.ac; this passes existing Travis CI test with guile-2.0)
file #45305:  denemo-2.2.0-build-logs.tar.bz2 added by waebbl (840KiB - application/x-bzip - build logs from testing combinatios of configure options.)
file #45236:  denemo-2.2.0-fix-guile.patch added by waebbl (2KiB - text/x-patch - patch to compile against guile versions 1.8, 2.0 and 2.2)
file #45194:  build.log added by waebbl (14KiB - text/x-log - logfile for build and config.log from configure output)
file #45195:  config.log added by waebbl (111KiB - text/x-log - logfile for build and config.log from configure output)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by foka (Posted a comment)
  • -email is unavailable- added by rshann (Posted a comment)
  • -email is unavailable- added by waebbl (Submitted the item)
  • -email is unavailable- added by waebbl
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-03-09 rshann StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2020-03-06 foka Attached File- Added denemo-2.3.0-and-master--support-guile-2.2-in-configure-ac--2020-03-04.patch, #48559
    2018-10-26 waebbl Attached File- Added denemo-2.2.0-build-logs.tar.bz2, #45305
    2018-10-18 waebbl Attached File- Added denemo-2.2.0-fix-guile.patch, #45236
    2018-10-14 waebbl Attached File- Added build.log, #45194
        Attached File- Added config.log, #45195
    2018-10-13 rshann StatusNone Need Info
    2018-10-11 waebbl Carbon-Copy- Added waebbl

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code