On Tue, Aug 24, 2010 at 23:05:46 (CEST), Jonas Smedegaard wrote:
> 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
>> 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.
That's why I was at first against adopting format 3.0 for this team.
> 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
indeed, and I at some point asked to integrate it into debian/rules to
streamline the workflow on Fromat 1.0 and Format 3.0 (quilt) packages.
> Others in this team disagree with me.
> Some git-ignore .pc subdir.
seems same to me, as dpkg ignores it as well per default (well, at least
with the option -i)
> Some implement quit-unrolling in clean rule or some other rule.
I think the clean rule is the right rule for that.
please note that if you do that, you also need to make sure additionally
that patches are being reapplied just before the build.
the obvious drawback is that patches are applied and unapplied unnecessarily.
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list