widelands is about to release build 15. this includes a new build system (cmake instead of scons) here is an ebuild that takes advanatage of this new build system Reproducible: Always
Created attachment 226307 [details] widelands ebuild
Created attachment 226315 [details] widelands ebuild widelands ebuild updated
Any locale files should be installed in /usr/share/locale
Created attachment 226573 [details] widelands ebuild widelands ebuild. now it installs locales properly also added language use flags based on available locales
I would like to just add a single note about the ebuild: you should not hardcode the '-rc2' part but instead take it from ${PV} and change the separator using versionator.eclass.
Created attachment 226873 [details] widelands ebuild update widelands ebuild. rc2 is no longer hardcoded I didn't use the versionator eclass (yet) because there are some differences how widelands and gentoo gives version numbers (build15-rc2 vs 0.0.15-rc2). will try to find more documentation later if the versionator ebuild is required
WARNING: Could not open pics/splash.jpg: [/var/tmp/portage/games-strategy/widelands-0.0.15_rc2/work/widelands-build15-rc2-src/src/graphic/graphic.cc:72] Failed loading libjpeg.so.7 I think on systems where the update guide to jpeg-8 was followed this ebuild wont work
Created attachment 227653 [details, diff] diff between ebuilds As for comment 7: it seems you didn't follow the guide correctly. I came up with a far smaller patch (diff between build14 and my ebuild). Minor note: it seems as if dev-libs/boost should be in DEPEND only, as though a few CMakeLists.txt claim otherwise, widelands is using only boost headers, not the libs. Though, that locale filter looks useful.
Created attachment 227659 [details, diff] new gentoo build patch Just the obvious modifications, so it works with cmake-utils eclass.
That boost line is due to the macro shipped with cmake 2.8.1 only supporting boost up to 1.41.0.
However, that boost problem is fixed for the moment in cmake-2.8.1-r1.
#7: did you run recdep-rebuild? libjpeg 8 is working here #8/9 i'll test out your changes but for one widelans is no longer hosted at sourceforge so i'm curious which version you are actually getting
I don't have any problems building this against libjpeg-8. It should, however, also be able to build against libjpeg-7 if someone did not update to libjpeg-8 yet. About the Boost issue: Yes, only Boost headers are used, no libraries. The two includes in the CMakeLists.txt files are: just an empty include and a useless include which is not used by any sources. Widelands is not hosted on sourceforge.net anymore, however the homepage has not changed: http://www.widelands.org. Codehosting is now done on Launchpad: https://launchpad.net/widelands
(In reply to comment #13) > I don't have any problems building this against libjpeg-8. > It should, however, also be able to build against libjpeg-7 if someone did not > update to libjpeg-8 yet. > > About the Boost issue: Yes, only Boost headers are used, no libraries. The two > includes in the CMakeLists.txt files are: just an empty include and a useless > include which is not used by any sources. > > Widelands is not hosted on sourceforge.net anymore, however the homepage has > not changed: http://www.widelands.org. Codehosting is now done on Launchpad: > https://launchpad.net/widelands > There was an update guide in jpeg-8 ebuild to delete libjpeg.so.7 and run revdep-rebuild to use libjpeg.so.8 now. On my other gentoo system where have not done this widelands runs fine but only because libjpeg.so.7 is already there. Look here at the 2nd post. http://wl.widelands.org/forum/topic/378/
(In reply to comment #14) #14, noone is arguing that you don't have the issue. or that others don't have the issue. but the problem isn't in widelands itself or the ebuild i proposed. if you look at the output of 'ldd widelands|grep jpeg' if it lists libjpeg.so.7 => not found rebuild widelands. if it isn't listed there then make sure to rebuild the sdl libraries it depends on Rafal, your diff is smaller but mine only installs the locales you want. it's something that probally will be fixed upstream soon but not before build15. i'd be happy to keep my ebuild updated if people are interested in it. if not just let me know too
@comment 14: revdep-rebuild catches most of the common problems, however, it can't do a thing about dlopen'ed libs. Till the recent ebuild revision most of the sdl packages did that (libsdl, sdl-gfx, sdl-ttf, etc.). You needed to remember to reemerge them manually. @comment 15: I think what should matter most is which one is less hackish, as hack obvious for the author at the time of writing, becomes far less obvious with time and leads to maintenance hell eventually. On a semi-related note CPPFLAGS!=CXXFLAGS.
On a different note: it seems that one of the people on CC list may be one of widelands devs. Let me comment on http://wl.widelands.org/forum/topic/391/ (among other). Those symlink "solutions" are rather unsafe - those jpeg versions *are* binary incompatible. I don't recall the numbers, but in Gentoo bugzilla at the time of jpeg7 -> 8 (or was that 6.2 -> 7 ?) transition, there were a few bugs that came from compiling against headers of one version and linking against a different one. Those were actually errors in the build system of those packages, but the point is that even if it seems to work, it may fail at any time in rather strange ways.
OK, it's been officially released three days ago. No build related changes since the tarball I tested my ebuild with, so it should still work.
I asked the games herd in IRC about commiting the updated ebuild to the main tree and ssuominen made the following suggestions for improving the ebuild: - don't hardcode paths as done in src_configure, use vars from games eclass instead (inherit games eclass) - if RDEPEND is same as DEPEND, you only need to define DEPEND which will be both then - the inherited toolchain-funcs seem to be unused (no $(tc-getCXX)s)
Created attachment 229451 [details, diff] new diff OK, this is the new diff. Though I'm almost sure boost should not be among RDEPEND, just in DEPEND.
Created attachment 231591 [details] Reworked ebuild
Created attachment 232045 [details, diff] widelands-0.0.15-gcc45-fix.patch There patch for gcc-4.5. https://bugs.launchpad.net/widelands/+bug/572383
(In reply to comment #21) > Created an attachment (id=231591) [details] > Reworked ebuild > Hmm, why do you introduce a new version scheme with your ebuild? I mean, why is it "widelands-0-15.ebuild" instead of "widelands-0-0-15.ebuild" and in the ebuild itself MY_PV=build$(get_version_component_range 2) instead of MY_PV=build$(get_version_component_range 3) Furthermore I found that the "build" patch can no longer be applied. Simply because the targeted files no longer exist. But I think the "gcc45" patch should still be applied. After removing the two extra " || die" you have added to your ebuild (why?) I finally get to the following ebuild which I will attach in a separate post. Almost forgot to mention that ./files/widelands-0.0.15-gcc45.patch is an exact copy of ./files/widelands-0.0.14-gcc45.patch and that this ebuild actually worked on my x86 box.
Created attachment 234331 [details] An ebuild for build15 that actually woked for me
Created attachment 234333 [details, diff] The same as unified diff to previous (build14) ebuild
(In reply to comment #23) > Hmm, why do you introduce a new version scheme with your ebuild? Because that's new upstream versioning scheme. You can find it in CMakeLists file. > Furthermore I found that the "build" patch can no longer be applied. > Simply because the targeted files no longer exist. Can't happen. And I guess it's quite improbable upstream changed the tarball in the meantime. Did you change the patch name to match new version? > After removing the two extra " || die" you have added to your ebuild (why?) Because '|| die' after do*/new* commands is necessary. Removing them only means that you omit catching the error which happens. Thus, I guess your problem might be uncorrectly unpacked sources. And before criticizing somebody's work, take a look _at least_ at devmanual.
(In reply to comment #26) ... > Thus, I guess your problem might be uncorrectly unpacked sources. And before > criticizing somebody's work, take a look _at least_ at devmanual. I was just asking questions and stated that your ebuild did not work for me with current build15 from upstream. The "build" patch targets the file ./build/scons-tools/scons_configure.py which used to exist in build14 but no longer does in build15. The entire "scons-tools" folder has been removed. But the only way to figure out whether I wasn't able to run your ebuild properly or upstream actually changed something (so that the "build" patch no longer applies) is to actually try it out yourself.
(In reply to comment #27) > The "build" patch targets the file > > ./build/scons-tools/scons_configure.py > > which used to exist in build14 but no longer does in build15. > The entire "scons-tools" folder has been removed. Take a look at files attached to this bug. There's a fresh build patch there. This one: http://bugs.gentoo.org/attachment.cgi?id=227659 I'll also attach a little newer ebuild, with some minor changes requested by games herd.
Created attachment 234339 [details] A little newer version of my ebuild This one has more strict dependencies and inheritance order requested by games team.
(In reply to comment #28) > Take a look at files attached to this bug. There's a fresh build patch there. > This one: > http://bugs.gentoo.org/attachment.cgi?id=227659 Attached to which bug?
(In reply to comment #26) ... > Because '|| die' after do*/new* commands is necessary. Removing them only means > that you omit catching the error which happens. ... > Thus, I guess your problem might be uncorrectly unpacked sources. And before > criticizing somebody's work, take a look _at least_ at devmanual. http://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html you mean? Well, to me it seems -- just by looking at the example -- that catching the error in case of a failing "do*" is more a matter of taste than something something "devmanual" requires you to do. ... and I admit, I haven't looked it up, before posting my comment on your ebuild. :-) Anyway, I just hope we have a working ebuild in portage soon. And it will surely we done "by the book" ( of "devmanual", "herd", ...) :-)
(In reply to comment #30) > (In reply to comment #28) > > > Take a look at files attached to this bug. There's a fresh build patch there. > > This one: > > http://bugs.gentoo.org/attachment.cgi?id=227659 > > Attached to which bug? > Sorry, found it in comment #9. (http://bugs.gentoo.org/show_bug.cgi?id=312847#c9)
Is there a working ebuild somewhere yet? I read through this thread with all of its ideas and several ebuild posts but there's neither an ebuild for .15 in portage nor in gamerlay. Anyway thanks for your work!!
It's in gamerlay now, as of f1e110b.
fails for me like: sk: ..........Traceback (most recent call last): File "/var/tmp/portage/games-strategy/widelands-0.15/work/widelands-build15-src/utils/buildlocale.py", line 78, in <module> do_compile(l) File "/var/tmp/portage/games-strategy/widelands-0.15/work/widelands-build15-src/utils/buildlocale.py", line 37, in do_compile if not buildcat.do_buildpo(po, pot, "tmp.po"): File "/var/tmp/portage/games-strategy/widelands-0.15/work/widelands-build15-src/utils/buildcat.py", line 270, in do_buildpo raise RuntimeError("msgmerge exited with errorcode %i!" % rv) RuntimeError: msgmerge exited with errorcode 8! make[2]: *** [CMakeFiles/lang] Error 1 make[1]: *** [CMakeFiles/lang.dir/all] Error 2 make: *** [all] Error 2
Hmmm, seems like it's parallel make related.
widelands-0.15.ebuild is in portage. thanks for the bug report and ebuild/patch submissions.
