Compile Remmina 1.1.x in Debian Jessie

Update: Okay this sucks; i'm still having copy/paste issues. But here's the post anyway:

UPDATE 2015 March: Okay this sucks even more, seems i had compilation issues and had to add more cmake flags; HOWEVER, upon install i had segmentation faults when running remmina.

SO, i've found an alternate and preferred method of installing: Add the unstable branch (debian experimental "sid") to your /etc/apt/sources.list and use sudo apt-get -t experimental install remmina freerdp to install the latest available.

i.e. I DO NOT RECOMMEND THE FOLLOWING
--

Remmina 1.0.0 is still the latest version in Debian Jessie (Testing) as of Nov 2014. However Remmina itself is up to version 1.1.x now.

Recently I have had issues with copy/paste (clipboard redirection) not working, so I decided to try to update it. Although not difficult, it was not exactly super quick to find the dependencies either.

note: I always use aptitude but you could just as easily use apt-get.

We will use the github version of Remmina:

sudo aptitude install git
cd ~/Downloads
git clone https://github.com/FreeRDP/Remmina.git

Of course, you probably already have the build tools; otherwise, install them:

sudo aptitude install build-essential

You may have issues with installing the following dependency due to a recent change in debian itself, but you should be able to work it out:

sudo aptitude install libgnutls28-dev

Now, we will install the rest of the dependencies:

sudo aptitude install libavahi-common-dev libavahi-client-dev libavahi-ui-gtk3-dev libvte-2.90-dev libappindicator3-dev libvncserver-dev libxkbfile-dev libfreerdp-dev libtelepathy-glib-dev

Now we can compile and install Remmina:

cd Remmina
cmake -DWITH_LIBSSH=OFF -DWITH_GNOMEKEYRING=OFF
make clean 
make
sudo make install

You need to make install otherwise it will not find the plugins.

I chose "keyring off" because I run XFCE and also when I compiled with it on, I still had copy/paste issues. However, that needs to be thoroughly tested and I was not interested in it.

Now you can run the new Remmina 1.1.x

killall remmina
remmina

good luck!

--

Please consider crypto tipping:
  

Holy X11 Batman (RDP via ssh X11Forwarding from an OSX host over VPN -- it's true!)

Can it be true??? YES it IS... with a caveat I hope you solve for me...
The caveat is with a Linux client; I've verified OSX to OSX has no issue.

Scenario: I wanted to ssh into my Mac Pro at work from my Linux box at home and launch RDP via X11Forwarding.  Of course, from-Linux to-Linux is a non-issue, but in this case my host is OSX.  I got to playing, and the surprise was joyous.

Setup/Prerequisites:
 Client: Linux or OSX
 Host: OSX 10.8
 VPN: Hamachi (Hamachi for Linux in Labs)
 RDP Client: FreeRDP via OSX HomeBrew
 X11: XQuartz will be required for both OSX Hosts and OSX Clients.  Of course X11 is already part of any Linux Desktop Environment.
 Host firewall's ssh port 22 open for NIC "ham0"


Assumptions/Prerequisites:
 Let's assume you've installed XQuarts on the OSX host already.
 Let's assume you have Hamachi fully operational on both machines. (i.e. hamachi logged in, VPN created, joined on both machines, firewall open for ham0) -- ("hamachi list" to see your IP's, "hamachi -h" for other options).
 Let's assume you've installed Homebrew on the host already. (or you can do it while ssh'd in).

We will do this remotely through the hamachi VPN.

From your linux client, ssh into your OSX host: (If on an OSX client, XQuartz's xterm is necessary)
 ssh -XC user@hostIP #(-X is for X11 forwarding, -C is for compression)

Edit the ssh server config:
 sudo nano /etc/sshd_config
Adding the following 3 lines to the end of the config file:
 AddressFamily inet #(required when IPv6 is disabled on any client or host)
 X11Forwarding yes
 X11DisplayOffset 10

Restart the sshd service:
 ps -ef | grep sshd | awk {'print $2'} | sudo xargs kill -HUP
 
This will have disconnected you, so ssh in again:
 ssh -XC user@hostIP

Let's install FreeRDP:
 brew install freerdp

Setup the display for the X11Forward:
 export DISPLAY=localhost:10.0

Now run xfreerdp:
 xfreerdp serverIP #(where serverIP is a legitimate internal network IP)
 #OR
 xfreerdp -u username -d domain serverIP  #(where -d domain is only needed for Active Directory members)

Proof:

Caveat:
  I've found a significant issue strictly when on Linux client-side --  When i type into the RDP session I get completely different characters making the session unusable.

Here I type "Administrator":

I'm sure it's a keyboard or character set issue.  I'm looking into the xfreerdp -k option, but have not solved it yet.  If you solve my problem, PLEASE post it in a comment.  Thank you, and good luck!
------------
Please consider crypto tipping: