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

Mon Apr 5 11:31:05 UTC 2010

On Mon, Apr 05, 2010 at 10:39:55AM +0200, Reinhard Tartler wrote:
>On Mon, Apr 05, 2010 at 00:34:47 (CEST), Jonas Smedegaard wrote:
>>
>>
>>>@@ -3,6 +3,7 @@
>>> -include /usr/share/cdbs/1/rules/upstream-tarball.mk
>>> include /usr/share/cdbs/1/rules/utils.mk
>>> include /usr/share/cdbs/1/rules/debhelper.mk
>>>+include /usr/share/cdbs/1/rules/patchsys-quilt.mk
>>> include /usr/share/cdbs/1/class/makefile.mk
>>
>> ...because adding above cause the package to need to build-depend on a
>> few additional packages.
>
>quilt, yes. is this a problem?

No no, just trying hard to sneak in an advertisement for another feature 
of CDBS.

...and no, it is not inly quilt it adds build-dependncy on: Try 
autoresolving and see:

   DEB_MAINTAINER_MODE fakeroot debian/rules clean
   git diff debian/control

Hmm - and while writing this I get an idea for an improvement to CDBS: 
build-depends-reason hints!  Now that recently I've managed to handle 
each set of added build-dependencies as a separate chunk and only merge 
when applying, it should be possible to add hints explaining the reason 
for each chunk (e.g. point to specific places in Debian Policy, Debian 
Python Pilicy, Python Policy, Perl Policy etc., and print those hints 
when in DEB_MAINTAINER_MODE.  Maybe even detect which are _newly_ added 
and treat them as *error* when in DEB_MAINTAINER_MODE to raise 
awareness.

>>> debian/stamp-waf-configure:
>>>        waf configure --prefix=/usr $(MIXED_FLAGS) --firewire --alsa --classic --dbus
>>>        touch $@
>>>-clean::
>>>+clean:: unpatch
>>>        rm -f debian/stamp-waf-configure
>>
>> I recommend to keep unrelated routines separate, even if it causes 
>> the rules file to be slightly larger, and document unclear intends:
>>
>>
>>         touch $@
>>  clean::
>>         rm -f debian/stamp-waf-configure
>> +
>> +# Un-apply patches left behind with source format 3.0 (quilt)
>> patches
>> +clean:: unpatch
>> +
>
>ok
>
>> Also, above always un-applies, not only when using git - I am uncertain
>> if that will cause problems somewhere.  Not sure waht that might be,
>> just worried...
>
>okay, then I'll need to extract some logic from patchsys-quilt.mk

Ah!  When I opened my eyes this morning (i.e. a moment ago - I watched 
movies with my step kids until 5 tonight) I remembered/realized a need 
for improvement in the above:

When we do

   clean:: unpatch

then unpatching happens _before_ clean rules.  And if parallellism is 
enabled even the order of those before-clean rules is uncertain.

So we should instead do

   clean::
         quilt pop -af

and in addition we should a) put that rule at the bottom of the rules 
file and b) explicitly set the number of allowed CPUs to 1, both of them 
to ensure (as best as we can) that patches are unapplied _last_.

Also, when we use the patchsys-quilt snippet we include not only our own 
clean-at-build but also patch and unpatch rules that I suspect some 
build routines may probe and use if found - which is bad as we most 
probably rely on source being patched early on.

Hmm, maybe we should actually ensure early patching, not just rely on 
dpkg doing it for us early enough.  I have had some odd experiences when 
invoking build rules expicitly to regenerate copyright hints that it was 
wrongly done on unpatches source.

>>>While we are at it, I'd suggest this change as well for Format 3.0
>>>packages in general:
>>>--- /dev/null
>>>+++ b/debian/source/options
>>>@@ -0,0 +1,2 @@
>>>+# use debian/patches/debian-changes as automatic patch
>>>+single-debian-patch
>>
>> Why?  I would consider autogenerated patches an error anyway, so do 
>> not care about its naming.
>
>The manpage recommends it this way, as when working in a VCS, the 
>version number, and therefore the file name of the generated patch is 
>meaningless if not wrong. Foring a stable filename ensures that changes 
>go into a single patch.
>
>If we consider these autogenerated patches an error, this way we can 
>extend debian/rules to check for existance of this file, and abort with 
>an meaningful error message.

Good point.  I am still not sure it is really necessary to add custom 
configuration, though: I suspect (but haven't investigated yet) that we 
can simply check for a pattern of autogenerated filenames - or simply 
check (using a checksum) that the series files does not change 
underneath us - which might protect against other kinds of automated 
surprises in the future.

>>> Ok, I think we agree here. Let's start with a wishlist bug against 
>>> devscripts for licensecheck2dep5. Do you want to file or shall I?
>>
>> Go ahead and do it.
>
>See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472199

Thanks!

>>> However, we mustn't forget to add our conclusions to 
>>> http://wiki.debian.org/DebianMultimedia/DevelopPackaging
>>
>> Hmm.  I am unsure what is policy and what is suggestions and what is 
>> my stubbornness in what we've discussed here - so please you do that, 
>> ok?
>
>Well, that's the problem. Now that we allow both cdbs and debhelper, 
>both format 1.0 and 3.0 patches, the page now becomes terribly 
>convoluted. I fear we need more discussion to streamline what we 
>actually want.
>
>I could imagine that we agree on a default workflow, which is applied 
>to all packages but exceptions, and list the excepted packages there.

Fair enough.  I have now subscribed to changes to that wiki pages, and 
am willing to help maintain it.

Please do ping me explicitly, though, if there are some things you feel 
the need for me to edit or for us to discuss, as I am involved in 
maintenance of 100+ packages and (try to) have a life aside too :-)

Or expressed differently: I am a bit of a lonely rider if not pushed 
into other workflows.  Please help push me from time to time :-)

  - 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/20100405/b407ad76/attachment-0001.pgp>