Description
gapon
2008-06-27 20:15:17 UTC
I just added this package and it worked fine with libtool-1.5, if anyone has a fix please let me know and I will check it out. Thanks. Well, the problem is the silly way they must have constructed acinclude.m4. To fix it, you have to remove from acinclude.m4 all the lines from the start of the DOLT macro (I don't think it's necessary to explain the silliness that is dolt) up to the line starting with "dnl Like AC_CHECK_HEADER". Then eautoreconf should work properly. Which one is the DOLT macro? I found "dnl Like AC_CHECK_HEADER" but I do not know how far the file needs to be cut. (Note to self: Remember to look at this) Created attachment 160123 [details, diff]
files/gambas-2.7.0-r1-libtool-2.2-and-FLAGS.patch
Created attachment 160125 [details, diff]
gambas-2.7.0-r1.ebuild.patch
I am not sure if this is the right way to do it at all, but it goes all the way through to install. I have not tried merging it.
I also put in a couple of minor enhancements. Hopefully those can be adopted at least.
I worked on amd64 and I think the ebuild should be keyworded ~amd64.
(In reply to comment #6) > Created an attachment (id=160125) [edit] > gambas-2.7.0-r1.ebuild.patch > > I am not sure if this is the right way to do it at all, but it goes all the way > through to install. I have not tried merging it. > > I also put in a couple of minor enhancements. Hopefully those can be adopted > at least. > > I worked on amd64 and I think the ebuild should be keyworded ~amd64. > Cool. It looks like you fixed all of the 'known' issues as presented in bug #146871. I'll test abit and see what happens. Ouch, that's some nasty seding, but looks like it should have the desired effect. However, it won't work with libtool 1.5, something bit more conservative may be required. You cut the correct block and DOLT macro was the one directly above libtool.m4. I call DOLT silly, cause it was created after libtool 2.2 was released and while it had a significant performance gain over libtool 1.5 (while loosing some portability), that gain was not-so-significant over 2.2. Answer was late, cause I wasn't CC'd to this but. I wonder if/when libtool upstream will address that AC_CONFIG_SUBDIRS libltdl incompability, BTW. When I was updating the ebuild I was not looking for compatibility with libtool 1.5. That is why there is a depend (not necessarily the proper kind) on libtool 2.2. If 1.5 compatibility is necessary, I could downgrade and work on it, but I have very little experience with libtool or autotools. About the seding, I am not sure when a "sed" patch is more appropriate than a regular ".patch". A maintainer with experience would know better. This is only the second ebuild I have worked on. Thanks for answering my question for the DOLT macro. Appreciated. (In reply to comment #10) > When I was updating the ebuild I was not looking for compatibility with libtool > 1.5. That is why there is a depend (not necessarily the proper kind) on > libtool 2.2. If 1.5 compatibility is necessary, I could downgrade and work on > it, but I have very little experience with libtool or autotools. Ah, well. We have to maintain compat until libtool-1.5 isn't in the tree anymore. And since libtool is an "implicit dependency", an ebuild shouldn't really depend on any version of it. > About the seding, I am not sure when a "sed" patch is more appropriate than a > regular ".patch". A maintainer with experience would know better. This is > only the second ebuild I have worked on. Mainly, readability. If you think that some people might not understand the sed'ing then you should make it a patch. Also, length. If the seding spans for multiple lines or multiple times, it is probably more appropriate to do a patch. > Thanks for answering my question for the DOLT macro. Appreciated. Created attachment 161148 [details, diff]
files/gambas-2.7.0-r1-gb.qt-QT_LDFLAGS.patch
.patch version of the previous sed patch
Upstream may/should apply something similar in the future or I am not understanding the build system
Created attachment 161149 [details, diff]
files/gambas-2.7.0-r1-help-GB_INIT_SHORT.patch
fixes build failure
Upstream may/should apply something similar in the future or I am not understanding the build system
Created attachment 161151 [details, diff]
files/gambas-2.7.0-r1-libtool-and-FLAGS.patch
libtool patch that works with 1.5 and 2.2
Created attachment 161153 [details, diff]
files/gambas-2.7.0-r1-remove-libltdl-from-main.patch
Created attachment 161155 [details, diff]
gambas-2.7.0-r1.ebuild.patch
Minor additions/changes from previous patch
Tested to "install" with libtool 1.5 and 2.2 on amd64
(In reply to comment #16) > Created an attachment (id=161155) [edit] > gambas-2.7.0-r1.ebuild.patch > > Minor additions/changes from previous patch > Tested to "install" with libtool 1.5 and 2.2 on amd64 > Alright, I have this in my local testing overlay. I will get to it soon, promise. Gambas 2.8.0 was released yesterday. I will not be able to look at it for at least two days. Please post if there is anything I need to know before I start updating the ebuild. I believe slot Qt dependencies are now required, about which I need to read more. Created attachment 163342 [details, diff]
files/gambas-2.8.0-FLAGS.patch
split gambas-2.7.0-r1-libtool-and-FLAGS.patch with changes
Created attachment 163343 [details, diff]
files/gambas-2.8.0-help-path.patch
left help/ in its original location and symlink-ed htmldir in the ebuild
Created attachment 163345 [details, diff]
files/gambas-2.8.0-libtool.patch
split gambas-2.7.0-r1-libtool-and-FLAGS.patch
Created attachment 163347 [details, diff]
files/gambas-2.8.0-sdl-component-name.patch
fixes sdl_sound
Created attachment 163349 [details]
gambas-2.8.0.ebuild
Version bump
- implemented "Reducing eautoreconf"
- enabled configure caching
- slot dependency for Qt
- new patches
- minor improvements
Tested to "install" with libtool 2.2, but I should not have broken compatibility, on amd64 with gcc 4.2.
gambas-2.8.0.ebuild works as gambas-2.8.1.ebuild without any changes. Could the reporter add EBUILD to the keywords since there is a user submitted ebuild here. I am not allowed to change that. (In reply to comment #24) > gambas-2.8.0.ebuild works as gambas-2.8.1.ebuild without any changes. > > Could the reporter add EBUILD to the keywords since there is a user submitted > ebuild here. I am not allowed to change that. > Compiling now. As promised, extremely late and I am a slacker...I know. Ebuild looks fine enough and passes my QA. Will commit afte rI am done compiling (gcc with USE-libffi as well), along with all those patches. Would you be interested in submitting those patches upstream so we don't have to have 10 patches floating around? Anyway, I also need to remove gambas-1*, is everyone confident that gambas-2.8.1 suits their needs? It will be the only one left because I want to remove 2.7.0 as well. (In reply to comment #25) > Compiling now. As promised, extremely late and I am a slacker...I know. Ebuild > looks fine enough and passes my QA. Will commit afte rI am done compiling (gcc > with USE-libffi as well), along with all those patches. Would you be interested > in submitting those patches upstream so we don't have to have 10 patches > floating around? Update: Compiled fine remotely. Just need to verify that it works properly when I get home. I will look for the proper contact and try to submit the non-Gentoo-specific ones upstream. Getting them accepted is something else. Can you modify the ebuild such that I don't get this error? %% gambas2 ERROR: ld.so: object 'libqt-mt.so.3' from LD_PRELOAD cannot be preloaded: ignored. ERROR: #27: Cannot load component 'gb.qt': cannot find library file Should the qt'ness be forced, non-optional? Test case is compiled only with: USE="bzip2 gtk pcre zlib" the rest are disabled. Thanks. Created attachment 163954 [details, diff]
patch attempting to fix new run-time error
I am not exactly sure why this is happening. This code in /var/tmp/portage/dev-util/gambas-2.8.1/work/gambas2-2.8.1/gb.gtk/src
CTreeView.cpp-851-static void init_settings()
CTreeView.cpp-852-{
CTreeView.cpp-853- static bool init = false;
CTreeView.cpp-854-
CTreeView.cpp-855- if (init)
CTreeView.cpp-856- return;
CTreeView.cpp-857-
CTreeView.cpp:858: GB.GetFunction(&_get_settings_func, GB.FindClass("Qt"), "_GetColumnViewSettings", "ColumnView;", "s");
CTreeView.cpp:859: GB.GetFunction(&_set_settings_func, GB.FindClass("Qt"), "_SetColumnViewSettings", "ColumnView;s", "");
CTreeView.cpp-860-
CTreeView.cpp-861- init = true;
CTreeView.cpp-862-}
makes me think the attached patch could prevent this problem. I am not sure, but this may have been introduced since 2.7.0.
I chose not to force QT in the ebuild. I believe gambas can be build as a basic interpreter only, without the GUI IDE, so that it can run programs stand-alone. I do not know if any other distribution does this, but if it is possible, Gentoo should give the user the choice to do it. (In reply to comment #30) > I chose not to force QT in the ebuild. I believe gambas can be build as a > basic interpreter only, without the GUI IDE, so that it can run programs > stand-alone. I do not know if any other distribution does this, but if it is > possible, Gentoo should give the user the choice to do it. > Maybe I am just running it wrong? I will attempt your patch at a later date and provide feedback. thanks. You are right. My patch in comment 29 is not correct. I am working on something different and will obsolete it (the patch) when I have it. If you still have the same build from comment 28, could you try this: %% GB_GUI="gb.gtk" ./gambas2 It still may not work, but you may get a different error message. Thanks. (In reply to comment #32) > If you still have the same build from comment 28, could you try this: > %% GB_GUI="gb.gtk" ./gambas2 > > It still may not work, but you may get a different error message. Thanks. > Same error message actually. Created attachment 164466 [details, diff]
files/gambas-2.8.2-FLAGS.patch
Created attachment 164467 [details, diff]
files/gambas-2.8.2-app-Makefile-install.patch
Created attachment 164469 [details, diff]
files/gambas-2.8.2-comp-Makefile-install.patch
Created attachment 164471 [details, diff]
files/gambas-2.8.2-examples-Makefile-install.patch
Created attachment 164472 [details] gambas-2.8.2.ebuild The IDE will not build properly without qt3. At least that is what I think after reading more code. The new ebuild reflects this. I looked at debian a little and how they package gambas2 for lenny. They have a gambas2-runtime and a gambas2-ide packages. They also separate the help and examples into a gambas2-doc package. That is why I added doc and examples to the USE flags. I may also have to add LINGUAS support in the future, but lets get this working first. If you plan on removing all other versions, should gambas2 be unsloted? There is a gambas3 on the horizon, apparently. How will bug 163724 affect this package? Does pkg_postrm see the USE flags the package was installed with or the current USE flags? I was thinking about what happens during an upgrade with a USE change and how that might affect using use conditionals in pkg_postrm. (In reply to comment #38) > Created an attachment (id=164472) [edit] > gambas-2.8.2.ebuild > > The IDE will not build properly without qt3. At least that is what I think ok. > after reading more code. The new ebuild reflects this. I looked at debian a > little and how they package gambas2 for lenny. They have a gambas2-runtime and > a gambas2-ide packages. They also separate the help and examples into a > gambas2-doc package. That is why I added doc and examples to the USE flags. sounds good. I > may also have to add LINGUAS support in the future, but lets get this working > first. agreed. > > If you plan on removing all other versions, should gambas2 be unsloted? There > is a gambas3 on the horizon, apparently. Well, its not trivial to just un-slot a package. You have to slotmove it so that portage knows about it. If there is a future SLOT=3 then let's keep the existing slot there because it doesn't hurt anything. > > How will bug 163724 affect this package? maybe gambas should depend on virtual/libffi after it is unmasked? not sure yet. > > Does pkg_postrm see the USE flags the package was installed with or the current > USE flags? I was thinking about what happens during an upgrade with a USE > change and how that might affect using use conditionals in pkg_postrm. the ones that it was installed with, they are preserved in environment.bz2 Our patchset is getting huge for this package. I have emailed upstream. Could you look at gambas-2.8.0-help-path.patch, the last "+" line. I do not understand why I have to use "ln -s" instead of "${LN_S}". ${LN_S} just does not work for me; the symlinks are not created. I just got an email that the majority of the patches have been accepted. On the next version bump I will update the ebuild and only the Gentoo-specific patches should remain. Any ideas on why ${LN_S} does not work correctly? (In reply to comment #41) > I just got an email that the majority of the patches have been accepted. On > the next version bump I will update the ebuild and only the Gentoo-specific > patches should remain. Great. > > Any ideas on why ${LN_S} does not work correctly? > No, not really. Problem with the sandbox or something? I do not know if it is the sandbox. It looks like a simple relative symlink to me. So far I suspect that ${LN_S} might be assigned something other than "ln -s", but I do not know how to check. I do not mind updating the patch every time there is a change, but I thought we might want to try to fix this while waiting for the version bump. (In reply to comment #43) > I do not know if it is the sandbox. It looks like a simple relative symlink to > me. So far I suspect that ${LN_S} might be assigned something other than "ln > -s", but I do not know how to check. > > I do not mind updating the patch every time there is a change, but I thought we > might want to try to fix this while waiting for the version bump. > 2.8.2 is in CVS now, should hit your mirrors in an hour or so. Thanks for all your work. Feel free to CC me on future gambas bugs. |