Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 12:44:47PM +0100, Tony Houghton wrote: On Thu, 16 Sep 2010 19:00:27 +1000 Matthew Palmer mpal...@debian.org wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. Did you miss the number of commits after it bit? I think that makes it ideal provided each release is tagged with its version number. Because tags aren't globally unique. Since you yourself said that tags weren't suitable, in and of themselves, when I proposed it, I can't imagine how a tag plus a commit count is of any use. The addition of a hash doesn't help, for the non-sortable reason I gave. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917082317.ge3...@hezmatt.org
Re: Doubts in Sigar packaging
On Fri, Sep 17, 2010 at 06:23:17PM +1000, Matthew Palmer wrote: On Thu, Sep 16, 2010 at 12:44:47PM +0100, Tony Houghton wrote: Did you miss the number of commits after it bit? I think that makes it ideal provided each release is tagged with its version number. Because tags aren't globally unique. Since you yourself said that tags weren't suitable, in and of themselves, when I proposed it, I can't imagine how a tag plus a commit count is of any use. The addition of a hash doesn't help, for the non-sortable reason I gave. Tags are unique in all even marginally sane projects. They may at most be limited to a certain group of people -- usually, upstream won't have your tags but you will have theirs. The reasons new tags are unsuitable are: * upstream or people pulling from upstream won't have them, so the tags would be meaningless * he is looking for versioning that works in an automated way. There's no reason to add tags that have no other use than attaching them to a single build. In general, tag means release, the --describe thing is there to help with versioning between releases. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917124421.ga27...@angband.pl
Re: Doubts in Sigar packaging
On Fri, 17 Sep 2010 18:23:17 +1000 Matthew Palmer mpal...@debian.org wrote: On Thu, Sep 16, 2010 at 12:44:47PM +0100, Tony Houghton wrote: On Thu, 16 Sep 2010 19:00:27 +1000 Matthew Palmer mpal...@debian.org wrote: git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. Did you miss the number of commits after it bit? I think that makes it ideal provided each release is tagged with its version number. Because tags aren't globally unique. Since you yourself said that tags weren't suitable, in and of themselves, when I proposed it, I can't imagine how a tag plus a commit count is of any use. The addition of a hash doesn't help, for the non-sortable reason I gave. I think you've got me confused with Adam Borowski. If multiple branches are involved you'd probably have to incorporate the branch name in the version string, and then the main problem is a bloated version string... If upstream aren't using tags that are or can be mangled to be sortable and representative of some sort of release versioning then, yes, you've got difficulties, but if they are, that plus number of commits gives you a sortable and meaningful version string, and the hash makes sure you can go straight to the correct commit. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917135035.6adcc...@toddler
Re: Doubts in Sigar packaging
* Tony Houghton h...@realh.co.uk schrieb: If upstream aren't using tags that are or can be mangled to be sortable and representative of some sort of release versioning then, yes, you've got difficulties, but if they are, that plus number of commits gives you a sortable and meaningful version string, and the hash makes sure you can go straight to the correct commit. Maybe OSS-QM can help ;-) http://www.metux.de/download/oss-qm/normalized_repository.pdf http://sourceforge.net/p/oss-qm/home/ cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100918054406.ga15...@nibiru.local
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. You can't compare unversioned branches to other branches anyway. If you move from one branch to another, you need to label that manually. Git's scheme provides enough versioning to handle anything that can be done in automated way. Indeed, packaging multiple branches stemming from the same tag may give versions that are not sufficiently sortable, but there's no way to tell which branch is the lesser and which is the greater one without human intervention. The hash prefix is there just to catch cases where you have some unofficial or cherry-picked patches, or the branch is not exactly what the reader expects. Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. This would be bad, as your tags won't say anything about the version you package. Without a mapping between your tags and particular commits, there's no way to tell what upstream source you refer to. If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. git --describe doesn't have that pesky requirement. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916075943.ga16...@angband.pl
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 09:59:43AM +0200, Adam Borowski wrote: On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. You can't compare unversioned branches to other branches anyway. If you move from one branch to another, you need to label that manually. Git's scheme provides enough versioning to handle anything that can be done in automated way. Indeed, packaging multiple branches stemming from the same tag may give versions that are not sufficiently sortable, but there's no way to tell which branch is the lesser and which is the greater one without human intervention. So what does this have to do with producing a suffix to put on an upstream version for a Debian package? Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. This would be bad, as your tags won't say anything about the version you package. Without a mapping between your tags and particular commits, there's no way to tell what upstream source you refer to. Can't you tell git to retrieve a tag (and all commits therefrom) from a remote repository? If not, what *is* the point of a git tag? If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. git --describe doesn't have that pesky requirement. git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916090027.ga4...@hezmatt.org
Re: Doubts in Sigar packaging
On Thu, 16 Sep 2010 19:00:27 +1000 Matthew Palmer mpal...@debian.org wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. Did you miss the number of commits after it bit? I think that makes it ideal provided each release is tagged with its version number. -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916124447.6a26f...@realh.co.uk
Re: Doubts in Sigar packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010-09-14 18:51, Thiago Franco de Moraes wrote: Hi all, Hi [...] * This library contains a bunch if bindings, one of them is java. These java bindings is compiled using ant. The compilations generates a bunch of .class and .jar files, and there isn't a make install. What is the best way to put those files in the right directories? To use the cp or mv command? And the right directories I think [4] is this /usr/share/java/libsigar-1.7 ? Personally I would recommend using jh_installlibs from javahelper. Thanks to all! PS. We need some help in translations [5] too. [1] - http://support.hyperic.com/display/SIGAR/Home [2] - http://svn.softwarepublico.gov.br/trac/invesalius [3] - http://github.com/hyperic/sigar [4] - http://www.debian.org/doc/packaging-manuals/java-policy/x104.html [5] - http://www.transifex.net/projects/p/invesalius/ By the way, you are very welcome to ask on debian-j...@l.d.o if you have questions on how to handle java related packaging. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkyQdZAACgkQVCqoiq1Ylqwh2wCeKVRA3ZdTeT23AXi1wl11WUpk gUMAn3+yvdJkhCzuxPcnEd1Fp95ctqtS =lyJQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c907590.1030...@thykier.net
Re: Doubts in Sigar packaging
On Wed, 15 Sep 2010 08:21:29 +1000 Matthew Palmer mpal...@debian.org wrote: On Tue, Sep 14, 2010 at 01:51:22PM -0300, Thiago Franco de Moraes wrote: * The Source is in git [3]. I'm not using the last stable version because I wasn't able to compile it. What's the policy to version packages from git? I'm using this way: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d after git is the commit version I'm using. Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. What you need to do is select a monotonically increasing number to work from. I think the most common option is to just take the date of the last commit in the repo and use that, so something like sigar-1.7.0~git20100915. Assuming that you don't want to package two versions from the same day, that should work just fine. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` It can be done in one line with nested $() but I prefer shorter more readable lines. And you can get rid of the %H%M%S if you're not going to do it more than once a day. [1] I wanted to use bzr for this very reason, but SourceForge's version is very old and I couldn't push to it with the version in Debian unstable. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915133139.7a9d7...@toddler
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915131820.ga31...@angband.pl
Re: Doubts in Sigar packaging
On Wed, 15 Sep 2010 15:18:20 +0200 Adam Borowski kilob...@angband.pl wrote: On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) Thanks, that looks useful. Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. Don't upstream version numbers have to be without hyphens so that Debian can easily distinguish the Debian revision from the upstream? Or is it OK, because it takes anything after the last hyphen to be the Debian revision? To make it absolutely clear that the release is newer than any pre-release snapshots I reserve *.0 version numbers for pre-release snapshots and use *.1 for release, so in your example I'd have 0.8.0* for snapshots and then 0.8.1 for release. Then I would use 0.8.1-* until releasing 0.8.2, then 0.9.0* for testing a major new feature to be released in 0.9.1. -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915151222.470d8...@realh.co.uk
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:12:22PM +0100, Tony Houghton wrote: Adam Borowski kilob...@angband.pl wrote: Why won't you just use `git --describe`? [...] Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. Don't upstream version numbers have to be without hyphens so that Debian can easily distinguish the Debian revision from the upstream? Or is it OK, because it takes anything after the last hyphen to be the Debian revision? The latter, Debian revision can not contain hyphens, but the upstream one is allowed to (Policy 5.6.12). To make it absolutely clear that the release is newer than any pre-release snapshots I reserve *.0 version numbers for pre-release snapshots and use *.1 for release, so in your example I'd have 0.8.0* for snapshots and then 0.8.1 for release. Then I would use 0.8.1-* until releasing 0.8.2, then 0.9.0* for testing a major new feature to be released in 0.9.1. Then it's a bit nicer for you -- you don't need to bother with tildes. Most upstreams use versions like 1.0pre23 followed by 1.0, which does not sort properly. The tilde is a hack to deal with such cases. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915143021.ga31...@angband.pl
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote:
[...]
I recommend against using dates to mark revisions, since there probably
will be multiple commits in a single day, so there is no way to tell
which exactly version you did package.
[...]
On one project where I'm upstream (not packaged for Debian
currently), I use seconds since the epoch from the last git commit
for a minor versioning component on tarballed development snapshots,
which at least reduces this problem down to multiple commits within
the same second rather than within the same day. On my project,
there's not enough churn to make this a relevant concern for now, I
don't care about human readability, and it's only an extra two
digits more than you need for an ISO 8601 date.
One related concern for some projects, however, is whether releasing
from different, out-of-sync VCS branches could make timestamp-only
version numbers appear to skip backwards under such a scheme. Making
sure your major version numbers are human-assigned is an important
component, obviously. ;)
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100915165858.ga2...@yuggoth.org
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. For Debian packaging, this is irrelevant. I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916052231.ge...@hezmatt.org
Doubts in Sigar packaging
Hi all, I'm trying again to package a library called SIGAR [1] because it's a requirement in a free software help to develop called InVesalius [2]. During this trying some doubts occurred: * The Source is in git [3]. I'm not using the last stable version because I wasn't able to compile it. What's the policy to version packages from git? I'm using this way: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d after git is the commit version I'm using. * This library contains a bunch if bindings, one of them is java. These java bindings is compiled using ant. The compilations generates a bunch of .class and .jar files, and there isn't a make install. What is the best way to put those files in the right directories? To use the cp or mv command? And the right directories I think [4] is this /usr/share/java/libsigar-1.7 ? Thanks to all! PS. We need some help in translations [5] too. [1] - http://support.hyperic.com/display/SIGAR/Home [2] - http://svn.softwarepublico.gov.br/trac/invesalius [3] - http://github.com/hyperic/sigar [4] - http://www.debian.org/doc/packaging-manuals/java-policy/x104.html [5] - http://www.transifex.net/projects/p/invesalius/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284483082.3140.21.ca...@paraopeba
Re: Doubts in Sigar packaging
On Tue, Sep 14, 2010 at 01:51:22PM -0300, Thiago Franco de Moraes wrote: I'm trying again to package a library called SIGAR [1] because it's a requirement in a free software help to develop called InVesalius [2]. During this trying some doubts occurred: * The Source is in git [3]. I'm not using the last stable version because I wasn't able to compile it. What's the policy to version packages from git? I'm using this way: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d after git is the commit version I'm using. Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. What you need to do is select a monotonically increasing number to work from. I think the most common option is to just take the date of the last commit in the repo and use that, so something like sigar-1.7.0~git20100915. Assuming that you don't want to package two versions from the same day, that should work just fine. You'll want a debian/README.source describing where the git repo is that you got your export from, and how other people can recreate it (or update it), for cleanliness. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100914222129.gs...@hezmatt.org
