Hi guys, :) Le vendredi 02 septembre 2011 à 09:31 +1000, Peter Drysdale a écrit : > Dear Sergio, > > > > My testing agrees it is backward compatible. > Their appears to be merit in this patch whether of not > upstream adopts it. > Thanks again. As you may know, upstream is not very active > (does not release often), although I will submit this patch > once it gets into Debian (if it is "approved in Debian" then > it is easier for me to tell upstream to consider it). > > Thanks for your contribution. We'll try doing the best with them. > > > Please note it is my current understanding that Debian sends all > applied patches upstream for consideration > without prejudice to upstream. Patches may be applied to a Debian > package for reasons of satisfying the > Debian Policy document and to fix bugs. There is no reason to expect > upstream to adopt patches - it is entirely > at their discretion. Festival has a number of patches including to > languages.scm > which are convenient for Debian packaging and interoperability which > have not been adopted by upstream.
You're right. However, except for specific packaging Debian patches, if there're some patches to fix bugs or improve the application, we prefer upstream to apply them, or explaining why they do not. In other words, when our package works fine with our patches, I plan forwarding to upstream to see if they want, why they don't and what is the solution. Ideally Debian needn't patching, upstream patches with our suggestions, we only patch for specific Debian reasons. > Festival is a research software for an upstream serving a very active > research community. In a sense it is quite different > to a number of packages in Debian which are written predominantly for > a non-expert end user. As such it > might be expected that Debian's focus and upstream's focus differ. ok why not. But in such case maybe it'd be a good idea to see the comunity's position and, optionally, having git/svn access to maintain the upstream code, patching, etc. so that Debian doesn't differ so much I think. But of course, let's start fixing and improving at Debian level, it'll be easier. > > > I am quite new to the Debian policies and maybe this is not > the place to ask, but have you considered fixing this wish > (#638394) [1] in libestools? The libestools patch [2] and a > simple rebuild in Festival would provide native ALSA support > and fix possible audio latencies deriving from the use of > aplay. Moreover, the aplay commands in /etc/festival.scm would > not be needed anymore, and we could let festival to autodetect > the audio module for linux and non-linux users. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638394 > > [2] > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=NativeALSA_fixed.patch;att=2;bug=638394 > > > As mentioned earlier Jean-Philippe and myself have only just started > working on festival. I had already seen your other bug > report. To some extent this will be influenced by the outcome of how > the "hanging" bug is ultimately resolved. > I have started playing with the patch though :-). The altered latency > was the first thing I noticed :-). > We should probably discuss this on that bug report's thread. If you > can wait a week while I get a longer time to > use the native alsa I can contribute to a more considered discussion. Cool. I will be happy with your analysis. I'll talk to you about the current situation of the package after I applied your 3 1st patches. Thanks and best regards, > > Thanks and best regards, > > Sergio > > best regards, > Peter > > Jean-Philippe MENGUAL
signature.asc
Description: Ceci est une partie de message numériquement signée
