ffado updates

[Jonas Smedegaard]

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:
>
>   http://subversion.ffado.org/changeset/1778
>
>which fixes #555176 and
>
>   http://subversion.ffado.org/attachment/ticket/261/ffado-2.0.0.patch
>
>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).


Regards,

  - 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/20100302/10eea6cd/attachment.pgp>