REVDETECT=BROKEN-PLEASE-REPORT-THIS(Release) in PPA builds

Where did you download this, and which version is this (supposed to be)?

Usually this message comes by building from a source-distribution which does not have bzr information but also not manually specified version information... (or something is really broken... but we didn't have this broken a long time =:-D )

also, can you try running utils/detect_revision.py from the top level directory. If it gives the same output could you try some print debugging in the script to figure out why the bzr version is not working properly?

HI,

I downloaded this from the following site:

https://launchpad.net/~widelands-dev/+archive/widelands-daily

Maybe the revision-detection does not work well with the auto-merging of the translations during the build (which would be strange, though). I will check the PPA sometime today.

From the build log at https://launchpadlibrarian.net/145792621/buildlog_ubuntu-saucy-amd64.widelands_1%3A17-ppa0-bzr6665-201307241913~saucy1_UPLOADING.txt.gz

-- Version of Widelands Build is REVDETECT-BROKEN-PLEASE-REPORT-THIS(Release)

https://launchpadlibrarian.net/145793540/buildlog_ubuntu-precise-amd64.widelands_1%3A17-ppa0-bzr6665-201307241914~precise1_UPLOADING.txt.gz

-- Version of Widelands Build is REVDETECT-BROKEN-PLEASE-REPORT-THIS(Release)

... me thinks this is something more serious.

ah yes... found it.

detect_revision.py has a special handling for the debian build stuff... and it searches with regex stuff for +trunk+ ;-)

This is done because the debian/control file does not list python-bzrlib as build dependency...

question is: who uses lp:~widelands-dev/widelands/debian - could we simply update that control file or do we cause trouble with that?

If we can update that, we can get rid of the debian stuff in detect_revision.py

Ok, 2 things to mention.

1. The ppa build uses the debian/changelog file which contains the version from the recipe - it contained the pattern "bzr[0-9]+\+.+\+" - and then it created the version information out of that by using the matched string and replacing the + by [ and ] - which made a version name of bzr6666[trunk]
This now fails, because the pattern does not match.

2. We can not use automatic revision detection because the build now merges translations into trunk and creates an additional revision which would be incorrect to report as version.

Therefor, my suggestion:
We keep the debian specific build stuff in detect_revision.py, and change the pattern for the recipe slightly: from "bzr{revno}-{time}" to "bzr{revno}+{time}+" - leading to a version of bzr6666[20130725154525] in the ppa.

> and it searches with regex stuff for +trunk+

Oh, so that's why it was added. Ops...

> who uses lp:~widelands-dev/widelands/debian - could we simply update that
>control file or do we cause trouble with that?

Well, I don't think it is used all that much, except for the PPA. I don't know how to assess the usage, unless someone speaks up. However, we should probably keep any changes to a minimum in order to make it easier to sync latest version of the packaging from Debian [1]. (Speaking of which, has anyone done that in a while? They have released a couple of updates to build17, so it is bound to have changed a bit).

Regarding your suggestion, that would still append Release/Debug at the end right? Other than that, looks good.

[1]http://anonscm.debian.org/gitweb/?p=pkg-games/widelands.git

As far as I understand, the (Release) part is added independently. The changes (which I did, by the way) should only be about the REVDETECT=BROKEN-PLEASE-REPORT-THIS part.

Let's see how this turns out with the next autobuild...

I think the +{time}+ was not a good idea, we might have broken the PPA this way :-D

I changed it back to -{time} and adjusted the regex in detect_revision.py.
I think nobody else will use this. Debian packagers will use a released build which has a VERSION file and does not fall back to the debian detection part...

PPA version is now something like:

-- Version of Widelands Build is bzr6669-201307261103(Release)

I consider this fixed.

Released in build-18 rc1.