<br><br><div class="gmail_quote">On Sat, Apr 2, 2011 at 1:47 AM, Vincent Cheng <span dir="ltr"><<a href="mailto:vincentc1208@gmail.com">vincentc1208@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Fri, Apr 1, 2011 at 2:42 AM, Gerfried Fuchs <span dir="ltr"><<a href="mailto:rhonda@deb.at" target="_blank">rhonda@deb.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
* Vincent Cheng <<a href="mailto:vincentc1208@gmail.com" target="_blank">vincentc1208@gmail.com</a>> [2011-04-01 03:52:54 CEST]:<br>
<div>> I've taken a closer look at this and I've tried to package the latest dev<br>
> release of Wesnoth (1.9.5). I've been using my own PPA to test it [1], and<br>
> it seems to build and run fine now. I've also attached a patch of my<br>
> changes, if that helps any.<br>
<br>
</div> Sorry, I don't see the need or requirement to switch to cdbs to make it<br>
work properly again. If cdbs is able to make it work, so must debhelper<br>
be able to do it. And actually, such changes definitely should be<br>
documented in debian/changelog, that's actually what it's there for.<br>
<br></blockquote></div><div>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.</div><div class="im">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just a sidenote: Did you check where the files end up after your patch?<br>
Do they appear in the same place as they were before? Including<br>
translations?<br>
<br></blockquote></div><div>Yes; see attached text file for the output of "dpkg -L" on my wesnoth-1.9 packages.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - $(MAKE) -C build DESTDIR=$(CURDIR)/debian/tmp install<div><div></div><div class="h5"><br>
> + $(MAKE) -C build DESTDIR=$(CURDIR) install<br>
<br>
Uh, *really* install into the current directory and not debian/tmp?<br>
That looks pretty much like an error to me, at least it it's totally<br>
counter-intuitive if it would end up in debian/tmp in the end?<br>
<br>
> - cd $(CURDIR)/debian/tmp/usr/share/games/wesnoth/$(BRANCH_VERSION)/data/tools \<br>
> + cd $(CURDIR)/usr/share/games/wesnoth/$(BRANCH_VERSION)/data/tools \<br>
> && chmod +x extractbindings unit_tree/TeamColorizer \<br>
> wesnoth/wescamp.py wesnoth/wmldata.py wesnoth/wmlparser.py \<br>
> wmlindent wmlflip wmllint wmlscope wesnoth_addon_manager \<br>
> @@ -178,10 +177,10 @@<br>
> done<br>
<br>
Sorry, this is totally weird, why did you go that approach?<br>
<br>
> # move binaries to their proper name<br>
> - mv debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth \<br>
> - debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth-$(BRANCH_VERSION)<br>
> - mv debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd \<br>
> - debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd-$(BRANCH_VERSION)<br>
> + #mv debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth \<br>
> + # debian/wesnoth-$(BRANCH_VERSION)-core/usr/games/wesnoth-$(BRANCH_VERSION)<br>
> + #mv debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd \<br>
> + # debian/wesnoth-$(BRANCH_VERSION)-server/usr/games/wesnothd-$(BRANCH_VERSION)<br>
<br>
So it looks you are changing the install structure of the package?<br>
<br>
Your patch seems to completely rewriting the whole thing, actually I<br>
don't really see the benefit or rationale for that, could you elaborate<br>
why this is needed?<br></div></div></blockquote></div><div><br></div><div>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:</div>
<div><br></div><div><br></div><div><div>-- Installing: /build/buildd/wesnoth-1.9-1.9.5/usr/include/ana/predicates.hpp</div><div>-- Installing: /build/buildd/wesnoth-1.9-1.9.5/usr/include/ana/binary_streams.hpp</div><div>
make[1]: Leaving directory `/build/buildd/wesnoth-1.9-1.9.5/build'</div>
<div>cd /build/buildd/wesnoth-1.9-1.9.5/usr/share/games/wesnoth/1.9/data/tools \</div><div class="im"><div><span style="white-space:pre-wrap"> </span>&& chmod +x extractbindings unit_tree/TeamColorizer \</div><div>
<span style="white-space:pre-wrap"> </span>wesnoth/wescamp.py wesnoth/wmldata.py wesnoth/wmlparser.py \</div><div><span style="white-space:pre-wrap"> </span>wmlindent wmlflip wmllint wmlscope wesnoth_addon_manager \</div>
</div><div><span style="white-space:pre-wrap"> </span>wmlvalidator hexometer/hexometer wmlxgettext imgcheck</div><div>dh_install</div><div>cp: cannot stat `debian/tmp/debian/tmp/usr/share/games/wesnoth/1.9/data/advanced_preferences.cfg': No such file or directory</div>
<div>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</div><div>make: *** [debian/stamp-install] Error 2</div>
<div>dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2</div></div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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. :(</div>
<div><br></div><div>- Vincent</div><div><br></div><div>[1] <a href="https://launchpadlibrarian.net/67766051/buildlog_ubuntu-lucid-amd64.wesnoth-1.9_1%3A1.9.5-1.1ppa1~lucid5_FAILEDTOBUILD.txt.gz" target="_blank">https://launchpadlibrarian.net/67766051/buildlog_ubuntu-lucid-amd64.wesnoth-1.9_1%3A1.9.5-1.1ppa1~lucid5_FAILEDTOBUILD.txt.gz</a></div>
<div>(also see attached file)</div>
</blockquote></div><br><div>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]</div>
<div><br></div><div>- Vincent</div><div><br></div><div>[1] <a href="http://dl.dropbox.com/u/7303069/Debian/dpkg-L-wesnoth-1.9.txt">http://dl.dropbox.com/u/7303069/Debian/dpkg-L-wesnoth-1.9.txt</a></div>