Re: [Spice-devel] Bug#603699: ITP: celt051 -- The CELT codec v0.5.1
Hi, The reason spice is still using celt-0.5.1 is that celt as a protocol / format is considered not finished yet by celt upstream and thus the bitstream format may change (and does change) with every new upstream release. In order to provide compatibility between different spice client and server versions we've frozen the celt bitstream protocol as used in spice at version 0.5.1 On 11/17/2010 04:25 AM, Liang Guo wrote: Add Cc to spice-devel list On Wed, Nov 17, 2010 at 5:11 AM, Adrian Knoth wrote: Ok, you'll lose backward compatibility to non-celt-0.9 installations already deployed and not being able to update... but who's using them? And who will be using them by 2011? RHEL6 and fedora are using spice with celt051, even if after several years development, spice can use a stable version of celt(maybe 1.0), spice may consider backward compatible to support celt051 in the future. so there will be plenty of spice server with celt051 support for many years. If there's such a legacy user base, then I suggest to embed your private copy of celt-0.5.1 into the spice client source. For everyone else, it's the wrong signal to expect any CELT version (below 1.0) to be widely installed anywhere. So strictly speaking: it's possible for spice to support more than one celt version (as shown above) without ruining backward compatibility. In Debian, only provide the newest celt version. If need be, embed celt-0.5.1 into spice, but the other approach would be to entirely ignore this 0.5.1 thing. This way, there'll be support for newest celt with the fallback to raw audio transfer (DATA_MODE_RAW). It looks like we have following options: 1 Package celt051 and spice in Debian, for spice and packaging works, it is a good option, after spice switch to the latest version celt and not use celt051 any more, we may remove celt051 in Debian archive. but there will be two different celt version 0.5.1 and the latest in Debian. Yes this would be the right solution. Note I think it would be great to have spice in Debian and I would be happy to help with any issues you may encounter. 2 Embed celt051 to spice, this option will add workload and complexity of packaging, and violate the Debian Policy 4.13[1], the advantage is Debian have only one version of celt. Although I'm only one member of the spice upstream team / community I think I can speak on behalf of upstream when saying we won't take patches to enable something like this. You're of course free to patch configure and the Makefiles in Debian to enable this, but we won't take such patches upstream. 3 Patch spice to remove depends on celt0.5.1, just let spice use only RAW codec. When connect to spice server. other spice client connect to Debian spice server, we will get high latency, high bandwidth consume audio. I'm not sure this option works. Please do not do this, this may break compatibility with none Debian spice versions and even if it does not it will make us look bad. 4 Do nothing, wait spice to switch to latest celt, or work on spice to switch to latest celt or at least support latest celt and celt 0.5.1, it will be matter long long before. Within this period, Debian can only run as a RHEV or spice-enabled qemu Guest OS. Again I'm only one member of the spice upstream team. But AFAIK our (upstreams) stance on this is that we won't switch to a newer celt until the bitstream protocol is stable, if at all. The if at all part depends on if it will be doable without too much pain to support both celt-0.5.1 and celt "1.0" in the same binary. This is important to us as we care a lot about protocol compatibility. Which is in downstreams best interest too btw, otherwise one gets a situation like with unison were distros need to package multiple versions so that users can talk to different servers with different versions, ie in Fedora we have both unison213 and unison227. Thanks & Regards, Hans -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce386e6.8040...@redhat.com
Re: [Spice-devel] Bug#603699: ITP: celt051 -- The CELT codec v0.5.1
Hi, On 11/17/2010 01:04 PM, Ron wrote: Hi Hans, Hans de Goede writes: The if at all part depends on if it will be doable without too much pain to support both celt-0.5.1 and celt "1.0" in the same binary. This is important to us as we care a lot about protocol compatibility. Are you seriously telling me that you have no plan whatsoever for how to transition from a random snapshot of an experimental codec, except to hope that somehow it might in some way become embedded in some other binary for the rest of eternity? In retrospect the decision to use celt may not have been the best, and chances are we will support another form of compressed audio besides celt in the near future. Then we will likely drop celt-0.5.1 in a few releases. But for now we are stuck with a celt-0.5.1 dependency as we are committed to maintaining wire protocol compatibility. Regards, Hans -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce3e56e.7000...@redhat.com
Re: Bug#649274: Forming a new upstream for timidity (and reporting various issues with current deb pkg)
Hi, On 11/19/2011 04:39 PM, Neil Williams wrote: On Sat, 19 Nov 2011 15:05:00 +0100 Hans de Goede wrote: This is a bit unusual bug-report I'm afraid normally I would've send this as an email to the Debian package maintainer of timidity, but it seems that timidity is currently orphaned in Debian :| There has been no interest from anyone wanting to take over Debian maintenance of timidity since the previous maintainer orphaned it. It now has a release critical bug because the current source fails to build. The bug has been open for 3 months and is sufficient reason to remove timidity from Debian today. As you've expressed some interest, I'm willing to not file the removal bug right now but that doesn't exclude someone else doing precisely that. In case this much was not clear already note that my interest does not extend to actually maintaining the Debian package myself. Given the status of the package in Debian, it is more likely that timidity will be removed rather than updated. Understood, I'm just trying to inform anyone who may pick up timidity for Debian about my work, so that they don't start from scratch. Maybe once there is a functioning upstream and a new upstream release, someone may reintroduce the package into Debian. CC'ing the only person to express some interest. Geoffrey, if you are no longer interested in timidity, despite signs of interest from a possible new upstream, please retitle #585039 as O: instead of ITA: Hans: have you any clues about the pulseaudio issues? Joost Yervante Damad comments in the bug report orphaning timidity: If you want to take over maintenance, be prepared to deal with obscure pulseaudio issues. #585039 I know of no pulseaudio issues, but note that in Fedora, the default timidity config will first try to use pulseaudio through libao's pulse support, before trying alsa (which will end up using pulse through an alsa plugin) I know that I'm the one who made that change, it could very well be that I did that because when timidity uses alsa directly it does so in a way which is not compatible with pulse. Note that we've had no issues with timidity which are pulse related for a long time know, so I would not worry about this. I think it would also be a very good idea, Hans, if you put a short message on bug #585039 about your interest in a new, fixed, upstream release as this will be one of the places people will look before seeking removal of timidity. That said, interest from upstream is not of itself going to stop removal from Debian. The reason I'm sending this mail is because one of the Fedora packages I (co)maintain is timidity. Recently we got a number of bugreports related to timidity, and one of the conclusions was that timidity needs some love. I sympathise, I've felt the same about other packages and gone into the cycle of getting the SourceForge project re-assigned, porting the code to current libraries and systems, only to find that the codebase really cannot sustain a second transition or some dependency simply becomes abandonware. The workload can gradually become unsustainable and sometimes it's simpler to just accept that the package has had too much bit rot already and it would be easier to drop it. I hear you loud and clear (similar experiences on my side), but in the case of timidity I think keeping it alive is important, because it is one of the few software wavetable midi synths we have (and as such has unfortunately been forked into SDL_mixer, libtimidity and too many others). I also went through all the changes in the Debian package, and were relevant have added those too. Note that I deliberately did not include a few of the changes from Debian, as I believe they are wrong! See below for details. As the potential new upstream, you are welcome to make that decision. It's better for Debian if there is just a new upstream release and then someone with sufficient interest (not me!) can look at what might need to be done to bring the Debian package up to date. Ok, note though that I'm not all too familiar with timidity internals myself, hence my attempts to explain my decisions, so that others can inspect them if they want to. Sadly, it is more likely that timidity will have to be removed and then, possibly, reintroduced if (and only if) someone reading this message gets sufficiently motivated to work on timidity in Debian. Understood. So now I've a nice and polished version of timidity, and given that the latest official release has been 6 years ago I think it would be good to do a new official release, hence I've contacted the current admin and developers of the sf.net timidity project, hopefully they will allow me to take over the sf.net project, I would have loved to work together with the Debian maintainer on forming a new upstream, but alas. When there is a new release available via SF or some other site,
Re: Bug#649274: Forming a new upstream for timidity (and reporting various issues with current deb pkg)
Hi, On 11/19/2011 09:59 PM, Geoffrey Thomas wrote: On Sat, 19 Nov 2011, Neil Williams wrote: CC'ing the only person to express some interest. Geoffrey, if you are no longer interested in timidity, despite signs of interest from a possible new upstream, please retitle #585039 as O: instead of ITA: Thanks for Ccing me. The "real world" had caught up with me a bit this semester, both in terms of taking away time for non-academic technical work and for writing music, but I'm graduating soon and done with interviews, so I have more time now (and have a laptop running testing) and do intend to maintain it. I'd given my sponsor a debdiff to adopt the package and fix the FTBFS. I think we'd just both forgotten about it -- I've just poked him about uploading it. Hans, thanks for the patches and review, and I'll try to take a look at them over the next few days. I'd definitely be interested in contributing to a revived upstream -- yes, timidity does need some love. :) That is great to hear! Let me know if you've any questions. Note that my patches are based on the current CVS code, not on the latest tarbal! I'm afraid that I'm not getting anywhere so far with my attempts to take over the current sf.net project, my mail to all the developers and the single admin it has now has bounced for at least the admin. I'll try to contact the sf.net staff, but AFAIK they no longer allow taking over projects without help from one of the former admins. Regards, Hans -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec8dc03.2000...@redhat.com
Re: Reviving timidity sourceforge project and doing a new official release
Hello TAMUKI and a lot of others (Cc: Various Debian people involved in $subject) On 12/03/2011 01:09 PM, TAMUKI Shoichi wrote: Hello Hans, (Cc: TiMidity++ developers) From: Hans de Goede So now I've a nice and polished version of timidity, and given that the latest official release has been 6 years ago I think it would be good to do a new official release. Thank you for your great effort to maintain TiMidity++ package for Fedora project. I looked into your patches, and I think they are almost fine. Thanks you for taking the time to look into all my patches and to merge most of them! And I must also say I'm very happy to see one of the original timidity developers back in action. You very likely know the timidity internals a lot better then me. The patch 0004 (thanks to Debian) fixes a number of typos in the man pages, but the hunks related to "FILES" and "SEE ALSO" will be omitted to leave them just as they are. Ok. Sorry, the patch 0005 seems to be ad hoc, so this will be omitted. I think that cases may be solved by the packagers' workaround and/or users' operation. Well it cannot be fixed by the users operation, unless they use scripts to move one config file out of place and another in to place whenever they start one of the involved apps. The fundamental problem is that now a days we've multiple apps using timidity.cfg and all but one of them expect timidity.cfg to point to GUS format patches. Anyways I'll start a separate email thread for this mostly aimed at explaining the problem to the Debian developers and try to come up with a solution which can be shared between Debian and Fedora. Once we (Debian and Fedora) have a consensus on how to handle this, I hope you will re-consider merging our solution. The patch 0011 will be also omitted. These shebang paths need to be corrected by packagers for now. TiMidity++ is conventionally designed for casual users' convenience. (i.e. ./configure with default prefix) :-) I see in a later mail in this thread that you've merged it after all in a slightly different version, thanks for that! For the patch 0013, autoreconf vs INSTALL issue should be solved by the packagers workaround as needed, so this patch will be omitted. I agree that my solution for this was not pretty, so instead I've now created a new autogen.sh file (attached), which takes care of re-generating *all* the autofoo related files while keeping INSTALL intact. Please add this to the cvs tree, and be sure to chmod +x it before adding it! While on the subject of all the autofoo generated files, must FOSS projects do not keep these in CVS/git instead users of the CVS/git tree are expected to run ./autogen.sh after a checkout. This avoids cluttering the history with changes to autogenerated files. I strongly believe we should adopt the same practice for timidity. With the patch 0018, I got a "undefined reference to" error during linking, so this patch will be also omitted. Patch 0018 should not be omitted it is definitively a correct patch, if timidity is build without any X11 based userinterfaces build in, it should not be linked against libX11, this is important for distributions, otherwise the cmdline only timidity package will depend on X11 for no good reason. I believe the "undefined reference to" error you got during linking means that you've build in a X11 based userinterface, and that we've a bug in the Makefiles where enabling that ui does not cause -lX11 to be added to the LIBS. But the code patch 0018 removes causes lX11 to be added to the LIBS always, iow independent of which UI's are enabled and that is just wrong. Can you please give me the ./configure line you were using which causes the "undefined reference to" errors when building with patch 0018? Then I'll try to reproduce and come up with a proper fix. As such I would like to ask you to become an admin for the sf.net timidity project, once that is done I plan to: 1) Create a (sf.net hosted) git tree based on converting CVS to git 2) Add my patches 3) Bump the release to 2.14, bake a tarbal, release 4) profit? That's not a bad idea to convert CVS to git, but we are not in trouble for now, so please let us keep the current environment. FYI, TiMidity++ hourly tarballs and released tarballs are created with attached shell scripts respectively. All files in the tar ball keep mtime as committed to see easily which files are newer or older. Note that some files was given wrong access perms when the initial commit. Therefore, their access perms should be corrected after cvs co. I would *really really* prefer to move to git, as once you get the hang of it is just so much easier and better then CVS. For example in git you can change permissions of files after there initial adding to the repository :) About your other mails, I've read through them all to, thanks fo
