Hello TAMUKI and a lot of others
(Cc: Various Debian people involved in $subject)
On 12/03/2011 01:09 PM, TAMUKI Shoichi wrote:
(Cc: TiMidity++ developers)
From: Hans de Goede<email@example.com>
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
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.
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
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
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
2) Add my patches
3) Bump the release to 2.14, bake a tarbal, release
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
About your other mails, I've read through them all to, thanks for
the updates. I'm going to reply to some of the things in there here,
to avoid spamming everybody with 4 mails on this topic:
> [known problems]
> * Checking for libOggFLAC fails. Note that libOggFLAC has been merged
> into libFLAC recently.
I don't see this as a problem, as you point out yourself, c has
been merged into libFLAC, so the check failing is to be expected. Maybe
we should change configure.in so that if it finds a new enough flac
it does not try to check for libOggFLAC. Other then that I think the
current behavior is fine, as the check is needed when building with
old flac libs. Although we should ask ourselves if we want to support
such quite old flac libs, or if we should just yank out the code for
> * The default of MAX_CHANNELS is 32. In the case of MAX_CHANNELS> 32
> (e.g. MAX_CHANNEL = 80,) Xaw interface does not work.
Hmm, if MAX_CHANNELS is a compile time define, which I think it is, this
is not really a problem as long as we don't change it. If it can be
changed runtime, we ought to fix the Xaw interface for this.
And for the benefit of the Debian people added to the CC, here are some
links from TAMUKI to tarbals of his latest work:
On 12/09/2011 11:25 AM, TAMUKI Shoichi wrote:
> Here are the tarballs created with ./release.sh "2011-12-09 00:00:00".