On Sat, Apr 2, 2011 at 1:47 AM, Vincent Cheng <vincentc1...@gmail.com>wrote:
> > > On Fri, Apr 1, 2011 at 2:42 AM, Gerfried Fuchs <rho...@deb.at> wrote: > >> Hi! >> >> * Vincent Cheng <vincentc1...@gmail.com> [2011-04-01 03:52:54 CEST]: >> > I've taken a closer look at this and I've tried to package the latest >> dev >> > release of Wesnoth (1.9.5). I've been using my own PPA to test it [1], >> and >> > it seems to build and run fine now. I've also attached a patch of my >> > changes, if that helps any. >> >> Sorry, I don't see the need or requirement to switch to cdbs to make it >> work properly again. If cdbs is able to make it work, so must debhelper >> be able to do it. And actually, such changes definitely should be >> documented in debian/changelog, that's actually what it's there for. >> >> I admit I don't really understand how cdbs works myself, so I ended up > going back to debhelper and building off of your debian/rules instead of > trying to write one from scratch. > > >> Just a sidenote: Did you check where the files end up after your patch? >> Do they appear in the same place as they were before? Including >> translations? >> >> Yes; see attached text file for the output of "dpkg -L" on my wesnoth-1.9 > packages. > > >> > - $(MAKE) -C build DESTDIR=$(CURDIR)/debian/tmp install >> >> > + $(MAKE) -C build DESTDIR=$(CURDIR) install >> >> Uh, *really* install into the current directory and not debian/tmp? >> That looks pretty much like an error to me, at least it it's totally >> counter-intuitive if it would end up in debian/tmp in the end? >> >> > - cd >> $(CURDIR)/debian/tmp/usr/share/games/wesnoth/$(BRANCH_VERSION)/data/tools \ >> > + cd $(CURDIR)/usr/share/games/wesnoth/$(BRANCH_VERSION)/data/tools >> \ >> > && chmod +x extractbindings unit_tree/TeamColorizer \ >> > wesnoth/wescamp.py wesnoth/wmldata.py wesnoth/wmlparser.py >> \ >> > wmlindent wmlflip wmllint wmlscope wesnoth_addon_manager \ >> > @@ -178,10 +177,10 @@ >> > done >> >> Sorry, this is totally weird, why did you go that approach? >> >> > # move binaries to their proper name >> > - mv debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth \ >> > - >> debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth-$(BRANCH_VERSION) >> > - mv debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd \ >> > - >> debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd-$(BRANCH_VERSION) >> > + #mv debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth \ >> > + # >> debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth-$(BRANCH_VERSION) >> > + #mv debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd \ >> > + # >> debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd-$(BRANCH_VERSION) >> >> So it looks you are changing the install structure of the package? >> >> Your patch seems to completely rewriting the whole thing, actually I >> don't really see the benefit or rationale for that, could you elaborate >> why this is needed? >> > > Actually, I'm not entirely sure why my patches are even necessary to get > Wesnoth to build (sorry, I'm still relatively new to Debian packaging). I > changed the install structure after taking a look at Launchpad's build log > after one of my earlier failed builds [1]. Here's a snippet: > > > -- Installing: > /build/buildd/wesnoth-1.9-1.9.5/usr/include/ana/predicates.hpp > -- Installing: > /build/buildd/wesnoth-1.9-1.9.5/usr/include/ana/binary_streams.hpp > make[1]: Leaving directory `/build/buildd/wesnoth-1.9-1.9.5/build' > cd /build/buildd/wesnoth-1.9-1.9.5/usr/share/games/wesnoth/1.9/data/tools \ > && chmod +x extractbindings unit_tree/TeamColorizer \ > wesnoth/wescamp.py wesnoth/wmldata.py wesnoth/wmlparser.py \ > wmlindent wmlflip wmllint wmlscope wesnoth_addon_manager \ > wmlvalidator hexometer/hexometer wmlxgettext imgcheck > dh_install > cp: cannot stat > `debian/tmp/debian/tmp/usr/share/games/wesnoth/1.9/data/advanced_preferences.cfg': > No such file or directory > dh_install: cp -a > debian/tmp/debian/tmp/usr/share/games/wesnoth/1.9/data/advanced_preferences.cfg > debian/wesnoth-1.9-data//usr/share/games/wesnoth/1.9/data/ returned exit > code 1 > make: *** [debian/stamp-install] Error 2 > dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave > error exit status 2 > > > dh_install tried to copy a file from debian/tmp/debian/tmp/..., which is > why I changed Wesnoth's install structure the way I did. I'm not sure if > this was the right thing to do, but it did finally lead to a successful > build in the end. > > Unfortunately, I just tried building Wesnoth 1.9 with pbuilder on my laptop > (running Debian testing) with the exact same debian/ structure from my > successful Launchpad build, and it doesn't even get to the point of building > itself. > > make[3]: *** No rule to make target > `../usr/share/games/wesnoth/1.9/locale/zh_TW/LC_MESSAGES/wesnoth-manual.mo', > needed by `po/CMakeFiles/mo-update'. Stop. > > I have no clue why it builds successfully in Launchpad, in Lucid, Maverick, > and Natty chroots, yet it fails unexpectedly when I try to build it myself > in Debian. After getting it right on Launchpad after 9 failed build > attempts, it fails on my laptop. This sure is frustrating. :( > > - Vincent > > [1] > https://launchpadlibrarian.net/67766051/buildlog_ubuntu-lucid-amd64.wesnoth-1.9_1%3A1.9.5-1.1ppa1~lucid5_FAILEDTOBUILD.txt.gz > (also see attached file) > I've just noticed that the Debian BTS doesn't seem to have received my previous message, so I'm resending this. Perhaps the log I attached was too big for the BTS to handle (1.2 MB in size), so I've uploaded it online and provided a link to it instead. [1] - Vincent [1] http://dl.dropbox.com/u/7303069/Debian/dpkg-L-wesnoth-1.9.txt