Hi Adrian (and others),

First of all: Congratulations with your new title as Debian Maintainer!!

On Mon, Mar 01, 2010 at 11:09:21PM +0100, Adrian Knoth wrote:
I have three things I want to add to the ffado package, one is the Juju patch, second is the binutils-gold fix and the other is the -dbg package.

The Juju patch is the one that I tested earlier on, right?

I thought before I start working on it, I'll ask you if you have a
clever idea how to achieve this.

First, I need to integrate the two patches:


which fixes #555176 and


for #565342.

Nothing special so far.

So above contained no questions, right - just info on current status?

For the -dbg package, I need to rerun scons with DEBUG=1 and put that library into a new package. I hope that "Replaces: libffado2" would do the trick.

Is there already some CDBS magic for this use case?

There is some general CDBS routines used by other build systems, and I would really want to integrate those with SCONS too. Unfortunately I lack knowledge on both :-/

I believe that the general logic of -dbg packages is to *not* compile specially, but compile once with debug enabled, and then for the normal package strip the debug symbols and have the -dbg package provide (using dpkg-divert?) binaries containing those symbols.

Without looking closely at it yet, I seem to recall that CDBS has a pattern of noticing if a package ends in -dbg and then do not strip debug symbols. I need to check if it does so always or only for known working build systems.

Do DEBUG=1 trigger other changes than building with debug symbols? I mean, would it hurt (e.g. performance or reliability) to always enable?

And last but not least: such a new libffado2-dbg package would need a DD to upload, my DM status doesn't allow that. So if you like, go ahead ;)

I don't sponsor packages!

I do, however, happily upload packages that I am directly involved in maintaining - i.e. those that I have dived in and applied my copyright-check.mk and other magic on, so I feel confident about the packaging quality.

So tell me if you would want me to get my hands dirty on the ffado package (or vice versa), or you'd rather look elsewhere for simple sponsorship.

If you do want me to work with you on the package, it off course does not mean that you preapprove any and all changes that I make. Please do tell me if anything I do you don't understand - or you do and disagree with it. :-)

PS: There's also ffado trunk. It has all the required patches and it supports more devices, foremost all DICE based audio interfaces. The code is really stable, the only broken stuff is half-working code for the RME Firewire, which is off by default.

So instead of applying patches in the Debian package, we could simply go for libffado2-2.0.0+svn1804-1. This would increase the user base and saves us some work.

(I'm not a fan of local patches. If it affects everyone, it should be patches upstream. Consequence of this paradigma is that you end up packaging svn/git versions, but pro-audio is bleeding edge anyway ;) )

I prefer to use a stable baseline, and if upstream is slow at releasing new stable stuff , then I cherry-pick when I have enough time to do so. That way I am free to have different ideas on when to apply soname-bumping changes etc.

It might seem sensible to follow a development branch when it currently is "reasonably stable", but this might change in the future - development branches almost by definition are places without promise of stability :-)

Have a look at the ghostscript packaging, where I (in the 0* patches) cherry-pick from upstream development what looks both stable and non-intrusive (does not depend too much on each other, so that single patches can be disabled again if need be).


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to