Created attachment 438986 [details] ebuilds with old guile While discussing bug 427346 with upstream: Jun 15 13:37:00 <wizardedit> hi there, I'm trying to compile guile-1.8.8 with clang on gentoo, which fails with ERROR: Wrong type argument in position 1: #<freed cell 0x7f69d9d8f180; GC missed a reference>, similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650761 (debian ia64) http://pastebin.com/9MCL2wjK. How can I debug this? Jun 15 13:41:18 <wizardedit> I've tried the freebsd patches mentioned at https://bugs.gentoo.org/show_bug.cgi?id=427346, but that made no difference Jun 15 15:08:16 <dsmith> wizardedit, I wish you well. Debugging GC stuff is hard. Unfortunately, I don't thing there is much motivation for fixing things in 1.8. 2.0 has been out for years, and there are rumors that 2.2 might be released soon. "soon" as in maybe in 2016. Jun 15 15:08:52 <daviid> wizardedit: guile-1.8 has been unmaintained for such a long time that you will hardly find any help from any one I'm afraid. I suggest you you grab guile-2.0 instead, the latest stable is 2.0.11 Jun 15 15:24:12 <wizardedit> daviid, my goal was to fix the bug in the gentoo tree, but thanks for the info. Maybe we should focus on dropping 1.8 instead Jun 15 15:24:27 <wizardedit> was hoping there was some easy fix I was missing :/ Jun 15 15:25:29 <daviid> wizardedit: you definitively want to get rid of 1.8 in all distro Jun 15 15:25:48 <wizardedit> daviid, okay. Thanks for clear statement :) Jun 15 15:26:00 <dsmith> wizardedit, Yeah. Jun 15 15:26:29 <daviid> welcome! As stated above, I've tried the FreeBSD clang patches, but that doesn't help. Given that upstream considers it deprecated and not worth supporting, we should try to move to 2.x asap. The following packages depend on dev-scheme/guile:12 / dev-scheme/guile-1.8*: austin@austin2:~/src/gentoo$ git grep dev-scheme/guile | grep -e 'dev-scheme/guile:12' -e 'dev-scheme/guile-1.8' | cut -d / -f1-2 | sort -u app-office/gnucash app-office/texmacs dev-scheme/greg dev-scheme/guile-cairo dev-scheme/guile-gnome-platform dev-scheme/guile-www games-strategy/liquidwar6 mail-filter/anubis media-sound/denemo media-sound/lilypond net-irc/weechat net-libs/gnutls sci-electronics/geda sci-electronics/gwave sci-libs/linux-gpib sci-libs/starparse sci-mathematics/drgeo sys-devel/autogen sys-devel/make x11-libs/guile-gtk x11-misc/xbindkeys Full ebuild list is included in attachment.
Hi, my free time is very limited, each time I 've tried to work on this, I've stuck in this bloody list of crappy reverse dependencies. I'll try build a testbox and work in the next weeks on this problem. I think amynka and others have tried to solve this too, don't know how far they have gotten, need to read all bugs again. The other way is to just drop guile-1.8 together with all reverse deps that don't work with guile-2 and get over this mess once and for all. Slotting sucks, I should have done it 3-4 years ago when fulax's eselect code was in play, now I I think it's a waste of time. If anyone wants to step up and do it, I have no objections, just try not to make things worse. Autogen and make are the packages that should always work because some base-system packages need it. Eg guile used to be needed when gcc was built with FEATURES=test because it pulled in autogen, don't know what happens now, have to check.
We can change this to a tracker bug then to follow all the bugs related with the reverse deps that will break with guile-2 and handle them more easily
I have fixed a few of these bugs. I have left some open (more specifically IN_PROGRESS) when they were stable for some arches prior to my fixes. I assumed we don't want to blindly carry those stable flags forward without adequate testing. You have a choice of closing those now or after stabilization.
general question: lilypond's devs say it's going to be "1-2 years" before lilypond will run with guile-2.* (iiuc there's something with the guile code itself that is causing lily to puke). I use(d) lilypond as one of my main tools; as it is broken with guile-2.*, what should I do in the meantime?
side note: I'm devaway and don't know the full status of guile in the tree. @Andrew: one of the main reasons I didn't push guile-2 in the tree myself 3-4 years ago, was lilypond. But we have waited too long. Amynka finally had the courage to start this task. To my point of view, everything with guile-1 should be dropped or fixed. I don't know how other distros handle lilypond but we can't keep the dinosaur guile just for a package. Upstream must be pushed to fix lilypond asap, or bundle it somehow if licensing accepts it. I'll try do some testing if I find spare time. I'm sorry we're causing this to you.
(In reply to N. Andrew Walsh from comment #4) > general question: lilypond's devs say it's going to be "1-2 years" before > lilypond will run with guile-2.* (iiuc there's something with the guile code > itself that is causing lily to puke). I use(d) lilypond as one of my main > tools; as it is broken with guile-2.*, what should I do in the meantime? I am sorry but you have incorrect information. The problem is not in guile but in lilypond. We however don't know why upstream was not able to patch lilypond so far but I believe they will or someone else will do it. Solution for you is to still use old guile which will not be removed till the upstream of lilypond don't fix their problems. Cheers, Amy
(In reply to Amy Winston from comment #6) > (In reply to N. Andrew Walsh from comment #4) > > general question: lilypond's devs say it's going to be "1-2 years" before > > lilypond will run with guile-2.* (iiuc there's something with the guile code > > itself that is causing lily to puke). I use(d) lilypond as one of my main > > tools; as it is broken with guile-2.*, what should I do in the meantime? > > I am sorry but you have incorrect information. The problem is not in guile > but in lilypond. We however don't know why upstream was not able to patch > lilypond so far but I believe they will or someone else will do it. > Solution for you is to still use old guile which will not be removed till > the upstream of lilypond don't fix their problems. > > Cheers, > Amy Since I think lilypond is the only package still not ported to guile-2... if you still want to keep in the tree, I would try to create a guile-1.8 slot only for that one in the way Fedora is doing (I mean, the main version without playing with the names of the files to not collide would be guile-2, while the "renamed one" guile-1.8). http://pkgs.fedoraproject.org/cgit/rpms/compat-guile18.git/tree/compat-guile18.spec Otherwise, lilypond users will stil be in trouble as other guile reverse deps will try to install guile-2
(In reply to Pacho Ramos from comment #7) > (In reply to Amy Winston from comment #6) > > (In reply to N. Andrew Walsh from comment #4) > > > general question: lilypond's devs say it's going to be "1-2 years" before > > > lilypond will run with guile-2.* (iiuc there's something with the guile code > > > itself that is causing lily to puke). I use(d) lilypond as one of my main > > > tools; as it is broken with guile-2.*, what should I do in the meantime? > > > > I am sorry but you have incorrect information. The problem is not in guile > > but in lilypond. We however don't know why upstream was not able to patch > > lilypond so far but I believe they will or someone else will do it. > > Solution for you is to still use old guile which will not be removed till > > the upstream of lilypond don't fix their problems. > > > > Cheers, > > Amy > > Since I think lilypond is the only package still not ported to guile-2... if > you still want to keep in the tree, I would try to create a guile-1.8 slot > only for that one in the way Fedora is doing (I mean, the main version > without playing with the names of the files to not collide would be guile-2, > while the "renamed one" guile-1.8). > http://pkgs.fedoraproject.org/cgit/rpms/compat-guile18.git/tree/compat- > guile18.spec > > Otherwise, lilypond users will stil be in trouble as other guile reverse > deps will try to install guile-2 We will probably slot the guile anyways working on it right now.
(In reply to Amy Winston from comment #8) > > We will probably slot the guile anyways working on it right now. Any news on this? I think texmacs will also need the old 1.8 slot :/
(In reply to Pacho Ramos from comment #9) > (In reply to Amy Winston from comment #8) > > > > We will probably slot the guile anyways working on it right now. > > > Any news on this? I think texmacs will also need the old 1.8 slot :/ I am working on texmacs but it can also happen that we will have to slot it eventually. I am working on solution.
commit e09fe196a13f2faa4b184b1bf5d7f961c4c8b8b0 Author: Matt Turner <mattst88@gentoo.org> Date: Sun Sep 1 12:16:42 2019 -0700 profiles: Mask dev-scheme/guile < 2 and app-office/texmacs Bug: https://bugs.gentoo.org/436400 Signed-off-by: Matt Turner <mattst88@gentoo.org>
I see `USE=guile2` is now forced for lilypond since Sep. 1st, 2019. guile2 cripples lilypond to the point of uselessness. "compiles without errors" is about the only positive thing that can be said about that combination. lilypond developers still have lots of work to do to finish their port to guile2, they are aware of it and I know, we've been waiting for years. Above in this report was a discussion of either slotting guile1 or bundling lilypond with guile1, but it appears those two points were ignored when decision to force guile2 was made. Does that mean gentoo will drop lilypond next and that I should copy the guile1 and lilypond ebuilds to my local overlay if I want to keep using a functional lilypond?
