On Fri, Apr 02, 2010 at 10:36:12AM -0400, Felipe Sateler wrote:
On Thu, Apr 1, 2010 at 16:42, Jonas Smedegaard <d...@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), j...@users.alioth.debian.org wrote:The following commit has been merged in the master.jackd2 branch: commit b24e80575850b4cd75c60550c52da99f3dab83e5 Author: Jonas Smedegaard <d...@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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
