Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Required for gnucash 1.9.x
Created an attachment (id=81681) [edit] g-wrap-1.9.6.ebuild
Created an attachment (id=81682) [edit] g-wrap-glib-problem-fix.patch
Created an attachment (id=81759) [edit] g-wrap-1.9.6.ebuild Added some comments to the ebuild...
I assume this is for the gtk 2 version of gnucash ? Does it need slotting ?
No; both gnucash 1.8 and 1.9/2.0 will build against g-wrap 1.9.6. It might need to force a gnucash-1.8 rebuild, though. Not sure. To be precise, g-wrap 1.9.6 is only really a requirement for gnucash-1.9.x on a system with gcc-4, as it generates code that causes compiler warnings with gcc4 (not gcc3) which gnucash their -Werrors out on. But gnucash-2.0 won't dist with --enable-error-on-warning. At the same time, it's probably a good idea to encourage moving past g-wrap-1.3.4 anyways.
ebuild should set SLOT="0".
Created an attachment (id=86947) [edit] g-wrap-1.9.6.ebuild revision [obsoletes previous] - remove commented-out sections - SLOT="0" (though g-wrap-1.3.4 has SLOT="1.3", and this will clobber that :( ) - add glib-2.0 as a DEPEND for emerge ordering, &c. - we only need to re-`autoconf`.
Can we get this in portage, please?
I would love to put this into portage, but I don't think the SLOT adjustment is appropriate, because that causes it to overwrite the prior version of g-wrap without unmerging that version. Are we all sure that the two versions are co-habitable? And furthermore, those libs and progs which depend on g-wrap-1.3 -- will they break with this new version?
g-wrap cannot be slotted; I have no idea why 1.3.4 has SLOT="1.3". It shouldn't. The only thing that uses g-wrap in portage is gnucash.
Thanks Ed, you confirmed my suspicions.
*** Bug 143748 has been marked as a duplicate of this bug. ***
*** Bug 150911 has been marked as a duplicate of this bug. ***
OK, I need to assess two things: 1. Will people running gnucash-1 need to remerge? 2. Will people running gnucash-2 need to remerge?
According to the folks on the devel list at gnucash, the answer is yes, both versions of gnucash (1.x and 2.x) would require recompiling.
thanks Bob. In this case then, I'll wait till we get rid of 1.8.11, and then I'll develop -r1's for the remaining to depend strictly on the newer g-wrap and make the old ones strictly depend on the existing g-wrap so that the upgrades all happen together (and then the three can be stabled simultaneously). This will take a couple of weeks to put into ~arches from the looks of it.
I've been waiting 2 months for >dev-libs/g-wrap-1.3.4 to somehow make it into the portage tree. Is there ANY chance this will become a reality in the next week? This is starting to impact the regular update process for my system. If it can't be done, let me know so that I can unmerge GNUcash from my gentoo machaine and start using it under ubuntu.
Bob, Please note the two bugs which depend on this, and the bug that this depends on. I'm interested in upgrading guile, slib and g-wrap (and the newest gnucash) in one go, but I'd like to do it smoothly. I'm working with our scheme team to get this in as smoothly as possible. It'll probably be another week, maybe 2. If you can wait, that'd be great, if not, then I do understand.
g-wrap's homepage is (now) incorrect. The right one is http://www.nongnu.org/g-wrap/
Created an attachment (id=104598) [edit] dev-libs/g-wrap/g-wrap-1.9.7.ebuild seems to work together with guile-1.6.8 and slib-3.1.4(3a4)
(In reply to comment #20) > Created an attachment (id=104598) [edit] > dev-libs/g-wrap/g-wrap-1.9.7.ebuild > > seems to work together with guile-1.6.8 and slib-3.1.4(3a4) I'm having trouble with g-wrap-1.9.7 due to code introduced in g-wrap-1.9.7: On my system, g-wrap-1.9.7 creates a file config.scm in directory /var/tmp/portage/dev-libs/g-wrap-1.9.7/image/usr/share/guile/site/g-wrap that contains the following code: (define *g-wrap-shlib-dir* "/var/tmp/portage/dev-libs/g-wrap-1.9.7/image//usr/lib/g-wrap/modules/") The problem with this code is that it refers to the temporary image directory, not the final destination directory (/usr/lib/g-wrap/modules/). This causes gnucash on start-up to issue the following error messages: ERROR: In procedure dynamic-link: ERROR: file: "/var/tmp/portage/dev-libs/g-wrap-1.9.7/image//usr/lib/g-wrap/modules/libgw-guile-standard", message: "/var/tmp/portage/dev-libs/g-wrap-1.9.7/image//usr/lib/g-wrap/modules/libgw-guile-standard.so: cannot open shared object file: No such file or directory" I can fix this problem by editing file /usr/share/guile/site/g-wrap/config.scm to remove the prefixed "/var/tmp/portage/.../image/", but I think the code upstream needs to be fixed.
without an external libffi g-wrap-1.9.7 will break dependent packages when emerged an even number of times. emerging g-wrap toggles the presence of libffi. when first emerged, g-wrap will build its internal ffi when it detects no external libffi. portage merges the libffi into the filesystem. emerged again, g-wrap doesn't build its internal ffi. portage then breaks any packages depending on g-wrap by removing the external libffi g-wrap built against. temp workaround: emerge g-wrap-1.9.7 an odd number of times :)
(In reply to comment #20) > seems to work together with guile-1.6.8 and slib-3.1.4(3a4) guile-gnome-platform-2.15.90's guile-gtk-demo successfully runs w/guile v1.8.1, slib 3.1.4, and g-wrap-1.9.7. i used the slib-1.3.4/guile-1.8.1 workaround at http://bugs.gentoo.org/show_bug.cgi?id=45826#c11. disabling deprecated features in guile 1.8.x breaks g-wrap. g-wrap-1.9.7 uses many things marked deprecated in 1.8.x. building guile-gnome-platform-2.15.90 failed w/guile-1.8.1 built with --disable-deprecated/--enable-deprecated=no.
(In reply to comment #22) > without an external libffi g-wrap-1.9.7 will break dependent packages when > emerged an even number of times. emerging g-wrap toggles the presence of > libffi. > > temp workaround: emerge g-wrap-1.9.7 an odd number of times :) What about adding dev-libs/libffi to (R)DEPEND?
(In reply to comment #23) > guile-gnome-platform-2.15.90's guile-gtk-demo successfully runs w/guile > v1.8.1, slib 3.1.4, and g-wrap-1.9.7. i used the slib-1.3.4/guile-1.8.1 > workaround at http://bugs.gentoo.org/show_bug.cgi?id=45826#c11. From http://www.gnu.org/software/guile-gnome/ "Also note that we have bumped our dependency on G-Wrap to an as-yet-unreleased version, and removed the dependency on SLIB." So can you really use slib functions from guile-1.8.*?
g-wrap-1.9.7 is in. This is fixed.
1.9.6 now in too, since gnucash has some trouble with 1.9.7 still
