[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4
dr at jones.dk
Fri Apr 2 18:51:29 UTC 2010
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.
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.
* 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
Size: 836 bytes
Desc: Digital signature
More information about the pkg-multimedia-maintainers