Re: dgit and git-dpm
On 3 November 2014 21:32, Bernhard R. Link wrote: > * Ian Jackson [141103 19:13]: >> The point is that the dgit user probably will have done git diff >> before dgit build / push. git diff provides a more convenient diffing >> tool than debdiff, and eyeballing the same thing twice is makework. > > git diff is a nice tool. But it has it limits. Try detecting the adding > or removel of an empty file with git diff for example. > I'm failing to see how this is a valid example. v1.0 diff and patch[1] tool, and the classical debdiff cannot track this, where as git diff / git format-patch / git am, actually can: $ git diff --cached diff --git a/bar b/bar new file mode 100644 index 000..e69de29 diff --git a/foo b/foo deleted file mode 100644 index e69de29..000 The point of using $ git diff, together with dgit is to make sure that valid uploads made with dgit, also generate valid debdiffs as generally accepted by dak/dpkg-source without requiring extra work by the user, irrespective of the source format versions used. dpkg-source alone does not guarantee that today, and there plenty of examples in the archive where running ./debian/rules clean will generate auxilary and unepected source packages changes, which would then leak into debdiff and the NMU itself. [1] some support git extended patch syntax are getting added to gnu patch, but this is not yet universally available. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluih0-rax0ijbk3x8jzjtfjh-y45u8yix2ccqcwj8ez...@mail.gmail.com
Re: dgit and git-dpm
* Ian Jackson [141103 19:13]: > The point is that the dgit user probably will have done git diff > before dgit build / push. git diff provides a more convenient diffing > tool than debdiff, and eyeballing the same thing twice is makework. git diff is a nice tool. But it has it limits. Try detecting the adding or removel of an empty file with git diff for example. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141103213245.ga4...@client.brlink.eu
Re: dgit and git-dpm
Bernhard R. Link writes ("Re: dgit and git-dpm"):
> To do an NMU, one has to generate a debdiff anyway to post it to the
> bug report (as the rules for NMUs mandate).
Generating it and reading it are two different things.
As I say, I intend for dgit to be able to send the debdiff to the BTS
all by itself.
> And the debdiff is the real difference so the real changes done, so
> worth looking at.
This presupposes that there is a significant risk of something
unexpected showing up in the debdiff.
> How is being quite sure what would be in there with dgit that much
> different as with other NMUs? Where is the difference to
> "I just applied those two patches from the BTS and changed
> debian/rules the way described in debian/changelog.
> Why should I look at the debdiff? I know I changed nothing else."?
The point is that the dgit user probably will have done git diff
before dgit build / push. git diff provides a more convenient diffing
tool than debdiff, and eyeballing the same thing twice is makework.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21591.50585.124208.288...@chiark.greenend.org.uk
Re: dgit and git-dpm
On Mon, 3 Nov 2014, Bernhard R. Link wrote: > different as with other NMUs? Where is the difference to Thanks, you described this better than I could. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411031034290.20...@tglase.lan.tarent.de
Re: dgit and git-dpm
* Ian Jackson [141030 13:42]:
> Thorsten Glaser writes ("Re: dgit and git-dpm"):
> > – I’d prefer users of even dgit, no matter how good it may be, to
> > not rely on that.
>
> Again, why ?
To do an NMU, one has to generate a debdiff anyway to post it to the
bug report (as the rules for NMUs mandate).
And the debdiff is the real difference so the real changes done, so
worth looking at.
How is being quite sure what would be in there with dgit that much
different as with other NMUs? Where is the difference to
"I just applied those two patches from the BTS and changed
debian/rules the way described in debian/changelog.
Why should I look at the debdiff? I know I changed nothing else."?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103061735.ga1...@client.brlink.eu
Re: dgit and git-dpm
Thorsten Glaser writes ("Re: dgit and git-dpm"):
> Ian Jackson dixit:
> [ NMU ]
> >A dgit user should be able to do this without reading the debdiff:
>
> This is a dangerous habit to get into
Why ?
Of course for this NMU approach to be a good one, dgit needs to
reliably do the right thing. dgit is still quite immature software so
some scepticism is probably warranted.
But, the whole purpose of computers is to save human effort. We
should not be spending our time double-guessing the output of
computers, unless we really can't avoid it. That our current NMU
practices involve a lot of pratting about, bookwork, double-checking,
paperwork, and so on, is not a feature.
It's a bug. A bug in our processes and tools. A bug I am fixing.
> – I’d prefer users of even dgit, no matter how good it may be, to
> not rely on that.
Again, why ?
If (hypothetically - I'm definitely not claiming this right now) dgit
were 100% reliable, there would be no reason not to simply rely on it.
> This is a social issue, not a technical one.
I don't understand this comment at all.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21586.12846.427325.890...@chiark.greenend.org.uk
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Thu, Oct 30, 2014 at 12:36:24AM +0900, Osamu Aoki wrote: > > This would mean a much more expensive build by default, please don't. > > git-pbuilder uses cowbulder by default (not bare-bone pbuilder), so it > is not as slow as pbuilder. Yes, but it is a lot slower than a plain build on the current system just because you have to install all dependencies at every build. > Chroot build is a good thing. Sure. > > I would rather make plain debuild, or just dpkg-buildpackage, the > > default. > > If you need this, set --git-builder=debuild or > set builder=debuild in ~/.gbp.conf > > It is no big deal which ever system default is chosen. I could use the same argument in reverse: if you want to use a full clean build by default you can also just do that. :) -- Antonio Terceiro signature.asc Description: Digital signature
Re: dgit and git-dpm
Le Wed, Oct 29, 2014 at 04:09:03PM -0500, Jose-Luis Rivas a écrit : > On 29/10/14, 07:44pm, Thorsten Glaser wrote: > > > > This is a dangerous habit to get into – I’d prefer users of even > > dgit, no matter how good it may be, to not rely on that. This is > > a social issue, not a technical one. > > Please explain yourself, is not obvious what social issue you're > referring to if dgit is replicating debdiff and dpkg-buildpackage > behavior. Sorry to be very rude, but the social issue here is people like Thorsten regulary asking a lot to others, in a way do not match the importance of their own contributions to Debian. Can we please us focus this list on what we do together, rather than on what one does not want others to do ? To those who want Debian to be different: move the project by contributing to its core, inspire others to do so, or make your area of contribution one of the major points for which Debian is recognised in the world. Our large diversity of non-essential contributions (mine included) is one of Debian's strength, but please remember that without the hard work of those that you constantly demotivate on this list, you would have no Debian project to contribute to. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030032519.gh5...@falafel.plessy.net
Re: dgit and git-dpm
On 29/10/14, 07:44pm, Thorsten Glaser wrote: > Ian Jackson dixit: > > [ NMU ] > >A dgit user should be able to do this without reading the debdiff: > > This is a dangerous habit to get into – I’d prefer users of even > dgit, no matter how good it may be, to not rely on that. This is > a social issue, not a technical one. > Please explain yourself, is not obvious what social issue you're referring to if dgit is replicating debdiff and dpkg-buildpackage behavior. -- ⨳ GPG 0x13EC43EE B9AC8C43 ⨳ https://ghostbar.co signature.asc Description: Digital signature
Re: dgit and git-dpm
Ian Jackson dixit: [ NMU ] >A dgit user should be able to do this without reading the debdiff: This is a dangerous habit to get into – I’d prefer users of even dgit, no matter how good it may be, to not rely on that. This is a social issue, not a technical one. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1410291943300.18...@herc.mirbsd.org
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Oct 29, 2014, at 01:47 PM, Ian Jackson wrote: >I got the impression that sbuild is winning over pbuilder BICBW. Especially now that bug #607228 has been fixed! Cheers, -Barry signature.asc Description: PGP signature
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
Hi,
On Wed, Oct 29, 2014 at 11:54:41AM -0200, Antonio Terceiro wrote:
> On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> > On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re:
> > > Standardizing the layout of git packaging repositories)"):
...
> > I do wonder if we should switch to using git-pbuilder by default and
> > rather offer to invoke 'git-pbuilder create' in case we don't find a
> > proper base.cow for it.
Auto-generation of base.cow will be nice.
As for build option, I am using builder = git-pbuilder -i -I -us -uc
alrready.
> This would mean a much more expensive build by default, please don't.
git-pbuilder uses cowbulder by default (not bare-bone pbuilder), so it
is not as slow as pbuilder. Chroot build is a good thing.
> I would rather make plain debuild, or just dpkg-buildpackage, the
> default.
If you need this, set --git-builder=debuild or
set builder=debuild in ~/.gbp.conf
It is no big deal which ever system default is chosen.
Osamu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029153624.GA5574@goofy.local
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing
> > the layout of git packaging repositories)"):
> > > dpkg-source removes it, by default, for 3.0 based formats as it's part
> > > of the default ignore list.
> > > (or rather ignores it)
> >
> > No, it's not strictly in dpkg-source (not in dpkg-source -b, or
> > dpkg-buildpackage8 -B, anyway). The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> > -I. git-buildpackage passes -I. dgit's build options specify (either
> > directly or via whatever helper they're using) -i\.git/ -I.git
>
> Git-buildpackage uses whatevert builder you want and it indeed
> currently defaults to 'debuild -i -I' which really isn't a good
> default nowadays for several reasons.
>
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
> proper base.cow for it.
This would mean a much more expensive build by default, please don't.
I would rather make plain debuild, or just dpkg-buildpackage, the
default.
--
Antonio Terceiro
signature.asc
Description: Digital signature
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
Guido Günther writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
> proper base.cow for it.
I got the impression that sbuild is winning over pbuilder BICBW.
dgit doesn't know how to invoke pbuilder[1]. It probably should.
Patches welcome.
[1] For various reasons it is a good idea to run your build tool via
dgit if you intend to use dgit to push. One is this trouble with
ignore lists; another is that with `3.0 (quilt)' someone has to do a
dpkg-source commit and dgit knows how to do that. dgit currently
knows how to run dpkg-buildpackage (for both binaryfull and
source-only uploads), git-buildpackage, and sbuild.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21584.61445.179755.181...@chiark.greenend.org.uk
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
Simon McVittie writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> On 29/10/14 12:08, Ian Jackson wrote:
> > The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> > -I. git-buildpackage passes -I.
>
> To be completely clear (because I misread it twice in a row), you mean
> that it is not enabled unless the caller uses «-I» with no argument,
> which git-buildpackage does? (No literal strings «-I.» anywhere.)
Yes.
> This seems appropriate for the model you encourage with dgit, where the
> git tree is identical to the unpacked .dsc.
Right.
> dpkg-source's -I is currently equivalent to [lots of stuff]
Blimey.
> I suspect that the reason .gitignore is included in that list is so that
> maintainers who build from git, but whose upstream does not, can drop a
> /.gitignore into their git tree, as the maintainer of xwit appears to
> have done, without it being managed as a Debian patch to the upstream
> source code. It is necessary that it appears at top-level, because
> otherwise it wouldn't have the desired effect; but it is an
> implementation detail of how the Debian maintainer chose to set up their
> VCS, so presumably they don't consider it to be something that should be
> in the .dsc (where it would have to be handled as a quilt patch, or as
> part of the diff.gz for format v1).
Yes.
I don't think there is any problem with including it as a quilt
patch.
> Obviously, this directly conflicts with dgit's view of the world, in
> which the git repository and the unpacked .dsc correspond 1:1.
Yes.
> I think debian/source/local-options is going to be another potential
> pain point for dgit: it is deliberately not included in a .dsc because
> that would defeat the object of those options being local.
If you have that file in your git branch then the git branch is indeed
unsuitable for use with dgit (and dgit will detect this when you try
to push).
> In non-native packages, if there's a /.gitignore in the orig.tar.gz, I
> think gbp would leave it alone? (The only other option would be to add a
> quilt patch that explicitly removes it, or add a patch-band for it in
> the v1 diff.gz, which seems unlikely.)
I recently did (with dgit) a maintainer upload of adns, which is a
non-native 1.0 package, whose upstream source has .gitignore.
Of course the upstream .gitignore doesn't mention files generated by
the Debian packaging.
So the .diff.gz for adns includes a patch to add the relevant
Debian-specific things to .gitignore. This doesn't seem to cause any
kind of problem.
> On 29/10/14 09:47, Dimitri John Ledkov wrote:
> > Ideally "packaging .gitignore" would be in debian/gitignore, but I
> > don't know if that will work.
>
> debian/.gitignore (which is presumably what you meant) can only be used
> to ignore files under debian/. So you can do
Indeed. And even if there's nothing else, dh tends to create
`/build-stamp'.
> I suspect that a lot of upstreams have a .gitignore, but don't put it in
> their tarball releases, on the basis that the tarball is not a git
> checkout. I certainly don't, although I'm considering it (it would make
> it easier for distro maintainers to cherry-pick patches that happen to
> add a new binary to .gitignore).
Yes.
If you have an upstream who think that their tarballs ought to be
different to their git trees, you are always going to have these kind
of difficulties.
You have two options:
A. Base your Debian packaging solely on the upstream git,
and arrange for your debian/rules to run autogen.sh et al.
You'll have to synthesize a .orig.tar.?z (eg with git-archive).
B. Base your Debian packaging on upstream tarballs.
Reasons to prefer A:
* You can easily make releases from any upstream git commit even if
upstream don't provide a tarball. (With B. you might have to
construct a fake upstream tarball, hopefully using the same scripts
that upstream do...)
* Cherry picking from upstream git works properly without
conflicts.
* With B it is difficult to always build from the `sourcest source'
(eg configure.ac and Makefile.am) because that might result in
pointless noise changes to files like configure - changes which the
Debian build and packaging workflow has trouble with.
Reasons to prefer B:
* The Debian .orig.tar.?z is identical to upstream's.
* The Debian source package is easier to use in semi-broken
environments, by disabling eg autogen.sh.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21584.61150.223925.35...@chiark.greenend.org.uk
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
> layout of git packaging repositories)"):
> > dpkg-source removes it, by default, for 3.0 based formats as it's part
> > of the default ignore list.
> > (or rather ignores it)
>
> No, it's not strictly in dpkg-source (not in dpkg-source -b, or
> dpkg-buildpackage8 -B, anyway). The contents of the default ignore
> list is in dpkg-source, but it is not enabled unless the caller says
> -I. git-buildpackage passes -I. dgit's build options specify (either
> directly or via whatever helper they're using) -i\.git/ -I.git
Git-buildpackage uses whatevert builder you want and it indeed
currently defaults to 'debuild -i -I' which really isn't a good
default nowadays for several reasons.
I do wonder if we should switch to using git-pbuilder by default and
rather offer to invoke 'git-pbuilder create' in case we don't find a
proper base.cow for it.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029133203.ga14...@bogon.m.sigxcpu.org
Re: dgit and git-dpm
Thorsten Glaser writes ("Re: dgit and git-dpm"):
> On Wed, 29 Oct 2014, Ian Jackson wrote:
> > maintainers of other tools. It does seem to me to imply that using
> > git-buildpackage to do an NMU is risky, because:
>
> Yes, it is – anything other than the standard Debian tool
> (dpkg-buildpackage) is.
Using dgit to do an NMU is not supposed to be risky. It is supposed
to get everything right.
At the moment it does comply with the policy and dev ref, but there
are two ways I intend to improve it: firstly to generate better
patches in debian/patches when exporting an NMUer's git tree back into
a Debian source package, and secondly to automatically email the
NMUdiff to the BTS.
> They should read the debdiff anyway… but yeah.
A dgit user should be able to do this without reading the debdiff:
`git diff dgit/dgit/sid' ought to suffice.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21584.60066.976053.734...@chiark.greenend.org.uk
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On 29/10/14 12:08, Ian Jackson wrote:
> The contents of the default ignore
> list is in dpkg-source, but it is not enabled unless the caller says
> -I. git-buildpackage passes -I.
To be completely clear (because I misread it twice in a row), you mean
that it is not enabled unless the caller uses «-I» with no argument,
which git-buildpackage does? (No literal strings «-I.» anywhere.)
> dgit's build options specify (either
> directly or via whatever helper they're using) -i\.git/ -I.git
This seems appropriate for the model you encourage with dgit, where the
git tree is identical to the unpacked .dsc.
dpkg-source's -I is currently equivalent to
-I*.a -I*.la -I*.o -I*.so -I.*.sw? -I*/*~ -I,,* -I.[#~]*
-I.arch-ids -I.arch-inventory -I.be -I.bzr -I.bzr.backup
-I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git
-I.gitattributes -I.gitignore -I.gitmodules -I.hg -I.hgignore
-I.hgsigs -I.hgtags -I.shelf -I.svn -ICVS -IDEADJOE -IRCS -I_MTN
-I_darcs -I{arch}
according to dpkg-source --help.
I suspect that the reason .gitignore is included in that list is so that
maintainers who build from git, but whose upstream does not, can drop a
/.gitignore into their git tree, as the maintainer of xwit appears to
have done, without it being managed as a Debian patch to the upstream
source code. It is necessary that it appears at top-level, because
otherwise it wouldn't have the desired effect; but it is an
implementation detail of how the Debian maintainer chose to set up their
VCS, so presumably they don't consider it to be something that should be
in the .dsc (where it would have to be handled as a quilt patch, or as
part of the diff.gz for format v1).
Obviously, this directly conflicts with dgit's view of the world, in
which the git repository and the unpacked .dsc correspond 1:1.
I think debian/source/local-options is going to be another potential
pain point for dgit: it is deliberately not included in a .dsc because
that would defeat the object of those options being local.
> It does seem to me to imply that using
> git-buildpackage to do an NMU is risky, because:
>
> If some user of git-buildpackage (without dgit) tries to do an NMU of
> a package containing .gitignore, it will remove the .gitignore.
In non-native packages, if there's a /.gitignore in the orig.tar.gz, I
think gbp would leave it alone? (The only other option would be to add a
quilt patch that explicitly removes it, or add a patch-band for it in
the v1 diff.gz, which seems unlikely.)
Your reasoning would seem to be true for native packages and for
/debian/.gitignore though.
I would personally hope that NMUers always do a source debdiff before
uploading, to confirm that they only made the changes they intended to
make; but perhaps not everyone is that conscientious.
On 29/10/14 09:47, Dimitri John Ledkov wrote:
> Ideally "packaging .gitignore" would be in debian/gitignore, but I
> don't know if that will work.
debian/.gitignore (which is presumably what you meant) can only be used
to ignore files under debian/. So you can do
echo "/tmp" > debian/.gitignore
echo "/hello" >> debian/.gitignore
echo "/*.debhelper" >> debian/.gitignore
echo ".*.swp" >> debian/.gitignore
and it will ignore debian/tmp, debian/hello, debian/*.debhelper,
debian/.*.swp and debian/**/.*.swp (in rsync notation) but will not
ignore, for instance, src/.hello.c.swp.
The story might be different if your upstream puts /.gitignore in (what
you use as) the .orig.tar.* archive?
I suspect that a lot of upstreams have a .gitignore, but don't put it in
their tarball releases, on the basis that the tarball is not a git
checkout. I certainly don't, although I'm considering it (it would make
it easier for distro maintainers to cherry-pick patches that happen to
add a new binary to .gitignore).
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5450e7bc.6050...@debian.org
Re: dgit and git-dpm
On Wed, 29 Oct 2014, Ian Jackson wrote: > maintainers of other tools. It does seem to me to imply that using > git-buildpackage to do an NMU is risky, because: Yes, it is – anything other than the standard Debian tool (dpkg-buildpackage) is. > If some user of git-buildpackage (without dgit) tries to do an NMU of > a package containing .gitignore, it will remove the .gitignore. If > the NMUer doesn't notice, then the maintainer certainly will when they They should read the debdiff anyway… but yeah. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410291353260.7...@tglase.lan.tarent.de
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
[resending because my MUA failed to mangle the headers]
Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
layout of git packaging repositories)"):
> dpkg-source removes it, by default, for 3.0 based formats as it's part
> of the default ignore list.
> (or rather ignores it)
No, it's not strictly in dpkg-source (not in dpkg-source -b, or
dpkg-buildpackage8 -B, anyway). The contents of the default ignore
list is in dpkg-source, but it is not enabled unless the caller says
-I. git-buildpackage passes -I. dgit's build options specify (either
directly or via whatever helper they're using) -i\.git/ -I.git
I think this is arguably a bug in git-buildpackage or dpkg-source, but
I don't want to get into a (another) workflow fight with the
maintainers of other tools. It does seem to me to imply that using
git-buildpackage to do an NMU is risky, because:
If some user of git-buildpackage (without dgit) tries to do an NMU of
a package containing .gitignore, it will remove the .gitignore. If
the NMUer doesn't notice, then the maintainer certainly will when they
come to integrate the changes, and can put the .gitignore back.
The maintainer can also send the NMUer a polite email asking them not
to use dodgy tools :-). If the maintainer is using dgit the
.gitignore removal will be quite obvious, and easy to undo.
Ian.
(build)ian@zealot:~/junk/d$ dpkg-source -x 1/dgit_0.22.dsc
gpgv: Signature made Tue 19 Aug 2014 10:53:40 UTC using RSA key ID 48B50D39
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on 1/dgit_0.22.dsc
dpkg-source: info: extracting dgit in dgit-0.22
dpkg-source: info: unpacking dgit_0.22.tar.gz
(build)ian@zealot:~/junk/d$ dpkg-source -b dgit-0.22
dpkg-source: warning: no source format specified in debian/source/format, see
dpkg-source(1)
dpkg-source: info: using source format `1.0'
dpkg-source: info: building dgit in dgit_0.22.tar.gz
dpkg-source: info: building dgit in dgit_0.22.dsc
(build)ian@zealot:~/junk/d$ mkdir 2
(build)ian@zealot:~/junk/d$ cd 2
(build)ian@zealot:~/junk/d/2$ dpkg-source -x ../dgit_0.22.dsc
dpkg-source: warning: extracting unsigned source package (../dgit_0.22.dsc)
dpkg-source: info: extracting dgit in dgit-0.22
dpkg-source: info: unpacking dgit_0.22.tar.gz
(build)ian@zealot:~/junk/d/2$ ls -al dgit-0.22/.gitignore
-rw-rw-r-- 1 ian ian 70 Nov 27 2013 dgit-0.22/.gitignore
(build)ian@zealot:~/junk/d/2$ cd ..
(build)ian@zealot:~/junk/d$ debdiff 1/dgit_0.22.dsc dgit_0.22.dsc
Warning: You do not seem to have interdiff (in the patchutils package)
installed; this program would use it if it were available.
gpgv: Signature made Tue 19 Aug 2014 10:53:40 UTC using RSA key ID 48B50D39
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on
/home/ian/junk/d/1/dgit_0.22.dsc
dpkg-source: warning: extracting unsigned source package
(/home/ian/junk/d/dgit_0.22.dsc)
(build)ian@zealot:~/junk/d$
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21584.55500.842182.565...@chiark.greenend.org.uk
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On 29 October 2014 05:39, Guido Günther wrote:
> On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote:
>> Brian May writes ("Re: Standardizing the layout of git packaging
>> repositories"):
>> > However, with git-dpm, no branch is ever destroyed. Every branch is always
>> > merged into the Debian branch. The Debian branch itself always heads in a
>> > single forward direction and this branch is never rebased. Furthermore,
>> > because this is a pseudo-standard, everything can expect this is what will
>> > happen.
>> >
>> > See http://git-dpm.alioth.debian.org/ for details.
>>
>> I have an experimental version of dgit (not yet uploaded anywhere)
>> which handles .pc differently: the dgit git tree does not contain .pc.
>> I wrote some (frankly quite terrifying) code to reconstruct a .pc from
>> the artifacts available to dgit (mainly debian/patches and ../*orig*).
>>
>> I used my new dgit to clone xwit (since that's listed as the example
>> in the git-dpm page) and the dgit git tree for 3.4-15 is almost
>> identical to that at the alioth tag debian-3.4-15. There is one
>> difference: dgit's tree does not contain .gitignore. I don't think
>> the lack of .gitignore is important for git-dpm users. (Arguably it's
>> a bug that git-buildpackage et al remove it.)
>
> At which step does gbp remove .gitignore? It shouldn't and it doesn't
> over here.
dpkg-source removes it, by default, for 3.0 based formats as it's part
of the default ignore list.
(or rather ignores it)
$ apt-get source hello
$ cd hello-*
$ cat debian/source/format
3.0 (quilt)
$ git init
$ echo "*.a" > .gitignore
$ git add .
$ git commit -m "initial"
$ debuild -S
$ dpkg-source -x ../hello*.dsc
$ cat hello-*/.gitignore
ls: cannot access hello-2.8/.gitignore: No such file or directory
Ideally "packaging .gitignore" would be in debian/gitignore, but I
don't know if that will work.
This is a problem, because it breaks the round-trip guarantees between
dgit, git, dsc. That is, unpacking source package does not re-create
matching git tree sha.
--
Regards,
Dimitri.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CANBHLUitoVvbS1Be1c5wSq+nPWZ4JJ=Rj-jG=cpjbkf399r...@mail.gmail.com
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote:
> Brian May writes ("Re: Standardizing the layout of git packaging
> repositories"):
> > However, with git-dpm, no branch is ever destroyed. Every branch is always
> > merged into the Debian branch. The Debian branch itself always heads in a
> > single forward direction and this branch is never rebased. Furthermore,
> > because this is a pseudo-standard, everything can expect this is what will
> > happen.
> >
> > See http://git-dpm.alioth.debian.org/ for details.
>
> I have an experimental version of dgit (not yet uploaded anywhere)
> which handles .pc differently: the dgit git tree does not contain .pc.
> I wrote some (frankly quite terrifying) code to reconstruct a .pc from
> the artifacts available to dgit (mainly debian/patches and ../*orig*).
>
> I used my new dgit to clone xwit (since that's listed as the example
> in the git-dpm page) and the dgit git tree for 3.4-15 is almost
> identical to that at the alioth tag debian-3.4-15. There is one
> difference: dgit's tree does not contain .gitignore. I don't think
> the lack of .gitignore is important for git-dpm users. (Arguably it's
> a bug that git-buildpackage et al remove it.)
At which step does gbp remove .gitignore? It shouldn't and it doesn't
over here.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029053926.gc2...@bogon.m.sigxcpu.org
dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
Brian May writes ("Re: Standardizing the layout of git packaging repositories"):
> However, with git-dpm, no branch is ever destroyed. Every branch is always
> merged into the Debian branch. The Debian branch itself always heads in a
> single forward direction and this branch is never rebased. Furthermore,
> because this is a pseudo-standard, everything can expect this is what will
> happen.
>
> See http://git-dpm.alioth.debian.org/ for details.
I have an experimental version of dgit (not yet uploaded anywhere)
which handles .pc differently: the dgit git tree does not contain .pc.
I wrote some (frankly quite terrifying) code to reconstruct a .pc from
the artifacts available to dgit (mainly debian/patches and ../*orig*).
I used my new dgit to clone xwit (since that's listed as the example
in the git-dpm page) and the dgit git tree for 3.4-15 is almost
identical to that at the alioth tag debian-3.4-15. There is one
difference: dgit's tree does not contain .gitignore. I don't think
the lack of .gitignore is important for git-dpm users. (Arguably it's
a bug that git-buildpackage et al remove it.)
Also, it appears that the successive git-dpm uploads in a suite are
fast-forwarding - usually, at least. (I don't know if this is
enforced.)
I think what this means is that the git-dpm git branch is suitable,
directly, for use with `dgit push'.
If you use dgit to build and push from the git-dpm branch, your source
package will contain .gitignore (which is good, of course). Another
developer who dgit clones your package will get your git-dpm history.
If they then NMU for a bugfix, they will make commits on the end of
your git-dpm history. Does git-dpm's workflow easily permit the
incorporation of such a bugfix into the git-dpm history ?
I have one further question: is it possible, with git-dpm, to
construct a commit to build and upload from which (a) has the
commit and tree structure required for git-dpm, and (b) has an
arbitrary commit as an ancestor (somewhere) ?
If you are the maintainer and are using dgit, you will need to do that
operation when you are incorporating a non-dgit NMU. Such an NMU will
be represented as an ad-hoc commit structure on the end of your
history.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21583.60381.571851.949...@chiark.greenend.org.uk
