The guile package in rawhide is planned for update to a new major release. In a test rebuild of all packages depending on guile, gnucash has failed to build. Rebuild results: http://mlichvar.fedorapeople.org/tmp/guile/rebuild/ New guile packages: http://mlichvar.fedorapeople.org/tmp/guile/ Please close this bug if a new upstream version of gnucash which works with the new guile is available or if you think the current version can be easily fixed. It doesn't have to be commited in fedora git, we are just trying to find out if we need to delay the guile update (or make a guile-compat package).
You're right, it does. There are some patches in upstream GnuCash head from the guile maintainer that theoretically fix this, but I haven't tested it yet.
Note that your guile-2.0 devel package needs to require gc-devel.
So, I can get it to build with some patches, but it doesn't *run* yet. More work needed.
Thanks, fixed packages uploaded.
$ GUILE_AUTO_COMPILE=0 gnucash Backtrace: In ice-9/boot-9.scm: 170: 12 [catch #t #<catch-closure 266a600> ...] In unknown file: ?: 11 [catch-closure] In ice-9/boot-9.scm: 2312: 10 [#<procedure 259f040 at ice-9/boot-9.scm:2300:4 (name #:optional autoload version #:key ensure)> # ...] 2578: 9 [try-module-autoload (gnucash main) #f] 1918: 8 [save-module-excursion #<procedure 291f0f0 at ice-9/boot-9.scm:2579:17 ()>] 2589: 7 [#<procedure 291f0f0 at ice-9/boot-9.scm:2579:17 ()>] In unknown file: ?: 6 [primitive-load-path "gnucash/main" #f] In ice-9/eval.scm: 458: 5 [#<procedure 247c1c0 at ice-9/eval.scm:452:4 (exp)> #] In ice-9/psyntax.scm: 1042: 4 [chi-top-sequence ((debug-set! maxdepth 100000)) () ...] 940: 3 [scan ((debug-set! maxdepth 100000)) () ...] 1033: 2 [scan ((#(syntax-object debug-options # ...) (# # #))) () ...] In ice-9/boot-9.scm: 2669: 1 [debug-options (show-file-name #t stack ...)] In unknown file: ?: 0 [debug-options-interface (show-file-name #t stack ...)] ERROR: In procedure debug-options-interface: ERROR: In procedure debug-options-interface: Unknown option name: maxdepth That's where I'm stuck now.
I've updated git master with the changes to at least let it build.
Commenting out that debug-set! call in gnucash/main.scm fixes that, but now I'm getting "ERROR: SCM_STRING_CHARS does not work with read-only strings" which seems to be triggered by the swig generated code.
Note that I did not regenerate the swig code from the .i files... this build is still using the generated code that's distributed in the tarball. I don't know if this makes a difference, but it would be an avenue to test.
There seems to be a problem with new guile and swig, bug #706140.
(In reply to comment #8) > Note that I did not regenerate the swig code from the .i files... this build is > still using the generated code that's distributed in the tarball. I don't know > if this makes a difference, but it would be an avenue to test. I'm sure bindings generated by swig need to be regenerated with updated swig. Can you please check if guile bindings regenerated via swig-2.0.3-2.fc16 are fine?
Same error even with recompiled swig bindings.
(In reply to comment #7) > Commenting out that debug-set! call in gnucash/main.scm fixes that, but now I'm > getting "ERROR: SCM_STRING_CHARS does not work with read-only strings" which > seems to be triggered by the swig generated code. I overcome it with Index: gnucash-2.4.7/src/app-utils/swig-app-utils.c =================================================================== --- gnucash-2.4.7.orig/src/app-utils/swig-app-utils.c +++ gnucash-2.4.7/src/app-utils/swig-app-utils.c @@ -771,7 +771,7 @@ static swig_module_info *SWIG_Guile_GetM SWIGINTERN char * SWIG_Guile_scm2newstr(SCM str, size_t *len) { #define FUNC_NAME "SWIG_Guile_scm2newstr" - char *ret; + char *ret, *tmp; size_t l; SCM_ASSERT (SCM_STRINGP(str), str, 1, FUNC_NAME); @@ -780,7 +780,9 @@ SWIG_Guile_scm2newstr(SCM str, size_t *l ret = (char *) SWIG_malloc( (l + 1) * sizeof(char)); if (!ret) return NULL; - memcpy(ret, SCM_STRING_CHARS(str), l); + tmp = scm_to_utf8_string(str); + memcpy(ret, tmp, l); + free(tmp); ret[l] = '\0'; if (len) *len = l; return ret; and similarly for all occurences of SCM_STRING_CHARS. See http://blog.peter-b.co.uk/2011/06/geda-and-guile-dealing-with-deprecated.html I also have to remove definition of maxdepth, I am not aware of any other replacement. Then have to replace all occurences of N_ by _ in files under gnucash/guile-modules/gnucash/{report,standard-reports} in order to have gnucash running. I will try to find oneliner for this, this smells after wrong inclusion.
(In reply to comment #12) ... > and similarly for all occurences of SCM_STRING_CHARS. See > > http://blog.peter-b.co.uk/2011/06/geda-and-guile-dealing-with-deprecated.html > > I also have to remove definition of maxdepth, I am not aware of any other > replacement. Then have to replace all occurences of N_ by _ in files under > gnucash/guile-modules/gnucash/{report,standard-reports} in order to have > gnucash running. I will try to find oneliner for this, this smells after wrong > inclusion. Petr, The SCM_STRING_CHARS are coming from SWIG auto-generated code. You could apply your patch to the gnucash tarball, since it contains the auto-generated files. The actual GnuCash source in svn only contains some *.i swig interface files that don't contain the code you are replacing yourself. You patch does cure the/a problem, but it should be applied to swig instead of gnucash. If you want to report this in the swig bugtracker, the source file in the swig release responsible for this code is: Lib/guile/guile_scm_run.swg Perhaps Fedora can apply a fix to swig locally already while it works with upstream to resolve this issue ?
(In reply to comment #13) > Petr, The SCM_STRING_CHARS are coming from SWIG auto-generated code. > > You could apply your patch to the gnucash tarball, since it contains the > auto-generated files. The actual GnuCash source in svn only contains some *.i > swig interface files that don't contain the code you are replacing yourself. > > You patch does cure the/a problem, but it should be applied to swig instead of > gnucash. If you want to report this in the swig bugtracker, the source file in > the swig release responsible for this code is: > Lib/guile/guile_scm_run.swg > > Perhaps Fedora can apply a fix to swig locally already while it works with > upstream to resolve this issue ? Feel free to open a bug report (or simply clone this one) against swig to fix this in Fedora, before upstream releases new version.
(In reply to comment #14) > Feel free to open a bug report (or simply clone this one) against swig to fix > this in Fedora, before upstream releases new version. Bug #752054
I've just built swig-2.0.4-4.fc17 which contains patch called "swig204-rh752054.patch". The patch fixes this issue but won't be applied until guile 2 gets into distribution.
Created attachment 533764 [details] Patch Generated guile bindings should be guile2-compatible with this patch (but incompatible with guile 1.8).
(In reply to comment #13) > Petr, The SCM_STRING_CHARS are coming from SWIG auto-generated code. I see, thanks! (In reply to comment #16) > I've just built swig-2.0.4-4.fc17 which contains patch called > "swig204-rh752054.patch". The patch fixes this issue but won't be applied until > guile 2 gets into distribution. JFYI, there seems to be a way to have it working for both 1.8 and 2.0 (see blog in comment 12), but I didn't go trough that.
(In reply to comment #18) > (In reply to comment #13) > > Petr, The SCM_STRING_CHARS are coming from SWIG auto-generated code. > > I see, thanks! > > (In reply to comment #16) > > I've just built swig-2.0.4-4.fc17 which contains patch called > > "swig204-rh752054.patch". The patch fixes this issue but won't be applied until > > guile 2 gets into distribution. > > JFYI, there seems to be a way to have it working for both 1.8 and 2.0 (see blog > in comment 12), but I didn't go trough that. You think about using scm_to_locale_string instead of scm_to_utf8_string? Well, scm_to_locale_string is probably better, thanks for the hint. However I will wait for upstream response about this. Ticket is http://sourceforge.net/tracker/?func=detail&aid=1511038&group_id=1645&atid=301645 , just for reference.
An update: as of r22655 the development branch of gnucash can be built and run with guile 2. It still spews warnings and the environment variable GUILE_AUTO_COMPILE should be set to 0, so this is still a work in progress. It is important to realize though that this is only possible is swig is properly patched as well. I have submitted a patch for swig in bug 752054 So build instructions in short: - download the swig patch from the above link (against swig 2.0.8) and build a patched swig - install guile 2 - checkout gnucash' trunk branch as of r22655 - you may need to update configure.ac to have it prefer guile 2 if both guile 1.8 and guile 2 are installed on the system - build gnucash as usual - run gnucash as GUILE_AUTO_COMPILE=0 /path/to/gnucash Feedback is welcome.
Is it worth trying to backport these to 2.4, or should we wait until the 2.6 cycle?
With my patches, I have gone so far to fix all but three deprecation warnings with guile 2 on top of the bare minimum fixes to get gnucash running with guile 2. The bare minimum set is actually fairly small and I thought for a moment it would be fairly trivial to backport these. Unfortunately when I started to test this, I realized that 2.4 still depends on the slib library, which is not compatible with guile 2. So getting 2.4 to run with guile 2 would mean backporting the slib removal as well as applying the minimal set of patches required to work with guile 2. Unfortunately this can't be done in our source tree, because the 2.4 series should continue to work with guile 1.6, which is only possible with slib. I don't know if you want to try this downstream for Fedora only. It is probably possible, but I'm not confident it will be a trivial task. On the other hand, there's no official release roadmap yet for gnucash 2.6. I had hoped we'd get it ready for spring 2013, but that's too optimistic.
Too curious to how difficult it would be, I continued anyway and backported all required changes in a separate branch, branched from current 2.4 HEAD. You can find it in my github gnucash repository: https://github.com/gjanssens/gnucash/tree/2.4-guile2-fedora-rebasing Note that I will continue to rebase this branch to the head of 2.4! This branch can serve as a basis to generate a patch set for gnucash 2.4 with guile 2 on Fedora. I haven't only lightly tested it (and with guile 2 only, not guile 1.8), but so far it seems to work fine. It does break the compatibility with guile 1.6, so as said before I can't push it to the official gnucash 2.4 branch. Feel free to play with it or ignore it.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
FYI, punting this until GnuCash 2.6, likely later this year.
So, I tried 2.5.1. It immediately falls over due to the swig issues above. Any chance the released dev tarballs can be generated with a fixed swig version?
I will have to ask our current release manager. The good news is that swig 2.0.10 is planned for release this weekend. That will be too close to be used for the release of 2.5.2 (planned early next week), but I hope 2.5.3 will take this into account.
JFYI http://sourceforge.net/p/swig/news/2013/05/swig-2010-released/
I spoke with our current release manager. He agreed to set up swig 2.0.10 to generate future tarballs. So I expect the tarballs for GnuCash 2.5.3 to be compatible with guile 2.
Yes, saw that on gnucash-devel - thanks! (Probably should have sent the original query there, sorry.)
Is this my problem as well? Trying to compile Gnucash 2.5 on Fedora 19. Configure tells me guile not found. Any suggestions? Thanks! ./configure --enable-compile-warnings --prefix=/opt ... checking for gethostid... yes checking for link... yes checking for guile-1.8 >= 1.8.5... yes checking GUILE_CFLAGS... -pthread checking GUILE_LIBS... -lguile checking for guile... no checking if guile needs our copy of (guile www)... checking for guile... no configure: error: guile required but not found [root@m72 gnucash]# rpm -qa|grep guile compat-guile18-devel-1.8.8-6.fc19.x86_64 compat-guile18-1.8.8-6.fc19.x86_64 guile-2.0.9-1.fc19.x86_64 guile-devel-2.0.9-1.fc19.x86_64 [root@m72 gnucash]#
For building against compat-guile-1.8: sed -i 's|guile-config|guile1.8-config|g' configure export GUILE=/usr/bin/guile1.8 For building against guile 2.0, it depends on the GnuCash 2.5 version, as mentioned above. I'll get around to some 2.5.4 test packages at some point.
gnucash-2.6.0-2.fc20, gnucash-docs-2.6.0-1.fc20, kmymoney-4.6.4-3.fc20, aqbanking-5.3.2-0.1.beta.fc20, gwenhywfar-4.9.0-0.2.beta.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/gnucash-2.6.0-2.fc20,gnucash-docs-2.6.0-1.fc20,kmymoney-4.6.4-3.fc20,aqbanking-5.3.2-0.1.beta.fc20,gwenhywfar-4.9.0-0.2.beta.fc20
Package gnucash-2.6.0-2.fc20, gnucash-docs-2.6.0-1.fc20, kmymoney-4.6.4-3.fc20, aqbanking-5.3.2-0.1.beta.fc20, gwenhywfar-4.9.0-0.2.beta.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnucash-2.6.0-2.fc20 gnucash-docs-2.6.0-1.fc20 kmymoney-4.6.4-3.fc20 aqbanking-5.3.2-0.1.beta.fc20 gwenhywfar-4.9.0-0.2.beta.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1136/gnucash-2.6.0-2.fc20,gnucash-docs-2.6.0-1.fc20,kmymoney-4.6.4-3.fc20,aqbanking-5.3.2-0.1.beta.fc20,gwenhywfar-4.9.0-0.2.beta.fc20 then log in and leave karma (feedback).
gnucash-2.6.0-2.fc20, gnucash-docs-2.6.0-1.fc20, kmymoney-4.6.4-3.fc20, aqbanking-5.3.2-0.1.beta.fc20, gwenhywfar-4.9.0-0.2.beta.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.