Merge lp:~hjd/widelands/new-binary into lp:~widelands-dev/widelands/debian
Status: | Merged |
---|---|
Merged at revision: | 30 |
Proposed branch: | lp:~hjd/widelands/new-binary |
Merge into: | lp:~widelands-dev/widelands/debian |
Diff against target: |
9 lines (+1/-0) 1 file modified
debian/widelands.install (+1/-0) |
To merge this branch: | bzr merge lp:~hjd/widelands/new-binary |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Widelands Developers | Pending | ||
Review via email: mp+282116@code.launchpad.net |
Description of the change
The PPA broke a couple of days back when a new binary was added. Since this wasn't covered among the files used in the packages produced, the packager became confused as to what to do with it. See either of the recent build logs on https:/
I've now added this to the list of files to be installed with the 'widelands' package, along with wl_map_info and wl_render_richtext which we did when they appeared. I don't know whether this is what we want or whether we should simply remove the files because they don't make much sense outside of debug contexts.
Tested with this change in https:/
If someone reviews this, feel free to merge it into the debian-branch as well. I can do it myself, but it might take some time before I can get round to it.
While talking about build failures, I've seen odd failures on Ubuntu with recent clang-versions (3.6 and 3.7). Have any clang-people seen similar things on other platforms. Sorry I don't have logs available at the moment, but I just wanted to check whether someone are able to successfully build Widelands with those versions. If that is the case I may have to investigate the clang packages in Ubuntu/Debian.
The binary is gone again in https:/ /code.launchpad .net/~widelands -dev/widelands/ use_image_ cache. It is hardly worth adding it in right now.
wl_map_info is used on the server, it relies on it being in the PPA. It might also be useful for others, dunno. The other is purely debug, but does it hurt to install it?
hjd, can these debian files not be in trunk? It seems more likely that they do not break if they are in trunk than being added on in the debian branch? We also have maintenance files for windows and mac in trunk, so I see no issue having debian there too.