[08:32] <pmjdebru1jn> hi folks
[08:33] <pmjdebru1jn> I'm getting some builds failure on my PPA, which I can't reproduce locally:
[08:33] <pmjdebru1jn> https://launchpadlibrarian.net/145214967/buildlog_ubuntu-precise-amd64.stockfish_3.0.0%2Bgit20130508-2pmjdebruijn1~precise_FAILEDTOBUILD.txt.gz
[08:33] <pmjdebru1jn> it's basically a backported package, with no real changes... so this probably builds fine on the Debian build farm as well
[13:17] <dobey> pmjdebru1jn: is the part where it fails, trying to connect to external network sites?
[13:17] <pmjdebru1jn> I don't think so
[13:18] <pmjdebru1jn> at least I have no reason to think that
[13:18] <pmjdebru1jn> I'd have to take a closer look locally of course
[13:18] <pmjdebru1jn> from what I can tell
[13:18] <pmjdebru1jn> it's an optimization step
[13:18] <pmjdebru1jn> where code is executed and benchmarked
[13:18] <pmjdebru1jn> to determine compiler options
[13:18] <pmjdebru1jn> (which I guess may not be the best idea for package build anyhow)
[13:19] <dobey> well, whatever it is doing, is hanging
[13:26] <pmjdebru1jn> so it's killed for inactivity?
[13:27] <dobey> yes
[13:28] <pmjdebru1jn> I'll have a closer look then
[13:28] <pmjdebru1jn> thanks
[13:33] <saiarcot895> I need some help on versioning
[13:34] <saiarcot895> Upstream has development versions on odd-numbered versions and stable versions on even-numbered versions
[13:34] <pmjdebru1jn> can you give concrete examples
[13:34] <saiarcot895> Flightgear/Simgear/fgfs-base
[13:34] <pmjdebru1jn> I mean with version numbers
[13:35] <pmjdebru1jn> and why would odd/even versioning be a problem for you?
[13:35] <saiarcot895> 2.11 is development version, and 2.12 is stable (well, to be released, version)
[13:35] <pmjdebru1jn> (typically that's type convenient)
[13:35] <saiarcot895> it's not the odd/even thing
[13:35] <pmjdebru1jn> ok, what's the issue then:)
[13:35] <pmjdebru1jn> s/type/quite/
[13:35] <pmjdebru1jn> :)
[13:36] <saiarcot895> when a stable version is about to be released, they branch off from the trunk, create the 2.12 branch, and update the versioning in the application itself to be 2.12, but it's a prerelease
[13:36] <saiarcot895> sort of like beta or rc
[13:36] <saiarcot895> there aren't official idenitifiers except for the git revision
[13:36] <dobey> that's a process problem, not a version problem exactly
[13:37] <dobey> but hopefully they also bump the trunk version at the same time
[13:37] <saiarcot895> trunk gets bumped up to next development version
[13:38] <pmjdebru1jn> well
[13:38] <pmjdebru1jn> you can use ~
[13:38] <dobey> so what's the problem?
[13:38] <saiarcot895> my idea was to use something like 2.12.0~<time>+git<version>
[13:38] <pmjdebru1jn> 2.12~rc is lower than 2.12
[13:38] <pmjdebru1jn> I wouldn't use time
[13:38] <dobey> yes, use 2.12~git$TIMESTAMP
[13:38] <pmjdebru1jn> commit count is often use
[13:39] <pmjdebru1jn> so you'd get something like 1:1.1.4+302~ge92f160
[13:39] <dobey> git doesn't have "commit counts" really. it has incomprehensible hashes, which are not constantly increasing
[13:39] <pmjdebru1jn> since the git sha isn't sequential
[13:39] <pmjdebru1jn> dobey: it has
[13:39] <pmjdebru1jn> or at least you can "get" them
[13:39] <saiarcot895> from the log
[13:39] <pmjdebru1jn> so that version is 302 commits past the last tag
[13:40] <pmjdebru1jn> with the last commit checksum starting with e92f160
[13:40] <pmjdebru1jn> with the g indicating a git version
[13:40] <dobey> i wouldn't use the hash at all
[13:40] <pmjdebru1jn> the problem with time is that it's ambiguous
[13:41] <dobey> time isn't ambiguous
[13:41] <pmjdebru1jn> commit count + hash specify a very point in the repository
[13:41] <dobey> time of commit in GMT is unique
[13:41] <saiarcot895> but if it's yyyymmddhhmm, then it's constantly increasing
[13:41] <pmjdebru1jn> dobey: I mean how time related to commits
[13:41] <pmjdebru1jn> relates
[13:41] <dobey> pmjdebru1jn: there are no two commits at the exact same time
[13:41] <saiarcot895> true, but I was just planning on using my time zone
[13:42] <pmjdebru1jn> dobey: yes, but you'd have to manually match to time to the last commit
[13:42] <saiarcot895> but then you have the git hash, so you can get the commit
[13:42] <dobey> and time is unique enough anyway
[13:42] <pmjdebru1jn> having the hash in the version can be very convenient at times
[13:42] <dobey> it's better to put it in the changelog if you want to put it somewhere
[13:43] <dobey> because it isn't sequential
[13:43] <dobey> not being sequential means it can break the versions tring
[13:43] <pmjdebru1jn> which is why it's prefixed by the commit count, which ensures sequentiality
[13:43] <pmjdebru1jn> 1.1.4+302~ge92f160 do mind the +302
[13:43] <saiarcot895> speaking of which, how do you get the commit count?
[13:43] <saiarcot895> it's not in the log
[13:43] <pmjdebru1jn> in saiarcot895 case that would be 2.12~302~g.....
[13:44] <pmjdebru1jn> saiarcot895: I have it in a script at home, so I can't look it up ATM :(
[13:44] <dobey> import to bzr, and bzr revno
[13:44] <pmjdebru1jn> heh
[13:44] <pmjdebru1jn> I'm fairly sure git can do the directly
[13:44] <pmjdebru1jn> saiarcot895: try git describe, see what that says
[13:45] <dobey> "git rev-list HEAD --count" apparently
[13:45] <dobey> but i don't think there's a variable in launchpad recipes that gives you that
[13:46] <dobey> saiarcot895: are you talking about recipes? or are you asking about making a tarball and doing a manual upload?
[13:46] <saiarcot895> interesting; git describe gives me version/2.11.0-226-gc2f8997
[13:46] <saiarcot895> tarball and manual upload
[13:46] <dobey> well you definitely don't want multiple "-" characters in the version
[13:47] <saiarcot895> at any rate, I can't use that version because it's definitely not 2.11
[13:49] <saiarcot895> also, 2.12 is about to be released, and there's an beta/rc branch
[13:49] <saiarcot895> if I use +, won't that rank above the official 2.12 when it's released
[13:52] <saiarcot895> pmjdebru1jn: if I use +, won't that rank above the official 2.12 when it's released?
[13:53] <dobey> if it's 2.12+ something, it will, unless official release is 2.12.0, then 2.12.0 should be higher than 2.12+; but that's why you should use 2.12~foo-0ubuntu1~ppa1~serices1
[13:55] <saiarcot895> dobey: well, upstream is considering it as 2.12.0, but I suppose I could just call it 2.12
[13:55] <saiarcot895> and call the official version 2.12.0
[13:55] <dobey> saiarcot895: what matters is what the official version actually is. if a tarball is foo-2.12.0.tar.gz you don't package it as foo-2.12; they aren't the same thing
[13:57] <saiarcot895> dobey: the official version will be 2.12.0; the development/rc versions don't have official tarballs, but their version files say 2.12.0
[13:58] <dobey> saiarcot895: then you should make tarballs that are 2.12.0~revcount+git$hash.tar.gz or whatever, and version the packages as 2.12.0~revcount+git$hash-0ubuntu1~ppa1~series1 or similar
[13:58] <dobey> or 2.12.0~rcN.tar.gz if it's a specific rc release maybe.
[13:59] <dobey> and add the ~revcount+git$hash after the ~rcN
[14:00] <saiarcot895> dobey: ok, will do that
[15:03] <saiarcot895> Frozen builds: https://launchpad.net/~mir-team/+archive/staging/+build/4803107 and https://launchpad.net/~mir-team/+archive/staging/+build/4804460