This is a reminder to unmask >=aisleriot-3.4 once >=dev-scheme/guile-2 has been unmasked.
Correction: guile-2.0.5 is required (currently in lisp overlay).
Should we treeclean this? I don't know if guile2 will be unmasked ever :(
Well, I guess yes. I'll continue trying to update it in overlay because it's less of a problem there :)
(In reply to Pacho Ramos from comment #2) > Should we treeclean this? I don't know if guile2 will be unmasked ever :( There is a recent ebuild for guile2 here: https://github.com/sakaki-/funtoo-2-gentoo/tree/master/dev-scheme/guile Imho it should be modified to use SLOT="2/2.0.11" instead of 0/2.0.11 slib-3.2.4.ebuild may be imported from funtoo as well: https://github.com/funtoo/funtoo-overlay/tree/master/dev-scheme It works with minor modifications (i.e. site/2.0 dir has to be created within pkg_postinst(), not in src_install() and gambit ebuild needs to install a link from gambit-interpreter got gsi) With those aisleriot-3.4 compiles and runs marvelously here. But some mainstream tree builds will not work with guile2, among them gnucash, lilypond, drgeo. If those are needed guile:12 and guile:2 need proper slot support to coexist, current state of thes ebuilds does not. - guile:12 needs to be uninstalled first in order for guile-2.0.11-r1:2 to merge - if make was built with "guile" use flag, guile:12 unmerge will break make - building make without "guile" use flag first will keep make functional - after guile:2 is installed, "guile" use flag may safely be enabled again (-> if make breaks, extract a working make and gmake temporarily from stage3 tarball) - run revdep-rebuild to fix broken packages To version bump guile, either guile:12 dependents in main tree need to be fixed to be able to use guile:2, or ebuilds need proper slot support to be coinstallable. So this bug is not really about aisleriot, but guile. There are some guides for the transition of code from guile:12 to guile:2, e.g. https://www.gnu.org/software/guile/manual/html_node/Transitioning-away-from-GH.html If there are no packages installed depending on guile:12, then guile:2 above may act as a drop-in-replacement right now (and aisleriot works).
We know of the ways to have guile-2 (lisp overlay), it is just not in tree and nobody seems to be doing that work. We certainly aren't as the gnome team is maintaining enough packages as it is. So if you are really interested in it, please get in touch by maintainers of guile, I am sure they will appreciate the help.
(In reply to Gilles Dartiguelongue from comment #5) > interested in it, please get in touch by maintainers of guile, I am sure > they will appreciate the help. What's the proper way to push ebuilds to lisp overlay? Is it ok to use this bug tracker using '[lisp overlay]' prefix or do the maintainers need to be contacted directly? https://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap104 Some of the packages preventing the move of guile-2 from lisp overlay to main tree were already identified in a prev comment. If you have a working guile-2 and slib, gnucash actually builds and runs fine with them, so this is one off the list (here) with 'drgeo' and 'lilypond' remaining to be checked. For guile-2 to appear in main tree, _all_ packages with guile deps need to either work with guile-2 _or_ it needs to be slotable (*). http://gentoobrowse.randomdan.homeip.net/herd/scheme Part of this work might be carried out first in lisp overlay. This is what you suggested in the first place. But currently, if a user decides to have guile-2 via lisp overlay, he/she will actually face the same compatibility problems with guile:12 dependent ebuilds from the main tree as long as (*) does not hold. E.g. for the lisp overlay, it misses gnucash ebuild, the version from main tree works with guile-2, but deps need to be modified: diff -ur gentoo/app-office/gnucash/gnucash-2.6.5.ebuild myrep/app-office/gnucash/gnucash-2.6.5.ebuild --- gentoo/app-office/gnucash/gnucash-2.6.5.ebuild 2014-12-31 11:34:52.000000000 +0100 +++ myrep/app-office/gnucash/gnucash-2.6.5.ebuild 2015-01-15 15:51:44.000000000 +0100 @@ -25,7 +25,7 @@ >=dev-libs/popt-1.5 >=dev-libs/libxml2-2.5.10:2 dev-libs/libxslt - >=dev-scheme/guile-1.8.3:12[deprecated,regex] + >=dev-scheme/guile-1.8.3[deprecated,regex] dev-scheme/guile-www gnome-base/libgnomecanvas >=net-libs/webkit-gtk-1.2:2 Bug 537306 was filed to have a dev-scheme/slib in main tree that's compatible with guile-2.0 from [lisp overlay] and guile-1.8 from main tree.
Afaik, lisp overlay is maintained (or was) by gentoo devs of the scheme herd so they have all needed powers to do whatever needs to be done. I am not sure of what is holding progress but that's why we have the blocker, so we are notified when we can do something about it. If you want to help these guys out, I suggest you get in touch with them to help proxy-maintain packages if needed or have access to overlay or even become a gentoo dev yourself if you are interested in scheme.
@Pacho Ramos, You've just masked and planned for removal every possible version (including a compiling and a working one - =games-board/aisleriot-3.2.3.2-r1) of games-board/aisleriot .... /usr/portage/profiles/package.mask: # Pacho Ramos <pacho@gentoo.org> (19 Mar 2015) # Hardmasked for ages and still impossible to unmask (#416683). # Removal in a month. # Alexandre Rostovtsev <tetromino@gentoo.org> (20 May 2012) # Requires dev-scheme/guile-2.0.5 which is in lisp overlay and masked; # bug #416683 And it is still a dependency of the "games" USE flag in =gnome-base/gnome-extra-apps-3.14.0-r1... Besides it (=games-board/aisleriot-3.2.3.2-r1) compiles and works ok with USE="gnome -debug" and was NOT "hardmasked for ages"........ Do you guys ever run "equery d -a" before removing/masking packages :S :( # equery d -a games-board/aisleriot * These packages depend on games-board/aisleriot: gnome-base/gnome-extra-apps-3.14.0-r1 (games ? >=games-board/aisleriot-3.2.3.2) I hope the solution will not be removing the dependency from gnome-base/gnome-extra-apps.... :) Thanks
(In reply to PhobosK from comment #8) > @Pacho Ramos, > > You've just masked and planned for removal every possible version (including > a compiling and a working one - =games-board/aisleriot-3.2.3.2-r1) of > games-board/aisleriot .... > > > /usr/portage/profiles/package.mask: > # Pacho Ramos <pacho@gentoo.org> (19 Mar 2015) > # Hardmasked for ages and still impossible to unmask (#416683). > # Removal in a month. > # Alexandre Rostovtsev <tetromino@gentoo.org> (20 May 2012) > # Requires dev-scheme/guile-2.0.5 which is in lisp overlay and masked; > # bug #416683 > > > > And it is still a dependency of the "games" USE flag in > =gnome-base/gnome-extra-apps-3.14.0-r1... > > Besides it (=games-board/aisleriot-3.2.3.2-r1) compiles and works ok with > USE="gnome -debug" and was NOT "hardmasked for ages"........ > > > > Do you guys ever run "equery d -a" before removing/masking packages :S :( > > > > # equery d -a games-board/aisleriot > * These packages depend on games-board/aisleriot: > gnome-base/gnome-extra-apps-3.14.0-r1 (games ? > >=games-board/aisleriot-3.2.3.2) > > > > I hope the solution will not be removing the dependency from > gnome-base/gnome-extra-apps.... :) > > Thanks I agree in full to this: The package compiles ok with those USE-flags. There's no need to bump out working packages, just to clean up the bug list. Leave it as it is, please. If you'll bump it, there will never be a solution, if not, maybe it will developed as a side effect of something else. There are people, which like to use it as there's no other as complete solitaire anywhere. If we all wanted to use mainstream, we wouldn't go with gentoo. Thanks!
Pacho, what's the actual problem with aisleriot-3.2? It builds and runs fine with old guile AFAIK, so why tree-clean it?
It's completely unmaintained for ages, upstream doesn't commit any fix to it. Also, it needs to be checked for the proper usage of python eclasses (or, at least, ensure it's in sync with the rest of the gnome games that are able to use gnome-games.eclass). Finally... I am unsure if maybe the "gnome" USE flag could be killed to (progressively) get rid of packages relying on gconf :S Obviously the proper option would be to try to go ahead and unmask finally guile-2... but I am really tired of needing to do that works specially taking care I am not familiar at all with all the guile stuff (every time I have tried to "push" guile-2 fixing I have get promises of it being fixed "soon" but we are still blocked :'( ) Personally I would also kill guile-2 from the tree and point people to lisp-overlay for it (and maybe aisleriot could be provided there). The other option is to get the packages from the overlat to the tree... but it's difficult to know what to do when you get nearly 0 replies from the maintainers of involved packages
I've changed the ebuild as appended, to build the latest version. I'm not sure, if all dependencies are as needed, as my system is mostly up to date or in ~amd64 state. If you move aisleriot to an overlay, that will be no problem, I think. What's with the following idea? - I'm not sure if it's even possible: Creating a virtual package, which relies on the aisleriot package in the overlay. I know, this is one step more of work, but only packages which are found by users, will be used, tested and given a feedback. Could be a new category, for example virtual-overlay, which will be used for other packages, too. This way we can get a mostly clean main-tree, but only frequently installed packages will be found too. The side effect: Users which aren't very deep envolved will find more easily what they seek for and as they are guided what to do, they may get interested in doing more.
Created attachment 400958 [details] works for me to install the actual version
removed
Is this the way you are cooperating with users? - And you are wondering, why nobody will involve himself?
(In reply to Berthold Humkamp from comment #15) > Is this the way you are cooperating with users? - And you are wondering, why > nobody will involve himself? As explained before, the major issue isn't bumping aisleriot bump having a recent enough guile in tree. The gnome team cannot manage scheme packages on top of gnome as well as gnome so if nobody takes over the work of the scheme team, we are left with no alternative but to remove aisleriot from the main tree. It will be bumped in the overlay once I or someone else gets around to solving the guile problems at least for the overlay or if guile gets updated in tree again.
Ok, this is an answer and not only ignoring my input. Why not put this ebuild into the overlay, as a starting point for whoever wants to use or work on it? I wouldn't know, how to get the old ebuild, if I hadn't put it into my local overlay already. Just set a comment in it, with a warning and a link to this bug.
There is a live ebuild already that should reflect the last time we worked on the issue which should be something like 3.6 or 3.8. It is not ideal. I will try to work on this again with Gnome 3.16 bumps.
@Gilles Dartiguelongue: What is the exact problem with guile-2.0.11? We are running this version for at least 2 months without any build problems related to it on hardened and non-hardened systems. There are now over 4 years since the 2.0.0 version was released in Feb 16 2011. So (mostly) all problems related to this ebuild version should be solved [Emacs/Lisp compilation problems]. Other distributions like Fedora running a nearly unchanged guile version for years [only patching multi-lib support]. So I can't imagine any problems when bumping/releasing just a guile-2.0.11 ebuild with gnome 3.16.
I have no idea, you'd have to check with the scheme team in bug #355355.
