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.

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$ 

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.

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.

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)

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

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.

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.

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#6178

Meta: #7

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

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.

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.

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

symless#6226

Meta: #7

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

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#5201

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.

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#6222

Meta: #7

Operating Systems

Server: Ubuntu 18.04

Client: Windows 10

altgr modifier do not work on client side

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

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#6174

Meta: #7

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.

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

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.

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"

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 (:

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
```

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

Meta: #7

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?

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?

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

symless#5245

Meta: #7

Comments? Can anyone confirm?

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

Synergy PR: symless#4

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

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...

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?

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

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.

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

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...

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@c3530a0
symless@23464a3

Meta: #7

symless#6182

Meta: #7

requires to build on alpinelinux

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.

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.

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.

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.

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

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

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.

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

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!

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

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