I think that is #7944 (closed): "Standalone flash proxy".
No, #7944 (closed) is for an outside-the-browser implementation of the flashproxy piece (that is, the one in the middle, between the client and the bridge). The bridge side needs some glue separate from the normal Tor bridge, since the Flashproxy piece can only make certain types of connections from within the browser.
I am in favor of having deb packages. I don't know much about building them myself, but I'm very willing to accept patches to make it happen. We have make dist and make install targets that might be useful.
If and when #7883 (closed) happens, there will also be needed a pyptlib deb. In fact having such a deb would make me more likely to go through with #7883 (closed).
The bridge-side server transport program is called websocket-transport--it actually uses WebSocket generically and doesn't know anything specifically about flash proxies. It lives in https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport. It has not gotten as much polish as the client programs.
Trac: Status: new to accepted Parent: #7166 (closed)toN/A
Slight extension of plans - I've also done a formal build-package-release scripts for the facilitator at #9974 (closed). It would not be much extra work to package all of the client, proxy, and facilitator as separate Debian binary packages, from the single source package (as we currently have the flashproxy git repo set up).
websocket-transport has already been split away in ticket #9863 (moved).