[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4

[Jonas Smedegaard]

On Fri, Apr 02, 2010 at 10:36:12AM -0400, Felipe Sateler wrote:
>On Thu, Apr 1, 2010 at 16:42, Jonas Smedegaard <dr at jones.dk> wrote:
>> On Thu, Apr 01, 2010 at 09:12:03PM +0200, Reinhard Tartler wrote:
>>>
>>> On Thu, Apr 01, 2010 at 15:22:01 (CEST), js at users.alioth.debian.org wrote:
>>>
>>>> The following commit has been merged in the master.jackd2 branch:
>>>> commit b24e80575850b4cd75c60550c52da99f3dab83e5
>>>> Author: Jonas Smedegaard <dr at jones.dk>
>>>> Date:   Thu Apr 1 15:09:44 2010 +0200
>>>>
>>>>    Use source format "3.0 (quilt)" (not CDBS simple-patchsys.mk).
>>>
>>> I think the current consensus is to avoid format "3.0 (quilt)" until
>>> support for VCS and helper tools like git-buildpackage improves.
>>>
>>> See e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 for an
>>> elaborate description of this.
>>>
>>> Until we have a clear idea on how format 3.0 (quilt) should be used with
>>> git-buildpackage, I'd suggest to revert this change.
>>
>> Current consensus where? In the Multimedia team?
>
>Yeap. See the log of the first IRC meeting.

Ahhh, thanks!

I read the summary as the new source format need not be recommended yet, 
which I see as something else than outright avoid it.

But hey - I did not attend the meeting, so if you tell me that the 
minutes are ambiguous or outright wrong and the real decision at the 
meeting was to not (yet) use the new source format at all(!) for 
packages in this team, then I cannot argue with that.

Is that what you are telling me?


>> I fail to understand how a wishlist issue like bug#572204 should stop 
>> us from using the new source format.
>>
>> If anyone is confused about how the new format works and can 
>> integrate most elegantly with our packaging style (which is similar 
>> but not entirely the same as the preferred one of Colin Watson) then 
>> let's discuss it - I believe I have found a useful set of routines, 
>> which could be put into README.source.
>
>I think the main issue is working with applied patches _and_ a
>debian/patches dir... If one does not use --export-dir
>git-buildpackage fails miserably.

True, git-buildpackage does not support applied patches commit'ed to Git 
- which seems to be Colins preferred VCS usage style in bug#572204.

What I do instead is to commit only unapplied patches (the files below 
debian/patches/ ),_not_ the applied ones.

This should work well with git-buildpackage - either using --export-dir 
or (my preferred style) by manually flip back and forth between "dpkg" 
and "git" mode using "quilt push -a" and "quilt pop -a".

Only odd thing I have experienced so far is that if breaking a build 
prematurely (e.g. in the middle of a configure) so than the clean rule 
does not cleanup properly, then dpkg automagically preserves the noise 
as a patch.  But this is actually not a regression but an improvement 
compared to old pre-source-format-3.0 days when similar cleanup breakage 
would be difficult to cleanup again - now it is as simple as removing 
the autogenerated patch and related entry in debian/patches/series.

Oh yeah, there's also that other little annoyance if working on top of 
the VCS (as opposed to using --export-dir) that git-buildpackage refuse 
to run when there is a .pc folder.  One way of solving that is to 
git-ignore it.  Personally I avoid custom gitignore for the same reason 
that I avoid --export-dir: I want Git to help me reveal oddities of the 
build routines so do not want to hide any of it.


Kind regards,

  - Jonas

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

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100402/94a93eac/attachment.pgp>