This issue has been migrated from old Barrier Github repository debauchee/barrier#7

Issue created on: 2018-02-23 by @walker0643
Issue last updated on: 2018-03-26

Barrier needs to catch up on some of the patches from other synergy forks and from synergy itself. Any patches that you think should be incorporated are to be added here. Please use this as a meta-issue by creating one issue per patch and adding a comment to it referencing this one. Thanks!

Commented on: 2018-03-25 by @DragoonAethis

I've created a list of all Synergy forks on GitHub which are still linked to the upstream repo and were pushed to at least once since their creation OR have some stars/watchers. It might help with finding forks with commits ready to be pulled, but the list needs to be filtered first, as there are ~200 repos which match those requirements. (Also the GitHub API seems to be a bit bugged and reports the number of watchers == the number of stars, but I've asked support to look at that, so I'll regenerate the list soon.)

Commented on: 2018-03-26 by @walker0643

Closing at 2.0 release. My thanks to all contributors!

Closed on: 2018-03-26 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#29

Issue created on: 2018-04-21 by @AdrianKoshka
Issue last updated on: 2018-06-07

Operating Systems

Server: Linux

Client: Linux

Server linux version: Fedora 27

Client linux version: Debian stretch

Barrier Version

barriers 2.0.0-RELEASE, protocol version 1.6

Steps to reproduce bug

1. plop systemd user unit in ~/.config/systemd/user/[email protected]

[Unit]
Description=Barrier keyboard & mouse sharing software
After=network.target

[Service]
PassEnvironment=DISPLAY
ExecStart=%h/.local/bin/barriers --address %i --no-restart --no-daemon --config %h/.config/Synergy/desktops.conf
Type=simple
ProtectHome=read-only
ProtectSystem=true
ReadWritePaths=%h/.config/Synergy
Restart=always
RestartSec=10

[Install]
WantedBy=alc.target # not really important or needed for debugging

1.5. supply your own config
2. run systemctl --user daemon-reload
3. run systemctl --user start barriers@::1.service
4. it will fail with (code=exited, status=4) when checking systemctl --user status barriers@::1.serivce

Other info

If I run barriers stand-alone, outside of a systemd user unit, it just works. Also unrelated to this issue, but barrierc happily runs as a systemd user unit.

Commented on: 2018-04-21 by @AdrianKoshka

False alarm... desktops.conf is supopsed to be desktops.config from my old synergy config, solved this myself.

Commented on: 2018-06-07 by @ghost

@AdrianKoshka Thanks for that service file! Can you tell me what that alc.target is? I can't find anything about. Also what is the reason to use --no-restart and --no-daemon flag?

Commented on: 2018-06-07 by @AdrianKoshka

Oh, alc.target is a custom systemd target I wrote. the --no-restart flag means barrier won't try to restart itself, and the --no-daemon flag means it won't fork itself into the background.

Commented on: 2018-06-07 by @AdrianKoshka

@glumanda99 if you're interested, all my unit files are in this repo: https://github.com/adriankoshka/config

Commented on: 2018-06-07 by @AdrianKoshka

Here's the documentation for how I have barrier seutp: https://github.com/AdrianKoshka/config/wiki/My-barrier-setup

Commented on: 2018-06-07 by @ghost

@AdrianKoshka Thanks for your fast response and detailed descriptions! It works great and was one of the reasons I switched to barrier as the 1.8 branch of synergy won't fix running it from systemd service.

Closed on: 2018-04-21 by @AdrianKoshka

This issue has been migrated from old Barrier Github repository debauchee/barrier#40

Issue created on: 2018-05-21 by @Schustudrai
Issue last updated on: 2018-06-30

Operating Systems

Server: Windows 1803
Client: MacOs 10.13.3

Barrier Version

v2.1.0 on both systems

Steps to reproduce bug

1. Start Barrier on Windows, as Server
2. Start Barrier on Mac as Client
3. Drag Mouse from Windows to Mac
4. Bug occurs: The MacOS Dock pops up for a second, a cursor is not shown. If I use the Mac Mousepad, I can move the cursor, with my Windows mouse, I can not.

Other info

• This problem started right when first using Barrier
• I could not find a way around it
• I can't use Barrier, since Mouse sharing does not work. Keyboard-Sharing and Copying still works

The client log shows the warning, that the mouse-cursor might not be visible. While it actually is not visible, it also can't be controlled, otherwise I would be able to drag the cursor back to Windows.
EDIT: I also tried different Versions of Barrier (2.0.0; 2.0.0-RC1) having the same issue

Commented on: 2018-05-22 by @Krizzza

Im having similar issues. Additionally, mac cursor disappears very often.. especially if you move mac cursor with its own pointing device.

Commented on: 2018-05-22 by @Schustudrai

Issue #42 does seem to be the same problem as this one.

Commented on: 2018-06-30 by @walker0643

Marking as duplicate of #42 for now. Reoopen if not.

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#55

Issue created on: 2018-05-30 by @massimo0315
Issue last updated on: 2021-07-02

II start the program on a PC the server and on the other the client, the connection seems to be successful but remains on: "Barrier is starting". The association between the devices is detected, but beyond the association you can not do anything else. In the log this appears in random:

[2018-05-30T13: 26: 23] ERROR: ipc connection error, code = 19
[2018-05-30T13: 26: 23] ERROR: ipc connection error, connection refused

I due pc hanno entrambi Windows 10 aggiornato all'ultima versione mentre barrier è l'ultima versione(2.1.0)

Commented on: 2018-05-30 by @massimo0315

Now I've: failed to get desktop path, no drop target available, error=2

Commented on: 2018-05-31 by @shuklaalok7

Almost similar thing happening between a Windows server and macOS client. See #53.

Commented on: 2018-06-06 by @massimo0315

is there any way to solve?

Commented on: 2018-08-07 by @KaNe23

I got this error, when the barrier service was not running on windows and was somehow not automatically starting. That's why the IPC (inter process communication) was not working.

The error: failed to get desktop path, no drop target available, error=2
is not fatal, have this one as well and everything works fine.
The other trouble I had, was the windows firewall, I basically added all execution files in the barrier
folder to the allowed applications and it worked.

Commented on: 2018-09-08 by @walker0643

Hi @massimo0315 -

Like @KaNe23 said, this error is due to the barrierd service not running. From your Services window (start, run, "services.msc") right-click the Barrier service and left-click Start from the popup menu. To save yourself grief in the future you could change the property "Startup type" to "Automatic" for the Barrier service by double-clicking on the Barrier line, making that change in the drop-down box, and clicking the OK button.

I would be interested to know why the service wasn't started automatically? Did you build barrier from source or use an installer? Anything else you could share about why the service didn't start?

Closing for now. Please reopen if you feel the issue hasn't been resolved. Thanks.

Commented on: 2019-04-13 by @stevesobol

I have the same issue on Windows 10 Pro x64, connecting to macOS 10.14.3.

With the Mac as the server, I can share the Mac's keyboard and mouse with the Win10 laptop, but I'm trying to share the Win10 laptop's mouse and keyboard, and that isn't working.

Commented on: 2019-04-24 by @iserl

Bro its becuase barrierD isnt running trust me dude

(edit) Just wanted to say that this wasn't a reply to you, stevesobol, but rather showing that it isn't necessarily that the service isn't started. Im pretty sure whats happening is that the service itself breaks, and requires reinstallation.

Commented on: 2019-04-24 by @stevesobol

Yeah, I should have commented again when I got it working. Sorry (and thanks for the advice).

That wasn't my problem. There are three or four binaries - and I whitelisted the wrong one in Windows Firewall.

barriers.exe whas what I needed to whitelist.

Commented on: 2020-03-02 by @ZeroBudgetDevelopments

dont know if anybody has solved this but i had a nightmare of night to solve it the way i made it work was by going to settings on the barrier server interface and clicking it then going to the networking part in the ip address change this to the exact address given by the barrier server app exit settings and reload or restart barrier do this for every network you use and viola your problems shoul be solved it took me all night to crack this i use my home network and my mobile hotspot network now i know i have to change the ip in the app i should be all good :)

Commented on: 2021-06-23 by @wxsgt

Running the Server on Win 10 Starts fine, Client on Win 10 will not start getting this error. Just installed today, manually allowed all barrier exe files through firewall and the barrier service will not start. The path links to barrierd but im getting a 193: 0xc1 error which means its not connecting through for some reason.

Commented on: 2021-07-02 by @yoshisatose

I had the same issue but solved it.
https://bobcares.com/blog/error-193-0xc1-service-fails-to-start/
In my case, my system drive (C:) had a file (not a folder) named "Program". When I removed this file from the system drive, I could start the barrier service.

Commented on: 2021-07-02 by @wxsgt

I had the same issue but solved it.
https://bobcares.com/blog/error-193-0xc1-service-fails-to-start/
In my case, my system drive (C:) had a file (not a folder) named "Program". When I removed this file from the system drive, I could start the barrier service.

That was exactly it thank you!

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#22

Issue created on: 2018-03-14 by @kloetzl
Issue last updated on: 2018-11-30

Hi,

Tru asked me to look into packaging for Debian. I started with that, but here are a few issues that should be resolved beforehand:

• Copyright: The LICENSE file claims GPLv2, but debian/copyright mentions proprietary components? → All free, see below.
• Tests: Is there an automated way to verify that the package works? → No. s.b.
• Convenience Libraries: For the Debian package I will have to remove the copies of external libraries and use the ones coming with the OS. Are you sure you need verbatim copies of other code in your repo? → Extra copies are not needed on linux, s.b.
• Manpages: They are out-of-date w.r.t. copyright and version number at least (blocked by #23).
• CMake: The configure script bails out if BARRIER_REVISION is not set or just an empty string. Note that for debian we use our own git repos, thus the current commit hash is not of interest.
• File an ITP
• Find a section and sponsor

I will extend the list as more issues pop up.

Best,
Fabian

Commented on: 2018-03-14 by @yupi2

Regarding copyright, that was around they time they were preparing to remove the v1 GUI and use the Synergy2 GUI. symless/synergy-core@513f50a

Commented on: 2018-03-15 by @walker0643

hi @kloetzl - thanks for helping us out with the debian packaging.

Copyright: no, there are no closed-source components in barrier. that line can be changed at anytime. i haven't had the chance yet to research the language that debian would use in its place. is the correct option to simply remove the disclaimer line and leave the rest as-is?

Tests: we don't have package testing as we're just now getting to our first real packaged release. i'm a big fan of automated testing, though, so if you have any suggestions please share them.

Convenience Libraries: if you're referring to the source trees under the ext folder then please be aware that gmock and gtest are only used for the testing targets and will not contribute to the package contents. openssl, similarly, will not contribute because it is only utilized on windows platforms; all other platforms use the system ssl libraries. a standard build/package on linux/osx/bsd will not pull anything from ext.

Manpages: yes, those need to be updated. for sure :) debauchee/barrier#23 ... eta around thurs-fri this week if no one beats me to it.

Commented on: 2018-03-15 by @kloetzl

• Copyright: Well, for the Debian package I will exclude your debian dir altogether. It was just weird that some files said GPL and others mentions proprietary components.
• Convenience Libraries: Thanks for the explanation; I will exclude ext as well.

Commented on: 2018-03-15 by @kloetzl

• CMake: The configure script bails out if BARRIER_REVISION is not set or just an empty string. Note that for debian we use our own git repos, thus the current commit hash is not of interest.

Commented on: 2018-03-15 by @kloetzl

• GPL v OpenSSL: There is some discussion on whether linking against OpenSSL violates the GPL. In the past debian has taken the position that an exception is required. If the exception is not granted I fear the FTP master will consider it non-distributable.

Commented on: 2018-03-15 by @yupi2

There's an exception: https://github.com/debauchee/barrier/blob/master/LICENSE#L6

Commented on: 2018-03-15 by @kloetzl

Sorry, my bad. 😸

Commented on: 2018-03-15 by @walker0643

@kloetzl - as far as building from source trees without proper git metadata you may just set BARRIER_REVISION to "00000001" or really any 8-digit hexadecimal value. once we tag v2.0.0 and we're doing the official builds please also set BARRIER_VERSION_STAGE to "RELEASE". these can both be set in the environment with env, inside the build_env.sh include script, or however else you please. for reference my build_env.sh for releases looks something like this:

export MAKEFLAGS=-j10
export B_BUILD_TYPE=RELEASE
export BARRIER_VERSION_STAGE=RELEASE
#export BARRIER_REVISION=00000001  # this is only needed for non-github-tree builds

Commented on: 2018-03-17 by @walker0643

@kloetzl - manpages updated. let me know if you see any problems.

Commented on: 2018-03-19 by @truatpasteurdotfr

thx @kloetzl :P

Commented on: 2018-03-26 by @kloetzl

• File an ITP
• Find a section and sponsor

Commented on: 2018-03-27 by @revast

hello, first of all, thanks for Barrier!

I have made a hand-packaged barrier debian package for ubuntu 16.04. I took synergy 1.8.8 package from getdeb as starting point.

My observations:

• /usr/bin/syntool name-conflicts with synergy package, so a "breaks" line is necessary in the control file
• what about synergyd? there is no barrierd built from master sources, is this obsolete?

Commented on: 2018-03-27 by @kloetzl

For future reference, the current status of my packaging attempt is here: https://github.com/kloetzl/barrier-debian

Commented on: 2018-03-29 by @walker0643

@kloetzl very good. thank you for the updates!

@revast barrierd was removed for all platforms except Windows. i think it's about time we did the same for syntool as well (#25). can you confirm that the syntool installed in your /usr/bin is not a synergy remnant? eg. does "/usr/bin/syntool --get-profile-dir" give you "/home/revast/.synergy" or something similar? thanks!

Commented on: 2018-03-31 by @revast

Confirmed. It is also present in the build folder.

Commented on: 2018-04-05 by @arooni

also would love this as i tried to build on ubuntu 16.04 and failed :(

Commented on: 2018-04-09 by @truatpasteurdotfr

@arooni does this Dockerfile works for you? https://github.com/truatpasteurdotfr/barrier/blob/master/docker/ubuntu16.04-release-builder/Dockerfile

Commented on: 2018-04-09 by @arooni

probably! but i'm running a little low on disk space

Need to get 128 MB of archives.
After this operation, 650 MB of additional disk space will be used.

Commented on: 2018-04-09 by @arooni

btw thanks!

Commented on: 2018-04-20 by @walker0643

@kloetzl - can you update us as to where you stand on the deb package? even if it doesn't make it into an official debian repository in the near future i would still like to have PR for the build script and a package for our website. thanks!

Commented on: 2018-04-25 by @kloetzl

From a technical perspective the package should be more or less done. It is an attempt to be more compliant to the debian policy. (Note that the package build fails atm because of the missing section in d/control.)

In order to get the package into debian the next step is to file an Intent to Package bug and then find a section and sponsor. At this point I would like to hand back the charge to you. 😺

Commented on: 2018-04-25 by @walker0643

Sounds good. Thanks for all your hard work, @kloetzl :)

Commented on: 2018-06-08 by @dayne

I am not parsing what the status of this effort is at. Interested in better understanding the direction of packaging and build process for barrier.

Looks like @kloetzl created some additional debian packaging stuff over in:
https://github.com/kloetzl/barrier-debian/tree/master/debian
that doesn't yet exist in:
https://github.com/debauchee/barrier/tree/master/debian

Also of interest to this topic is the docker work done by @truatpasteurdotfr over at:
https://github.com/truatpasteurdotfr/barrier/blob/master/docker/ubuntu16.04-release-builder/Dockerfile

In fact it looks like @truatpasteurdotfr did a bunch of docker work that would be handy to bundle up into barrier - especially for package building efforts like for this debian issue.

I feel like the next step here is to ask @kloetzl to rebundle changes made for the debian packaging into a single Pull Request and same thing from @truatpasteurdotfr so they can be brought in and help finish up this thought.

Commented on: 2018-06-10 by @kloetzl

I feel like the next step here is to ask @kloetzl to rebundle changes made for the debian packaging into a single Pull Request […].

You could do that, but note that this is by no means required for the packaging process. Also, it is somewhat discouraged to have a debian dir in your upstream source. First thing my package does is exclude the directory from the source. The debian dir is usually only added in the repository on the Debian servers.

I am not parsing what the status of this effort is at.

One might have to adapt my package for the latest releases and then

In order to get the package into debian the next step is to file an Intent to Package bug and then find a section and sponsor.

Commented on: 2018-07-05 by @eadmaster

I am interested in this as well.
BTW I've found an Ubuntu package here:
https://launchpad.net/~unit193/+archive/ubuntu/test/+packages

Commented on: 2018-07-06 by @cblknittights

https://launchpad.net/~unit193/+archive/ubuntu/test/+packages

I see this, and I am curious as to what the status is on the pacakge?

Packages for

16.04, 18.04,

14.04 and 12.04 would be a plus if this is possible. I have stuff which can not be changed past these for mission critical applications.... Thats real life....

I also see the words DFSG in the repo above, and to me that means a problem, as normally anything that is DFSG'zd has had features removed due to some policy in the DFSG. Look I get that some want a pure "non tainted environment," sorry I am just not in to that. I've been exclusive linux for 20 years, but I use what ever, I need. I use the OEM drivers from nVidia. I use VMWares free Player, etc.. I use darkice with MP3, and sox with MP3 etc... So is there stuff that is removed to meet the DFSG and that we need to have DFSG Debian packages ,and packages for DEB based like *Bunutus which RESTORE the missing functions? I appreciate the work to package this, and I see and appreciate your views in re DFSG, I ask that you understand that some of use just don't have those issues. So if it means that we need to have a PPA or someplace outside the official repos, fine with me. So long as I can grab a DEB putinto QtDebi etc. to install, were good to go! :)

Commented on: 2018-07-06 by @kloetzl

I also see the words DFSG in the repo above, and to me that means a problem, as normally anything that is DFSG'zd has had features removed due to some policy in the DFSG.

That is not the issue here. Instead, barrier comes with some external source dependencies in ext and links to that. However, the DFSG encourage packages to link against the shared libraries against other packages. To follow these guidelines ext is excluded from the "orig tarball" (see debian/copyright). To signal that this tarball now differs from upstream a +dfsg is appended.

Commented on: 2018-07-10 by @arooni

so are these packages legit to use for ubuntu 18.04? thx!

Commented on: 2018-08-29 by @duck-rh

@arooni this PPA by Unit193 was made for his own usage and is not an official repository; I asked him and he does not plan to do regular maintenance on this PPA

@kloetzl and others, as an official DD, I would recommend asking the current synergy's maintainer if he would be interested in replacing his package by this fork. He seems missing in action but maybe that would arouse some interest or he would be ok to let go of maintainership. Several persons can comaintain together to ease the workload. Maybe Unit193 could be interested to join too. I personally have enough on my plate, but I could help for review and sponsoring.

Commented on: 2018-09-06 by @aveach

Any update on getting a .deb up and running? Trying to install on a clean Ubuntu 16.04 installation and I am running into a handful of errors as it stands.

Commented on: 2018-09-07 by @brisssou

I just installed barrier from https://launchpad.net/~unit193/+archive/ubuntu/test

running like a charm as I type this.

Commented on: 2018-09-09 by @the-wes

@duck-rh I was able to reach the person who submitted Synergy to the Debian repos. That was all he wanted to do, get it in there. He is not interested in working on Synergy or Barrier any further.

@brisssou What OS are you on?

@everyone else the current status is that we need a successfully built package (DEB file). If someone can create one and host it somewhere we can move forward with an ITP request.

Commented on: 2018-09-10 by @AdrianKoshka

If anyone wants a quick & dirty way to build the .deb, this should work.

FROM debian:stretch
## 
RUN apt-get update && apt-get -y upgrade
RUN apt-get -y install \
build-essential cmake qt5-default \
wget \
libxtst-dev libxinerama-dev libice-dev libxrandr-dev \
libavahi-compat-libdnssd-dev \
libcurl4-openssl-dev \
libssl-dev \
dh-make
#  
CMD wget https://github.com/debauchee/barrier/archive/v2.1.1.tar.gz  && tar xzvf  v2.1.1.tar.gz  && cd barrier-2.1.1 && dpkg-buildpackage -us -uc | tee debian.log 

Commented on: 2018-09-10 by @AdrianKoshka

Or not...

tail: cannot open 'debian/changelog' for reading: No such file or directory
dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1

Commented on: 2018-09-10 by @brisssou

@the-wes The OS is Ubuntu 18.04

Commented on: 2018-09-11 by @TafThorne

@AdrianKoshka Too quick and too dirty.

http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/x169.html
There are a few copies of files that need to be placed around in the container for the Debian packaging tool. Time to start the big ticklist:

Generate the following prerequisit files.

• one or more binary executable or shell script files
• a man page for each executable file
• a 'control' file
• a 'copyright' file
• a 'changelog' and 'changelog.Debian' file

The format of the control, copyright and change logs is discussed from http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/x88.html onwards. Someone should skim read the whole document.

Setup temporary 'debian' directories:

• create 'debian/usr/bin' directory (or wherever you plan to place your executable files)
• create 'debian/usr/share/man/man1' (or whatever section your man page belongs into)
• create 'debian/DEBIAN' directory
• create 'debian/usr/share/doc/<package_name>'
• make sure all sub directories of 'debian' have file permission 0755

Copy files into temporary 'debian' tree:

• copy executable file into 'debian/usr/bin' directory (or wherever you plan to place your executable files)
• copy man page file into 'debian/usr/share/man/man1' directory
• copy 'control' file into 'debian/DEBIAN' directory
• copy 'copyright', 'changelog', and 'changelog.Debian' files into 'debian/usr/share/doc/<package_name>'
• gzip man page, 'copyright', 'changelog', and 'changelog.Debian' files with option '--best' inside the temporary 'debian' tree

And finally Build and check binary Debian package:

• invoke 'dpkg-deb --build' using 'fakeroot' on the 'debian' directory
• rename resulting 'debian.deb' file to its final package name including version and architecture information
• check resulting .deb package file for Debian policy
• compliance using 'lintian'

Once all that is done, it should be an acceptable Debian package.

If everything can be done in Docker containers, I can try and action most of this at lunch. Even better if I can setup a CI on here to do it for me in a branch.

Commented on: 2018-09-11 by @kloetzl

Here is a deb package created in a fresh bionic beaver container (zipped, because github): barrier_2.0.0-RC2-1_amd64.zip. Hope this helps. — Didn't test. 😅

Steps to reproduce:

apt install  libssl-dev debhelper cmake qt5-default libxtst-dev libxinerama-dev libice-dev libxrandr-dev libavahi-compat-libdnssd-dev libcurl4-openssl-dev libgtest-dev
gbp clone https://github.com/kloetzl/barrier-debian.git
cd barrier-debian
sed -i 's/libssl1.0-dev/libssl-dev/' debian/control
gbp buildpackage -uc -us --git-ignore-new

Commented on: 2018-09-11 by @duck-rh

@TafThorne sorry but we do not make Debian packages this way (except maybe in the very early days of Debian). You have official, if not perfect, documentation. I would suggest you look at https://www.debian.org/doc/manuals/debmake-doc/index.en.html (more technical details in chapter 5).

Using debhelper (and the dh command) it should be pretty easy nowadays (like a 2-lines debian/rules, copyright file, and a few metadata). And debmake or dh-make should help setup some files for you, but that's not compulsory. Then pbuilder or sbuild can help build in a clean environment and check you did not forget any build dependency (but you can build directly to begin with using debuild, a wrapper for dpkg-buildpackage).

Also we use gbp (git-buildpackage) to import sources with metadata in git repositories, so it can be handy to have a look.

Here are the steps, have fun.
\_o<

Commented on: 2018-09-12 by @cblknittights

sorry but we do not make Debian packages this way

This is where I think you are loosing the BIG PICTURE HERE, and the ultimate goal here.

I appreciate the work that people who can create these packages, I can't. Thats a different discussion.

Let me outline this for you, 98% of the users here really could care less whether it meets this or that license, this or that copyright, or your other long list of rules, do's, don'ts, etc.. All of what your post outlines in "the rules" and "proper" ways to do this might be needed for "official DEBS." Users really don't care if they are "official" or not, they simply want to install the software and move on.

Compiling from the source from a git pull when you have full complete instructions can be done just as easy as apt. When you these don't exist, and/or for some its much easier to get a DEB, mostly via apt, install and done. APT is a beautiful system, it pretty much does the work, fetches what you need, installs it all, done.

We are complicating things beyond need for "official" DEB's. I get why, legal, etc. that Debian/Canoncial (Ubuntu) need/require. That requirement just doesn't exist at this level.

See my earlier post of about DFSG. The tl;dr of that, is USERS do NOT CARE about all this stuff!

What we want is EASE OF INSTALLATION. Period. Full hard stop.

Now, to incorporate this in to the "official" repo(s) of what ever distro be it Debian, or Ubunutu's probably all of that is needed. Thats great, and all that, but your legal mumbo jumbo is holding up ease of use.

Hold it, read this again, USERS DO NOT CARE!

So to that end I WILL PUT SKIN IN THE GAME.

Here is my offer, I WILL HOST a REPO for this for FREE!

All that is needed is:

1. Some one will need to assist on setting up a DEB based repo on my server. I've not done it before, but I am interested in to doing this for something else, so this is as good a time to start than ever.

a) If thats more undertaking that its worth, then I will take DEBS as per below, and offer them up for DL and then users can install via dpkg -i/QtDebi etc..

2. PROVIDE THE DEB's for use:

a) 32bit for use on *bunutu's 12.04, 14.04, 16.04, 18.04 for the ESR releases
b) 64bit for use on *bunutu's 12.04, 14.04, 16.04, 18.04 for the ESR releases

No rules on how they are made, no need to meet DFSG, or any other do/don'ts, just that the DEB packages will install and work. If needed you can create versions needed for other DEB based distro's which might have differing dependencies for some reason.

3. I do NOT NEED any of that legal mumbo jumbo stuff. Just DEBS that will install in the above for users to get working installs of the software, via sudo apt-get install barrrier after adding the repo etc..

So maybe the DEB's crated via what ever method posted may not be usable in the "OFFICIAL" Debian or Ubuntu repos, for what ever reasons. And while I understand your views, position etc. ie: legal, again, users do not care! I don't care whether the DEBS have stuff that doesn't concern the operation or installation. I don't care of they include libs in the DEB that maybe is not the "official" way to provide those.

Again, read this line and take it to hear, users do not care about this minutiae.

I get it that to you and others that may be a big part of things to you and your view of Linux etc.. It is not to me, and again, users don't care! They just want to install stuff move on with life.

So lets step back and work the problem, not the problem work us.

DEBS for ease of installation.

I doubt to many it makes a difference if its sudo apt-get install barrier or sudo dpkg -i barrier1.0amd64.deb

Maybe it is more important to others to get things in the official repos versus private ones, to me no difference, whether it works via apt or I manaully DL a DEB and use dpkg or QtDebi etc..

I simply want a way to install the software that works 100%, upgradable to the new version as needed. Whether thats via apt or manually via dpkg/QtDebi etc. doesn't matter.

So if you want to help me setup a DEB repo, and/or can provide the DEB's I've listed let me know, and we can work to solve this problem, without complicating this with lists of rules, and do, and more dont(s) etc..

Solve the problem , not create more.

Commented on: 2018-09-12 by @duck-rh

@cblknittights you do not represent all users, sorry.

Also aside from the (very small) legal part of the document there are information about the tooling. Debhelper has made a lot of progress and ease of packaging, not wasting your time with recreating the wheel and learning internal technical details of how a .deb is created, is probably something people who would work on this software would care about.

I was just trying to help, that was just a suggestion of documentation, you're still free to do whatever the fuck you want, so I do not understand your behavior. I certainly will not work with an unpleasant person such a you, and you're going to drive away people who could have brought help. Good luck then.

Commented on: 2018-09-12 by @cblknittights

you do not represent all users, sorry.

I suggest you check. I've been in this for a while, users do not care about all the stuff you post about.

They find software x, and want to download it, install, move on. Maybe you care about this or that license ie: GPL 2 v. 3, etc.. Guess what users are going to install that software if it works and does what they want. License or not. They don't read that, nor care.

They don't care if including lib21414 in the DEB is not the proper way, versus doing something else. They want the software to install and work.

They don't care how the DEB gets built. That they can do some simple steps to add the repo, and apt -get install move on.

You may disagree with the above, but 20+ years of dealing with users, and I can tell you they, and I don't care about that stuff. Too many people with the knowledge on packaging are caught up in making things way more difficult, and hindering Linux adoption and software distribution than it needs to be.

One user posted a way to create a DEB, if that works, great. lets move on to getting DEB's distributed! Oh, it doesn't follow this edict of the DEB Policy Board, users don't care!

Maybe we should go back to software distribution on card stacks. As this just serves to impeded those who know from those who don't know all the packaging ins and outs.

Look at the posts, "here is a way to create a DEB..." There are several, and then there is the usual response "We don't create debs that way!"

Pretty clear, users just wants DEBS to install and get on with it!

My offer stands, I will provide hosting for DEBS via apt or DL for free. Provide the DEBS, skip the drama.

Commented on: 2018-09-12 by @kloetzl

Just updated my packaging attempt to version 2.1.1. Here is the resulting package for bionic barrier_2.1.1-1ubuntu1_amd64.zip.

My offer stands, I will provide hosting for DEBS via apt or DL for free. Provide the DEBS, skip the drama.

/drama

Commented on: 2018-09-12 by @AdrianKoshka

Thanks @kloetzl. Also, just to remind everyone, the issue was originally opened so that we could hopefully take steps to get barrier into the official Debian repos (and possibly ubuntu's later on).

@cblknittights I'd have to agree with @duck-rh that you simply don't represent users. You're just trying to cram what you want down everybody elses throat. Until you decided to chime in with your two cents, the issue was being handled in a respectful manner. Either treat others with respect, or leave.

Commented on: 2018-11-27 by @duck-rh

Btw, this ticket was not updated but it was done in October by Unit193: https://tracker.debian.org/pkg/barrier

Commented on: 2018-11-27 by @AdrianKoshka

So it's in the Debian repos?

Commented on: 2018-11-27 by @nodiscc

@AdrianKoshka It's available in Debian unstable and testing (codename buster) https://packages.debian.org/unstable/barrier

Commented on: 2018-11-28 by @AdrianKoshka

So would it be okay to close this issue, or wait until it's in stable?

Commented on: 2018-11-28 by @p12tic

I think we can close it. The package will automatically appear in the next stable version unless something really bad is discovered.

Commented on: 2018-11-28 by @kloetzl

Done; thanks everyone.

Commented on: 2018-11-30 by @truatpasteurdotfr

congrats :P

Closed on: 2018-11-28 by @kloetzl

This issue has been migrated from old Barrier Github repository debauchee/barrier#3

Issue created on: 2018-01-29 by @walker0643
Issue last updated on: 2018-01-29

Operating Systems

Server: windows

Client: linux / arch

Barrier Version

git

Details

occasionally when exiting the server (barriers) it will crash on an access violation. seems to only happens when a client is connected.

Closed on: 2018-01-29 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#42

Issue created on: 2018-05-22 by @rainybreeze777
Issue last updated on: 2019-12-29

Operating Systems

Server: Windows 10 version 1709 (OS build 16299.431)

Client: Ubuntu 18.04 LTS

Barrier Version

2.1.0-Release

Steps to reproduce bug

1. Establish server on Windows
2. Establish client on ubuntu
3. Set up server monitor configuration such that ubuntu is on the left of windows
4. Log reports connection is successful
5. Attempts to move cursor from windows to the left of the screen to ubuntu machine
6. Cursor disappears on Windows, cursor does not appear on Ubuntu
7. Ubuntu can accept keyboard strokes and mouse clicks, but cursor does not move
8. Cannot move cursor back to Windows, had to manually stop Ubuntu client for the cursor to return to windows

Other info

• When did the problem start to occur?
  When I just finished setting up Barrier and establish connection, first attempt at using
• Is there a way to work around it? No
• Does this bug prevent you from using Barrier entirely? Yes

Commented on: 2018-06-09 by @AurisAudentis

I can attest to the same issue on Linux Mint Sylvia 18.3.
Is there any workaround/fix availiable or in the works?

UPDATE:
found a workaround: properties of the executable barrier -> compatibility -> all users -> High dpi options -> check all the boxes.
After this, the program seems to work as intended. This was a known problem in synergy.

Commented on: 2018-06-10 by @dayne

Sounds like these issues from synergy-core:

• symless/synergy-core#4041
• symless/synergy-core#6070

Commented on: 2018-09-08 by @walker0643

Can you try 075d4f4 and report back? If you're not comfortable building from source you could wait for the next release, 2.2. Thanks!

Commented on: 2018-09-08 by @walker0643

Please reopen if you still have this issue after upgrading to 2.2. Thanks!

Commented on: 2019-02-24 by @xurongchen

I can attest to the same issue on Linux Mint Sylvia 18.3.
Is there any workaround/fix availiable or in the works?

UPDATE:
found a workaround: properties of the executable barrier -> compatibility -> all users -> High dpi options -> check all the boxes.
After this, the program seems to work as intended. This was a known problem in synergy.

Thanks! However I solved the problem by setting the executable 'barrriers' but not the 'barrier'.

Commented on: 2019-08-10 by @ScriptingDad

@AurisAudentis your workaround still worked in 2.3.1. Thanks! not sure why it worked but I've been playing with this for 4 hours now and this is the only thing that did the trick.

Commented on: 2019-12-23 by @stevesobol

I'm having the same problem with macOS, as detailed in a bug that was marked as a dupe of this one. It existed in Synergy 1.8 and the workaround there was to turn off clipboard sharing, which I have done, but I'd rather have it enabled.

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#45

Issue created on: 2018-05-23 by @Ashark
Issue last updated on: 2021-09-04

There are many issues when you are using multiple layouts on both client and server side. I have done some testing and publishing results here.
In the table I have marked unexpected behavior with red circle (:red_circle:). Cases that are working as expected I have not marked just because there is still no green circle until unicode 12.0.

What I consider as expected behavior?

When I am typing text in a client, I expect that when I hit switch layout key combination, then I continue typing in client in another language. My main attention is in client's layout indicator, but not server's. Actually, I do not care of server's layout until I return my mouse to server.

Versions

I tested both Linux and Windows in both roles.

Linux: ArchLinux 4.16.9-1-ARCH and Barrier 2.1.0-RELEASE (built from aur)

Windows: windows 10 v1803 (17134.48) and Barrier 2.1.0-RELEASE-0b2dfd80

Linux server and Windows client

Windows server and Linux client

Commented on: 2018-05-23 by @Ashark

Reserved place for future comments

Commented on: 2018-11-30 by @Ashark

I have found a very quirky way to change linux client's layout while the same shortcut on a server (Alt+Shift).

1. Run setxkbmap -option on server. After that client will not switch layout with alt+shift or shift+alt, in despite of kde system settings were not changed.
2. Run xmodmap -e "keycode 64 = Alt_L" on server. This will prevent Alt + Shift to become Meta.
3. Move mouse to client and press alt+shift. Layout will be switched. For some reason, shift+alt still do not switch layout on client.
4. To be able to switch layout again on server, go to system settings -> input devices -> keyboard -> advanced -> Switching to another layout -> uncheck and then check again Alt+Shift, then press Apply.

Commented on: 2020-10-14 by @eugenegff

Windows server often improperly converts UTF16 char obtained from KB layout to ANSI and then back to UTF16, probably using two different ANSI code pages. This issue was fixed in pull request debauchee/barrier#910 and Windows clients with this fix now works properly with windows hosts. Current issue probably has more problems...

Commented on: 2020-12-20 by @darkdragon-001

Might this help? #134

Commented on: 2021-08-17 by @yakoder

red circle (🔴). ...just because there is still no green circle until unicode 12.0.
Probably a good thing (red-green colorblindness is a very real thing.

Since this seems to be a catch-all type issue.
RE: Alt-Shift for switching lang layout. On my Win installs (from about 95 to 10) it's specifically the Left-Alt + Shift, not just "Alt" as others keep stating. (Diff keys, diff keycodes, we're techies, we're supposed to be specific).

Not seen mention: (Possibly pasting into cmd/cygwin/wsl terminal related.) The language layout seems to change on its own for me. I'll be moving back and forth between 2 computers (both win10 21h1 w/ en & ru layouts) and at some point I'll go to type on the client & get ????? instead of whatever I wanted to type (or something like Ctrl-S will do nothing).
Client shows ENG; Server shows PYC
Steps after that: switch back to server. Win_Key+Space (since we can't disable that shortcut) now shows ENG. Move back to client, as soon as client becomes active, server shows PYC again. Move back to server. Change layout back to ENG. Click on something (background, a term window, another program). Change back to client. Yay! We're still on ENG on both.

I've not quite worked out the exact steps, as it seems to not happen frequently enough to work out a pattern/cause. And I wind up trying to just switch several times. It's either that it needs to switch PYC->ENG & auto-switch back to (unwanted... I didn't hit that shortcut) PYC, three separate times, or it's that after changing the server back to ENG, making a click on something is needed.

Disabling the older shortcut (that Left-Alt+Shift combo) does seem to help some, but it still happens, almost as if a phantom "change keyboard layout" shortcut sequence gets sent during frequent (like every minute or less) moves between computers. Possibly a dropped/errant packet?

Commented on: 2021-09-04 by @yakoder

Additional info: this does seem to be related to having a Windows command prompt open (be it cmd.exe, mintty.exe, or similar), hereafter called "terminal".
Without any terminal open, am able to switch back-and-forth between computers without any change of server's keyboard layout language.

Open a terminal on the server (either start->command prompt or win-x->c) and as soon as the client is given focus, the server's keyboard layout language is changed to (in my case) Russian. Switch back to server. Close terminal. Switch back to English. Click on another program, so it has focus. Then switching back to client does not change server's keyboard language.

Open a terminal on the client and changing between client and server does not change either machine's keyboard layout language.

Currently, for both of my boxes, barrier is set to run as a service. No further testing (of disabling service & running manually; or of reversing server-client assignments) is planned.

Just checked: this is with "latest release" (for windows) of 2.3.3.

This issue has been migrated from old Barrier Github repository debauchee/barrier#15

Issue created on: 2018-02-24 by @walker0643
Issue last updated on: 2018-02-24

I haven't seen anything personally that would indicate that this is a huge issue for barrier. It does stand to reason though that if it affected synergy it will affect barrier. Either way, reducing the size of the clipboard buffer sounds like a good idea to me.

symless/synergy-core#6222

Meta: #7

Closed on: 2018-02-24 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#54

Issue created on: 2018-05-30 by @giammin
Issue last updated on: 2020-08-19

this is a really old and know synergy bug.

I hope that maybe here will be fixed because symless does not have any intention to fix it

symless/synergy-core#5201

Commented on: 2018-09-08 by @walker0643

Can you try 075d4f4 and report back? If you're not comfortable building from source you could wait for the next release, 2.2. Thanks!

Commented on: 2018-09-08 by @walker0643

Please reopen if your problem persists after 2.2. Thanks :)

Commented on: 2018-09-10 by @giammin

ok thanks!

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#33

Issue created on: 2018-04-29 by @AdrianKoshka
Issue last updated on: 2018-07-03

This is mostly just a reminder to myself that I should probably document how to compile the flatpak for barrier on the wiki for this repo.

Commented on: 2018-04-29 by @AdrianKoshka

I wrote something up, but don't have push access to the wiki. here's the diff

@@ -0,0 +1,23 @@
+## Install dependencies
+
+Thunderbird is built against the KDE runtime and SDK, to install them, follow
+these steps:
+
+```shell
+$ flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
+$ flatpak --user install org.kde.Platform/x86_64/5.10
+$ flatpak --user install org.kde.Sdk/x86_64/5.10
+```
+You should replace `x86_64` with your architecture (`i386`, `arm`, `aarch64`, `x86_64`)
+and `5.10` with the current version of the runtime/SDK used in the [`com.github.debauchee.barrier` file](https://github.com/AdrianKoshka/flathub/blob/com.github.debauchee.barrier/com.github.debauchee.barrier.json#L3-L5).
+
+To make compilation smoother, we use `make`, which can be installed from your
+package manager.
+
+## Compiling the flatpak
+
+First thing you'll wan to do if you haven't already, is clone the repo:
+
+`git clone [email protected]:AdrianKoshka/flathub.git -b com.github.debauchee.barrier`
+
+Then `cd flathub` and `make`.

Commented on: 2018-04-29 by @AdrianKoshka

Ideally, later, this will be put on the flathub repo as well. :P

Commented on: 2018-06-30 by @walker0643

@AdrianKoshka, are you able to join us on IRC? #barrier on freenode. I'd like to discuss adding you as a Barrier contributor so you can have push access. Thanks!

Commented on: 2018-06-30 by @AdrianKoshka

Yep.

Closed on: 2018-07-03 by @AdrianKoshka

This issue has been migrated from old Barrier Github repository debauchee/barrier#23

Issue created on: 2018-03-15 by @walker0643
Issue last updated on: 2018-03-17

The barriers and barrierc manpages are WAY out of date (2010). Update versions, copyrights, and review contents for accuracy and completeness.

Closed on: 2018-03-17 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#53

Issue created on: 2018-05-30 by @shuklaalok7
Issue last updated on: 2018-10-22

Operating Systems

Server: Windows 10 Pro Version 1803
Client: macOS High Sierra 10.13.4

Barrier Version

2.1.0-RELEASE

Steps to reproduce bug

1. Start server on Windows
2. Configure Barrier on macOS as client.
3. Windows recognizes a zero-conf client.
4. On macOS, it keeps showing that "Barrier is starting." In the logs, it shows time out while connecting to server.
5. No matter what I do with the Windows machine, the macOS side does not run as a client.
6. If it matters, both the devices are on the same network Windows is 192.168.1.34 and mac is 192.168.1.35.

Other info

• I have enabled all access in Windows firewall and macOS firewall to these apps.
• When I create server on macOS and run Barrier as client on Windows, it works.
• Does this bug prevent you from using Barrier entirely? Yes, because Windows PC is a desktop with the best keyboard and mouse attached, and my mac lacks enough ports to attach external keyboard and mouse.

Commented on: 2018-05-30 by @shuklaalok7

Release 2.1.0 for Windows uses OpenSSL 1.0.2n, while for macOS, it uses OpenSSL 1.0.2l.
I don't know if it's relevant here but I am writing a difference that I found.

Commented on: 2018-06-09 by @dayne

What happens if you launch the client with DEBUG2 on the client. Launch manually like this:

barrierc -f --no-tray --debug DEBUG2 --name hostname --enable-crypto your_server_ip:24800

Commented on: 2018-06-14 by @Mfoor

I also have the same issue as above. The log tells me the following:

[2018-06-14T04:45:28] INFO: starting client
[2018-06-14T04:45:28] INFO: config file: /var/folders/4j/g5jp97gn43b8dvfp32yt4b4r0000gn/T/Barrier.FBzYsZ
[2018-06-14T04:45:28] INFO: log level: INFO
[2018-06-14T04:45:28] INFO: drag and drop enabled
[2018-06-14T04:45:28] NOTE: started client
[2018-06-14T04:45:28] NOTE: connecting to '192.168.1.114': 192.168.1.114:24800
[2018-06-14T04:45:28] INFO: OpenSSL 1.0.2n 7 Dec 2017
2018-06-14 04:45:28.162 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.172 barrierc[59092:1775135] starting cocoa loop
2018-06-14 04:45:28.173 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.173 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.173 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2018-06-14 04:45:28.174 barrierc[59092:1775155] pid(59092)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
barrierc(59092,0x7000012af000) malloc: *** error for object 0x7fc4f2620e38: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
[2018-06-14T04:45:28] ERROR: process exited with error code: 6
[2018-06-14T04:45:28] INFO: detected process not running, auto restarting

Commented on: 2018-07-08 by @CrafterLaughter

I noticed the same behavior. I could always run the server on my Mac but not my Win10 PC. What it wound up being is "C:\Program Files\Barrier\barriers.exe" has to be allowed in Windows firewall. I expect the "s" in barriers, stands for server. Just adding barrier.exe for the firewall wouldn't allow it to work.

Commented on: 2018-07-08 by @AdrianKoshka

That'd be the correct assumption, barriers is the server, and barrierc is the client.

Commented on: 2018-07-22 by @chrisvltn

I allowed port 24800, barriers.exe, and barrierc.exe in Windows Firewall and then I was able to use my Mac as a client. Without that I was always getting "Connection timeout error"

Commented on: 2018-09-08 by @walker0643

3794767 should fix this. Please reopen if it's still a problem after release 2.2. Thanks :)

Commented on: 2018-10-22 by @Technocaveman

This should really be added to the Wiki as someone who is new to this software will probably not be aware of how it works

Commented on: 2018-10-22 by @AdrianKoshka

Yeah, if someone can give me instructions on how to do this (this being adding barrier to the windows firewall), I'd be more than willing to add it to the wiki. You can either open an issue with detailed instructions, and I'll add it, or just give me the instructions here.

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#5

Issue created on: 2018-02-16 by @Cpuroast
Issue last updated on: 2018-02-16

Operating Systems

Server: Windows 8.1

Client: macOS 10.12.6

Barrier Version

1.9.0-snapshot-a8d0dfda

Steps to reproduce bug

Not a bug, more of an improvement.
Make Barrier on macOS compliant with application support file storage.

Barrier should store the folder containing the SSL pem and fingerprints data inside ~/Library/Application Support/Barrier instead of ~/Library/Barrier

Closed on: 2018-02-16 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#14

Issue created on: 2018-02-24 by @walker0643
Issue last updated on: 2018-02-24

Another one I'm not sure of. Does anyone see why having low-level keyboard/mouse hooks on a windows client would be useful? It was hinted that this was for bi-directional support but seems to be a long way off from a full bi-directional implementation.

symless/synergy-core@c3530a0
symless/synergy-core@23464a3

Meta: #7

Commented on: 2018-02-24 by @walker0643

Confirmed that this feature was added to synergy 2 as part of the new auto-switching feature, swapping the master/slave roles of the client and server. If anyone really wants this functionality for barrier add your votes below please and if we get enough people we may do it. Closing for now, though.

Closed on: 2018-02-24 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#16

Issue created on: 2018-02-25 by @walker0643
Issue last updated on: 2018-02-25

A memory leak was reported (with a patch) for synergy in late 2017 but was summarily ignored, in short, due to symless's desire to deprecate and stop maintaining the 1.9 branch.

symless/synergy-core#6174

Meta: #7

Closed on: 2018-02-25 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#28

Issue created on: 2018-04-09 by @tavasti
Issue last updated on: 2019-03-31

Build instructions for linux are needed. Plain cmake + make does not work. Make fails on
/home/tavasti/Downloads/barrier-2.0.0/src/./lib/common/common.h:27:3: error: #error "config.h missing"

error "config.h missing"

Commented on: 2018-04-14 by @walker0643

I believe I saw you getting help with this on IRC, @tavasti ... did everything work out?

And, yes, documentation is lacking at this point.

Commented on: 2018-04-15 by @tavasti

Yes, I got things rolling. Point was run clean_build.sh and if you are not on git version, in cmake/Version.cmake adding line like:
set (BARRIER_REVISION 12345678)

Commented on: 2018-04-15 by @yupi2

You might be able to do cmake -DBARRIER_REVISION 123123123 .....etc

Commented on: 2018-05-04 by @VertigoRay

Just walked through it on a new Linux Mint 18.3 Sylvia installation:

# Clone Repo
git clone https://github.com/debauchee/barrier.git
cd barrier

Now, you need to edit the CMakeLists.txt file and add /usr/include to the CMAKE_INCLUDE_PATH, seems to be known, but didn't work for me until I added it.

set (CMAKE_INCLUDE_PATH "${CMAKE_INCLUDE_PATH}:/usr/include")
set (XKBlib "X11/Xlib.h;X11/XKBlib.h") # This line is already here; add the previous line just above this.

Now, more bash commands:

# Install Dependencies
sudo apt -y install cmake gcc build-essential libx11-dev libavahi-compat-libdnssd-dev libxtst-dev qtbase5-dev libssl-dev

# Build Barrier
./clean_build.sh

# Run Barrier
./build/bin/barrier

Tried running ./build/bin/barrierc so I could just pass it all the parameters to connect to my barrier server, but it seemed to crash my terminal and not do anything else. So, for now I've added ./build/bin/barrier to my Startup Applications and I'll just have to type in the server IP each time I reboot. Not the end of the world, since I've been suffering a lot more since Synergy 2 released.

Commented on: 2018-05-12 by @Persei08

Thx @VertigoRay , for me on ubuntu 18.04, it was also necessary to install libcurl4-nss-dev (and there is a typo for libavahi-compat-libdnssd-dev)

Thanks everyone for this project

Commented on: 2018-05-13 by @VertigoRay

I'm glad it helped. 😊 Fixed the typo.

Commented on: 2018-05-29 by @dayne

I happen to have an answer (that I've since verified does successfully build barrier) for issue #41 where I tossed the following reply for the build process on linux:

sudo apt update && sudo apt upgrade
sudo apt install git cmake make xorg-dev g++ libcurl4-openssl-dev \
                 libavahi-compat-libdnssd-dev libssl-dev libx11-dev \
                 libqt4-dev qtbase5-dev
git clone [email protected]:debauchee/barrier.git
cd barrier
./clean_build.sh
cd build
sudo make install  # installs to /usr/local/ 

I'll recommend we add these (or better) instructions to the wiki at: https://github.com/debauchee/barrier/wiki/Building-on-Linux

Commented on: 2018-05-30 by @tavasti

For release-versions (tar or zip) instructions need bit more fidling, and those should be also covered.

Commented on: 2018-11-29 by @bezoris

Install Dependencies

sudo apt -y install cmake gcc build-essential libx11-dev libavahi-compat-libdnssd-dev libxtst-dev qtbase5-dev libssl-dev

Build Barrier

./clean_build.sh

Run Barrier

./build/bin/barrier

Many thanks!
Successful build on Debian stretch after installing libcurl3-nss separately followed by libcurl4-nss-dev; already had libcurl3 and libcurl3-gnutls installed.

Was going a bit batty trying to figure this out. Thanks again!

Commented on: 2019-03-31 by @adeperio

Can confirm @dayne 's instructions worked for me on ubuntu 18

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#31

Issue created on: 2018-04-26 by @AdrianKoshka
Issue last updated on: 2018-05-14

Using the XDG specification directories would not only make the linux package work better as a flatpak, but play nicer with distributions in general. This was mentioned in #30.

• XDG_CONFIG_HOME
• XDG_DATA_HOME
• XDG_CACHE_HOME

flatpak specific docs
XDG Base Directory spec as documented by FreeeDesktop

Commented on: 2018-05-07 by @walker0643

@AdrianKoshka if i missed anything with the patch let me know. thanks for the suggestion!

Commented on: 2018-05-07 by @AdrianKoshka

Looks good, haven't tested. Did you make a new release? Flathub doesn't allow just pointing to master if the source is a git repo.

Commented on: 2018-05-07 by @walker0643

Nope. Tagging will happen once I hear from the various package maintainers that they do not need any additional code changes in order to proceed.

Commented on: 2018-05-07 by @AdrianKoshka

Alright, I'll keep an eye out then for whenever the next tag is out.

Commented on: 2018-05-14 by @walker0643

2.1 tagged

Closed on: 2018-05-07 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#58

Issue created on: 2018-06-10 by @BtheDestroyer
Issue last updated on: 2021-01-10

Operating Systems

Server: Windows 10 build 1803

Client: Linux Mint 18.3 Cinnamon

Barrier Version

2.1.0-RELEASE

Steps to reproduce bug

1. Run the server on Windows
2. Connect with a client on Linux
3. Moving the mouse from Windows to Linux works, but if the mouse stops moving, it won't move for a few seconds when on the client. The same occurs with the keyboard (there's a noticeable delay when beginning to type)

This does not occur when Linux is hosting the server and Windows connects as the client.

Commented on: 2018-09-08 by @walker0643

I have a Win10/arch setup here but I can't reproduce your issue. Can you provide anything that might help me bring out the bug? Can anyone else confirm similar behavior?

Commented on: 2018-12-09 by @AngelJA

I know this is late, but I just had a similar issue, except instead of pausing for a few seconds it was only like a half second. If I moved the mouse continuously it seemed fine, but if I paused, then the first time I moved the mouse or typed there'd be a noticeable, annoying lag. (Also Windows server, Linux Client)

For me it turned out to be because my Linux Client was on wifi; using ethernet gave me super smooth performance. So for anyone else having issues I'd consider looking at your network setup.

Commented on: 2018-12-09 by @AngelJA

Followup to my last post: I did a bit more research and found that the reason ethernet was so much better was because wifi powersave was on. I won't list the steps to fix that since it may vary, but you should be able to google it. :)

Commented on: 2018-12-12 by @AdrianKoshka

Can this issue be closed?

Commented on: 2018-12-13 by @p12tic

I think barrier could issue a warning when excessive network latency is present. At least users would know that it's something on their side instead of thinking that the software is crap.

Commented on: 2019-09-14 by @mirh

At least users would know that it's something on their side instead of thinking that the software is crap.

This, a hundred times.

Though, couldn't barrier also took care of handling powersave? It would be much more user-friendly, and it could even allow still some nice power saving (e.g. if the mouse is on the host, no need to keep it disabled)
I know wifi.powersave should be an actual hook for snaps then..
but NM can only set them via cfgs, and the kernel dropped long ago the api specifically crafted for that..
So, I think the only option would be calling iw? With some caveats.

Commented on: 2020-04-06 by @Xekon

In my Case I am running Windows 8.1 in QEMU KVM with GPU passthrough for gaming, its the only thing the windows VM gets used for.

Windows 8.1 is the Server and Linux is the client. My linux client occasionally hangs/pauses for what seems to be about 5 seconds. This only happens occasionally.

I would not think latency could be the issue when it happens on the same machine between the VM and Host.

Is there any way for me to debug what might be causing this? It only occurs when I have the input moved over to the linux client.

I notice it often if I am opening a right click menu of the mouse, but that's not the only time, its just one of the times I seem to notice it happen the most. During this time I can use the secondary mouse or keyboard that are connected directly to Linux, its just the ones being used through Barrier that appear to freeze/lock up.

Also sometimes I type things On the linux client, and the freeze up will happen, after a few seconds when it goes back to working the things that I was trying to type will finally show up, as if there was a massive delay but it still received the characters I was trying to type.

I have been dealing with this for about the last 8 months, and every time I silently grumble and just deal with it, but i have been using windows more lately.

Commented on: 2020-05-19 by @axtux

May be related to #617

Commented on: 2020-05-19 by @Xekon

I ended up opening my own issue: debauchee/barrier#645

I had issues with barrier the entire time I was using it which was under ubuntu 18.04.
Once I did a clean install of Ubuntu 20.04 and a clean install of my windows 8.1 vm, the issue was magically gone so I closed the issue I had open.

I suspect the issue was somehow with Ubuntu 18.04 because I used the exact same install media for the windows VM, and all it gets is a few games installed.

Commented on: 2021-01-10 by @p12tic

This has been fixed in #679.

Closed on: 2021-01-10 by @p12tic

This issue has been migrated from old Barrier Github repository debauchee/barrier#50

Issue created on: 2018-05-27 by @c-mauderer
Issue last updated on: 2018-06-09

Operating System (server and client): Arch Linux with 4.16.10-1-ARCH Kernel
Barrier Version: 2.1.0 (from Arch AUR)

My client is a tablet. If I rotate the screen (for example via xrandr -o right), barrier has problems after the rotation. The mouse cursor (moved via barrier) is hanging at one edge of the screen and I can't reach any positon. I can move the cursor normal with a directly connected mouse or with the touchscreen. Keyboard input works normal.

Note that I also had that problem with an (old) synergy version on some other hardware. On synergy I have been able to just killall synergyc to get a running instance again. It seems that this workaround doesn't work with barrier any more.

Edit: I totally forgot: A big thanks for continuing the development of synergy in this fork. I really like it a lot more than the "new" synergy.

Commented on: 2018-06-09 by @c-mauderer

Found out some more details about that problem: It seems that it isn't with rotating the screen but with rotating the touch of the tablet. My method for that recently changed (as did my synergy / barrier usage). Some time back I used a script that rotated specifically one touch device. My new script rotates every device that has a "Coordinate Transformation Matrix" via (for example)

xinput set-prop 2 150 0 -1 1 1 0 0 0 0 1

That works well as long as there is only a touch screen. But for some reason the "Virtual core XTEST pointer" has a "Coordinate Transformation Matrix" too that shouldn't be rotated. So it's not a bug of barrier but one of my rotation script. I'll fix that there.
Sorry for the wrong bug.

Closed on: 2018-06-09 by @c-mauderer

This issue has been migrated from old Barrier Github repository debauchee/barrier#39

Issue created on: 2018-05-20 by @llitz
Issue last updated on: 2018-06-30

Operating Systems

Server: Windows 10 - Version 1803 - Build 17134.48
Using github Binary

Client: Linux - Gentoo
Kerne:l 4.16.7
Compiling from source
INFO: OpenSSL 1.0.2o 27 Mar 2018
DEBUG1: openSSL : compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -march=bdver4 -O2 -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp -madx -mrdseed -mmwaitx -msha -mxsavec -mxsaves -mclflushopt -mpopcnt -fno-strict-aliasing -Wa,--noexecstack

Barrier Version

2.1.0 Windows
2.1.x Linux (2.1.0 and 2.1.1 have same error)

When running Windows on 2.1.0 and Linux 2.0.0 error disappears

Steps to reproduce bug

Updating from 2.0.0 to 2.1.0/2.1.1 introduced the error. This is seen on client side:
NOTE: server fingerprint: xx:xx:xx:xx..............
ERROR: failed to verify server certificate fingerprint

Rolling back to 2.0.0 on client eliminates the error (without needing to change certificates or anything else. I have regenerated them but the error persists.

The server (2.1.0), sometimes, will show this error when running against the 2.1.0 client:
[2018-05-20T00:13:00] NOTE: accepted client connection
[2018-05-20T00:13:11] ERROR: ssl error occurred (system call failure)

Was anything related to SSL changed between 2.0.0 and 2.1.0?

Commented on: 2018-05-20 by @walker0643

Hi @llitz - This issue is most likely that between 2.0 and 2.1 the data directory locations were changed to be more conformant to each platform's specs. As a result users will need to recreate their SSL certs and fingerprints (or copy the old ones). The new location for Windows is %USERPROFILE%\AppData\Local\Barrier and for Linux it's $HOME/.config/Barrier. If it's easier for you, you can simply delete the old configurations (but back them up first!) and let the Barrier UI make them as if it were a fresh install.

Commented on: 2018-05-20 by @llitz

I have definitely done that and the Linux client didn't create anything for me under .config, I run barrier on Linux only by calling barrierc with the encryption option.

if I delete everything, 2.0 works fine, 2.1 doesn't.

I will try to move the directory and see if it works, but it should've created it automatically. Any ideas on how to track it?

Commented on: 2018-05-20 by @walker0643

You need to run the UI (barrier, not barrierc) in order to approve the server's fingerprint. Either that or create a text file called TrustedServers.txt under $HOME/.config/Barrier/SSL/Fingerprints (assuming Linux) and put the server's fingerprint inside it.

Commented on: 2018-05-20 by @llitz

Is this a new behavior? I did not need to do it on 2.0.0? I will test in a few and report back, thanks.

Commented on: 2018-05-20 by @llitz

All right, so I have just tested it all starting with barrierc again (barrier doesn't show up on my server and even if it did I couldn't really click on it if I can't pass the mouse). The barrierc binary doesn't even try to read the .config/barrier/SSL/Fingerprints/TrustedServers.txt, confirmed it with strace (or any other .config/barrier or .barrier file for that matter).

The new directory tracking is outputting something wrong, I don't even know what it is trying to read and it doesn't show up with DEBUG2. Something is broken because of it.
Not sure if you can reproduce it, if not I can help track it if you point me in the right direction (I see several changes regarding the logic to find the right directory).

Commented on: 2018-05-21 by @walker0643

You're right, of course. I shouldn't have replied until I was able to verify what I was telling you, and I was remembering the linux path incorrectly. The actual path under your home directory defaults to .local/share/barrier as per the freedesktop standard. Assuming an otherwise standard installation you should have your trusted fingerprints file at /home//.local/share/barrier/SSL/Fingerprints/TrustedServers.txt.

Commented on: 2018-05-21 by @llitz

Perfect, it is working now! Thanks (=

Could I suggest some usability improvements?
1 - The fact that the fingerprint isn't found inside the TrustedServers.txt isn't completely clear on Logs. Can we add the TrustedServers.txt path to the Log?
2 - When running "barrierc --help" is it possible to indicate the --enable-crypto require servers to be listed under "$Platform_path/SSL/Fingerprints/TrustedServers.txt" and, somewhere in that help screen, provide the location for "$Platform_path".

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#61

Issue created on: 2018-06-20 by @DiThi
Issue last updated on: 2021-11-03

Operating Systems

Server: latest Windows 10 (1803), but happened in previous versions too (tested with Windows 8.x). I don't remember right now if it happened with Linux. It either happens with Linux, or happens with the client, since I couldn't get a setup without this problem.

Client: Bug happens even before connecting, so no client needed to reproduce.

Barrier Version

2.1.0

Steps to reproduce bug

Set keyboard to Spanish (Spain). Press "a" and "´" (accent mark, in US keyboard it's the aposthrophe mark) repeatedly, quickly.

When the "a" is released before the "´" is, the next "a" won't be á. You should get áááááááááááá but you get something like áááaaaaaaaáa.

As a fast typist, in practice most of the accents are missing.

Other info

• When did the problem start to occur? Years... As long as I can remember with any Synergy 1.x.
• Is there a way to work around it? Writing very slowly, accepting the annoying typos or not writing Spanish at all.
• Does this bug prevent you from using Barrier entirely? Yes, or at least I only start the server if strictly necessary...

Commented on: 2018-06-21 by @DiThi

Just found the issue I sent in 2015, because it has been marked as "stale" and closed: symless/synergy-core#5007

There's more info in there:

On client machines the issue is even worse, sometimes putting the accent twice, e.g. "c´ámara" instead of "cámara".

Commented on: 2018-06-30 by @walker0643

I use spanish quite a bit and I haven't had this issue. Can anyone else confirm??

Commented on: 2018-06-30 by @DiThi

@walker0643 I wonder what's different... What's your typing speed for Spanish? Mine is 84 WPM (>400 PPM). What keyboard layout do you use? Mine is Spanish (Spain), where the accents don't appear when you press them, but only after you press another key. That's called dead key IIRC.

Can you try the áááááá test described above or in the linked issue?

Commented on: 2018-06-30 by @walker0643

I have tried speed-typing áááááááááááá with the "United States-International" layout. It's very responsive here and doesn't miss or misprint any characters.

And I have no idea what my spanish typing speed is 😄

Commented on: 2018-07-04 by @danielmunoz

I have this very issue with Synergy, even with the latest paid version they provide.

However, I am unable to reproduce this issue with my current setup using Barrier 2.0.0:

• Server on macOS 10.12.6
• Client on Windows 10 (1803)

So, with my current setup, I can type áéíóú perfectly fine.

I will test if reversing client/server sides works fine or not.

Commented on: 2018-09-08 by @walker0643

Please reopen if you have anything to add. Thanks!

Commented on: 2018-09-09 by @DiThi

Reinstalled Barrier 2.1.0, still happening.

@walker0643 Make sure to use "Spanish keyboard" or "Spanish (Spain)". The error can't be reproduced with US-intl for some reason.

Commented on: 2020-10-28 by @setovi

I confirm, still in version 2.3.3

Sometimes the accent mark is missing, sometimes is double printed with no vowel, like: ''

It's very annoying and makes the application unusable.

TIA

Commented on: 2021-02-01 by @DragonSlifer

Also, the "¨" symbol does not work at all. I have to copy and paste whenever I want to put "ü". It's really annoying. The accents "´" work sometimes good, but most of the time it just prints "´´a" instead of "á". And yes, I've checked if it was a keylogger virus, and obviously wasn't.

Commented on: 2021-05-10 by @robsonferreir4

some solutions?

Commented on: 2021-11-03 by @LaraArgento

Same here. I have to Reload Barrier in order to fix the issue, but it comes back in a matter of a few minutes and it is very annoying.

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#13

Issue created on: 2018-02-24 by @walker0643
Issue last updated on: 2018-09-08

I'm not sure if we really want this. Apparently VBox adapters screw up auto-config on unixes if not all platforms.

symless/synergy-core#5245

Meta: #7

Comments? Can anyone confirm?

Commented on: 2018-09-08 by @walker0643

Reopen if anyone needs this patch.

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#32

Issue created on: 2018-04-27 by @ramesh45345
Issue last updated on: 2018-05-12

Referencing issue #18, when connecting to an Ubuntu 18.04 server running barriers (git master 0b5ca57), a Fedora 27 client (same barrier version) connecting via IPv6 (resolved from the avahi hostname resolution as well as router hostname resolution) receives a connection refused message. Both the server and client are using SSL, and both work fine when an IPv4 address is hard-coded. The following log is generated on the client (Fedora 27):

[2018-04-27T08:48:15] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:15] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839
[2018-04-27T08:48:15] WARNING: failed to connect to server: Connection refused
	/var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301
[2018-04-27T08:48:16] NOTE: connecting to 'rkrishna-pc': fd5b:88e:f3e5::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:16] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839
[2018-04-27T08:48:16] WARNING: failed to connect to server: Connection refused
	/var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301
[2018-04-27T08:48:17] INFO: stopping barrier desktop process
[2018-04-27T08:48:17] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:17] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839

The following log is generated on the server running Ubuntu 18.04 (basically nothing, since the server doesn't hear anything from the client):

[2018-04-27T08:46:54] INFO: starting server
[2018-04-27T08:46:54] INFO: config file: /tmp/Barrier.h26056
[2018-04-27T08:46:54] INFO: log level: INFO
[2018-04-27T08:46:54] NOTE: started server, waiting for clients
	/var/tmp/barrier/src/lib/barrier/ServerApp.cpp,540

Note: The openssl version on the server is as follows:

[2018-04-27T08:48:17] INFO: OpenSSL 1.1.0g  2 Nov 2017
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839

Operating Systems

Server: Ubuntu 18.04
Client: Fedora 27
Both updated to latest software from repositories.

Barrier Version

git master 0b5ca57, compiled on their respective machines. After upgrading to Ubuntu 18.04, barrier was recompiled as a precaution.

Steps to reproduce bug

1. On the client, either specify an IPv6 address for the server (this I didn't test), or use a hostname which resolves to an IPv6 address first through avahi or router name resolution (this was used in my case).
2. Ensure SSL is enabled on both the client and server.
3. Ask the client to connect. The client will not be able to connect, saying connection refused.
4. Replace the IPv6 address with an IPv4 address.
5. Connection will work properly.

Other info

Bug doesn't prevent me from using barrier, however it is inconvenient since hostname resolution is IPv6 first on all my networks, and then IPv4. As a workaround, I'm not sure if barrier can ask for an IPv6 address first from avahi, and then an IPv4 address?

Commented on: 2018-04-28 by @walker0643

HI @ramesh45345 -

This is a very well-written bug report. Thank you! We're currently short on IPv6 developers but I've asked a couple people to have a look at this. Hopefully we can get you up and running shortly. Stay tuned!

Commented on: 2018-04-28 by @AdrianKoshka

If it helps any, I know IPv6 works on barrier, I have my server bound to ::1. (client remote port-forwards connection over SSH and connects). I could also test to see if synergy connects of a /127 prefix IPv6 address. I would test over a normal /64 but my ISP has broken DHCPv6-PD and I haven't called them to fix it, and too lazy to setup an internal /64

Commented on: 2018-04-29 by @ramesh45345

Thanks a bunch @walker0643 . I think this should be easily reproducible, I have another set of machines using barrier (Ubuntu 18.04 on the client, and Fedora 27 on the server, the reverse of my bug report above), and seem to have the same problem. Connection refused when I use the avahi IPv6 autoconfigured address. @AdrianKoshka , what git revision of barrier are you using (or released version, if applicable)? Perhaps I should test an older version and see if I have the same problem.

Commented on: 2018-04-29 by @AdrianKoshka

Release 2.0.0 @ramesh45345

Commented on: 2018-04-29 by @AdrianKoshka

So I tested with this setup and it worked (used SSL):

• server: ::40/127 Fedora 27
• client: ::41/127 Debian 9 stretch

Of course, I sepcified the IPv6 address(es) for both client and server in my systemd template user unit.

• barriers@::40.service
• barrierc@::40.service

Replication

If you want a quick and dirty way to replicate what I did.

Server:

1. sudo ip addr add dev enp1s0 ::40/127 (replace enp1s0 with your interfaces' name)
2. barriers --address ::40 --enable-crypto --no-restart --no-daemon --config /path/to/your/config

Client:

1. sudo ip addr add dev enp2s0 ::41/127 (replace enp2s0 with your intefaces' name)
2. barrierc --enable-crypto --no-restart --no-daemon ::40

Cleanup:

1. kill barriers and barrierc
2. sudo ip addr del dev enp1s0 ::40/127 (replace ::40 with ::41 on the client, and enp1s0 with your intefaces' name)

Commented on: 2018-05-08 by @ramesh45345

@AdrianKoshka Thanks for the insight, I should have tested the CLI apps before. I have tested IPv6 and it seems to work when I call it from the command line for git version 5e19820 (which is the closest to 2.0.0), as well as master (b43581c). I am using the below command for the server (Fedora 28):

barriers --address fd7f:7549:7489::2cc --enable-crypto --no-restart --no-daemon --config ~/test.cfg

And the below command for the client (Fedora 28 as well):

barrierc -f --enable-crypto fd7f:7549:7489::2cc

I believe there are two things going on here:

1. I believe the GUI barrier program does not by default listen on IPv6 when it calls barriers on the server.
2. Furthermore, when I feed an IPv6 address into the client GUI for master b43581c (when both the server and client are running via Barrier GUI), the client's barrierc log from the GUI gives an "unknown error" when trying to connect:

[2018-05-08T18:11:01] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,304

Notice the repeated 24800 port above. I would bet that has something to do with the problem. In my entry for the client in the GUI, I have omitted the port altogether (I only filled an IPv6 address). I think the GUI is doing the duplication.

@walker0643 I guess I have two questions:

1. Is the GUI listening on IPv6 as well as IPv4 by default? It would explain my earlier "Connection Refused" messages in my initial report if it wasn't doing this.
2. Any idea why the GUI client and GUI server have differing behavior than the CLI commands? It seems I can get IPv6 working from the CLI, but not the GUI, and barrierc does not duplicate the port like in the GUI output above.

Commented on: 2018-05-08 by @wltjr

Just to chime in here, I did not author, but I did update the IPv6 patches for Synergy. Which I believe is the basis for this in Barrier. Looking back over that patch in symless/synergy-core/pull/6178. Even in the original symless/synergy-core/pull/4499. It was just patching lib, client and server, not gui. Based on that, it seems there may have been further IPv6 changes done as part of the work in Barrier.

@walker0643 that may be a partial answer to your question 2. Seems they furthered the code into the GUI and something maybe off there. Which is why one works and the other does not.

I can see about taking a look there, but not sure if I can help at all. I was contacted regarding the patches and this issue. Thus chiming in, and I am happy to help if I can.

Commented on: 2018-05-10 by @walker0643

It's entirely possible that the GUI is to blame. The GUI does not open any sockets nor do any real networking itself, it simply starts barriers/barrierc (and barrierd on windows) and passes configuration params as arguments.

@ramesh45345 Can you enable debugging info in the GUI settings window (any level INFO and above iirc) and compare the arguments that it passes to barriers/barrierc to those that you were using above?

Commented on: 2018-05-10 by @wltjr

I would assume something is being passed incorrectly from UI to CLI, however that is done. It seemed above a port was duplicated. I do not use any UI with synergy, just text config and starting via cli. That part should be good to go with any IPv6 address.

Commented on: 2018-05-10 by @ramesh45345

@walker0643 Here is the output from the server:

[2018-05-10T07:46:33] INFO: starting server
[2018-05-10T07:46:33] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name rkrishna-pc --enable-crypto -c /tmp/Barrier.i22916 --address :24800
[2018-05-10T07:46:33] INFO: config file: /tmp/Barrier.T22916

I think in modern versions of barriers the ":24000" is unnecessary? In my command line post earlier, I fed an IPv6 address into barriers, however ideally I would have wanted to accept connections from alll IPv6 and IPv4 addresses.

Commented on: 2018-05-10 by @walker0643

That's very helpful. Can you test the dualstacked branch to see if it fixes this?

https://github.com/debauchee/barrier/tree/dualstacked

Commented on: 2018-05-11 by @ramesh45345

Hmm, using the dualstacked branch (4806a66a), I am still getting the same result.

Server command:

[2018-05-11T17:22:06] INFO: starting server
[2018-05-11T17:22:06] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name HomeLaptop --enable-crypto -c /tmp/Barrier.Woawqk --address :24800
[2018-05-11T17:22:06] INFO: config file: /tmp/Barrier.WcMPIT
[2018-05-11T17:22:06] INFO: log level: DEBUG2

Client log (same version, 4806a66a):

[2018-05-11T17:23:50] NOTE: connecting to 'HomeLaptop': fd7f:7549:7489::2cc:24800
	/mnt/nasvol/DLs/barrier/src/lib/client/Client.cpp,146
[2018-05-11T17:23:50] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/mnt/nasvol/DLs/barrier/src/lib/net/SecureSocket.cpp,839
[2018-05-11T17:23:50] WARNING: failed to connect to server: Connection refused
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301

Looks like the GUI is still not listening on IPv6 by default. IPv4 still works normally. The above client log was taken with avahi resolution of the IPv6 address. It seems that if you fill in the IPv6 address into the client GUI manually, it still duplicates the port:

[2018-05-11T17:28:09] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301

Commented on: 2018-05-12 by @walker0643

Take 2 ... this time barriers will tell you explicitly which socket family it's using. There will be a NOTE-level line in the debug output stating either

• NOTE: started server (IPv4), waiting for clients
  or
• NOTE: started server (IPv4/IPv6), waiting for clients

Also you can confirm via netstat or another similar tool (netstat -46l for example) whether or not barrier has opened the correct socket type.

Commented on: 2018-05-12 by @ramesh45345

Excellent! It works! It did start in IPv6/IPv4 mode, and the client was able to connect using the avahi name resolution.

Server:

[2018-05-12T10:25:27] INFO: starting server
[2018-05-12T10:25:27] INFO: config file: /tmp/Barrier.EwSlum
[2018-05-12T10:25:27] INFO: log level: INFO
[2018-05-12T10:25:27] NOTE: started server (IPv4/IPv6), waiting for clients

There is only one small issue remaining, and that is manually inputting an IPv6 address into the client GUI's "Server IP" field. It still yields the following results in 5bc3fef8:

[2018-05-12T10:31:52] INFO: starting client
[2018-05-12T10:31:52] INFO: command: /usr/local/bin/barrierc -f --no-tray --debug DEBUG2 --name HomeServer --enable-crypto fd7f:7549:7489::2cc:24800
[2018-05-12T10:31:52] INFO: config file: /tmp/Barrier.lvqIHI
[2018-05-12T10:31:52] INFO: log level: DEBUG2
[2018-05-12T10:31:53] NOTE: started client
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,393
[2018-05-12T10:31:53] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800

I admit that I probably won't rely on this much, but I can see this bug needing to be fixed at some point. I believe the way it is working right now, for an IPv6 address, I can't specify the port using the command line in order for it to connect properly. For example, using the following command (without the GUI) on the client works:

barrierc -f --enable-crypto fd7f:7549:7489::2cc

However, this results in the port error seen above:

barrierc -f --enable-crypto fd7f:7549:7489::2cc:24800

I suspect the issue is specifc to parsing the semi-colons in IPv6 addresses (a wild guess on my part). Might explain why hostnames or IPv4 addresses work just fine with ports.

Commented on: 2018-05-12 by @yupi2

Wrapping the IPv6 address in brackets seems to be the notation used to separate port and address (since IPv6 uses colons). https://serverfault.com/questions/205793/how-can-one-distinguish-the-host-and-the-port-in-an-ipv6-url

Would need to change parsing in https://github.com/debauchee/barrier/blob/24987e069496b185ad88de09657dced2a73189ef/src/lib/net/NetworkAddress.cpp#L60
and then make the GUI put brackets around IPv6 addresses (with the port outside the brackets) I imagine.

Commented on: 2018-05-12 by @walker0643

Among other cleanup and bookkeeping items I also added today (what I hope is) a fix for the host:port argument issue you mentioned. Take a look and please let me know if you see anything else related that needs to be addressed before merging. Thanks!

Commented on: 2018-05-12 by @ramesh45345

No further complaints from me, 92e8e1e seems to be working regarding everything reported above. Thanks a bunch for your work on this, its a really appreciated fork of the synergy codebase.

Closed on: 2018-05-12 by @ramesh45345

This issue has been migrated from old Barrier Github repository debauchee/barrier#35

Issue created on: 2018-05-04 by @wanjizheng
Issue last updated on: 2018-05-04

Hi, anyone can tell me how to install/debug this on Ubuntu?

Closed on: 2018-05-04 by @wanjizheng

This issue has been migrated from old Barrier Github repository debauchee/barrier#20

Issue created on: 2018-03-09 by @truatpasteurdotfr
Issue last updated on: 2018-03-13

Operating Systems

CentOS-7

Barrier Version

2.0.0-RC2

Steps to reproduce bug

running barrier on CentOS-7 gives this warning message:

$ barrier
*** WARNING *** The program 'barrier' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=barrier>

when clicking on the [] server checkbox these additionnal lines appears:

*** WARNING *** The program 'barrier' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=barrier&f=DNSServiceRegister>

list of the avahi packages installed on the machine:

$ rpm -qa \*avahi\*| sort
avahi-0.6.31-17.el7.x86_64
avahi-compat-libdns_sd-0.6.31-17.el7.x86_64
avahi-compat-libdns_sd-devel-0.6.31-17.el7.x86_64
avahi-devel-0.6.31-17.el7.x86_64
avahi-glib-0.6.31-17.el7.x86_64
avahi-gobject-0.6.31-17.el7.x86_64
avahi-libs-0.6.31-17.el7.i686
avahi-libs-0.6.31-17.el7.x86_64
avahi-ui-gtk3-0.6.31-17.el7.x86_64
```

---

> Commented on: 2018-03-10 by @walker0643

These warnings seems to be benign. Several other projects using libraries for apple technology have seen them and most seem to disregard them ...

eg:
https://github.com/nfarina/homebridge/blob/master/README.md#errors-on-startup

The question now becomes one of whether or not it is worth it to "fix" code that otherwise works.

---

> Commented on: 2018-03-12 by @truatpasteurdotfr

Either fix, or put an entry for a FAQ, with a better wording than "the cost of removing the issue at the core of the errors isn't worth the effort", imho.

---

> Commented on: 2018-03-13 by @walker0643

More info:

https://src.fedoraproject.org/rpms/cups/tree/f15

The 5 patches beginning with cups-avahi- are what the cups folks had to do to get this warning to go away. I'm not finding any indication whatsoever of a change in functionality. It seems to be simply an effort to get developers not to use Apple APIs even though they are supported now and have been for > 10 years (this warning is older than that).

---

> Commented on: 2018-03-13 by @walker0643

Fixed in https://github.com/debauchee/barrier/commit/921a40c6841951fc6b744751f39c1a0dcf1b94ed

---

> Closed on: 2018-03-13 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#38

Issue created on: 2018-05-16 by @rodrigocam
Issue last updated on: 2018-05-17

I want to contribute with this project (I think it is a really good tool!!), so I read #22 issue, and I don't know how it is going the progress to make a .deb package. I have build a .deb for my own, and if there is anything I can help, I will be at your disposal (:

Commented on: 2018-05-17 by @walker0643

Hi @rodrigocam - Thanks for offering to help! As I understand it our debian packager is in the process of getting the package added to the repositories. It's been a rather slow process, I admit, but we should be seeing packages appear "soon"(TM) 😛

Commented on: 2018-05-17 by @rodrigocam

Oh cool! I hope the best for you guys 😃

Closed on: 2018-05-17 by @rodrigocam

This issue has been migrated from old Barrier Github repository debauchee/barrier#21

Issue created on: 2018-03-11 by @walker0643
Issue last updated on: 2018-03-11

Non-Windows platforms do not make use of the barrierd daemon, therefore it should not be built.

Meta: #7

Commented on: 2018-03-11 by @walker0643

fixed in b9a59c0 and 51abdc2

Closed on: 2018-03-11 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#18

Issue created on: 2018-03-06 by @walker0643
Issue last updated on: 2018-03-26

While it may not be popular in LAN environments at the moment, there are LANs that utilize IPv6. I would expect that the number of these LANs will increase as time goes by.

Ref: symless/synergy-core#6178

Meta: #7

Commented on: 2018-03-26 by @walker0643

Added in debauchee/barrier@9a2d61c

Closed on: 2018-03-26 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#25

Issue created on: 2018-03-29 by @walker0643
Issue last updated on: 2018-04-16

syntool no longer seems to do anything that cannot be done from the calling process. verify and remove.

Commented on: 2018-03-29 by @walker0643

branch created. PR #26

Commented on: 2018-04-16 by @walker0643

branch merged. closing.

Closed on: 2018-04-16 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#57

Issue created on: 2018-06-06 by @mario98
Issue last updated on: 2018-06-09

Is there an option to select the specific network controller that should be used for connection?

If not, do you think such an option could be implemented?

Commented on: 2018-06-07 by @dayne

The server binds to 0.0.0.0 by default meaning the port (24800) is open for business on all interfaces/networks on a system.

I think this is the correct behavior and can be managed at firewall level "I want to allow traffic from X network or X.Y IP to connect to my synergy port". I've had to handle this in the past and securing it at the firewall level for networks/IPs felt right.

Having to worry about an additional launch option/parameter to restrict the port binding to a specific network interface does not feel right at all.

That said if you want to restrict at the server level which network the port is open on it allows for that already using the -a or --address option.

barriers --help shows the following hint for this:

The argument for --address is of the form: [][:]. The
hostname must be the address or hostname of an interface on the system.
Placing brackets around an IPv6 address is required when also specifying
a port number and optional otherwise. The default is to listen on all
interfaces using port number 24800.

Given that typically a network controller is handling just a single network you are getting the effect you I think you are asking for. Recommend closing this issue as I think the core feature being requested is available already.

Commented on: 2018-06-09 by @mario98

Ok, I see.

I also found out that in my setup, a connection via. the network I wanted is not possible anyway; I have a VPN that block every other network (blocking split tunneling). So it's not a missing option that holds me back, but the VPN of my company (which makes sense from a security perspective).

Closed on: 2018-06-09 by @mario98

This issue has been migrated from old Barrier Github repository debauchee/barrier#52

Issue created on: 2018-05-29 by @xantoz
Issue last updated on: 2018-06-30

Operating Systems

Gentoo Linux

Barrier Version

2.1.0

Steps to reproduce bug

1. cd /path/to/barrier
2. mkdir build
3. cd build
4. cmake -DBARRIER_BUILD_GUI=OFF -DBARRIER_BUILD_INSTALLER=OFF ../

If I do not have any provider of dns_sd.h installed (such as mdnsresponder or avahi with mdnsrespondercompat) cmake aborts with: "Missing header: dns_sd.h"

Expected result: cmake will succeed as long as BARRIER_BUILD_GUI=OFF, despite the lack of a provider of dns_sd.h on my system. With BARRIER_BUILD_GUI=ON cmake will complain about missing dns_sd.h

Other info

The only files that include dns_sd.h are under src/gui/src, thus it seems that dns_sd is only a requirement when building the GUI. This also reflects the state of things for old versions of synergy.

Further I ended up installing avahi and building with GUI and I checked the output of ldd on the resulting binaries:
barrier-ldd.txt
Only the GUI executable "barrier" shows any dependency on libdns_sd.so.1, libavahi-client.so.3 and libavahi-common.so.3

Commented on: 2018-05-29 by @AdrianKoshka

I could be wrong, but I think barrier needs dns_sd.h whether you're building the GUI or not.

Commented on: 2018-05-30 by @xantoz

synergy-1.9 doesn't, and judging from the barrier source code and the resulting binaries it shouldn't need it as well.

Commented on: 2018-06-30 by @walker0643

You're absolutely right, @xantoz :) fixed in debauchee/barrier@e88bc97

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#51

Issue created on: 2018-05-28 by @rmb938
Issue last updated on: 2021-09-17

Operating Systems

Server: Fedora 28

Client: Windows 10 Build 1803

Barrier Version

2.1.0

Steps to reproduce bug

1. Use a mouse that has additional buttons (i.e forward and back buttons)
2. Try and use those buttons while in the client

Other info

It would be nice if at least the forward and back buttons would work.

Commented on: 2018-05-28 by @yupi2

I got forward&back buttons working along with horizontal scroll some time ago. Works on X11 & Win32 but I never tested on OSX.
main patch:

• yupi2/synergy@b2a0ab2
• https://github.com/yupi2/synergy/commit/b2a0ab2f58038a7b20f6e792711f33a778053350.patch

later patch to suppress warning:

• yupi2/synergy@4541a79#diff-a32b85f634235bfc6c47ee4b259d4175R700

If/when someone applies the patch remember to include my author information for git.

Commented on: 2018-06-30 by @walker0643

Can someone make a PR for this please?

Commented on: 2018-09-08 by @walker0643

Inactive for over 2 months. Closing (but would still like to have the PR!)

Commented on: 2018-12-13 by @aaronsb

Inactive for over 2 months. Closing (but would still like to have the PR!)

What's the most effective way to get this patch integrated? I'd really like to use my back and forward buttons without maintaining an entire copy of this. 👍

Commented on: 2019-01-23 by @vorph1

Hi, here's a patch with yupi2's changes modified to apply correctly to barrier.

vorph1/barrier@5111f40

Back/forward buttons and horizontal scroll work but there's some instability. I'm not sure if that's from the patch or the master branch is unstable itself as I only applied to head and not any stable releases.
Tested only linux server and win10 client so far.

Commented on: 2019-01-25 by @vorph1

I've now confirmed that the instability is not present with the patch applied to 2.1.2.
I might find time to set up a macos instance to test but no promises there.

Would you consider merging the patch as is or do you need any changes? Also I'm not sure where would be the best place to mention it's yupi2's contribution so any feedback welcome there.

Commented on: 2019-01-25 by @AdrianKoshka

Would just need to create a PR. I could do it and then we could review the code.

Commented on: 2019-05-31 by @aaronsb

Would just need to create a PR. I could do it and then we could review the code.

Has a PR been created yet?

Commented on: 2019-05-31 by @AdrianKoshka

Yes, #242

Commented on: 2021-09-17 by @RotBolt

Hello, I am still facing the same issue. I have mouse with additional buttons and horizontal scroller and its not working
I was trying barrier on macOS and Ubuntu

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#56

Issue created on: 2018-06-02 by @alvarogf97
Issue last updated on: 2018-06-20

Operating Systems

Server: Ubuntu 18.04

Client: Windows 10

altgr modifier do not work on client side

Commented on: 2018-06-07 by @dayne

Googled this a bit and turns out synergy-core has this as a well known issue in the fork for barrier and also on their current Synergy 2 (as of June, 2018). So a known issue in this code for over 4 years or more.

Wiki entry: https://github.com/symless/synergy-core/wiki/AltGr

Consolidated issue: symless/synergy-core#4411

More advanced than the altgr = shift fix to consider looking at:

• symless/synergy-core#4411 (comment)
• symless/synergy-core#5723 (comment)

Report back if you find success.

Commented on: 2018-06-20 by @alvarogf97

it's work thanks, but I have the following warnings:
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi
I do not want to open GUI, but how can I init barrier with conf file from shell?

Commented on: 2018-06-20 by @alvarogf97

./barriers --debug DEBUG --no-daemon --enable-crypto --no-tray

it's work. Thanks

Closed on: 2018-06-20 by @alvarogf97

This issue has been migrated from old Barrier Github repository debauchee/barrier#44

Issue created on: 2018-05-23 by @kenny-w1
Issue last updated on: 2021-04-01

Hey, lovely project! Very happy to have an alternative to the mainline synergy what with the pay-wall and all, but I have the same problem on synergy as I do on barrier, the 'server IP: ' is always blank when I restart my client PC's, I'd like my client PCs to work without keyboards & mice but I cannot do that it would seem, I've tried saving the configuration but that doesn't seem to do it, and auto config asks me for a hostname.... What am I missing here? I must be doing something wrong but I don't know.

Using the AUR version of the program, in case that matters.

Commented on: 2018-05-23 by @johnny-mac

I have the same issue on my Arch distro, the client server IP always goes blank on reboot, I'd like it to be filled in & auto-"start"ed but I cant figure this out either. Surely there is something we must have missed but I'm not sure what or where that could be, perhaps a config file must be editted so it starts up with an IP & auto-"start"s....

I don't mind if I have to toggle configurations on the keyboard/mouse server PC but having to do so on the client PC's is kind of a pain, that means I have to unplug my keyboard & plug it into the other computers every time I start them up.. I have over-looked the example config files but no luck there unfortunately.

Commented on: 2018-05-23 by @johnny-mac

Hey kenny-w1 I have something you can try, when you start barrier you just have to add --config barrier.sgc
like this:

barrier --config barrier.sgc

That did it for me :) this just made everything 10000x easier, thank you for this awesome free fork of Synergy. you save configuration to make a barrier.sgc
I think it would benefit everyone else for this to be documented in an obvious & easy-to-see place.

Commented on: 2018-05-25 by @walker0643

hi @kenny-w1 - the server's info should persist inside the following file:
$HOME/.config/Debauchee/Barrier.conf

Can you verify that the file exists and that it has a "serverHostname=" line under the "[General]" section?

Commented on: 2018-05-26 by @kenny-w1

Yeah and my IP address for my server PC is in serverHostname=, BUT the configuration(and by configuration I mean the program won't auto-connect when it opens back up, the server IP: is always blank) won't save unless I do what Johnny here did. If I don't do barrier --config ~/.barrier.sgc after saving a configuration to /home/user/.barrier.sgc then barrier will open up without any of the configuration working, also there's a funny error about qt5_use_modules, I think its occuring since I updated cmake...

It would also appear that if I use -DCMAKE_BUILD_TYPE=Release in the CMAKE command that it won't save the configuration right or start with the configuration right or something, all I know is that with =Release it doesn't want to work on start-up. all exact same settings work fine when -DCMAKE_BUILD_TYPE=Release isn't included... I imagine that is Synergy's doing upstream but IDK.

Commented on: 2018-09-08 by @walker0643

Closing due to lack of activity since May. If this is still a problem for you can you try "-config $HOME/.config/Debauchee/Barrier.conf" instead of ~/.barrier.sgc -- does it also work? If not can you paste the contents of that file? Thanks :)

Commented on: 2019-01-22 by @wemakefuture

I am facing the same issue. When i startup barrier doenst connect and the server IP is empty. When i save my config file, there is no IP in it. Can someone pls tell me how to set it up, so my ubuntu 18.04 is by startup connecting?

section: screens
end

section: aliases
end

section: links
end

section: options
	relativeMouseMoves = false
	screenSaverSync = true
	win32KeepForeground = false
	clipboardSharing = true
	switchCorners = none 
	switchCornerSize = 0
end

My Barrier.conf file which was saved by Barrier save configuration.

Commented on: 2019-01-22 by @AdrianKoshka

The barrier config has no IP in it to my knowledge, here's my server config:

section: screens
	am1m-s2h.ccbp.online:
		halfDuplexCapsLock = false
		halfDuplexNumLock = false
		halfDuplexScrollLock = false
		xtestIsXineramaUnaware = false
		switchCorners = none 
		switchCornerSize = 0
	acer:
		halfDuplexCapsLock = false
		halfDuplexNumLock = false
		halfDuplexScrollLock = false
		xtestIsXineramaUnaware = false
		switchCorners = none 
		switchCornerSize = 0
end

section: aliases
end

section: links
	am1m-s2h.ccbp.online:
		left = acer
	acer:
		right = am1m-s2h.ccbp.online
end

section: options
	relativeMouseMoves = false
	screenSaverSync = true
	win32KeepForeground = false
	clipboardSharing = true
	switchCorners = none 
	switchCornerSize = 0
end

Commented on: 2019-11-08 by @Riztard

sorry im new for using linux. so how do i start the client without fill with ip address?

Commented on: 2020-03-18 by @geraldvillorente

I have the same issue on my Mac (server) and Ubuntu (client) setup. Everytime I reboot my Ubuntu the server IP textfield is blank.

Commented on: 2020-09-11 by @PCAri75

I know this is an old thread, but there is a fix described here that isn't clearly described (and I joined Git today just to add this note :) ).

For my MacBook Pro running Catalina, I added the "serverHostname" directive to the"section: options" block of the barrier.sgc file in my macOS home-directory, which now looks like this:

section: screens
end

section: aliases
end

section: links
end

section: options
relativeMouseMoves = false
screenSaverSync = true
win32KeepForeground = false
clipboardSharing = true
switchCorners = none
switchCornerSize = 0
serverhostname = <A.B.C.D>
end

I have Barrier added to my login-items, and in the Barrier settings interface I have "Hide on startup" enabled.

With that setup, Barrier starts when I log in, successfully connects to the server, and remains visible only in the menu-bar at the top of the screen.

Good luck!
--Ari

Commented on: 2021-04-01 by @tienloc1

I know this is an old thread, but there is a fix described here that isn't clearly described (and I joined Git today just to add this note :) ).

For my MacBook Pro running Catalina, I added the "serverHostname" directive to the"section: options" block of the barrier.sgc file in my macOS home-directory, which now looks like this:

section: screens
end

section: aliases
end

section: links
end

section: options
relativeMouseMoves = false
screenSaverSync = true
win32KeepForeground = false
clipboardSharing = true
switchCorners = none
switchCornerSize = 0
serverhostname = <A.B.C.D>
end

I have Barrier added to my login-items, and in the Barrier settings interface I have "Hide on startup" enabled.

With that setup, Barrier starts when I log in, successfully connects to the server, and remains visible only in the menu-bar at the top of the screen.

Good luck!
--Ari

So simple and 100% working for me, thank you so much.

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#34

Issue created on: 2018-04-29 by @Tblue
Issue last updated on: 2018-05-15

I created an Arch Linux AUR package: https://aur.archlinux.org/packages/barrier/

Just in case you want to link it in the wiki... :-)

Commented on: 2018-05-02 by @walker0643

Hi @Tblue - do you plan to maintain this package in the AUR? if so we'll list it for the next release and credit you as the maintainer.

Commented on: 2018-05-02 by @Tblue

Yes, I plan to maintain the AUR package for now.

Thanks!

Commented on: 2018-05-14 by @walker0643

2.1 tagged

Commented on: 2018-05-14 by @Tblue

AUR package updated.

Commented on: 2018-05-14 by @walker0643

https://github.com/debauchee/barrier/wiki

You're officially the AUR maintainer 😄

Commented on: 2018-05-15 by @Tblue

Thanks! 😀

Closed on: 2018-05-14 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#12

Issue created on: 2018-02-23 by @truatpasteurdotfr
Issue last updated on: 2018-02-24

symless/synergy-core#6182

Meta: #7

requires to build on alpinelinux

Commented on: 2018-02-23 by @truatpasteurdotfr

--- a/src/lib/net/SecureSocket.cpp
+++ b/src/lib/net/SecureSocket.cpp
@@ -814,7 +814,7 @@ SecureSocket::showSecureCipherInfo()
         showCipherStackDesc(sStack);
     }
 
-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) // see PR for synergy-core 6182
 	// m_ssl->m_ssl->session->ciphers is not forward compatable,
 	// In future release of OpenSSL, it's not visible,
     STACK_OF(SSL_CIPHER) * cStack = m_ssl->m_ssl->session->ciphers;

Commented on: 2018-02-24 by @walker0643

Is this the only thing needed to fix compatibility with LibreSSL?

Commented on: 2018-02-24 by @truatpasteurdotfr

it's the only changed I made to have barrier build with libressl on alpine...

Commented on: 2018-02-24 by @walker0643

debauchee/barrier@b994c94 thanks!

Closed on: 2018-02-24 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#1

Issue created on: 2018-01-25 by @walker0643
Issue last updated on: 2018-02-13

Quote keys do not function correctly when using an international keyboard layout. This issue is a carry-over from synergy.

Synergy PR: symless/synergy-core#4

Commented on: 2018-02-13 by @walker0643

I have not had this issue for a while now. I'm not sure when/how it was corrected but please re-open on regression.

Closed on: 2018-02-13 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#2

Issue created on: 2018-01-29 by @truatpasteurdotfr
Issue last updated on: 2018-02-23

Operating Systems

macmini:~ tru$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.13.2
BuildVersion: 17C205

Barrier Version

git version: 33b8174
barrier: 1.9.0-snapshot.b1-33b81742

Steps to reproduce bug

#!/bin/sh
export Qt5_DIR=/usr/local//Cellar/qt/5.10.0_1
cd "$(dirname $0)" || exit 1
rm -rf build
mkdir build || exit 1
cd build || exit 1
cmake -D CMAKE_BUILD_TYPE=Debug \
-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk \
      -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13 \
      -DCMAKE_OSX_ARCHITECTURES=x86_64 ..  || exit 1
make -j 4 || exit 1
echo "Build completed successfully"

Other info

• When did the problem start to occur? run the script
• Is there a way to work around it? Not yet
• Does this bug prevent you from using Barrier entirely? Yes

errors:

[ 78%] Linking CXX executable ../../bin/barrier
Undefined symbols for architecture x86_64:
  "_AXIsProcessTrusted", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
  "_AXIsProcessTrustedWithOptions", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
  "_CFDictionaryCreate", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
  "_CFRelease", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
  "_GetCurrentProcess", referenced from:
      MainWindow::setVisible(bool) in MainWindow.cpp.o
  "_TransformProcessType", referenced from:
      MainWindow::setVisible(bool) in MainWindow.cpp.o
  "_kAXTrustedCheckOptionPrompt", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
  "_kCFBooleanTrue", referenced from:
      checkMacAssistiveDevices() in main.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/barrier] Error 1
make[1]: *** [src/gui/CMakeFiles/barrier.dir/all] Error 2
make: *** [all] Error 2
macmini:build tru$ 

Commented on: 2018-02-13 by @walker0643

Fixed in debauchee/barrier@f07070f. Please test.

Commented on: 2018-02-19 by @truatpasteurdotfr

ld: warning: object file (/usr/local/opt/openssl/lib/libcrypto.a(p12_asn.o)) was built for newer OSX version (10.13) than being linked (10.9)

but it builds fine :D

[ 99%] Building CXX object src/gui/CMakeFiles/barrier.dir/barrier_autogen/mocs_compilation.cpp.o
[100%] Building CXX object src/gui/CMakeFiles/barrier.dir/barrier_autogen/PNK5WDWK6L/qrc_Barrier.cpp.o
[100%] Linking CXX executable ../../bin/barrier
[100%] Built target barrier
Build completed successfully
macmini:barrier tru$ 

Commented on: 2018-02-19 by @truatpasteurdotfr

trying to push a 10.13 target yields:

[100%] Linking CXX executable ../../bin/barrier
[100%] Built target barrier
Build completed successfully

with this warning:

/Users/tru/barrier/src/lib/platform/OSXDragSimulator.m:38:18: warning: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
                                                styleMask: NSBorderlessWindowMask
                                                           ^~~~~~~~~~~~~~~~~~~~~~
                                                           NSWindowStyleMaskBorderless
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:954:32: note: 'NSBorderlessWindowMask' has
      been explicitly marked deprecated here
static const NSWindowStyleMask NSBorderlessWindowMask NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskBorderless", 10.0, 10.12) = NSWindowStyleMaskBorderless;
                               ^
1 warning generated.
[ 62%] Building C object src/lib/platform/CMakeFiles/platform.dir/OSXDragView.m.o
/Users/tru/barrier/src/lib/platform/OSXDragView.m:72:8: warning: 'dragPromisedFilesOfTypes:fromRect:source:slideBack:event:' is deprecated: first deprecated in macOS 10.13 - Use
      -beginDraggingSessionWithItems:event:source: with an NSFilePromiseProvider instead [-Wdeprecated-declarations]
        [self dragPromisedFilesOfTypes:[NSArray arrayWithObject:m_dragFileExt]
              ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:582:1: note: 
      'dragPromisedFilesOfTypes:fromRect:source:slideBack:event:' has been explicitly marked deprecated here
- (BOOL)dragPromisedFilesOfTypes:(NSArray<NSString *> *)typeArray fromRect:(NSRect)rect source:(id)sourceObject slideBack:(BOOL)flag event:(NSEvent *)event NS_DEPRECATED_MAC(10_0, 10_13, "Use -beginD...
^
1 warning generated.
[ 62%] Building C object src/lib/platform/CMakeFiles/platform.dir/OSXMediaKeySimulator.m.o
/Users/tru/barrier/src/lib/platform/OSXMediaKeySimulator.m:74:49: warning: 'NSSystemDefined' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
        NSEvent* downRef = [NSEvent otherEventWithType:NSSystemDefined
                                                       ^~~~~~~~~~~~~~~
                                                       NSEventTypeSystemDefined
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:78:26: note: 'NSSystemDefined' has been
      explicitly marked deprecated here
static const NSEventType NSSystemDefined        NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSEventTypeSystemDefined", 10.0, 10.12) = NSEventTypeSystemDefined;
                         ^
/Users/tru/barrier/src/lib/platform/OSXMediaKeySimulator.m:81:47: warning: 'NSSystemDefined' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
        NSEvent* upRef = [NSEvent otherEventWithType:NSSystemDefined
                                                     ^~~~~~~~~~~~~~~
                                                     NSEventTypeSystemDefined
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:78:26: note: 'NSSystemDefined' has been
      explicitly marked deprecated here
static const NSEventType NSSystemDefined        NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSEventTypeSystemDefined", 10.0, 10.12) = NSEventTypeSystemDefined;
                         ^
2 warnings generated.
[ 63%] Building C object src/lib/platform/CMakeFiles/platform.dir/OSXMediaKeySupport.m.o
/Users/tru/barrier/src/lib/platform/OSXMediaKeySupport.m:136:49: warning: 'NSSystemDefined' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
        NSEvent* downRef = [NSEvent otherEventWithType:NSSystemDefined
                                                       ^~~~~~~~~~~~~~~
                                                       NSEventTypeSystemDefined
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:78:26: note: 'NSSystemDefined' has been
      explicitly marked deprecated here
static const NSEventType NSSystemDefined        NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSEventTypeSystemDefined", 10.0, 10.12) = NSEventTypeSystemDefined;
                         ^
/Users/tru/barrier/src/lib/platform/OSXMediaKeySupport.m:143:47: warning: 'NSSystemDefined' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
        NSEvent* upRef = [NSEvent otherEventWithType:NSSystemDefined
                                                     ^~~~~~~~~~~~~~~
                                                     NSEventTypeSystemDefined
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:78:26: note: 'NSSystemDefined' has been
      explicitly marked deprecated here
static const NSEventType NSSystemDefined        NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSEventTypeSystemDefined", 10.0, 10.12) = NSEventTypeSystemDefined;
                         ^
2 warnings generated.
[ 63%] Building C object src/lib/platform/CMakeFiles/platform.dir/OSXPasteboardPeeker.m.o
/Users/tru/barrier/src/lib/platform/OSXPasteboardPeeker.m:24:21: warning: 'NSDragPboard' is deprecated: first deprecated in macOS 10.13 [-Wdeprecated-declarations]
        NSString* pbName = NSDragPboard;
                           ^~~~~~~~~~~~
                           NSPasteboardNameDrag
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSPasteboard.h:347:32: note: 'NSDragPboard' has been
      explicitly marked deprecated here
APPKIT_EXTERN NSPasteboardName NSDragPboard NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSPasteboardNameDrag", 10.0, 10.13);
                               ^
1 warning generated.

Commented on: 2018-02-20 by @walker0643

Unfortunately the previous two post of yours, tru, are highlighting known issues with the build. They both stem from needing to support more releases than just the latest OSX (currently 10.13). As it stands right now the source tree will create builds that are compatible with 10.9 through 10.13 even though the builds are rather noisy with respect to warnings.

Before we close this issue would you mind confirming that the program itself runs well on your OSX test box(es)? Thanks!

Commented on: 2018-02-23 by @walker0643

Got confirmation from tru via IRC. Closing.

Closed on: 2018-02-23 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#60

Issue created on: 2018-06-18 by @datgame
Issue last updated on: 2021-01-12

Operating Systems

Server: Windows 10, version 1703. OS Build 15063.1088

Client: Arch Linux 4.16.12-1-ARCH

Barrier Version

2.1.0-RELEASE-00000000

Steps to reproduce bug

1. move mouse from server (windows) to client (linux)
2. click things. mostly works for up to 5 seconds
3. clicks stop working

Other info

• When did the problem start to occur? right away when i installed and tried it out.
• Is there a way to work around it? yes. click apply on server barrier GUI, or do ctrl-alt-del ESC, and clicks are back working for another 5 seconds.
• Does this bug prevent you from using Barrier entirely? Yes

Put anything else you can think of here.
https://symless.com/forums/topic/3121-mouse-clicks-on-client-not-working/
synergy 1.8.8 had the same problem, but could be used for a few hours before this happened.
I've tried changing the "Elevate" option to both never and always, without effect.

Commented on: 2018-06-18 by @datgame

In response to myself, I found a workaround it seems.
I've been using https://stefansundin.github.io/altdrag/ on Windows, which is great, coming from Linux.
Disabling that fixes the problem of disappearing clicks.
Setting AltDrag to Elevate doesn't help.
So for people with similar problems, make sure you don't have global mouse affecting tweaks running.
Would be great if I could use both at the same time. But being able to click at all is a priority now.
And I can finally delete that pile of trash Synergy has become.

Commented on: 2018-06-30 by @walker0643

hi @datgame - yes, having multiple apps that do keyboard/mouse trickery running simultaneously can definitely cause a conflict. i'm glad you found the workaround. cheers!

closing because this is not a bug.

Commented on: 2018-12-23 by @exodist

Can we re-open this? I am having the same problem, using latest version client and server are both arch. I have not (intentionally?) installed anything that might grab or mess with mouse. Fresh arch installs on both client and server.

Commented on: 2018-12-23 by @exodist

More info: It looks like clicks are not the problem. My client seems to be under the impression that the windows-key (whatever you want to call it) is constantly pressed. In fact even if I move the mouse back to the server the client seems to be stuck in windows-pressed until I kill barrierc.

Commented on: 2018-12-23 by @exodist

correction. It keeps the windows-pressed status even after killing barrierc..... bizarre

Commented on: 2018-12-23 by @exodist

making a new issue, unrelated to this original one it seems

Commented on: 2019-03-07 by @mrwensveen

I also have this bug, or something like it. Usually not after 5 seconds, but after a minute or so of inactivity. Moving the mouse off screen and then on screen again makes clicks work again, until it stops working. The workaround is only slightly annoying so I can live with it. Nothing in particular shows up in the log.

Commented on: 2020-07-14 by @LaraArgento

I'm having the same issue.

Commented on: 2020-07-14 by @LaraArgento

I'm having the same issue.

I found out xD. Everytime i tried to open the current server settings (hitting win + barrier [enter]) I was opening a NEW instance of the software. Closing everything (aka restarting) solved the issue. It was Barrier conflicting with itself.

Commented on: 2021-01-12 by @PingHGao

I am having the same issue. Every time I close all barrier by restarting, click works for 5 seconds and I can not click any more. But switching between screen is alright.

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#8

Issue created on: 2018-02-23 by @walker0643
Issue last updated on: 2018-02-24

This one has been on my list to do since the beginning. Imagine my joy when I found it had already been done:

symless/synergy-core#6226

Meta: #7

Closed on: 2018-02-24 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#43

Issue created on: 2018-05-22 by @daankortenbach
Issue last updated on: 2018-09-08

I'm probably alone is this... but I have a 20"-30"-20" PLP Mac setup with a 22" PC on the right. The 30" is hooked up to a Mac/PC KVM so I can switch my main display to PC when I need it.

Config 1 (work mode): [Mac][Mac][Mac][PC]
Config 2 (play mode): [Mac][PC][Mac]

Currently in config 1 everything is fine and works as expected, but in config 2 the order of mouse movement from left to right is wrong: [1][3][2].

It would be supercool to manage monitors as individual displays instead of all monitors as one. Functionality to manage multiple display setup profiles would be needed, I guess.

Surely there's more important issues to be solved before edge cases from multi monitor nutcases like me get priority, but hey... Who knows?!

Thanks for forking and continuing where others crippled.

Commented on: 2018-06-14 by @Mfoor

Currently I use this program with a 3 monitor set up for both mac and pc, two of those monitors are shared( [PC][MAC/PC][MAC/PC] ). In order to shift between Mac and PC on the shared monitors I change their input. However this results in some weird unintuitive layouts. I move the mouse up to access PC and down for Mac. It ends up looking like this:

[ PC ] [ PC ] [PC]
[Mac] [Mac]

Only one os can be seen at a time on the screens that are shared. It would be nice to be able to have all screens (5 total) so I can create a config that leaves out the screens I'm not using while coding on mac.

Commented on: 2018-09-08 by @walker0643

Duplicate of #127

Closed on: 2018-09-08 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#41

Issue created on: 2018-05-21 by @clay53
Issue last updated on: 2021-06-04

Operating Systems

Server: Windows 10

Client: Raspbian Stretch

Barrier Version

2.1.0

Steps to reproduce bug

Try

Other info

• When did the problem start to occur? When I tried to install it
• Is there a way to work around it? No/Yes, you can if you know how to
• Does this bug prevent you from using Barrier entirely? Yes

Put anything else you can think of here.

I can't seem to figure out how to install this on Debian/Raspberry Pi/ARM Linux. Whenever I attempt to use the files is ./bin I get cannot execute binary file: Exec format error. Maybe I'm incompetent, but I just can't seem to get this to work. Whenever I try to search for it I get things about barriers instead of this.

Commented on: 2018-05-25 by @walker0643

Hi @clay53 - it sounds like you're attempting to run a Barrier build from another platform. When you installed it did you use a precompiled package for another Linux (non-ARM, perhaps?) or did you compile it natively yourself?

Commented on: 2018-05-26 by @clay53

I used the precompiled Linux package I was hoping it was universal (ARM & x86), but maybe not.

Commented on: 2018-05-26 by @clay53

If I do need to compile it myself, how would I did that?

Commented on: 2018-05-29 by @dayne

@clay53 the Raspberry Pi is an ARM based processor meaning it can't directly use binaries built for x86. You'll need to build it up.

Here are the instructions I think should work for you on latest Raspbian Stretch:

sudo apt update && sudo apt upgrade
sudo apt install git cmake make xorg-dev g++ libcurl4-openssl-dev \
                 libavahi-compat-libdnssd-dev libssl-dev libx11-dev \
                 libqt4-dev qtbase5-dev
git clone https://github.com/debauchee/barrier.git
cd barrier
cmake .
make

Somebody with wiki editing permissions might consider adding these steps to the wiki at: https://github.com/debauchee/barrier/wiki/Building-on-Linux

Commented on: 2018-05-29 by @dayne

To follow up - there might be more issues here. The build on the RPi did succeed and I was able to launch barrier, configure it, and exchange (trust) SSL certs. However it didn't actually work correctly.

• Barrier 2.1.0 on Windows as the server.
• Barrier from Git (master) as of today 773a008

Result when client (rpi) was connected was the mouse didn't move or have effect on either system. When client disconnected mouse control on windows box resumed working.

The only messages in the logs that appear relevant are on the client (RPi) side:

See the following details from the RPI DEBUG2 log:

[2018-05-29T12:14:29] DEBUG2: can't read property 530 on window 0x01200730
[2018-05-29T12:14:29] DEBUG2: can't read property 530 on window 0x01200731
[2018-05-29T12:14:29] DEBUG2: can't read property 530 on window 0x01200732
[2018-05-29T12:14:29] DEBUG2: can't read property 530 on window 0x01200733
[2018-05-29T12:14:29] DEBUG2: can't read property 530 on window 0x01200734
[2018-05-29T12:14:30] DEBUG2: reading secure socket
[2018-05-29T12:14:30] DEBUG2: reading secure socket
[2018-05-29T12:14:30] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:30] DEBUG2: msg from server: CALV
[2018-05-29T12:14:30] DEBUG2: writef(CALV)
[2018-05-29T12:14:30] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:30] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:30] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:30] DEBUG2: writef(CNOP)
[2018-05-29T12:14:30] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:30] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:30] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200742
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200743
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200744
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200745
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200746
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200747
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200748
[2018-05-29T12:14:31] DEBUG2: can't read property 530 on window 0x01200749
[2018-05-29T12:14:33] DEBUG2: reading secure socket
[2018-05-29T12:14:33] DEBUG2: reading secure socket
[2018-05-29T12:14:33] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:33] DEBUG2: msg from server: CALV
[2018-05-29T12:14:33] DEBUG2: writef(CALV)
[2018-05-29T12:14:33] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:33] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:33] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:33] DEBUG2: writef(CNOP)
[2018-05-29T12:14:33] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:33] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:33] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:36] DEBUG2: reading secure socket
[2018-05-29T12:14:36] DEBUG2: reading secure socket
[2018-05-29T12:14:36] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:36] DEBUG2: msg from server: CALV
[2018-05-29T12:14:36] DEBUG2: writef(CALV)
[2018-05-29T12:14:36] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:36] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:36] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:36] DEBUG2: writef(CNOP)
[2018-05-29T12:14:36] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:36] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:36] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:39] DEBUG2: reading secure socket
[2018-05-29T12:14:39] DEBUG2: reading secure socket
[2018-05-29T12:14:39] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:39] DEBUG2: msg from server: CALV
[2018-05-29T12:14:39] DEBUG2: writef(CALV)
[2018-05-29T12:14:39] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:39] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:39] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:39] DEBUG2: writef(CNOP)
[2018-05-29T12:14:39] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:39] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:39] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:42] DEBUG2: reading secure socket
[2018-05-29T12:14:42] DEBUG2: reading secure socket
[2018-05-29T12:14:42] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:42] DEBUG2: msg from server: CALV
[2018-05-29T12:14:42] DEBUG2: writef(CALV)
[2018-05-29T12:14:42] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:42] DEBUG2: writef(CNOP)
[2018-05-29T12:14:42] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:42] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:45] DEBUG2: reading secure socket
[2018-05-29T12:14:45] DEBUG2: reading secure socket
[2018-05-29T12:14:45] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:45] DEBUG2: msg from server: CALV
[2018-05-29T12:14:45] DEBUG2: writef(CALV)
[2018-05-29T12:14:45] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:45] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:45] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:45] DEBUG2: writef(CNOP)
[2018-05-29T12:14:45] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:45] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:45] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200764
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200765
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200766
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200767
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200768
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x01200769
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x0120076a
[2018-05-29T12:14:46] DEBUG2: can't read property 530 on window 0x0120076b
[2018-05-29T12:14:46] DEBUG: stopping process
[2018-05-29T12:14:46] INFO: stopping barrier desktop process
[2018-05-29T12:14:48] DEBUG2: reading secure socket
[2018-05-29T12:14:48] DEBUG2: reading secure socket
[2018-05-29T12:14:48] DEBUG2: want to read, error=2, attempt=1
[2018-05-29T12:14:48] DEBUG2: msg from server: CALV
[2018-05-29T12:14:48] DEBUG2: writef(CALV)
[2018-05-29T12:14:48] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:48] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:48] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:48] DEBUG2: writef(CNOP)
[2018-05-29T12:14:48] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:48] DEBUG2: writing secure socket:0x86f200
[2018-05-29T12:14:48] DEBUG2: wrote 4 bytes
[2018-05-29T12:14:48] DEBUG1: stopping client
[2018-05-29T12:14:48] INFO: leaving screen
[2018-05-29T12:14:48] DEBUG2: mapping state: 0
[2018-05-29T12:14:48] DEBUG: Closing socket: 00842770
[2018-05-29T12:14:48] DEBUG: adopting new buffer
[2018-05-29T12:14:48] DEBUG: discarding 5 event(s)
[2018-05-29T12:14:48] DEBUG: closed display
[2018-05-29T12:14:48] NOTE: stopped client
[2018-05-29T12:14:48] DEBUG1: caught cancel on thread 0x00000002
[2018-05-29T12:14:48] INFO: process exited normally

Commented on: 2018-06-04 by @dayne

The issue I saw after a build on a pi sounds like #42

Commented on: 2018-06-30 by @walker0643

Closing because the original issue is not a bug.

Commented on: 2021-06-03 by @gregpalaci

would be nice to have this debauchee/barrier#41 (comment)
and this debauchee/barrier#805 (comment)
in the docs unless i missed it?

Commented on: 2021-06-04 by @dayne

would be nice to have this #41 (comment)
and this #805 (comment)
in the docs unless i missed it?

The instructions are on the Building-on-Linux wiki page -- just broken up into different chunks. If you downloaded the package instead of cloning the git repo then you should be able to skip the git commands (haven't tested that though)

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#47

Issue created on: 2018-05-23 by @johnny-mac
Issue last updated on: 2018-06-30

Operating Systems

Artix Linux

Server: Artix & Void

Client: Artix & Devuan

Barrier Version

2.1.1

Steps to reproduce bug

"Don't take foreground window on Window servers"

I'm sorry if I misunderstand this but shouldn't this option stop barrier from making my game window become 'not the main window' when I move my mouse to the other screen? Its really annoying, I'd like to use this while gaming & watching videos but this messes my game up & sometimes my PS3 controller will stop working.... I take my mouse off my main PC to my secondary one & it makes it not the main window, the active window... but its not like I clicked on anything else on that window, I just moved my mouse to the other one... Apparently this works for some people but I can't seem to make it work for me.

Commented on: 2018-06-01 by @johnny-mac

The "Dead Corners" don't work either, I enabled dead corners for top left & top right corners but the corners most certainly are not dead, but that's not anywhere near as important as the original issue above, but maybe it has something to do with it?
When I disable clipboard sharing it appears clipboard sharing still works too.

Don't take foreground window on Windows servers... oh... Windows, like microsoft windows... is that what this means? :/ why isn't there an option like that for Linux? I don't want the window to become inactive when I put my mouse on the other screen, I want to keep my mouse & keyboard on the computer I use to play videos while I'm gaming on my main PC with a PS3 controller... Why isn't this possible? Surely I am not the only one to suggest such a thing?

Commented on: 2018-06-30 by @walker0643

Not quite, @johnny-mac. Your mouse never really leaves your primary screen in the technical sense... the same way a magician's fingers never leave his hands... part of the magic of Barrier is that it simulates a single mouse being connected to and communicating with multiple machines while only being physically connected to one of them.

TLDR: When your mouse is active on another screen it can't also be active inside your game window on the primary screen. Same with the keyboard.

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#36

Issue created on: 2018-05-09 by @AdrianKoshka
Issue last updated on: 2019-11-29

I've written some systemd user services for my own personal use, and know some people might appreciate having a unit provided by upstream. This is mostly just a note for myself, I'll create a PR later, if you'd be open to the idea.

Commented on: 2018-05-10 by @walker0643

Sure, Adrian. Would it be as simple as making a dist/archlinux dir to hold the template and then having cmake fill it in at config-time?

Commented on: 2018-09-08 by @walker0643

Closing since we dropped this back in May. Go ahead and submit the PR if you still want to.

Commented on: 2019-11-29 by @shymega

Reopening for the benefit of #508 and other users.

This issue has been migrated from old Barrier Github repository debauchee/barrier#37

Issue created on: 2018-05-14 by @AdrianKoshka
Issue last updated on: 2018-05-16

Build OS: SilverBlue (previously known as Fedora Atomic Workstation)
Build tool: flatpak run org.flatpak.Builder (the flatpak of flatpak-builder)

error:

/app/share/applications/barrier.desktop: error: value "2.1" for key "Version" in group "Desktop Entry" is not a known version
Error on file "/app/share/applications/barrier.desktop": Failed to validate the created desktop file
Error: module barrier: Child process exited with code 1
make: *** [Makefile:8: build] Error 1

.desktop file:

[Desktop Entry]
Type=Application
Version=2.1
Name=Barrier
Comment=Keyboard and mouse sharing solution
Exec=barrier
Icon=barrier
Terminal=false
Categories=Utility;
Keywords=keyboard;mouse;sharing;network;share;

X-Desktop-File-Install-Version=0.23

Commented on: 2018-05-15 by @walker0643

Oops that's my mistake. I set it to the product version, not the .desktop spec version. I think we can just take that line out, no?

Commented on: 2018-05-15 by @AdrianKoshka

I'd assume so? I don't edit .desktop files often.

Commented on: 2018-05-16 by @walker0643

fixed in 773a008

Commented on: 2018-05-16 by @AdrianKoshka

Will there be a 2.1.1 so I can test this ASAP?

Commented on: 2018-05-16 by @walker0643

Done

Closed on: 2018-05-16 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#30

Issue created on: 2018-04-21 by @AdrianKoshka
Issue last updated on: 2018-12-31

I was wondering if there'd be any interest in packaging barrier in flatpak format. Distros like Fedora Atomic Workstation encourage the use of flatpaks for GUI applications over traditionally packaged applications. I help maintain the Thunderbird flatpak so I'd be willing to help package barrier. Getting it up on flathub would also help.

Commented on: 2018-04-22 by @walker0643

hi @AdrianKoshka - of course we would have no objection to that. if you're offering to maintain the package then just let us know what you need from us to get started. cheers!

Commented on: 2018-04-22 by @AdrianKoshka

A list of dependencies that barrier needs to compile against would be a good start, and then how to build in on linux. I see there's an issue filed already for build instructions for linux (#28).

Commented on: 2018-04-22 by @AdrianKoshka

Seems avahi libraries aren't part of the KDE/FreeDesktop runtime, what version of avahi is barrier 2.0.0 built against?

Commented on: 2018-04-24 by @AdrianKoshka

If you want to keep up with the repo: https://github.com/AdrianKoshka/flathub/tree/com.gituhb.debauchee.barrier

I don't think I'll make the PR to flathub until I can at least get this thing to at least build.

Commented on: 2018-04-24 by @AdrianKoshka

Seems avahi libraries aren't part of the KDE/FreeDesktop runtime, what version of avahi is barrier 2.0.0 built against?

In what capacity does barrier make use of avahi? I ask because I realize if I have to compile avahi daemon and all, it would just be more efficient to (in my opinion):

- [x] Ask flatpak/xdg-portal to add Avahi protal (We just need to open the sandbox so it can be talked to over DBus)

• Only build dev libraries so barrier can at least build
• Go from there?

Commented on: 2018-04-24 by @walker0643

avahi is used to do auto configuration (auto-connect) between server and client on the LAN. I've been linking it against 0.7 on linux platforms.

as a quick rundown, barrier also needs the following to build: CMake, Python, GNU Make, GCC v4.9+, X11 headers and libs, Qt 5 (core, ui, widgets, network, qmake), libcurl, and openssl headers and libraries.

there is a clean_build.sh script in the base directory to automate the process a little. anything you need to tweak in the environment should go into a new script beside it called build_env.sh (make it +x). git won't track it nor overwrite it when you pull (it's a site config).

Commented on: 2018-04-24 by @AdrianKoshka

Thanks for the info.

Commented on: 2018-04-24 by @AdrianKoshka

Do you know anything about building avahi (or it's libraries rather)?

Commented on: 2018-04-25 by @walker0643

I've not built it yet; so far the target platforms have all had usable packages. Are you running into trouble?

Commented on: 2018-04-25 by @AdrianKoshka

Yeah...the build options are just poorly documented or just not documented at all. I've disabled quite a bit but can't get everything I need disabled (like the daemon component).

Commented on: 2018-04-26 by @AdrianKoshka

Thanks to @lathiat, I was able to get avahi to at least compile. Though still working out some stuff.

Commented on: 2018-04-26 by @AdrianKoshka

So If I remember correctly the default config file is ~/.barrier.config? right? I was wondering if instead you could use XDG_CONFIG_HOME. (so something like ~/.config/barrier/<files-within>)

Commented on: 2018-04-26 by @AdrianKoshka

Also use XDG_DATA_HOME to store the SSL certs?

Commented on: 2018-04-26 by @AdrianKoshka

http://docs.flatpak.org/en/latest/conventions.html#xdg-base-directories

Commented on: 2018-04-26 by @AdrianKoshka

Also, apparently the .desktop file's executable path is hardocded. An excerpt of a conversation I had with a flatpak dev on what's wrong with the .desktop file you supply with barrier:

TingPing: hardcoding /usr/bin is wrong any time you have a different prefix
TingPing: either A) Use just the binary name, no path. B) At configure time insert the correct prefix

Commented on: 2018-04-26 by @AdrianKoshka

Also, there seems to be something wrong the include check you have CMake do. As of now, I have to manually tell it where to look for the dns_sd.h header for avahi in the flatpak manifest. An excerpt from the manifest:

"build-options": {
    "cflags": "-O2 -g -I/app/include/avahi-compat-libdns_sd",
    "cxxflags": "-O2 -g -I/app/include/avahi-compat-libdns_sd",
    "env": {
      "V": "1"
    }
  },

the full manifest

Commented on: 2018-04-26 by @walker0643

setting BONJOUR_SDK_HOME in the environment should take care of the non-standard location of the avahi package. eg. if the header is /opt/bonjour/include/dns_sd.h and the lib is /opt/bonjour/lib/dnssd.lib then add "export BONJOUR_SDK_HOME=/opt/bonjour" to your build_env.sh file in the root of the source.

Commented on: 2018-04-26 by @walker0643

as far as the config file locations, can you create a new issue for that so it can be addressed separately?

Commented on: 2018-04-26 by @AdrianKoshka

Can do.

Commented on: 2018-04-26 by @AdrianKoshka

Issue #31 created.

Commented on: 2018-04-26 by @AdrianKoshka

then add "export BONJOUR_SDK_HOME=/opt/bonjour" to your build_env.sh file in the root of the source.

The build scripts are actually bypassed entirely when I build with flatpak, I think flatpak-build just knows magically how to run CMake and friends. Though, I can probably add BONJOUR_SDK_HOME in the build env section of the manifest.

Commented on: 2018-04-26 by @AdrianKoshka

"build-options": {
        "env": {
          "BARRIER_REVISION": "2.0.0",
	      "BONJOUR_SDK_HOME": "/app/include"
        }
      },

Putting it in the barrier module section of the build manifest doesn't work.

Commented on: 2018-04-26 by @AdrianKoshka

Setting it in the higher-level section of the build-manifest via:

  "build-options": {
    "cflags": "-O2 -g",
    "cxxflags": "-O2 -g",
    "env": {
      "V": "1",
      "BONJOUR_SDK_HOME": "/app/include"

doesn't work either...

Commented on: 2018-04-26 by @AdrianKoshka

The contents of app/include btw:

total 0
drwxrwxr-x. 2 alc alc  55 Apr 26 18:49 avahi-client
drwxrwxr-x. 2 alc alc 260 Apr 26 18:49 avahi-common
drwxrwxr-x. 2 alc alc  22 Apr 26 18:49 avahi-compat-libdns_sd
drwxrwxr-x. 2 alc alc  78 Apr 26 18:49 avahi-core

Commented on: 2018-04-27 by @AdrianKoshka

This appears to be a CMake issue (or rather, an issue with your build files)?

because:

1. The env variable works just fine in a shell module
2. I was told so by somebody helping me in #flatpak

AdrianCeleste TingPing: I got /app/include from my shell module
TingPing then its just a cmake problem
AdrianCeleste So do I need to go back to using the -I option in the build-options section?
TingPing it should be fixed in the build files
AdrianCeleste Ah, so I need to tell upstream?
TingPing yes, they clearly knew it was a problem since they had freebsd workarounds, they expect everythign to be in /usr
AdrianCeleste :T Ah, right...

Commented on: 2018-04-27 by @walker0643

oops that was my bad... BONJOUR_SDK_HOME only works on windows. sorry 😛

yes, if cmake isn't finding your bonjour libs then just add your include and link options as you were doing. it's certainly cleaner to find out why cmake isn't finding bonjour and fix that instead, but for now just getting through the build might be enough.

btw, might it have something to do with the fact that bonjour is under /app ?? i'm not familiar with flatpak but /app seems like a very non-standard location. is everything used by the build process under /app or just bonjour?

Commented on: 2018-04-27 by @AdrianKoshka

Everything, kinda, I can get you a link of flatpak file-structure if you want. While I would rather not do that include thing, but if it makes it work for now and will actually get solved later, I'll do it. I haven't even gotten around to see if barrier launches/work yet, but will probably later today.

here's that link.

Commented on: 2018-04-27 by @AdrianKoshka

I actually probably won't test that it works until #31 is solved, I don't feel like opening the sandbox.

Commented on: 2018-04-28 by @AdrianKoshka

I lied, and I can confirm it at least launches. Oh, question, does Barrier need DRI access? I ask because I see this:

alc@am1m-s2h ~/git/github/flathub/flathub (git)-[com.gituhb.debauchee.barrier] % flatpak run com.github.debauchee.barrier
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu
libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: radeonsi

Commented on: 2018-04-28 by @AdrianKoshka

Commented on: 2018-04-28 by @AdrianKoshka

I added --device=dri (enables OpenGL rendering) to the finish-args section of the manifest, and it no-longer complains about the DRI stuff.

Commented on: 2018-04-28 by @AdrianKoshka

Did a single test, and the keyboard/mouse sharing worked, as well as copy/paste:

• Host: Fedora 27, flatpak'd barrier (running without SSL [The screenshot above is from before I started testing]) 2.0.0
• Client: Debian 9 stretch, ~/.local/bin/barrierc --no-daemon <server-ip> 2.0.0

I might do a test with SSL later.

Commented on: 2018-04-28 by @walker0643

That's good news, Adrian. Cheers for sticking with it. Barrier itself doesn't explicitly access the dri device, though Qt5 might use it if it's available.

On a side note, all the cool kids use i3 😄

Commented on: 2018-04-28 by @AdrianKoshka

I guess what needs to be done now is:

• Write an appstream file
• take care of #31
• Some more testing
• PR to flathub?

Commented on: 2018-04-29 by @AdrianKoshka

Here's a rough-draft of the appstream metadta

Commented on: 2018-04-29 by @AdrianKoshka

I built barrier as a 32-bit flatpak, and it runs! (flathub prefers if something can build for i386, x86_64, arm, and aarch64. I'd test arm/aarch64 but I don't feel like spinning up VMs.) If you're wondering how I did it, I simply did:

make BUILDER_OPTIONS="--arch=i386" which passes that argument to flatpak-builder via a variable.

Commented on: 2018-04-29 by @AdrianKoshka

Here's the 32-bit flatpak'd barrier running on 32-bit flatpak on my netbook (64-bit kernel, mostly 32-bit userland, Debian 9 stretch [x86 raspbian spin]):

Commented on: 2018-05-22 by @AdrianKoshka

Apologies for the radio silence, I was on a vacation for the past two weeks, and went to VCF-E (Vintage Computer Festival East) this past weekend.

Commented on: 2018-05-22 by @AdrianKoshka

Thanks for b43581c, I was able to remove a section from my manifest.

Commented on: 2018-05-23 by @johnny-mac

So this is in active development on flatpak? that's awesome! But your link up there didn't work, page not found.. You gonna be adding it to flathub any time soon?
I run Void Linux (GLIBC & MUSL) but can't get Barrier to build, would really love to be able to use a flatpak app for it.

Commented on: 2018-05-23 by @AdrianKoshka

I'm going to PR to flathub when I feel it's ready. I already have one WIP PR to flathub (for virt-viewer/remote-viewer) so I don't have two WIP PR's.

If you want my repo so you can build from source: https://github.com/AdrianKoshka/flathub/tree/com.github.debauchee.barrier

Commented on: 2018-05-23 by @AdrianKoshka

So far, the easiest way to build the flatpak is:

$ flatpak --user install flathub org.flatpak.Builder
$ git clone https://github.com/AdrianKoshka/flathub.git -b com.github.debauchee.barrier
$ cd flathub
$ make FLATPAK_BUILDER="flatpak run org.flatpak.Builder

Then to install locally:

$ flatpak --user remote-add --no-gpg-verify lbr /full/path/to/repo/
$ flatpak --user install lbr com.github.debauchee.barrier

Commented on: 2018-06-30 by @AdrianKoshka

Why was this closed? Inactivity, I've been waiting on a PR you pulled into a different branch to be pulled into master. #48 specifically.

Commented on: 2018-07-03 by @AdrianKoshka

Now that the pkg-config fixe was merged (#86), I can say that I no longer have to use the hack to point the compiler to the avahi libraries.

Commented on: 2018-07-03 by @AdrianKoshka

This means I can finally start moving forward again, probably start working on the appstream data.

Commented on: 2018-07-03 by @AdrianKoshka

How do you properly pass the version of barrier to the buildsystem? I have:

{
            "name" : "barrier",
            "buildsystem" : "cmake-ninja",
            "build-options" : {
                "env" : {
                    "BARRIER_REVISION" : "2.1.2"
                }
            },
            "sources" : [
                {
                    "type" : "git",
                    "url" : "git://github.com/debauchee/barrier.git",
                    "tag" : "v2.1.2",
                    "commit" : "cc69299ea39bd39caad54ae349564e22593eb4df"
                }

Though when I run --version, I get:

alc@am1m-s2h ~ % flatpak run --command=barrierc com.github.debauchee.barrier --version
barrierc 2.1.0-snapshot
Protocol version 1.6
Copyright (C) 2018 Debauchee Open Source Group
Copyright (C) 2012-2016 Symless Ltd.
Copyright (C) 2008-2014 Nick Bolton
Copyright (C) 2002-2014 Chris Schoeneman

Commented on: 2018-09-08 by @walker0643

The top of cmake/Version.cmake has the constants that cmake uses to fill in the placeholder variables like @BARRIER_VERSION@ in the .in files. Is that what you were asking??

Commented on: 2018-12-31 by @ugtar

is avahi required? i personally don't have the avahi daemon running because i don't need to auto-discover anything. With avahi not running, barrier can't auto-configure, but it works fine if I manually enter the barrier server IP. Seems like avahi could be an optional dependency that just disables the auto-discovery option at build time.

Commented on: 2018-12-31 by @AdrianKoshka

I'm not going to take avahi out just because one user doesn't use it. Also I should've closed this issue a while ago.

Commented on: 2018-12-31 by @AdrianKoshka

@ugtar If your intention is to make avahi an optional build component (which it seems to be, partially), then open another issue instead of piggy-backing off of this one.

Closed on: 2018-12-31 by @AdrianKoshka

This issue has been migrated from old Barrier Github repository debauchee/barrier#49

Issue created on: 2018-05-26 by @kenny-w1
Issue last updated on: 2018-06-30

Operating Systems

Server: Artix

Client: Artix & Devuan

Barrier Version

snapshot, latest

Steps to reproduce bug

Try to build barrier on arch-based distro with newest cmake from pacman package manager

qt5_use_modules is apparently deprecated but its back now? I don't know how to make this build now...

-- Full Barrier version string is '2.1.0-snapshot-snapshot.b1-773a0081'
-- Configuring directory /home/user/Compiles/Barrier-fresh/src/barrier/build/rpm
-- Configuring file barrier.spec
CMake Error at src/gui/CMakeLists.txt:25 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".

I'm having a hard time trying to figure out how to make this build now... :(
QT_SELECT=5 / QT_SELECT=4 doesn't seem to have any effect...

Commented on: 2018-05-26 by @kenny-w1

I think the problem is in the source-code of Barrier but maybe I'm wrong, I don't really know...
This is really confusing :/ I can't find any answers to this anywhere.... ugh...

Commented on: 2018-05-29 by @xantoz

Do the changes in the following patch resolve it: https://gitweb.gentoo.org/repo/gentoo.git/plain/x11-misc/synergy/files/synergy-1.9.1-qt-5.11.patch?id=5dd1f7a3908dec9ae6cf6773acd8ec3b33fc0b2c

You will need to change synergy to barrier in a few places to make it apply. Alternatively, it might just be easier to apply the changes by hand.

Commented on: 2018-05-29 by @Tblue

@xantoz, thanks -- the patch fixes the issue.

As a hotfix, I included the patch in the Arch Linux AUR package, see 0001-Handle-removal-of-cmake-macro-qt5_use_modules.patch. Of course, credit for the patch goes to whoever created it for Gentoo. :-)

Commented on: 2018-06-07 by @johnny-mac

Hey Tblue how do you make it skip the integrity check for the .patch file? It keeps wanting to do an integ check only when I include the .patch file, but even when I add
md5sums=('SKIP')
sha256sums=('SKIP')
sha512sums=('SKIP')
it won't validate the integrity, even when I add the md5sums for the .patch file it still tells me:

-> Found 0001-Handle-removal-of-cmake-macro-qt5_use_modules.patch
==> ERROR: Integrity checks (md5) differ in size from the source array.

Commented on: 2018-06-10 by @Tblue

@johnny-mac, as the error message suggests, each file in the source array needs to have a corresponding checksum (or the keyword SKIP) in the checksum arrays (md5sums etc.).

Try makepkg -g >> PKGBUILD to have the checksums generated automatically. You could also use my Arch Linux AUR package as a base for your own modifications. :-)

Commented on: 2018-06-30 by @walker0643

Confirmation on fix and 3 weeks since activity. Closing for now but please reopen if I'm mistaken.

Commented on: 2018-06-30 by @walker0643

I went ahead and added the patch. Seemed like a good idea ...

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#46

Issue created on: 2018-05-23 by @johnny-mac
Issue last updated on: 2018-06-30

Sorry I don't know where the template went but this field is completely blank, I saw it for a second but it went away. I'll fill it out if I have to, sorry.

Trying to get Barrier to build on Void Linux (GLIBC) but can't seem to do so, it tells me:

CMake Error at CMakeLists.txt:191 (message):
Missing header: dns_sd.h

I've installed c-ares c-ares-devel nss-mdns mDNSResponder and any other dependencies I could find... but still get this error.

Commented on: 2018-05-23 by @johnny-mac

configure_args="--disable-qt3 --disable-qt4 --disable-mono --disable-monodoc
--disable-doxygen-doc --enable-compat-libdns_sd --enable-compat-howl
--with-xml=expat --with-avahi-user=avahi --with-avahi-group=avahi
--with-avahi-priv-access-group=network --with-autoipd-user=avahi
--with-autoipd-group=avahi --with-distro=none --disable-xmltoman
--disable-static ssp_cv_lib=no --enable-python --disable-pygtk
--disable-glib --disable-python-dbus --disable-gobject --disable-gtk
--disable-gtk3 --disable-dbm --disable-introspection --sbindir=/usr/bin
--disable-pygobject"

dns_sd is enabled, why isn't it working? I even custom-compiled AVAHI through the Void Linux template yet I still get this funny error...

libdns_sd.so
libdns_sd.so.1
libdns_sd.so.1.0.0

These all exist in Void Linux... Perhaps there's some sort of symlink that needs to be made? I dont know..
Is avahi being compiled the wrong way for barrier/synergy to work? Most versions of synergy fail to compile but don't notify me of missing headers in cmake, the build in synergy usually fails while running make & outputs errors about dns_sd.h but in barrier it warns me in cmake.

the dns-sd command appears to work... I guess I'll try to enable glib, introspection & gobject, just to see if that changes anything or not, its just a guess though, if anyone knows what would make this work I would be very pleased to know, thanks.
appears not to work with glib introspection & gobject enabled, IDK what else I can try.

Commented on: 2018-05-25 by @Johnnynator

The problem is that VoidLinux does provide dns_sd.h like FreeBSD in the avahi-compat-libdns_sd subdirectory. Adding /usr/include/avahi-compat-libdns_sd to the include_directories should help.

Commented on: 2018-05-25 by @Johnnynator

I created a template for Void. https://github.com/voidlinux/void-packages/pull/14707

Commented on: 2018-05-26 by @Johnnynator

So, barrier is now in the void linux repository.

Commented on: 2018-05-30 by @johnny-mac

WOW! Where did you come from Johnnynator? From heaven?! lol
thank you, this template will make everything much easier. Any idea how long it'll take before it reaches XBPS package manager? I'll probably just build it from template but I'm curious
I made a post on your github void-packages repo about a package I'd like to get packaged, hope you don't mind my asking, you don't have to! I'm only asking!

Commented on: 2018-05-30 by @Johnnynator

It is afaik already iinstallable with xbps-install -S barrier or xbps-install -S barrier-gui.

Commented on: 2018-06-30 by @walker0643

Looks resolved to me. Reopen if not.

Closed on: 2018-06-30 by @walker0643

This issue has been migrated from old Barrier Github repository debauchee/barrier#4

Issue created on: 2018-01-29 by @walker0643
Issue last updated on: 2018-01-29

barriers.exe on windows will not completely handle events such as a client connecting or ctrl+c. with --debug up high enough you might see that it knows that something happened but it will not follow through on dealing with it.

to reproduce:

1. start barriers.exe from cmd so you have keyboard input (get nice command line from GUI log pane) and set --debug to at least INFO
2. once it's idling, hit ctrl+c

notice that it acknowledges the command with the following line:

• INFO: got shutdown signal

but it does not react to it otherwise by shutting down.

Closed on: 2018-01-29 by @walker0643