Reminder to bump guile to 2.0.0. Also, to take a look at the 2.1 development branch.
Created attachment 265793 [details] guile 2.0.0 ebuild Seems to work here, might need some corrections, i'm not very experienced with ebuilds.
Created attachment 268767 [details] File collisions between 1.8 and 2.0 I wonder if we want to support slotting on Legacy and 2.x Guile series I've attached a list of file collisions between Guile 2.0 and Guile 1.8.7. Note that by using --program-suffix=${MAJOR} option of Guile build system we can fix collisions on these files: * /usr/bin/guile-config * /usr/bin/guile-tools * /usr/bin/guile * /usr/bin/guile-snarf by translating them into * /usr/bin/guile-config2.0 * /usr/bin/guile-tools2.0 * /usr/bin/guile2.0 * /usr/bin/guile-snarf2.0 Then we'll need to maintain a symlink to /guile version via eselect. Python versions are handled in similar way in Gentoo. Info and /usr/share/aclocal/guile.m4 files will still class without any observable way to avoid collisions.
*** Bug 336662 has been marked as a duplicate of this bug. ***
I've committed a guile-2.0.0 version based on the latest guile-1.8.8 in main tree, but masked because of the following issues: - Broken emacs support (ulm has promised to look) - doesn't build when boehm-gc is built without threads (have mailed bug-guile@) - no SLOTting yet! (we should prolly use --program-suffix=${MAJOR} and fix the remaining collisions by renaming occurrences of guile with some variant of `guile2'. If anyone would look into the slotting support I would really appreciate it. I also dropped keywords since this is a major rewrite of guile, but I think we can delay rekeywording requests until we have worked out most of these issues (devs should feel free to add their arch). Daniel, thanks for the ebuild. A thought for your next contribution: It seems that you based your ebuild on a very old guile version or created it from scratch. That is certainly educational, but less useful when you want to share. Dima, thanks for your testing and analysis.
Regarding issues with `modules` and `posix` configure flags, I've started a thread on Guile ML recently http://thread.gmane.org/gmane.lisp.guile.devel/12141. Andy Wingo promised on IRC to look into that soon.
Files under `emacs/` seem to get stripped when configuring with EMACS=no.
(In reply to comment #2) > Then we'll need to maintain a symlink to /guile version via eselect. Python > versions are handled in similar way in Gentoo. > > Info and /usr/share/aclocal/guile.m4 files will still class without any > observable way to avoid collisions. I have just pushed to the lisp overlay an update to guile ebuilds and an eselect module for managing the symbolic links. Please test and report issues in a separate bug blocking this one. (One can simply report minor issues on the #gentoo-lisp IRC channel or on the gentoo-lisp mailing list) This bug will serve as a tracker for guile-2 unmasking.
*** Bug 433700 has been marked as a duplicate of this bug. ***
dev-scheme/guile-2.0.9 and a tag guile-2.1.0 http://git.savannah.gnu.org/gitweb/?p=guile.git
Created attachment 348944 [details] Just a wild guess with eapi4 this ebuild
Created attachment 348946 [details, diff] Also a wild guess this patch from git on the way to guile-2.1.0
Uups, at https://bugs.gentoo.org/show_bug.cgi?id=355355#c10 the file name doesn't show up: guile-2.0.9.ebuild
(In reply to comment #9) > dev-scheme/guile-2.0.9 We have it in the lisp overlay, http://git.overlays.gentoo.org/gitweb/?p=proj/lisp.git;a=blob;f=dev-scheme/guile/guile-2.0.9-r1.ebuild;hb=HEAD > and a tag guile-2.1.0 It seems to replace the previous 2.2/master branch. However, 2.0.9 is still promoted as 'stable' by Guile's website. Last time I checked, it was not possible to have a parallel installation of guile 2.0 and 2.2 due to file collisions in guile-readline. I suggest you to try the lisp overlay (available through layman) to get latest guile releases
3 1/2 years on and it doesn't seem there is any way to reasonably expect a smooth transition from Guile 1.x to Guile 2.x -- particularly considering the amount of other projects that depend on Guile 1 and won't move to Guile 2 because of this very problem. I suggest that handling guile as a multi-version runtime the way Python 2/3 is handled is the only way we can expect to get Guile2 into the system before the decade is up.
This blocks bug 523104: weechat.
(In reply to Craig Everett from comment #14) > 3 1/2 years on and it doesn't seem there is any way to reasonably expect a > smooth transition from Guile 1.x to Guile 2.x -- particularly considering > the amount of other projects that depend on Guile 1 and won't move to Guile > 2 because of this very problem. When looking at other projects, I found these: - graphviz does not build with 2.0.x - lilypond does not build with 2.0.x, but they are working on that[1] - greg does not run correctly with 2.0.x, - texmacs does not build with 2.0.x and the developers alledgedly don’t want to change that (but redhat can build it against 2.0.7: https://bugzilla.redhat.com/show_bug.cgi?id=704515#c2 ) - weechat does not build, because it needs at least guile 2.0.4 and the tree only has 2.0.0 and guile 2.0.11 is not in the tree. Which ones did I miss? [1]: https://code.google.com/p/lilypond/issues/detail?id=1055&q=guile%202.0&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary https://code.google.com/p/lilypond/issues/detail?id=3799&q=guile%202.0&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary https://code.google.com/p/lilypond/issues/detail?id=1826&q=guile%202.0&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary https://code.google.com/p/lilypond/issues/detail?id=1780&q=guile%202.0&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary > I suggest that handling guile as a multi-version runtime the way Python 2/3 > is handled is the only way we can expect to get Guile2 into the system > before the decade is up. Since that’s supported upstream, it sounds like a good plan. Is there a way to fix the collisions for Info and /usr/share/aclocal/guile.m4?
Add a dep on 494424 ?
How about adding the guile-2.0.11 ebuild from the lisp overlay - hardmasked just like the current one? That should create no regressions, but fix weechat.
I did some testing today after emerging guile-2.0.11 from the lisp overlay. From 43 reverse dependencies that guile has atm, the following still fail to compile for various reasons: =mail-filter/anubis-4.1.1-r1 =dev-tex/slatex-20090928 =media-sound/lilypond-2.18.2 =sci-mathematics/drgeo-1.1.0 =net-irc/bobotpp-2.2.3 =sci-physics/mpb-1.4.2-r2 =app-office/texmacs-1.99.2 =app-office/gnucash-2.6.5 =net-mail/perdition-1.18 =sci-electronics/gwave-20090213-r2 =x11-libs/guile-gtk-2.1-r2 =games-board/aisleriot-3.2.3.2-r1 =sci-libs/starparse-1.0-r1 =sci-libs/linux-gpib-3.2.21 =dev-scheme/greg-2.0.0-r1 =net-dialup/gnuradius-1.6.1-r1 =media-libs/aubio-0.3.2-r2 This means that we have a long road ahead before guile-2 hits the tree. I'll try work on each package, see what I can fix and I'll also work on improving the overlay's ebuild. My time is limited though, any help in testing would be much appreciated.
(In reply to Panagiotis Christopoulos from comment #19) > I did some testing today after emerging guile-2.0.11 from the lisp overlay. > From 43 reverse dependencies that guile has atm, the following still fail to > compile for various reasons: … Do these compile for guile-2.0.0 which is in the tree but masked? If these aren’t regressions, would it be possible as first step simply upgrade the guile-2 in the tree to 2.0.11 but keep it masked?
(In reply to Panagiotis Christopoulos from comment #19) > =games-board/aisleriot-3.2.3.2-r1 We already have a version of aisleriot in the tree that works with guile-2 and in fact requires guile-2, and it has been pmasked for years (bug #416683) because of no action on guile-2 unmasking :/ > =app-office/gnucash-2.6.5 This builds and works fine on my guile-2 machine, can you open a bug and attach the build log?
(In reply to Panagiotis Christopoulos from comment #19) [...] > This means that we have a long road ahead before guile-2 hits the tree. I'll > try work on each package, see what I can fix and I'll also work on improving > the overlay's ebuild. My time is limited though, any help in testing would > be much appreciated. What is blocking to make guile2 really be slottable? That is the way taken by Fedora, for example, instead of waiting for all reverse deps to move to guile2 support :/ I have looked to: https://cgit.gentoo.org/proj/lisp.git/tree/dev-scheme/guile/guile-2.0.11.ebuild But looks like (apart of using einstall... that is discouraged) it adds no prefix option to try to avoid collisions :| anyway, looks like at Fedora, the main guile package is the version 2 and, then, the renaming is done for 1.8.x series (look at all the renames part at .spec file) http://pkgs.fedoraproject.org/cgit/compat-guile18.git/tree/compat-guile18.spec
Guile itself already prefixes everything except for the man- and info-pages, an m4-file and the final binaries: $ equery f ">=dev-scheme/guile-2.0" -f obj,sym,dev,conf,cmd,doc,man,info,fifo | sed s/.*2\\.0.*// | sort -u /usr/bin/guild /usr/bin/guile /usr/bin/guile-config /usr/bin/guile-snarf /usr/bin/guile-tools /usr/lib64/libguilereadline-v-18.la /usr/lib64/libguilereadline-v-18.so /usr/lib64/libguilereadline-v-18.so.18 /usr/lib64/libguilereadline-v-18.so.18.0.0 /usr/lib/debug/usr/bin/guile.debug /usr/lib/debug/usr/lib64/libguilereadline-v-18.so.18.0.0.debug /usr/share/aclocal/guile.m4 /usr/share/guile/site/.keep_dev-scheme_guile-2 /usr/share/info/guile.info-10.bz2 /usr/share/info/guile.info-1.bz2 /usr/share/info/guile.info-2.bz2 /usr/share/info/guile.info-3.bz2 /usr/share/info/guile.info-4.bz2 /usr/share/info/guile.info-5.bz2 /usr/share/info/guile.info-6.bz2 /usr/share/info/guile.info-7.bz2 /usr/share/info/guile.info-8.bz2 /usr/share/info/guile.info-9.bz2 /usr/share/info/guile.info.bz2 /usr/share/info/r5rs.info.bz2 /usr/share/man/man1/guile.1.bz2
(In reply to Arne Babenhauserheide from comment #20) > If these aren’t regressions, would it be possible as first step simply > upgrade the guile-2 in the tree to 2.0.11 but keep it masked? Would it possible to follow that route? If we have a masked guile-2 in portage, might it not aswell be the latest version?
(In reply to Cedric Sodhi from comment #24) > (In reply to Arne Babenhauserheide from comment #20) > > If these aren’t regressions, would it be possible as first step simply > > upgrade the guile-2 in the tree to 2.0.11 but keep it masked? > > Would it possible to follow that route? If we have a masked guile-2 in > portage, might it not aswell be the latest version? That’s what I think, yes. @Panagiotis: It looks like there are only two people in the Scheme herd ( https://wiki.gentoo.org/wiki/Project:Scheme ), is this just a matter of missing free time?
We have a guile (and patched gnutls to depend on it) in our overlay, I don't know anymore where this originated or if it was rewritten by someone, but unlike the guile-2 currently masked in portage this hasn't broken my amd64 based system. If someone wants to create a diff, pull this either via tor: git clone git://far37qbrwiredyo5.onion:/youbroketheinternet-overlay clear: git clone git://n0.is:/youbroketheinternet-overlay I'm using dev-scheme/guile-2.0.11-r1 on livesystems and using it as a basis for developing an ebuild for guix, which requires a version of guile which is not outdated for years (>= 2.0). =net-libs/gnutls-3.5[networking] (or whatever guile pulled in at gnutls) on amd64 builds and works with it. guix-0.9 (haven't worked on it in a while) builds with it.
Thanks @ng0 .. will try and pick this up with you via IRC, and we'll see if we can get it into portage central. I know the scheme project are MIA, so provided this is tested, it would be good to start a migration path from 1.8 ;). It's also blocking me creating an unstable ebuild for sci-electronics/geda-1.9.2 which depends on guile-2.
Just taken a quick clone myself, and looks good. @ng0 - can you take a quick look at how much work to update to EAPI6 ?
(In reply to Michael Everitt (IRC: veremit) from comment #28) > Just taken a quick clone myself, and looks good. > > @ng0 - can you take a quick look at how much work to update to EAPI6 ? Thanks, that's good to hear. Concerning EAPI5->EAPI6 update of it: Possibly not much work, I see if I can handle it as soon as I have a test VM ready. I'm halfway at having an amd64-gcc-vanilla blueprint VM, I can't risk to test this on a host where I'm currently mainly debugging gnunet-gtk ebuild. Last time guile-2 from portage broke for me, it broke the entire system non-recoverable, so you can understand that I'll be extra cautious with this test.
URL of this bug is 404 now, it should be: https://www.gnu.org/software/guile/download/
(In reply to Nils Gillmann (ng0) from comment #30) > URL of this bug is 404 now, it should be: > https://www.gnu.org/software/guile/download/ Confirmed, and updated.
@veremit, regarding slotting like I said on IRC if we use slotting at all it would make sense to slot guile-1 and let guile-2 become slot 2 and have no subslots. As guile-1 is old and established in portage, we can't change that, so some of my ideas without re-reading the thread above: - let guile:1 keep the name of the files and move guile:2 to ${basename}-2 where basename is every file it would install or only the ones which would collide with guile:1 - create an eselect (new field for me) which can select a symlink of guile-1 or guile-2, defaulting to the newer and now standard guile-2. I think some of these points have been discussed before, from the amount of problems it probably would be best to handle it like python is currently handled, be able to install multiple versions, have an eselect to manage the version selection. I have to look into how this is done for python to see how this can be achieved for guile. Unreleated to the statements above, the packages below are all the packages we should care about, right? From the guile:12 slot, weechat version 1.4,1.5,9999 works with guile-2.0.11, has been tested didn't fail for me. From the guile:1 slot, gnutls 3.4.11, one of the 3.3 versions, and 3.5 are functional with guile-2.0.11 for me. ng0@khazad-dum|master=:~/src/re-src/gentoo/portage/gentoo$ grep -r "dev-scheme/guile-1.8" * app-office/gnucash/gnucash-2.6.10.ebuild: >=dev-scheme/guile-1.8.3:12[deprecated,regex] app-office/gnucash/gnucash-2.6.11.ebuild: >=dev-scheme/guile-1.8.3:12[deprecated,regex] app-office/gnucash/gnucash-2.6.9.ebuild: >=dev-scheme/guile-1.8.3:12[deprecated,regex] dev-scheme/guile-cairo/guile-cairo-1.9.91.ebuild: >=dev-scheme/guile-1.8 dev-scheme/guile-cairo/guile-cairo-1.4.0.ebuild:RDEPEND=">=dev-scheme/guile-1.8 dev-scheme/greg/greg-2.0.0.ebuild:RDEPEND=">=dev-scheme/guile-1.8" dev-scheme/greg/greg-2.0.0-r1.ebuild:RDEPEND=">=dev-scheme/guile-1.8" mail-filter/anubis/anubis-4.1.1-r1.ebuild: guile? ( >=dev-scheme/guile-1.8 ) mail-filter/anubis/anubis-4.1.1.ebuild: guile? ( >=dev-scheme/guile-1.8 ) media-sound/lilypond/lilypond-2.18.2.ebuild: >=dev-scheme/guile-1.8.2[deprecated,regex] media-sound/lilypond/lilypond-9999.ebuild: >=dev-scheme/guile-1.8.2[deprecated,regex] media-sound/lilypond/lilypond-2.18.2-r1.ebuild: >=dev-scheme/guile-1.8.2:12[deprecated,regex] media-sound/lilypond/lilypond-2.19.15.ebuild: >=dev-scheme/guile-1.8.2[deprecated,regex] media-sound/denemo/denemo-1.0.0.ebuild: >=dev-scheme/guile-1.8 media-sound/denemo/denemo-1.0.2.ebuild: >=dev-scheme/guile-1.8 net-libs/gnutls/gnutls-3.4.11.ebuild: guile? ( >=dev-scheme/guile-1.8:*[networking] ) net-libs/gnutls/gnutls-3.3.17.1.ebuild: guile? ( >=dev-scheme/guile-1.8:*[networking] ) net-libs/gnutls/gnutls-3.3.22.ebuild: guile? ( >=dev-scheme/guile-1.8:*[networking] ) net-libs/gnutls/gnutls-3.5.0.ebuild: guile? ( >=dev-scheme/guile-1.8:*[networking] ) sci-electronics/gwave/gwave-20090213-r1.ebuild:DEPEND="=dev-scheme/guile-1.8*[networking] sci-electronics/geda/geda-1.9.1.ebuild: >=dev-scheme/guile-1.8:12[deprecated] sci-electronics/geda/geda-1.8.1.ebuild: >=dev-scheme/guile-1.8[deprecated] sci-electronics/geda/geda-1.8.2.ebuild: >=dev-scheme/guile-1.8[deprecated] sci-mathematics/drgeo/drgeo-1.1.0.ebuild: >=dev-scheme/guile-1.8[deprecated] sys-devel/make/make-4.1-r1.ebuild:CDEPEND="guile? ( >=dev-scheme/guile-1.8 )" sys-devel/make/make-4.0-r1.ebuild:CDEPEND="guile? ( >=dev-scheme/guile-1.8 )" sys-devel/autogen/autogen-5.17.3.ebuild:RDEPEND=">=dev-scheme/guile-1.8 sys-devel/autogen/autogen-5.15.ebuild:RDEPEND=">=dev-scheme/guile-1.8 sys-devel/autogen/autogen-5.18.1.ebuild:RDEPEND=">=dev-scheme/guile-1.8 sys-devel/autogen/autogen-5.18.2.ebuild:RDEPEND=">=dev-scheme/guile-1.8 sys-devel/autogen/autogen-5.17.4.ebuild:RDEPEND=">=dev-scheme/guile-1.8 sys-devel/autogen/autogen-5.18.4.ebuild:RDEPEND=">=dev-scheme/guile-1.8 x11-misc/xbindkeys/xbindkeys-1.8.6.ebuild: guile? ( >=dev-scheme/guile-1.8.4[deprecated] ) ng0@khazad-dum|master=:~/src/re-src/gentoo/portage/gentoo$ grep -r "dev-scheme/guile:12" * app-office/texmacs/texmacs-1.0.7.21.ebuild: dev-scheme/guile:12[deprecated] app-office/texmacs/texmacs-1.99.1.ebuild: dev-scheme/guile:12[deprecated] app-office/texmacs/texmacs-1.99.2-r1.ebuild: dev-scheme/guile:12[deprecated] app-office/texmacs/texmacs-1.99.2.ebuild: dev-scheme/guile:12[deprecated] dev-scheme/guile-www/guile-www-2.34.ebuild:RDEPEND="dev-scheme/guile:12" dev-scheme/guile-gnome-platform/guile-gnome-platform-2.16.1-r1.ebuild: dev-scheme/guile:12 dev-scheme/guile-gnome-platform/guile-gnome-platform-2.16.2.ebuild: dev-scheme/guile:12 games-strategy/liquidwar6/liquidwar6-0.4.3681-r1.ebuild: dev-scheme/guile:12 net-irc/weechat/weechat-1.4.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-9999.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-1.4-r1.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-1.2.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-1.3.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-1.5.ebuild: guile? ( dev-scheme/guile:12 ) net-irc/weechat/weechat-1.1.1.ebuild: guile? ( dev-scheme/guile:12 ) sci-libs/starparse/starparse-1.0-r1.ebuild:RDEPEND="guile? ( dev-scheme/guile:12 )" sci-libs/linux-gpib/linux-gpib-3.2.21-r1.ebuild: guile? ( dev-scheme/guile:12 ) sci-libs/linux-gpib/linux-gpib-4.0.2.ebuild: guile? ( dev-scheme/guile:12 ) x11-libs/guile-gtk/guile-gtk-2.1-r2.ebuild: dev-scheme/guile:12[deprecated(+)]
In reference to my last comment, and a comment of Arne in 2015, I think the multiversion like python solution could be easy, the files for 2.0 are already sorted except a little number of files: https://ptpb.pw/b_Q5
(In reply to Nils Gillmann (ng0) from comment #33) > In reference to my last comment, and a comment of Arne in 2015, > I think the multiversion like python solution could be easy, the files for > 2.0 are already sorted except a little number of files: > https://ptpb.pw/b_Q5 Which ones of these are not separated? These should likely be symlinks set by eselect: /usr/bin/guild /usr/bin/guile /usr/bin/guile-config /usr/bin/guile-snarf /usr/bin/guile-tools Documentation should just point to the current version, I think. /usr/share/info/guile.info-1.bz2 /usr/share/info/guile.info-10.bz2 /usr/share/info/guile.info-2.bz2 /usr/share/info/guile.info-3.bz2 /usr/share/info/guile.info-4.bz2 /usr/share/info/guile.info-5.bz2 /usr/share/info/guile.info-6.bz2 /usr/share/info/guile.info-7.bz2 /usr/share/info/guile.info-8.bz2 /usr/share/info/guile.info-9.bz2 /usr/share/info/guile.info.bz2 /usr/share/info/r5rs.info.bz2 /usr/share/man/man1/guile.1.bz2 For this we might need to add a doc useflag to guile and make guile-2.0.x depend on (no guile 1.8 || guile 1.8 with -doc). This I don’t know: /usr/share/aclocal/guile.m4
(In reply to Arne Babenhauserheide from comment #34) > (In reply to Nils Gillmann (ng0) from comment #33) > > In reference to my last comment, and a comment of Arne in 2015, > > I think the multiversion like python solution could be easy, the files for > > 2.0 are already sorted except a little number of files: > > https://ptpb.pw/b_Q5 > This I don’t know: > > /usr/share/aclocal/guile.m4 This is already handled in the ebuild for guile-1.8.8-r3 from the lisp overlay: mv "${ED}"/usr/share/aclocal/guile.m4 "${ED}"/usr/share/aclocal/guile-${MAJOR}.m4 || die "rename of guile.m4 failed" (In reply to Arne Babenhauserheide from comment #34) > Documentation should just point to the current version, I think. > > /usr/share/info/guile.info-1.bz2 > /usr/share/info/guile.info-10.bz2 > /usr/share/info/guile.info-2.bz2 > /usr/share/info/guile.info-3.bz2 > /usr/share/info/guile.info-4.bz2 > /usr/share/info/guile.info-5.bz2 > /usr/share/info/guile.info-6.bz2 > /usr/share/info/guile.info-7.bz2 > /usr/share/info/guile.info-8.bz2 > /usr/share/info/guile.info-9.bz2 > /usr/share/info/guile.info.bz2 > /usr/share/info/r5rs.info.bz2 > /usr/share/man/man1/guile.1.bz2 We could fix these by modifying the infodir and mandir in 1.8.8. From ./configure: --infodir=DIR --mandir=DIR The ebuild from the lisp overlay does that for info: https://cgit.gentoo.org/proj/lisp.git/tree/dev-scheme/guile/guile-1.8.8-r3.ebuild#n50
Thanks for your input, this looks very useful. I started writing an eselect-guile and adjust the ebuilds of guile. It doesn't look like much to build, so I could probably testbuild the applications which depend on guile (if gentoo only had a buildbot or hydra).
(In reply to Nils Gillmann (ng0) from comment #36) > Thanks for your input, this looks very useful. > > I started writing an eselect-guile and adjust the ebuilds of guile. you might be able to save some work by building upon the eselect-guile from the lisp-overlay: https://cgit.gentoo.org/proj/lisp.git/tree/app-admin/eselect-guile/eselect-guile-1.2-r1.ebuild > It doesn't look like much to build, so I could probably testbuild the > applications which depend on guile (if gentoo only had a buildbot or hydra). You could try sys-devel/make[guile]
(In reply to Arne Babenhauserheide from comment #37) > (In reply to Nils Gillmann (ng0) from comment #36) > > Thanks for your input, this looks very useful. > > > > I started writing an eselect-guile and adjust the ebuilds of guile. > > you might be able to save some work by building upon the eselect-guile from > the lisp-overlay: > https://cgit.gentoo.org/proj/lisp.git/tree/app-admin/eselect-guile/eselect- > guile-1.2-r1.ebuild Okay, I already wrote something based on eselect-emacs, but the one you linked me to looks already functional if I did not miss anything. So only the ebuilds needs to be adjusted now - I already started this for my testing overlay (the .is disappeared and I moved it all back to .onion) > > It doesn't look like much to build, so I could probably testbuild the > > applications which depend on guile (if gentoo only had a buildbot or hydra). > > You could try sys-devel/make[guile]
This is what I will do now: I will compare the eselect I wrote and the one in the overlay, then update the guile ebuilds to include running the eselect, then I'll update the ebuild to eapi6.
(In reply to Nils Gillmann (ng0) from comment #36) > Thanks for your input, this looks very useful. > > I started writing an eselect-guile and adjust the ebuilds of guile. > It doesn't look like much to build, so I could probably testbuild the > applications which depend on guile (if gentoo only had a buildbot or hydra). It might be worthwhile just throwing one together if you can for this purpose .. would be interesting to see the breakage.
ng0: A couple of projects (sci for example) are already using https://travis-ci.org/ which could be a quick/easy solution via Github.
(In reply to Nils Gillmann (ng0) from comment #39) > This is what I will do now: > I will compare the eselect I wrote and the one in the overlay, > then update the guile ebuilds to include running the eselect, then I'll > update the ebuild to eapi6. That sounds great! Thank you for taking this up!
So the state of my work on this (this and guix on gentoo being my last native gentoo projects I will work on): 1) I wrote an eselect for guile which covers what I know and what I care for. There's a preview here[0] but I will also add the eselect here later next week/as soon as I have time. 2) guile-2.0.11 is stable enough for myself to have run numerous compiles, changes and systems of guix and gnutls. 3) absolutely nothing broke on my end for 6-7 months now. If what I send in later still breaks things I can't invest time into fixing or maintaining it, as mentioned in my other open bug tickets that I can invest the energy in two OS projects in addition to other projects, so the logical choice is to invest into the one which can run through guile on gentoo (however I suck at openrc scripts, so that needs to be fixed for the package which isn't focus of this bug ticket). [0]: http://youbroketheinternet.org/#overlay
Created attachment 440278 [details] app-eselect/guile metadata If name "ng0" is not enough, we can talk about an abbreviation of my name. However I see no reason why it should be like this, ng0 is a name which can be found in the other projects I contribute to and is close to my (legal) name. This is the first in a series of contributions to this bug ticket, They should soon be reachable in some webinterface again, and can be git cloned at several urls.
Created attachment 440280 [details] app-eselect/guile ebuild (1.2-r1) the ebuild.
Created attachment 440282 [details] guile.eselect this has been tested with the incoming versions of guile. I did not care about versions which are no longer in my scope or relevant, this is the task of people who use outdated versions or prefer to keep them in their tree. for 1.8 + 2.0.11 switching it worked.
Created attachment 440284 [details] guile 1.8.8-r3
Created attachment 440286 [details] guile 2.0.11-r99
Created attachment 440288 [details] guile metadata
Unlike stated in other bugs I left due to resource reasons: I am willing to help to fix this bug and even co-maintain the ebuild if other developers in gentoo are interested in fixing it, helping with it when I can not and accept that my resources are limited due to works in GNU Guix, in projects around GNUnet, and other personal projects.
For the impatient ones who stumble across this bug, you may want to git clone either of the following ones: http://youbroketheinternet.cheettyiapsyciew.onion/#overlay http://youbroketheinternet.org/#overlay or their mirrors at git://git.far37qbrwiredyo5.onion:/youbroketheinternet-overlay git://s.n0.is:/youbroketheinternet-overlay our Gentoo developer overlay which holds the guile related packages I just submitted.
(In reply to ng0 from comment #51) > For the impatient ones who stumble across this bug, you may want to git > clone either of the following ones: > http://youbroketheinternet.cheettyiapsyciew.onion/#overlay > http://youbroketheinternet.org/#overlay > or their mirrors at > git://git.far37qbrwiredyo5.onion:/youbroketheinternet-overlay > git://s.n0.is:/youbroketheinternet-overlay > > our Gentoo developer overlay which holds the guile related packages I just > submitte Well my problem right now is that I have working ebuild for guile-2.0.11 but I cant build greg with it. Did you solve this issue?
If this was a follow-up comment after trying what I submitted, could you go more into detail? If it wasn't, I have not tried greg. I use guile-2.0.11-r99 as a base to build and run guix on gentoo which, except for some random things that are related to my openrc file, just works. At the moment I have no working gentoo system and would advise people to test in their test environment and give me results I can work with.
(In reply to Amy Winston from comment #52) > (In reply to ng0 from comment #51) > > For the impatient ones who stumble across this bug, you may want to git > > clone either of the following ones: > > http://youbroketheinternet.cheettyiapsyciew.onion/#overlay > > http://youbroketheinternet.org/#overlay > > or their mirrors at > > git://git.far37qbrwiredyo5.onion:/youbroketheinternet-overlay > > git://s.n0.is:/youbroketheinternet-overlay > > > > our Gentoo developer overlay which holds the guile related packages I just > > submitte > > > Well my problem right now is that I have working ebuild for guile-2.0.11 but > I cant build greg with it. > > Did you solve this issue? Without building greg, I can say that the eselect I wrote works with the ebuilds of 1.8 and 2.0.11 I added. In my opinion there's no reason to keep anything other than 1.8 and 2.0.11, and 1.8 only if you figure out that something does no longer work with 2.0.11 and needs to be adjusted and a reasonable number of people depend on the thing which requires 1.8 and is a system critical dependency. 2.0.11 is the current stable upstream.
Sorry, correction. 1.8 might be kept as the old stable series, but 2.0.11 should clearly have priority over old stable.
(In reply to ng0 from comment #55) > Sorry, correction. > 1.8 might be kept as the old stable series, but 2.0.11 should clearly have > priority over old stable. Why we even need eselect at the first place? Why would anyone want the old version meaning 1.8 ??
I don't know, I just adjusted to the years old discussion. If it was for me, I'd try to just have 2.x series. For guile there's also what's considered guile-next, which is the development branch releases. Using an eselect is logical for gentoo. If you can find a consensus of enough developers which vote to proceed as you said, then this bug can be resolved in a different way.
(In reply to Amy Winston from comment #56) > > Why we even need eselect at the first place? Why would anyone want the old > version meaning 1.8 ?? I believe the 'correct' and/or 'proper' solution is to slot guile-2, but there are a lot of packages dependant on guile, which may/may not build with guile-2 vs guile 1.8. I'm not sure what state of testing this (ever) got to, but this is why a transition arrangement is being proposed. If you can advise a preferred course of action, and help with the solution, I'm sure there will be ears waiting to listen.
(In reply to ng0 from comment #57) > I don't know, I just adjusted to the years old discussion. > If it was for me, I'd try to just have 2.x series. > For guile there's also what's considered guile-next, which is the > development branch releases. > Using an eselect is logical for gentoo. If you can find a consensus of > enough developers which vote to proceed as you said, then this bug can be > resolved in a different way. If you want to help there are bugs opened which blocks this bug. I am trying to work on greg but not successfully so far. Any help is welcome. Thanks
(In reply to Amy Winston from comment #59) > (In reply to ng0 from comment #57) > > I don't know, I just adjusted to the years old discussion. > > If it was for me, I'd try to just have 2.x series. > > For guile there's also what's considered guile-next, which is the > > development branch releases. > > Using an eselect is logical for gentoo. If you can find a consensus of > > enough developers which vote to proceed as you said, then this bug can be > > resolved in a different way. > > If you want to help there are bugs opened which blocks this bug. > > I am trying to work on greg but not successfully so far. Any help is welcome. > > Thanks No, I will just work on this bug. I do not have the time or energy to help on other bugs.
I'm working on 2.0.12, but between now and a finished updated ebuild stands the part where I redo the gentoo test system because switching from hardened-musl to hardened-gcc is not doable at this point (this used to be a server). So some time next week.
(In reply to ng0 from comment #61) > I'm working on 2.0.12, but between now and a finished updated ebuild stands > the part where I redo the gentoo test system because switching from > hardened-musl to hardened-gcc is not doable at this point (this used to be a > server). So some time next week. System finished but is occupied with debug symbols now for some hours. Boring copy & paste, read for access if you wish to test guile-2.0.12 which was just version bumped on our side but not tested yet because I lack the resources to build more than I'm building at the moment. It should just work - if it doesn't, don't blame me I have warned you that this is an untested ebuild. Thanks, ng0 Some of these repositories can be found mirrored at notabug later on or on other external web services. For licenses, refer to the file headers or included license files. The repositories are accessible at locations which follow this syntax: for tor access: git://git.far37qbrwiredyo5.onion:/name-of-repository.git (example: git://git.far37qbrwiredyo5.onion:/gentoo-overlays/n0is-overlay) for clearnet: git://s.n0.is:/name-of-repository.git (example: git://s.n0.is:/gentoo-overlays/n0is-overlay) For mirrors it is equal to this: mirror: protocol://mirror-provider.domain/user-name/name-of-repository.git Because of this, only the repository name are mentioned below, with eventual upstream and mirror locations where it applies. Gentoo: youbroketheinternet-overlay The primary Gentoo developer overlay. name: youbroketheinternet-overlay upstream [http://youbroketheinternet.org/#overlay]
Adding to this a quote from https://lists.gnu.org/archive/html/info-gnu/2016-07/msg00007.html > This release contains 245 commits by 23 people over more than two years, > and is essentially a maintenance release, maintaining full compatibility > with the 2.0 release series. See the end of this mail for a full > description of user-visible changes. > > In parallel the Guile development team has been hard at work on the next > stable series, which we hope will see a stable release within the next > couple months. Inquisitive users should see the recent 2.1.3 release > notes at > https://lists.gnu.org/archive/html/guile-user/2016-06/msg00058.html for > a preview of our future stable series. I do not know much about how you communicate in Gentoo, and to be honest I was not interested in it to begin with. It's faster for us to work outside of discussions which can extend to ridiculous lengths of 6 years. Ping me once you have found a consensus on how you **really** want to address this problem as a community, democratic. If Gentoo does not get to guile-2 when 2.1.3 is released, I could not care less as we will be providing it outside of the portage tree together with many backported (from packages I do for Guix), changed, and unique ebuilds, in our youbroketheinternet overlay.
edit: when 2.1.x release tarball is out. An edit function in bugzilla would be nice.
(In reply to ng0 from comment #64) > edit: when 2.1.x release tarball is out. An edit function in bugzilla would > be nice. Have often thought the same myself .. >,<
https://wiki.gentoo.org/wiki/Overlay:Youbroketheinternet the guile-2.0.12 is masked now, it builds and autconf afterwards builds, but when guile-1.8 is present on the system it fails. I'm investigating where the source of failure is. Maybe the backwards compability to 1.8 is really broken, deprecated, obsolete and everything still using 1.8 should not be the problem of the system but the respective packages which are stuck with 1.8.
equery f guile |grep __scm.h /usr/include/guile/2.0/libguile/__scm.h /usr/src/debug/dev-scheme/guile-2.0.12-r99/guile-2.0.12/libguile/__scm.h But autogen complains about the lack of the __scm.h Nothing major changed in 2.0.12, it's a maintenance release.
greping in the autoconf work dir it looks like autoopts/mk-tpl-config.sh expects to find __scm.h in $libguiledir/libguile/__scm.h and not $libguiledir/$version/libguile/__scm.h Should be easy to fix.
GUILE_VERSION='200012' LIBGUILE_CFLAGS='-pthread -I/usr/include/guile/2.0 ' LIBGUILE_LIBS='-lguile-2.0 -lgc ' Should this point to /usr/include/guile/2.0/libguile ? Should I fix it with eselect symlinking 2.0/libguile two levels up into /usr/include/guile/ ? I don't know what the expected way for Gentoo would be here.
Created attachment 441096 [details] eselect-guile moved to: https://git.n0.is/eselect-guile.git git://git.far37qbrwiredyo5.onion:/eselect-guile.git git://git.n0.is:/eselect-guile.git
Created attachment 441098 [details] eselect-guile.ebuild
Here is the status update: For guile -r3 and -r99 are now masked as they use the eselect. The eselect worked in the environment I had before, but I redid the install on "bare metal" which is when it started to fail for packages installed afterwards (primarily: autoconf). I was told that lilypond is one of the biggest users of guile 1.8. and that dropping that would not be good (I considered dropping 1.8 and versioning altogether because I'm getting tired of using resources for this bug). It does not mean we can not change the default, as long as an older guile to depend on, let's name it “guile-compat” is still provided. Soon 2.2 will be released and 2.0 will become the old stable (which currently 1.8 is). It will be easier to move from 2.0 to 2.2 than from 1.8 to 2.2. I'm setting up again an environment where I can run either VMs or not worry about nuking the system and test the eselect ... any input, patches, pull requests on the eselect are welcome. The same message for contributions as for the youbroketheinternet overlay applies. --ng0
(In reply to ng0 from comment #72) > Here is the status update: > > For guile -r3 and -r99 are now masked as they use the eselect. The eselect > worked in the environment I had before, but I redid the install on "bare > metal" which is when it started to fail for packages installed afterwards > (primarily: autoconf). > > I was told that lilypond is one of the biggest users of guile 1.8. > and that dropping that would not be good (I considered dropping 1.8 and > versioning altogether because I'm getting tired of using resources for this > bug). > It does not mean we can not change the default, as long as an older guile to > depend on, let's name it “guile-compat” is still provided. > > Soon 2.2 will be released and 2.0 will become the old stable (which > currently 1.8 is). It will be easier to move from 2.0 to 2.2 than from 1.8 > to 2.2. > > I'm setting up again an environment where I can run either VMs or not worry > about nuking the system and test the eselect ... any input, patches, pull > requests on the eselect are welcome. The same message for contributions as > for the youbroketheinternet overlay applies. > > --ng0 Thank you for your work. I have one question how slotting the same ABI make sense? We will not implement eselect on guile we will put guile to the one slot. But as I told you before I will not add version 2.0.11/12 to the tree cause bugs which blocks this bugs needs to be resolved first.
(In reply to Amy Winston from comment #73) > > Thank you for your work. > > I have one question how slotting the same ABI make sense? > > We will not implement eselect on guile we will put guile to the one slot. > > But as I told you before I will not add version 2.0.11/12 to the tree cause > bugs which blocks this bugs needs to be resolved first. Are we talking about the three bugs listed in the Depends of this bug? ng0's efforts are indeed applaudable, but without further gentoo support, this will never be available 'officially' if we are bogged down with issues the previous maintainers never addressed. We need to take a serious look at the situation of this package in gentoo, or it will eventually be found by the treecleaners by being so out-of-date and broken, that despite anyone's efforts, it won't be possible to integrate into the tree. Not only this, but any packages that depend on it will also have to be tree-cleaned as they will be unsupportable without considerable effort to bring everything into line. I suggest we get on board with ng0's efforts, sort out some of the blockers, and get this package back into maintainership so that the packages which depend on guile-2 and future releases can be updated and included in the portage directory for all to use. Just my 2c...
(In reply to Amy Winston from comment #73) > (In reply to ng0 from comment #72) > > Here is the status update: > > > > For guile -r3 and -r99 are now masked as they use the eselect. The eselect > > worked in the environment I had before, but I redid the install on "bare > > metal" which is when it started to fail for packages installed afterwards > > (primarily: autoconf). > > > > I was told that lilypond is one of the biggest users of guile 1.8. > > and that dropping that would not be good (I considered dropping 1.8 and > > versioning altogether because I'm getting tired of using resources for this > > bug). > > It does not mean we can not change the default, as long as an older guile to > > depend on, let's name it “guile-compat” is still provided. > > > > Soon 2.2 will be released and 2.0 will become the old stable (which > > currently 1.8 is). It will be easier to move from 2.0 to 2.2 than from 1.8 > > to 2.2. > > > > I'm setting up again an environment where I can run either VMs or not worry > > about nuking the system and test the eselect ... any input, patches, pull > > requests on the eselect are welcome. The same message for contributions as > > for the youbroketheinternet overlay applies. > > > > --ng0 > > Thank you for your work. > > I have one question how slotting the same ABI make sense? > > We will not implement eselect on guile we will put guile to the one slot. > > But as I told you before I will not add version 2.0.11/12 to the tree cause > bugs which blocks this bugs needs to be resolved first. Why do people continue to read between the lines? I did not start with the slotting, it started with what people here wanted. Second thing, I work for Guix. The only motivation to keep Gentoo around is to fix this bug, to fix up my Guix package for Gentoo and to maintain GNUnet and their dependencies. My personal resources are limited, I do not intend to fix other open bugs related to guile. Third: people, get your priorities and focus straight. I mentioned this before, Gentoo needs to reach a consensus with this. What do you want to do with this? How do you want to proceed? Do you have some kind of liquid democracy voting tool for internal solutions? If my position on this is not clear, then at least give me something to work on, what you want, so that our work (youbroketheinternet overlay and portage tree) will not divide unnecessarily much. The reason that this bug still exists after 6 years is one of the reasons why I withdrew my intentions to apply as developer officially. Let me put this into perspective for you: If you do not fix Guile in the next years, eventually autoconf/gen will be updated at some point in the future to a version which is no longer supported then but still in Gentoo. Run a dependency tree on Guile to see how much it affects your system. > We will not implement eselect on guile we will put guile to the one slot. Can you be more clear what you mean? I understand this as: You think we do not need an eselect, the problems which appear are not existing and we should just ignore them or you have found a solution which you have not yet shared. To be clear on my progress: guile-2.0.11 and possibly even 2.0.12, assumed to work but the version which uses my eselect broke due to the eselect, both work. I ignore 1.8.8 but worked with it in the beginning when I did not focus on eselect. > But as I told you before I will not add version 2.0.11/12 to the tree cause > bugs which blocks this bugs needs to be resolved first. I did not ask for inclusion so far, read my comments and otherwise the overlay commit messages and notes. I don't want to turn in circles, so please address the comments I made. Thanks.
(In reply to Amy Winston from comment #73) > (In reply to ng0 from comment #72) > > Here is the status update: > > > > For guile -r3 and -r99 are now masked as they use the eselect. The eselect > > worked in the environment I had before, but I redid the install on "bare > > metal" which is when it started to fail for packages installed afterwards > > (primarily: autoconf). > > > > I was told that lilypond is one of the biggest users of guile 1.8. > > and that dropping that would not be good (I considered dropping 1.8 and > > versioning altogether because I'm getting tired of using resources for this > > bug). > > It does not mean we can not change the default, as long as an older guile to > > depend on, let's name it “guile-compat” is still provided. > > > > Soon 2.2 will be released and 2.0 will become the old stable (which > > currently 1.8 is). It will be easier to move from 2.0 to 2.2 than from 1.8 > > to 2.2. > > > > I'm setting up again an environment where I can run either VMs or not worry > > about nuking the system and test the eselect ... any input, patches, pull > > requests on the eselect are welcome. The same message for contributions as > > for the youbroketheinternet overlay applies. > > > > --ng0 > > Thank you for your work. > > I have one question how slotting the same ABI make sense? > > We will not implement eselect on guile we will put guile to the one slot. > > But as I told you before I will not add version 2.0.11/12 to the tree cause > bugs which blocks this bugs needs to be resolved first. As you could notice I am trying to fix guile and bugs which are linked to this one. We already agreed with pchrist we will remove slots and put it to one slot with new 2.0.12 version.
(In reply to Amy Winston from comment #76) > As you could notice I am trying to fix guile and bugs which are linked to > this one. This is obvious, no need to point it out more than one time. > We already agreed with pchrist we will remove slots and put it to > one slot with new 2.0.12 version. This could have been communicated much earlier to me. Suggestion for the future: Do not assume people know what you know. This does not answer how you want to proceed with this in detail. As I pointed out 1.8 will be needed by some applications even when 2.0 becomes the "old stable" branch. Can you communicate a bit more? This is neither productive nor friendly.
ng0/varmit, can you both please stop making drama here, it is incorrect place for it.
(In reply to Mikle Kolyada from comment #78) > ng0/varmit, can you both please stop making drama here, it is incorrect > place for it. One last comment before I leave this bug and work on it only in our overlay: the way you communicate and handle critism is seriously wrong. I did not "make drama" here I tried to get more information.Apparently this is too much to demand.
(In reply to Mikle Kolyada from comment #78) > ng0/varmit, can you both please stop making drama here, it is incorrect > place for it. I'm not here to create drama, I'm here to solve problems and contribute to Gentoo in what small way I can. It is exactly this attitude from the Developer Clique that discourages the community from getting involved with the distribution - something that, as a recruiter, I would imagine you may be concerned about. I have tried repeatedly to contact pchrist on IRC about the best way forward, and he has been unable to address my questions. I'm therefore glad that Amy has managed to join the scheme project to address the lack of resource, and move this issue forward. You can see the discussion in the comments above as to the 'right' way forward, and we have lacked 'official' input on this until recently. The reason I wanted to address guile (foolishly) was to solve a problem with another package I intended to maintain (or at least contribute) but if we cannot move forward with this dependency I am stymied. I have been impressed with ng0's contribution, and in the absence of the expertise to write eselect modules or contemplate slotting myself, am glad to see some progress. It is a pity this effort could be wasted by a lack of support and poor communication by the project it is intended to support.
Apologies for my obvious being ignorant of ulterior considerations here, but I don't quite see what justifies keeping Guile-1.8 around, at all. If there are a packages which do not build with newer versions of Guile, they will have to be update or - if they are not accordingly maintained - will be removed. Isn't that the way it has always been? A quick search even suggests that the next version of autogen will even REQUIRE >guile-2 [1] and if something like dev-scheme/greg refuses to work that's the problem of "greg" but no reason to make the rest of the system into a mess. I don't think Slotting is intended to accomodate for packages which are outdated by 6 years and not properly maintained, are they? [1] http://savannah.gnu.org/support/?109051
(In reply to Cedric Sodhi from comment #81) > Apologies for my obvious being ignorant of ulterior considerations here, but > I don't quite see what justifies keeping Guile-1.8 around, at all. If there > are a packages which do not build with newer versions of Guile, they will > have to be update or - if they are not accordingly maintained - will be > removed. Isn't that the way it has always been? A quick search even suggests > that the next version of autogen will even REQUIRE >guile-2 [1] and if > something like dev-scheme/greg refuses to work that's the problem of "greg" > but no reason to make the rest of the system into a mess. I don't think > Slotting is intended to accomodate for packages which are outdated by 6 > years and not properly maintained, are they? > > [1] http://savannah.gnu.org/support/?109051 No point is to make guile work. Unfortunately problem was not with greg but with guile itself I am almost done with that. Sorry If I was not clear.
I have a question on this bug: Can you be more transparent about when you aim to have guile-2 finished, as guile 2.0.0 was just removed 5 days ago.
Whilst definitely not speaking on Amy's behalf here, I would imagine that the 2.0.11/12 ebuild that she is working on, might be committed soon. The 2.0.0 was hard-masked as I recall, and was therefore not a lot of use to anyone. From the guile download page, the 2.0.11 release remains the stable version.
committer Amy Winston <amynka@gentoo.org> 2016-08-04 20:26:59 (GMT) commit ae5cef0546efda8d02fb8b25c69b82db272b13a0 dev-scheme/guile: version bump 2.0.12 bug #355355
app-office/gnucash-2.6.13 depend on dev-scheme/guile-1.8*, by manually change the ebuild: --with-guile=1.8 to --with-guile=auto, gnucash finished configure stage, but still failed to compile. The last build messages: /usr/bin/guild compile -o html-linechart.go html-linechart.scm Backtrace: In system/base/target.scm: 59: 19 [with-target "x86_64-pc-linux-gnu" ...] In system/base/compile.scm: 152: 18 [compile-file "report-collectors.scm" #:output-file ...] 43: 17 [call-once #<procedure 285f8c0 at system/base/compile.scm:56:5 ()>] In ice-9/boot-9.scm: 174: 16 [with-throw-handler #t ...] In system/base/compile.scm: 59: 15 [#<procedure 285f880 at system/base/compile.scm:58:9 ()>] 155: 14 [#<procedure 285f900 at system/base/compile.scm:153:8 (port)> #<closed: file 0>] 218: 13 [read-and-compile #<input: report-collectors.scm 9> #:from ...] 234: 12 [lp (# # # # ...) #<directory # 2b0d360> #<directory # 2b0d360>] 182: 11 [lp (#<procedure compile-tree-il (x e opts)>) (use-modules #) ...] In ice-9/boot-9.scm: 2404: 10 [save-module-excursion #<procedure 2e647e0 at language/scheme/compile-tree-il.scm:29:3 ()>] In language/scheme/compile-tree-il.scm: 31: 9 [#<procedure 2e647e0 at language/scheme/compile-tree-il.scm:29:3 ()>] In ice-9/psyntax.scm: 1106: 8 [expand-top-sequence ((use-modules (gnucash report report-system))) () ...] 989: 7 [scan ((use-modules (gnucash report report-system))) () ...] 279: 6 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...] In ice-9/boot-9.scm: 3589: 5 [process-use-modules (((gnucash report report-system)))] 705: 4 [map #<procedure 25f38a0 at ice-9/boot-9.scm:3589:25 (mif-args)> ((#))] 3590: 3 [#<procedure 25f38a0 at ice-9/boot-9.scm:3589:25 (mif-args)> (#)] 2870: 2 [resolve-interface (gnucash report report-system) #:select ...] In unknown file: ?: 1 [scm-error misc-error #f ...] In ice-9/boot-9.scm: 109: 0 [#<procedure 285f840 at ice-9/boot-9.scm:100:6 (thrown-k . args)> misc-error ...] Do I have to attach the full build log?
(In reply to Drunkard Zhang from comment #86) > app-office/gnucash-2.6.13 depend on dev-scheme/guile-1.8*, by manually > change the ebuild: --with-guile=1.8 to --with-guile=auto, gnucash finished > configure stage, but still failed to compile. The last build messages: > > /usr/bin/guild compile -o html-linechart.go html-linechart.scm > Backtrace: > In system/base/target.scm: > 59: 19 [with-target "x86_64-pc-linux-gnu" ...] > In system/base/compile.scm: > 152: 18 [compile-file "report-collectors.scm" #:output-file ...] > 43: 17 [call-once #<procedure 285f8c0 at system/base/compile.scm:56:5 ()>] > In ice-9/boot-9.scm: > 174: 16 [with-throw-handler #t ...] > In system/base/compile.scm: > 59: 15 [#<procedure 285f880 at system/base/compile.scm:58:9 ()>] > 155: 14 [#<procedure 285f900 at system/base/compile.scm:153:8 (port)> > #<closed: file 0>] > 218: 13 [read-and-compile #<input: report-collectors.scm 9> #:from ...] > 234: 12 [lp (# # # # ...) #<directory # 2b0d360> #<directory # 2b0d360>] > 182: 11 [lp (#<procedure compile-tree-il (x e opts)>) (use-modules #) ...] > In ice-9/boot-9.scm: > 2404: 10 [save-module-excursion #<procedure 2e647e0 at > language/scheme/compile-tree-il.scm:29:3 ()>] > In language/scheme/compile-tree-il.scm: > 31: 9 [#<procedure 2e647e0 at language/scheme/compile-tree-il.scm:29:3 ()>] > In ice-9/psyntax.scm: > 1106: 8 [expand-top-sequence ((use-modules (gnucash report report-system))) > () ...] > 989: 7 [scan ((use-modules (gnucash report report-system))) () ...] > 279: 6 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...] > In ice-9/boot-9.scm: > 3589: 5 [process-use-modules (((gnucash report report-system)))] > 705: 4 [map #<procedure 25f38a0 at ice-9/boot-9.scm:3589:25 (mif-args)> > ((#))] > 3590: 3 [#<procedure 25f38a0 at ice-9/boot-9.scm:3589:25 (mif-args)> (#)] > 2870: 2 [resolve-interface (gnucash report report-system) #:select ...] > In unknown file: > ?: 1 [scm-error misc-error #f ...] > In ice-9/boot-9.scm: > 109: 0 [#<procedure 285f840 at ice-9/boot-9.scm:100:6 (thrown-k . args)> > misc-error ...] > > Do I have to attach the full build log? No please make separate bug about it with proper build.log and emerge --info. Thanks
