Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9192 > unrolled thread

git-dpm breakage src:faker

Back to article view | Back to linux.debian.maint.python

Contents

  git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 22:50 +0100
    Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 23:00 +0100
      Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-28 23:20 +0100
        Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 23:40 +0100
          Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-29 00:00 +0100
            Re: git-dpm breakage src:faker Arto Jantunen <viiru@debian.org> - 2017-01-29 08:30 +0100
              Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-29 21:00 +0100
                Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-30 10:20 +0100
              Re: git-dpm breakage src:faker Thomas Goirand <zigo@debian.org> - 2017-02-13 02:30 +0100
          Re: git-dpm breakage src:faker Raphael Hertzog <hertzog@debian.org> - 2017-01-29 21:00 +0100
            Re: git-dpm breakage src:faker Simon McVittie <smcv@debian.org> - 2017-01-29 21:50 +0100
            Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-30 07:40 +0100
          Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-01-31 20:30 +0100
            Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-01-31 21:00 +0100
              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-01-31 21:00 +0100
              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-05 06:00 +0100
                Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-05 08:10 +0100
                  Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-06 22:30 +0100
                  Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Ghislain Vaillant <ghisvail@gmail.com> - 2017-02-07 12:10 +0100
                    Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Simon McVittie <smcv@debian.org> - 2017-02-07 15:10 +0100
                    Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-07 15:20 +0100
                      Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-09 20:00 +0100
                        Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-10 03:30 +0100
                          Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-10 05:30 +0100
                            Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-10 07:00 +0100
                              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-10 11:20 +0100
                                Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) kuLa <kula@kulisz.net> - 2017-02-10 11:40 +0100
                                  Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-11 03:10 +0100
                              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-11 22:10 +0100
                                Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-14 02:50 +0100
                                  Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:30 +0100
                                    Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-14 20:00 +0100
                                  Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-16 06:20 +0100
                                    Re: Moving off of git-dpm Piotr Ożarowski <piotr@debian.org> - 2017-02-16 12:40 +0100
                                      Re: Moving off of git-dpm Dimitri John Ledkov <xnox@debian.org> - 2017-02-16 13:50 +0100
                                        Re: Moving off of git-dpm Scott Kitterman <debian@kitterman.com> - 2017-02-16 14:00 +0100
                                          Re: Moving off of git-dpm Barry Warsaw <barry@debian.org> - 2017-02-16 16:00 +0100
                            Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-10 11:10 +0100
                              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-11 02:30 +0100
                    Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Dmitry Shachnev <mitya57@debian.org> - 2017-02-07 21:20 +0100
            Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-05 06:10 +0100
              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-06 22:30 +0100
                Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-08 09:10 +0100
                  Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-13 07:00 +0100
                    Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-13 17:20 +0100
                      Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:00 +0100
                        Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:20 +0100
                        Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-14 17:30 +0100
                          Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Arto Jantunen <viiru@debian.org> - 2017-02-14 17:40 +0100
                            Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-14 17:50 +0100
                              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Simon McVittie <smcv@debian.org> - 2017-02-14 18:00 +0100
                              Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Arto Jantunen <viiru@debian.org> - 2017-02-14 18:00 +0100
                        Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-03-09 11:20 +0100
                          Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Vincent Bernat <bernat@debian.org> - 2017-03-09 11:30 +0100
                          Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Ghislain Vaillant <ghisvail@gmail.com> - 2017-03-09 12:10 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9229 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:

>I know the discussion is leaning towards replacing usage of git-dpm
>with gbp-pq. I have nothing against it but, since we are talking about
>solutions for a git-centric workflow, has anyone considered the dgit-
>maint-merge workflow [1]?

As I understand it, there are a few design choices that make dgit less
desirable for this team.

The first is that dgit uses single-debian-patch rather than a series of
patches as with quilt.  The individual patches can be viewed in git but that
implies more work for interacting with upstreams and requires the use of the
git repo to examine the individual patches, making it harder for
non-developers or others outside of Debian to see what we've done to their
packages.

The second is that dgit prefers to use the upstream git repo but our work is
heavily orig-tar based since our main input is PyPI and there orig-tars (or
zips) are the predominant distribution format.  This may not be a showstopper
since dgit does say it will work with tarball workflows, but I don't know how
natural that is.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#9235 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 07 2017, Barry Warsaw <barry@debian.org> wrote:
> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>
>>I know the discussion is leaning towards replacing usage of git-dpm
>>with gbp-pq. I have nothing against it but, since we are talking about
>>solutions for a git-centric workflow, has anyone considered the dgit-
>>maint-merge workflow [1]?
>
> As I understand it, there are a few design choices that make dgit less
> desirable for this team.

No. You are confusing dgit with one particular way to use it. You can
use dgit with the maint-merge workflow mentioned above, you can use dgit
with git-dpm, and you can use dgit with gbp.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[toc] | [prev] | [next] | [standalone]

#9240 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 9, 2017 10:52:04 AM PST, Nikolaus Rath <Nikolaus@rath.org> wrote:
>On Feb 07 2017, Barry Warsaw <barry@debian.org> wrote:
>> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>>
>>>I know the discussion is leaning towards replacing usage of git-dpm
>>>with gbp-pq. I have nothing against it but, since we are talking
>about
>>>solutions for a git-centric workflow, has anyone considered the dgit-
>>>maint-merge workflow [1]?
>>
>> As I understand it, there are a few design choices that make dgit
>less
>> desirable for this team.
>
>No. You are confusing dgit with one particular way to use it. You can
>use dgit with the maint-merge workflow mentioned above, you can use
>dgit
>with git-dpm, and you can use dgit with gbp.

OK.  So then I gather it's effectively a layer on top of 'normal' things like gbp-pq or git-dpm?  What added value would it provide?

Scott K

[toc] | [prev] | [next] | [standalone]

#9241 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>>No. You are confusing dgit with one particular way to use it. You can
>>use dgit with the maint-merge workflow mentioned above, you can use
>>dgit
>>with git-dpm, and you can use dgit with gbp.
>
> OK.  So then I gather it's effectively a layer on top of 'normal'
> things like gbp-pq or git-dpm?  What added value would it provide?

Among other things, it enables users to run 'dgit clone', and get an
up-to-date, patches-applied copy of the most recent source package.

But it seems to me that you are contemplating whether or not the team
should be using dgit. This is also not a decision that needs to be made
prior to any switch away from dgit-dpm, you can start using dgit at any
point.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[toc] | [prev] | [next] | [standalone]

#9242 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 9, 2017 8:29:32 PM PST, Nikolaus Rath <Nikolaus@rath.org> wrote:
>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>>>No. You are confusing dgit with one particular way to use it. You can
>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>dgit
>>>with git-dpm, and you can use dgit with gbp.
>>
>> OK.  So then I gather it's effectively a layer on top of 'normal'
>> things like gbp-pq or git-dpm?  What added value would it provide?
>
>Among other things, it enables users to run 'dgit clone', and get an
>up-to-date, patches-applied copy of the most recent source package.

How is that different/better than debcheckout?

>But it seems to me that you are contemplating whether or not the team
>should be using dgit. This is also not a decision that needs to be made
>prior to any switch away from dgit-dpm, you can start using dgit at any
>point.

OK.  

Scott K

[toc] | [prev] | [next] | [standalone]

#9246 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

Scott Kitterman <debian@kitterman.com> writes:

> How is that different/better than debcheckout?

I am still learning dgit, however I think that dgit uses its own git
repositories. dgit-repos. I am not sure where these are located or how
access is controlled.

>From the man page for push "This will push your git history to the
dgit-repos, but you probably want to follow it up with a push to
alioth."
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#9247 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Multipart message — attachments visible in raw view] — view raw

On 2017-02-10 21:11:42, Brian May wrote:
> Scott Kitterman <debian@kitterman.com> writes:
> 
> > How is that different/better than debcheckout?
> 
> I am still learning dgit, however I think that dgit uses its own git
> repositories. dgit-repos. I am not sure where these are located or how
> access is controlled.

dgit indeed is using it's own repos:
https://browse.dgit.debian.org/
git.dgit.debian.org

All DDs are having RW access, but I'm not sure how exactly it's done, service
is managed by DSA from what I know.
-- 

|_|0|_|                                                  |
|_|_|0|                  "Panta rei"                     |
|0|0|0|             -------- kuLa --------               |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3

[toc] | [prev] | [next] | [standalone]

#9252 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

kuLa <kula@kulisz.net> writes:

> dgit indeed is using it's own repos:
> https://browse.dgit.debian.org/
> git.dgit.debian.org


The way I understand it is that dgit is simply a replacement for the
upload operation. To implement this with the required checks, it is
recommended (but not required) that you use its build operation.

Instead of using "dput" or similar, you use "dgit push". This checks the
most recent build and makes sure it was built correctly from git HEAD,
and then uploads the build to debian *and* the source to
git.dgit.debian.org

Apart from build and upload there are no other changes to standard
git-dpm or gbp pq procedures.

This provides one key benefit for us, we can be reasonably confident
that the upload corresponds with a published git source.

As an example of an existing dgit package with multiple patches, have a
look at Samba: https://browse.dgit.debian.org/samba.git/tree/debian/patches

Having said that, it looks like the server might be having problems at
the moment, I can't clone any packages.

[brian:/tmp] % dgit clone samba
canonical suite name for unstable is sid
fetching existing git history
remote: fatal: Out of memory, calloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
dgit: failed command: git fetch -p -n -q https://git.dgit.debian.org/samba '+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*' '+refs/tags/debian/*:refs/dgit-fetch/debian/tags/debian/*' '+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid'
dgit: subprocess failed with error exit status 128
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#9254 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath <Nikolaus@rath.org> wrote:
>>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>>>>No. You are confusing dgit with one particular way to use it. You can
>>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>>dgit
>>>>with git-dpm, and you can use dgit with gbp.
>>>
>>> OK.  So then I gather it's effectively a layer on top of 'normal'
>>> things like gbp-pq or git-dpm?  What added value would it provide?
>>
>>Among other things, it enables users to run 'dgit clone', and get an
>>up-to-date, patches-applied copy of the most recent source package.
>
> How is that different/better than debcheckout?

It works all the time. debcheckout does not guarantee you the newest
version (VCS may lag behind Debian archive), nor does it guarantee a
patches applied, complete package (you might end up with just debian/,
patches-unapplied, or even weirder things).

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[toc] | [prev] | [next] | [standalone]

#9258 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 11, 2017 4:05:46 PM EST, Nikolaus Rath <Nikolaus@rath.org> wrote:
>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath <Nikolaus@rath.org>
>wrote:
>>>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>>>>>No. You are confusing dgit with one particular way to use it. You
>can
>>>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>>>dgit
>>>>>with git-dpm, and you can use dgit with gbp.
>>>>
>>>> OK.  So then I gather it's effectively a layer on top of 'normal'
>>>> things like gbp-pq or git-dpm?  What added value would it provide?
>>>
>>>Among other things, it enables users to run 'dgit clone', and get an
>>>up-to-date, patches-applied copy of the most recent source package.
>>
>> How is that different/better than debcheckout?
>
>It works all the time. debcheckout does not guarantee you the newest
>version (VCS may lag behind Debian archive), nor does it guarantee a
>patches applied, complete package (you might end up with just debian/,
>patches-unapplied, or even weirder things).

We know in the DPMT context what debcheckout will produce, so for our purposes they don't matter.

How does dgit avoid maintainer forgot to push problems without being limited to the granularity of one commit per upload?

Scott K

[toc] | [prev] | [next] | [standalone]

#9261 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

Scott Kitterman <debian@kitterman.com> writes:

> We know in the DPMT context what debcheckout will produce, so for our purposes they don't matter.
>
> How does dgit avoid maintainer forgot to push problems without being limited to the granularity of one commit per upload?

When you upload a package, you upload the *.debs and push to git a the
same time. With the one dgit command that checks everything is
consistant, and tags things appropriately. I not sure of the exact
details of how the push is done yet.

I think dgit would really help with the problem I occasionally get: Does
this git source really correspond with the package that was
uploaded. Mistakes can happen in git that can result in you looking at
one git version that is very different to what was uploaded. Yes, this
does happen.

Mostly however, I think the prime benefit of using dgit would be that it
helps other non-team members maintain the package - as does happen from
time to time in the form on NMUs. We can help these people by sticking
to a standard that others can use.

It would not directly help DPMT workflow, as that mostly remains as
is. Hence my first priority would be to change to GBP PQ for work flow,
and then worry about dgit after I have had a chance to play with dgit a
bit more.
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#9267 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Tuesday, February 14, 2017 06:23:43 PM Brian May wrote:
> Scott Kitterman <debian@kitterman.com> writes:
> > We know in the DPMT context what debcheckout will produce, so for our
> > purposes they don't matter.
> > 
> > How does dgit avoid maintainer forgot to push problems without being
> > limited to the granularity of one commit per upload?
> When you upload a package, you upload the *.debs and push to git a the
> same time. With the one dgit command that checks everything is
> consistant, and tags things appropriately. I not sure of the exact
> details of how the push is done yet.
> 
> I think dgit would really help with the problem I occasionally get: Does
> this git source really correspond with the package that was
> uploaded. Mistakes can happen in git that can result in you looking at
> one git version that is very different to what was uploaded. Yes, this
> does happen.
> 
> Mostly however, I think the prime benefit of using dgit would be that it
> helps other non-team members maintain the package - as does happen from
> time to time in the form on NMUs. We can help these people by sticking
> to a standard that others can use.
> 
> It would not directly help DPMT workflow, as that mostly remains as
> is. Hence my first priority would be to change to GBP PQ for work flow,
> and then worry about dgit after I have had a chance to play with dgit a
> bit more.

Thanks.  I agree we should wait on this.

Scott K

[toc] | [prev] | [next] | [standalone]

#9269 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 14 2017, Scott Kitterman <debian@kitterman.com> wrote:
> How does dgit avoid maintainer forgot to push problems without being
> limited to the granularity of one commit per upload?

It does not. Until 'dgit push' is called the next time, it will revert
to one commit per upload for the "dark" period.

I am not sure if the next dgit push will retroactively fix history, or
only affect changes that have not yet been uploaded.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[toc] | [prev] | [next] | [standalone]

#9270 — Re: Moving off of git-dpm

Are you guys seriously considering dgit to replace anything other than
dput in DPMT? I'd rather go back to svn-buildpackage than use something
that will not allow me (f.e. as sponsor) to review before uploading!

Anyway, as DPMT admin I will block any transitions before Stretch release
(yet another reason to replace me, volunteers?)
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#9271 — Re: Moving off of git-dpm

On 16 February 2017 at 11:31, Piotr Ożarowski <piotr@debian.org> wrote:
> Are you guys seriously considering dgit to replace anything other than
> dput in DPMT? I'd rather go back to svn-buildpackage than use something
> that will not allow me (f.e. as sponsor) to review before uploading!

One can totally review before uploading with dgit.
dgit takes ownership/syncing of your dgit/* heads.
One can totally push master; review it; fix it up; push more; and then
as a sponsor if you are happy to publish master one invokes dgit push
to update the dgit/* branches & execute dput with a source matching
the git tree.

Is this the workflow you want?

dgit doesn't impose anything what one does with master branch, or any
other branch names you want.

-- 
Regards,

Dimitri.

[toc] | [prev] | [next] | [standalone]

#9272 — Re: Moving off of git-dpm

On Thursday, February 16, 2017 12:42:59 PM Dimitri John Ledkov wrote:
> On 16 February 2017 at 11:31, Piotr Ożarowski <piotr@debian.org> wrote:
> > Are you guys seriously considering dgit to replace anything other than
> > dput in DPMT? I'd rather go back to svn-buildpackage than use something
> > that will not allow me (f.e. as sponsor) to review before uploading!
> 
> One can totally review before uploading with dgit.
> dgit takes ownership/syncing of your dgit/* heads.
> One can totally push master; review it; fix it up; push more; and then
> as a sponsor if you are happy to publish master one invokes dgit push
> to update the dgit/* branches & execute dput with a source matching
> the git tree.
> 
> Is this the workflow you want?
> 
> dgit doesn't impose anything what one does with master branch, or any
> other branch names you want.

Which is completely separate from the question of if we want to use it as a 
team.  Whoever it was that suggested focusing on what (if anything) to replace 
git-dpm with (post-stretch) and leave the dgit discussion for later, I 
completely agree with.

Scott K

[toc] | [prev] | [next] | [standalone]

#9273 — Re: Moving off of git-dpm

On Feb 16, 2017, at 07:53 AM, Scott Kitterman wrote:

>Which is completely separate from the question of if we want to use it as a
>team.  Whoever it was that suggested focusing on what (if anything) to
>replace git-dpm with (post-stretch) and leave the dgit discussion for later,
>I completely agree with.

+1
-Barry

[toc] | [prev] | [next] | [standalone]

#9245 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

Nikolaus Rath <Nikolaus@rath.org> writes:

> But it seems to me that you are contemplating whether or not the team
> should be using dgit. This is also not a decision that needs to be made
> prior to any switch away from dgit-dpm, you can start using dgit at any
> point.

My vague understanding is that dgit complements the workflow, whatever
workflow you may want - including git-dpm and pq. Hence I was surprised
and confused when people said it only supported the single patch model -
I don't think this is correct.

My attempt to build a package (in this case pq based) was less then
successful. Possibly because I am not awake.

[brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git sbuild --verbose                        
Format `3.0 (quilt)', need to check/update patch stack
examining quilt state (multiple patches, gbp mode)
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea
dgit: quilt differences: src:  ## orig ##     gitignores:  == orig ==
dgit: quilt differences:      HEAD ## o+d/p               HEAD == o+d/p
dgit: --quilt=gbp specified, implying patches-unapplied git tree
dgit:  but git tree differs from orig in upstream files.

This error puzzles me, to me it seems to be saying there is a mismatch
between git with patches unapplied and the *.orig.tar.gz file - however
I don't think this is the case.
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#9250 — Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

Brian May <bam@debian.org> writes:

> [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git sbuild --verbose                        
> Format `3.0 (quilt)', need to check/update patch stack
> examining quilt state (multiple patches, gbp mode)
> dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
> dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea
> dgit: quilt differences: src:  ## orig ##     gitignores:  == orig ==
> dgit: quilt differences:      HEAD ## o+d/p               HEAD == o+d/p
> dgit: --quilt=gbp specified, implying patches-unapplied git tree
> dgit:  but git tree differs from orig in upstream files.
>
> This error puzzles me, to me it seems to be saying there is a mismatch
> between git with patches unapplied and the *.orig.tar.gz file - however
> I don't think this is the case.

Ok, so there really was a difference: the git archive was missing the
"docs/_static/.keep_dir" file that is included in the upstream file.

Probably good that dgit detects discrepancies such as these, however not
so good that it took me sometime to work out the problem based on the
given message. If it told me what was different, it would be much be
helpful.

(also leads to the question why this file was missing from my import
last month - but I can't remember what I did now)

When I did build the package I can confirm that the generated source
package had multiple patch files (as expected).
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#9232 — Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 07, 2017 at 10:47:00AM +0000, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workflow [1]?
>
> [1] https://www.mankier.com/7/dgit-maint-merge

Quoting from that manpage:

| Debian modifications to the upstream source are squashed into a single diff,
| rather than a series of quilt patches.

No, please let’s not use this. (I am with ScottK here.)

The gbp-pq approach looks fine to me.

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web