[00:33] <samd> hi, im in the process of making my first deb package. The software im packing has no version, what version should i put?
[00:38] <arand> samd: What software is it, is it taken from a revision control of some sort?
[00:38] <arand> samd: Normally, one would use the date of the release as a stand-in version
[00:39] <samd> arand: yes, its mjpg-streamer, it was taken from the svn repository because it was the only source i found, if i download the tar.gz package from them, they use "r150" as 'version' where 150 is the last commit
[00:40] <arand> As an example I am using "lugaru-data_0~20110520.1+hge4354-1" for a game from mercurial (hg) with no versioning currently
[00:41] <samd> arand: alright, sounds good, ill use the date
[00:41] <arand> samd: So following that it would be "0~$date.1+svn150-1" or something to that effect
[00:43] <samd> arand: sounds good, thank you very much, ill continue with the packing
[00:43] <samd> arand: im following the guide from https://wiki.ubuntu.com/PackagingGuide/Basic
[00:43] <arand> samd: Alternatively r150, I think that might just be your preference
[00:45] <samd> arand: i tried that , but for some reason dh_make didnt recognized "r150" as a version, i might had it wrote wrong, but i changed the version to 1.0 just to see, and it worked.
[00:46] <arand> dh_make might be a bit more strict there.. you can always change it afterwards in the changelog though
[00:47] <arand> I meant 0~$date.1+r150-1 is also an alternative
[00:47] <samd> arand: alright, , i think i will go and try with  0~$date.1+r150-1
[00:48] <arand> (replacing $date with the date of the commit, just to note)
[00:48] <samd> yeah, something like YYYYMMDD i got that
[00:49] <tumbleweed> no need to include both a date and a commit number. one of the two will suffice
[00:50] <samd> oh ok
[00:50] <arand> I'm not sure but I've had some discussions with debian folks who are of the opinion that the revision number is not relevant at all, I personally think it is though, even in the case of hashes, ah, there we go ^ :)
[00:51] <tumbleweed> 0~YYYYMMDD-1 or 0~svn12-1 (or bzr) are both sensible versions
[00:51] <samd> i see, what does the 0~ mean?
[00:52] <arand> It allows for any kind of 0something to be a higher version than 0~something
[00:52] <tumbleweed> revision number is not a good idea for git (where the number of revisions is variable), but svn, bzr and hg have monotonic revision numbers (within a single tree, in hg and bzr, assuming no rebasing or commit removal)
[00:52] <tumbleweed> 0~ is smaller than 0
[00:53] <samd> i see
[00:53] <arand> So basically, it means that you don't have to worry about upstream releasing a 0.0.0.0.0.1 version, it will always be greater than 0~
[00:54] <samd> got it
[00:55] <samd> let me try to build the package , ill probably throw out more questions as i advance.  thank you!
[00:56]  * tumbleweed is going to bed, enjoy :)
[08:29] <Laney> morning
[08:29] <Laney> (in before dholbach who isn't evne here!)
[08:30] <geser> morning
[08:30] <vish> Laney: he is at Dublin sprint, so … that might be the delay
[08:31] <Laney> vish: I am going to claim this as a victory nonetheless. :-)
[08:31] <vish> :D
[08:33] <nigelb> Laney: got a min for a PM?
[08:34] <Laney> yeah
[16:57] <nigelb> I made a mistake in the spelling of a word in the dep-3 patch tagging guidelines.
[16:57] <nigelb> Do I send a patch to debian or should I just leave it
[16:58] <Laney> the guidelines themselves?
[16:58] <tumbleweed> one presumes debian package maintainers all read the patches they receive and edit if necessary
[16:59] <tumbleweed> also, not much actulaly depends on having valid dep3 headers
[16:59] <Laney> assuming not, I'd just reply to the bug and point it out (if it's not archived)
[17:01] <nigelb> Ok, I'll add a reply to the bug
[17:13] <nigelb> \o/ DD replies back with thanks and he fixed it in git :-)
[17:19] <Laney> sweet