On Wed, Aug 17, 2016 at 09:25:21PM +0200, Adam Borowski wrote:
> > > > > If the repository contains any tags, I'd strongly recommend the
> > > > > output of
> > > > > "git describe --tags". This will, beside DTRT when you're exactly on
> > > > > a
> > > > > tag (ie, on a release), produce
On Wed, Aug 17, 2016 at 11:04:39AM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 16, 2016 at 11:39:33PM +0200, Adam Borowski wrote:
> > > > If the repository contains any tags, I'd strongly recommend the output
> > > > of
> > > > "git describe --tags". This will, beside DTRT when you're exactly
On Tue, Aug 16, 2016 at 11:39:33PM +0200, Adam Borowski wrote:
> > > If the repository contains any tags, I'd strongly recommend the output of
> > > "git describe --tags". This will, beside DTRT when you're exactly on a
> > > tag (ie, on a release), produce version numbers of the form:
> > > -<#
On Tue, Aug 16, 2016 at 08:43:05AM +0200, Ferenc Wágner wrote:
> Sean Whitton writes:
>
> > For example, support I'm packaging 0~git.abc123d. This version number
> > might be used because I'm basing my packaging on upstream git commit
> > whose hash is uniquely
On Tue, Aug 16, 2016 at 10:04:43PM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 16, 2016 at 05:00:02PM +0200, Adam Borowski wrote:
> > If the repository contains any tags, I'd strongly recommend the output of
> > "git describe --tags". This will, beside DTRT when you're exactly on a
> > tag
On Tue, Aug 16, 2016 at 05:00:02PM +0200, Adam Borowski wrote:
> If the repository contains any tags, I'd strongly recommend the output of
> "git describe --tags". This will, beside DTRT when you're exactly on a
> tag (ie, on a release), produce version numbers of the form:
> -<# of commits>-g,
On Tue, Aug 16, 2016 at 11:54:19AM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 16, 2016 at 07:50:37AM +0100, Ghislain Vaillant wrote:
> > > > For example, support I'm packaging 0~git.abc123d. This version number
> > > > might be used because I'm basing my packaging on upstream git commit
> > >
On Tue, Aug 16, 2016 at 10:09:48AM +0100, Ghislain Vaillant wrote:
> > > Generally speaking, is there a recommended Debian version format for
> > > git snapshots?
> > 1.1+20160816, or ~ instead of +, as usual.
> > Unless you are packaging two different snapshots committed at the same
> > day.
>
>
On 16/08/16 07:54, Andrey Rahmatullin wrote:
On Tue, Aug 16, 2016 at 07:50:37AM +0100, Ghislain Vaillant wrote:
For example, support I'm packaging 0~git.abc123d. This version number
might be used because I'm basing my packaging on upstream git commit
whose hash is uniquely identified by the
On Tue, Aug 16, 2016 at 07:50:37AM +0100, Ghislain Vaillant wrote:
> > > For example, support I'm packaging 0~git.abc123d. This version number
> > > might be used because I'm basing my packaging on upstream git commit
> > > whose hash is uniquely identified by the string 'abc123d'.
> >
> > Such
On 16/08/16 07:43, Ferenc Wágner wrote:
Sean Whitton writes:
For example, support I'm packaging 0~git.abc123d. This version number
might be used because I'm basing my packaging on upstream git commit
whose hash is uniquely identified by the string 'abc123d'.
Such
Sean Whitton writes:
> For example, support I'm packaging 0~git.abc123d. This version number
> might be used because I'm basing my packaging on upstream git commit
> whose hash is uniquely identified by the string 'abc123d'.
Such version numbers won't order correctly.
On Mon, Aug 15, 2016 at 04:53:59PM -0700, Sean Whitton wrote:
> One thing I've done is added a tag corresponding to upstream part of the
> version in my Debian changelog entry. Then gbp can generate the tarball
> for me.
Sure, but Jerome didn't say he was using gbp.
--
WBR, wRAR
signature.asc
Hello,
On Mon, Aug 15, 2016 at 09:24:01PM +0500, Andrey Rahmatullin wrote:
> > Do you have a example or a wiki in mind ?
> Um. git archive | xz > foo.tar.xz, I guess.
One thing I've done is added a tag corresponding to upstream part of the
version in my Debian changelog entry. Then gbp can
Hi,
On 15/08/16 17:46, Andrew Shadura wrote:
> On 15 August 2016 at 17:24, Andrey Rahmatullin wrote:
>> On Mon, Aug 15, 2016 at 04:58:32PM +0100, Jerome BENOIT wrote:
> So I am considering to create a Debian Source from the GIT repository.
> Unfortunately, the GIT
On Mon, 15 Aug 2016 16:58:32 +0100, Jerome BENOIT wrote:
> >> What is the best way to create a Debian Source from the upstream GIT
> >> repository ?
> > git archive would be enough, you don't need uscan for that.
> > You can't have a debian/watch in this case, of course.
> Do you have a example
On Mon, Aug 15, 2016 at 04:58:32PM +0100, Jerome BENOIT wrote:
> >> So I am considering to create a Debian Source from the GIT repository.
> >> Unfortunately, the GIT repository contains no tags, so uscan(1) seems
> >> not be useful here. I have already submitted a ticket to the upstream
> >>
Hello Andrey,
thanks for your prompt reply.
On 15/08/16 16:43, Andrey Rahmatullin wrote:
> On Mon, Aug 15, 2016 at 04:19:03PM +0100, Jerome BENOIT wrote:
>> it appears that for one of my pacage, libgap-sage not to mention it [1],
>> the upstream source tarbal does not contain the required
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Forum,
it appears that for one of my pacage, libgap-sage not to mention it [1],
the upstream source tarbal does not contain the required material to be not
rejected by ftpmaster [2]. So I am considering to create a Debian Source
from the GIT
On Mon, Aug 15, 2016 at 04:19:03PM +0100, Jerome BENOIT wrote:
> it appears that for one of my pacage, libgap-sage not to mention it [1],
> the upstream source tarbal does not contain the required material to be not
> rejected by ftpmaster [2].
Your link doesn't seem to support that.
> So I am
Hello Forum,
it appears that for one of my pacage, libgap-sage not to mention it [1],
the upstream source tarbal does not contain the required material to be not
rejected by ftpmaster [2]. So I am considering to create a Debian Source
from the GIT repository. Unfortunately, the GIT repository
21 matches
Mail list logo