moto4lin, I give up.

[Kevin Kofler]

dragonauta x <dragonauta.x <at> gmail.com> writes:
> This is what I got on bugzilla:"I'm sorry, but this is still an upstream
> issue.  The fact that the upstream author has a patch that fixes this problem
> but is not releasing it in anofficial release does not make this a packaging
> issues, IMHO.

IMHO it does. Maintainers: In a situation like this, if there's a patch from 
upstream, please apply it!

If upstream only provides the fix in the form of a commit to SVN trunk, first 
try applying the diff from SVN to the release, sometimes it just works. If it 
doesn't apply, you have 3 options:
1. Try asking upstream (nicely) for a backport which applies to the stable 
release. Keep in mind though that the upstream author(s) might be very busy and 
do(es) not necessarily have the time to do backports.
2. Backport the patch yourself. This is often fairly easy.
3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real 
release for ages, this may well be the best option, however be careful, as the 
snapshot may also include regressions. It is usually a good idea to run the 
idea by upstream first, as for one they are likely to know about any 
regressions in the snapshots, and secondly, unfortunately some uncooperative 
upstreams may also get upset and hostile if you package snapshots (whereas 
others will even ask you to do just that, also depending on the state the code 
in SVN is in, thus the importance of asking).

If you have a ready-to-apply patch or if you use options 1 or 2, please don't 
patch the source tarball directly, use Patch0 (or Patch1, ...). If you use 
option 3, make your SVN checkout the new Source0.

> It is my position that bugs like this need to be fixed by an upstream
> release, particularly in cases like this.  Because upstream fixes help all
> distributions,and Fedora, effectively, forking it does not.

First of all: It isn't "forking" to backport a patch which is already in the 
upstream SVN trunk. It's even less "forking" to package something straight from 
the SVN trunk.

Secondly: Other distros will eventually get the fix because it's already in SVN 
trunk, so it will be in the next release. And if they want it first, they can 
backport it, just as you can.

Notwithstanding all the above: It would of course be better for all distros, 
including Fedora, if there was a new stable release with the fix. However, as I 
said above, upstream may be too busy to do backports, and unwilling to release 
from the current state of the SVN trunk for reasons unrelated to the fix 
(regressions etc.). So sometimes, backporting is really the only option.

> I don't believe it is Fedora's place to be tracking svn.

Then backport the fix.

If it doesn't apply to the stable version and you can't get it to apply, let us 
see the BZ report and the fix and I'm sure one of us will be able to help you.

> Does the upstream maintainer have a good reason for not having a real release
> that fixes this?

You have to ask this question to upstream themselves. :-)

        Kevin Kofler