Yeah, I messaged the project maintainer who had made the latest
patches, but we'll see what happens.  That is why I have also made a
patch against the Ubuntu package.  If the upstream patch gets delayed
from inaction, I'll start pestering people until one of the package
maintainers does something about it.  I've been using this patch daily
in a production environment with no issues.  If the package
maintainers won't do anything, I'll just build a .deb package and post
the URL.  I hear all this "if you don't like it, submit a patch" talk,
but when someone finally builds a patch, they have to jump through
hoops to get it applied.  I have to contact upstream, then Debian
package maintainer, then Ubuntu package maintainers.  This has got to
be a major deterrent to anyone wanting to distribute code.  My patch
is really simple, easy to read, and almost an exact copy of the
existing disk redirection patch which was applied by package
maintainers because upstream won't do anything.  It can't be that hard
to review, test, and make a new package revision.  I would hope that
issues like this would be brought more to light from the wine DIB
discussion, but I'd bet that's asking too much as well.

My big problem is that I emailed the package maintainer listed for the
package, but it was just the generic package maintainers for Ubuntu.
If an email is listed as a package maintainer, the person at that
email should be someone who can execute action, not just tell me "go
upstream" when I know damn well that upstream isn't doing anything on
the project.  I guess that if I don't hear anything in the next few
days, I'm going to start sending emails to everyone I can find until
someone gets pissed off enough to just apply the damn patch.

As a side note, this is a pretty ridiculous feature to be missing from
the application.  The application is well thought out and easy to use,
as well as extremely useful for those who need it.  What I don't
understand is why the printer redirection wasn't included in the first
place.  Imagine if any commercial company had released this
application in the state that it's in.  They would get rave reviews -
easy to use, save/load feature, everything anyone would want - oh wait
- WTF?  Why can't I use my printer?  And that would be the end of the
good review, and many customers would return the product, or just
never buy it.  It took me an afternoon, but I am not a Debian
developer (had to figure out how to build from Debian source package),
C programmer (well, how hard can it be?), or GTK programmer
(documentation not as easy to use as I would want - getting a list of
printers was pretty hard to figure out how to do).  I imagine the
project developers could have done this in less than an hour.

Anyways, the patch it written, and if it doesn't get applied soon, I'm
going to start to get noisy.  Now I understand why Linus, Wine devs,
and some of the other OSS devs get so aggressive in their statements
and policies.  My first useful patch to the OSS community, and it may
discourage me from ever sending another one.  Really dumb.

-Joseph

On Fri, May 29, 2009 at 1:26 AM, Procion <email address hidden> wrote:
> I'am  very glad to see that patch has been written, thanks!
> I wonder if it can be commited and passed to repository in less than another year. =)
> Seems like project mantainers not interested in it's development.
>
> --
> Local printer on remote desktop via RDP
> https://bugs.launchpad.net/bugs/233784
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in tsclient: New
> Status in “tsclient” source package in Ubuntu: Triaged
> Status in “tsclient” source package in Baltix: New
>
> Bug description:
> Binary package hint: tsclient
>
> I have a local printer at lan, and I want to map it on a remote terminal server in my session, but tsclient don't provide such option. Rdesktop can do this from command line (... -r printer:<printername>[=<driver>],... )
>