Bug#617265: wesnoth-1.9: New version 1.9.4 is out for a long time already. PLEASE update.

Vincent Cheng vincentc1208 at gmail.com
Sat Apr 2 23:22:18 UTC 2011


On Sat, Apr 2, 2011 at 1:47 AM, Vincent Cheng <vincentc1208 at gmail.com>wrote:

>
>
> On Fri, Apr 1, 2011 at 2:42 AM, Gerfried Fuchs <rhonda at deb.at> wrote:
>
>>        Hi!
>>
>> * Vincent Cheng <vincentc1208 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20110402/292ec018/attachment-0001.htm>


More information about the Pkg-games-devel mailing list