[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4
dr at jones.dk
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/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
...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
>>> waf configure --prefix=/usr $(MIXED_FLAGS) --firewire --alsa --classic --dbus
>>> touch $@
>>> 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 $@
>> rm -f debian/stamp-waf-configure
>> +# Un-apply patches left behind with source format 3.0 (quilt)
>> +clean:: unpatch
>> 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
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
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:
>>>@@ -0,0 +1,2 @@
>>>+# use debian/patches/debian-changes as automatic 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.
>>> However, we mustn't forget to add our conclusions to
>> 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,
>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
>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 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