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
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
