On Tue, Aug 24, 2010 at 10:24:25PM +0200, Rémi Duraffort wrote:
Le mardi 24 août 2010 à 09:33:56, Jonas Smedegaard a écrit :
[sent again, to proper mailinglist this time]

On Tue, Aug 24, 2010 at 07:08:32PM +0000, ivoire-gu...@users.alioth.debian.org wrote:

   Some patches to add a missing license and fix some typos.

diff --git a/debian/gbp.conf b/debian/gbp.conf
index 8e96d07..1ee58fc 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,4 @@
pristine-tar = True
compression = bzip2
+ignore-new = True

Above is not a patch.
You are right I might have split it in two commits.

Also, I find it unwise to enable that option - if source is not clean after build + clean then something is wrong which should be fixed instead.
I'm usually doing git-buildpackage, change something, commit it and then git-buildpackage again. The second one complain. It does not complain if I add this option (but I can do a dh_quilt_unpatch before git-buildpackage if this option is not recommended)

git-buildpackage currently do not work 100% with quilt variant of source format 3.0.

What I personally do after clean is this - manually:

  QUILT_PATCHES=debian/patches quilt pop -a
  [check that .pc is virtually empty]
  rm -rf .pc

I dislike integrating above with packaging rules, as I consider the issue a bug/limitation in either or both of git-buildpackage and dpkg, so "fixing" it in packaging really means covering over a bug somewhere else.

Others in this team disagree with me.

Some git-ignore .pc subdir.

Some implement quit-unrolling in clean rule or some other rule.

I believe that your above approach (I notice that you since reverted it) is bad even if you find my approach too complex/stupid/whatever: it ignores *any* changes in source, not only the patches.

Hope that helps.

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to