On Wed, Sep 18, 2013 at 05:42:17PM +0100, Ian Jackson wrote:
Adam Borowski writes
Here's one way:
rm -rf .pc debian/patches
echo single-debian-patch debian/source/options
The rm needs to be repeated, either in the clean target or perhaps by
dgit.
I don't think removing .pc and
On Wed, 18 Sep 2013, Ian Jackson wrote:
I don't think removing .pc and debian/patches will DTRT because
dpkg-source -x will produce a directory containing them. dgit's idea
of the source tree from the source package is whatever dpkg-source
-x produces.
You could decide that the canonical
On Thu, Sep 19, 2013 at 04:25:06PM +0200, Adam Borowski wrote:
[...]
I don't understand the arguments against 3.0 (git). For every 3.0 (quilt)
package, you can produce a 3.0 (git) with exactly the same data (but not
metadata[1]) bits.
It is claimed that it can smuggle some not visible
Ben Hutchings b...@decadent.org.uk writes:
Of course unreachable objects should be pruned from a 3.0 (git) package.
But I believe the FTP team's concerns are about *reachable* objects that
may be copyright violations. It is hard enough to check this for one
version.
I think Adam's point is
On Thu, Sep 19, 2013 at 11:31:32AM -0700, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk writes:
Of course unreachable objects should be pruned from a 3.0 (git) package.
But I believe the FTP team's concerns are about *reachable* objects that
may be copyright violations. It is
Russ Allbery r...@debian.org writes:
Adam Borowski kilob...@angband.pl writes:
You can trim the history at any commits you want.
Trimming the history of commits doesn't help. In order to have
something that's equivalent from a license review standpoint, you have
to rebase all of the
Adam Borowski kilob...@angband.pl writes:
On Thu, Sep 19, 2013 at 11:31:32AM -0700, Russ Allbery wrote:
I think Adam's point is that there's a one-to-one correspondance
between a 3.0 (quilt) package and a 3.0 (git) package that consists
solely of an import of the most recent upstream source
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Or do you mean that you have files in your git branch which are removed
by debian/rules clean ? (I'm no longer ruling anything out merely on
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
No, I mean the upstream tarball contains autotools-generated files that
debian/rules deletes (and that aren't in my, or upstream's, git tree).
dpkg-source ignores removals when generating the debian
On Wed, 2013-09-18 at 14:16 +0100, Ian Jackson wrote:
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
No, I mean the upstream tarball contains autotools-generated files that
debian/rules deletes (and that aren't in my, or upstream's, git
Ian Jackson ijack...@chiark.greenend.org.uk (2013-09-18):
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
No, I mean the upstream tarball contains autotools-generated files that
debian/rules deletes (and that aren't in my, or upstream's, git
Steve Langasek writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Tue, Sep 17, 2013 at 07:19:22PM +0100, Ian Jackson wrote:
TBPH I think it's a bug if build followed by clean doesn't restore the
package to the state you got out of dpkg-source. I don't want
Ben Hutchings writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Example from sgt-puzzles:
override_dh_auto_clean:
! [ -f Makefile ] || $(MAKE) clean
$(MAKE) -f Makefile.doc clean
if [ -d .git ]; then\
On Wed, 2013-09-18 at 14:49 +0100, Ian Jackson wrote:
Ben Hutchings writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Example from sgt-puzzles:
override_dh_auto_clean:
! [ -f Makefile ] || $(MAKE) clean
$(MAKE) -f Makefile.doc clean
if [
On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
No, I mean the upstream tarball contains autotools-generated files that
debian/rules deletes (and that aren't in my, or upstream's, git
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:
Julien Cristau writes (Re: Status of dgit (good for NMUs and
fast-forwarding Debian branches)):
No, I mean the upstream tarball
Cyril Brulebois writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Charles Plessy ple...@debian.org (2013-09-18):
for a small native package that I prepared, I would like to indicate dgit's
repository as VCS in its source control file (Vcs-Browser and Vcs-Git
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
This is common. Usually it's because upstream ships generated files in
the upstream tarball as well as source files. As part of building the
Debian package from source, one wants to remove all generated files and
Adam Borowski writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
Or you could simply ignore the format `3.0 (quilt)' thing entirely and
allow it to automatically accumulate one diff per upload, and
Ian Jackson ijack...@chiark.greenend.org.uk writes:
If your source package contains the files, and your git tree does too,
then you will find that debian/rules clean generates a dirty git tree.
How do you deal with this problem at the moment ?
Generally by not running debian/rules clean in my
Ben Hutchings writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Example from sgt-puzzles:
override_dh_auto_clean:
! [ -f Makefile ] || $(MAKE) clean
$(MAKE) -f Makefile.doc clean
if [ -d .git ]; then\
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Single-patch 3.0 (quilt) is still IMO insane. The droppings in .pc
and debian/patches (which require workarounds in dgit) also mean (for
example) that a debdiff of a one-line change contains a giant pile of
poo.
I don't understand what you
Ian Jackson wrote:
That it doesn't browse well is indeed annoying. On the server the
dgit suite branch ref names aren't in refs/heads/, which is needed to
stop git pushing to them by default. But that makes gitweb not show
them either. I'm open to suggestions for how to improve this.
If
My original announcement was quite cautious. I've also recently seen
an article in LWN which was also rather cautious. I think it's
probably a good idea to set out what the current state of play is:
dgit's current functionality seems to be in reasonably good shape, but
it lacks additional
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I should also mention a non-goal:
...
* I have no plans to support a workflow where dgit's git tree
contains different contents to the
On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
I should also mention a non-goal:
* I have no plans to support a workflow where dgit's git tree
contains different contents to the source packages.
To me the tree that matters is the one after debian/rules clean, not
On Tue, Sep 17, 2013 at 10:54:57AM -0700, Russ Allbery wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
debian/source/local-options and debian/source/local-patch-header are
included in the working Git repository for the package but are not
included in the
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I guess that you think I'm saying that the series of git commits in the
dgit history must correspond to the series of patches found in the
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Does dpkg-source provide a way to collapse all the patches into one ?
If so you could use that before doing dgit push, and have much the same
effect.
Well, you can always run dpkg-source with --single-debian-patch and figure
out how to plug
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
I should also mention a non-goal:
* I have no plans to support a workflow where dgit's git tree
contains different contents to
Ian Jackson writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
In particular, if the package you are working with leaves droppings in
the source tree which its clean target doesn't pick up,
dgit sbuild -wg
will use git-clean to remove them before building the
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Or you could simply ignore the format `3.0 (quilt)' thing entirely and
allow it to automatically accumulate one diff per upload, and presumably
Steve Langasek vor...@debian.org writes:
On Tue, Sep 17, 2013 at 10:54:57AM -0700, Russ Allbery wrote:
Correct, and that's partly the point. It means that the maintainer
changes are collected into one patch, but NMU patches are kept separate
from that one patch. (So I guess I misspoke --
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
So dpkg-source strips these options files out when it builds the
package ?
Correct.
Oh my god.
Surely then if someone does an NMU based on
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Or do you mean that you have files in your git branch which are removed
by debian/rules clean ? (I'm no longer ruling anything out merely on
the grounds that it would be utterly insane...)
This is common. Usually it's because upstream
Ian Jackson writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Russ Allbery writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I should also mention a non-goal:
...
* I
On Tue, Sep 17, 2013 at 19:19:22 +0100, Ian Jackson wrote:
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
I should also mention a non-goal:
* I have no plans to support a
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
debian/source/local-options and debian/source/local-patch-header are
included in the working Git repository for the package but are not
included in the source package as uplaoded to Debian. (Yes, this means
that
On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
Does dpkg-source provide a way to collapse all the patches into one ?
If so you could use that before doing dgit push, and have much the
same effect.
Or you could specify the single Debian patch in debian/options rather
than
On Tue, Sep 17, 2013 at 11:27:08AM -0700, Russ Allbery wrote:
There used to be far more of these, but dh-autoreconf goes to the effort
of stashing the files and restoring them on debian/rules clean, since
someone did the effort of centralizing that support in one place.
Sadly, it doesn't - it
Colin Watson cjwat...@debian.org writes:
On Tue, Sep 17, 2013 at 11:27:08AM -0700, Russ Allbery wrote:
There used to be far more of these, but dh-autoreconf goes to the
effort of stashing the files and restoring them on debian/rules clean,
since someone did the effort of centralizing that
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I should also mention a non-goal:
* I have no plans to support a workflow where dgit's git tree
contains different contents to the source packages.
My view is that the source code is the source code. If something
is not needed
On Tue, Sep 17, 2013 at 07:19:22PM +0100, Ian Jackson wrote:
Julien Cristau writes (Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)):
On Tue, Sep 17, 2013 at 11:43:29 +0100, Ian Jackson wrote:
I should also mention a non-goal:
* I have no plans to support a
Le Tue, Sep 17, 2013 at 11:43:29AM +0100, Ian Jackson a écrit :
dgit's current functionality seems to be in reasonably good shape, but
it lacks additional features which are important in some workflows.
Dear Ian,
for a small native package that I prepared, I would like to indicate dgit's
Charles Plessy ple...@debian.org (2013-09-18):
Dear Ian,
for a small native package that I prepared, I would like to indicate dgit's
repository as VCS in its source control file (Vcs-Browser and Vcs-Git fields).
However, it does not clone nor browse well:
-
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ian Jackson writes:
I believe, if I understand this correctly, this will cause problems
for the use of local-options and local-patch-header to set
single-debian-patch for maintainer uploads.
I'm not sure what you mean, but I don't think
Steve Langasek vor...@debian.org writes:
My understanding is that the current policy implies that the
'dpkg-source -x' - './debian/rules clean' - 'dpkg-source -b'
round-trip should be idempotent for all practical purposes,
This is idempotent for many packages because dpkg-source -b ignores
47 matches
Mail list logo
