[GH-ISSUE #30] Flatpak package

gitea-mirror commented

2026-05-05 04:44:35 -06:00

Owner

Originally created by @AdrianKoshka on GitHub (Apr 21, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/30

Originally assigned to: @AdrianKoshka on GitHub.

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.

Originally created by @AdrianKoshka on GitHub (Apr 21, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/30 Originally assigned to: @AdrianKoshka on GitHub. I was wondering if there'd be any interest in packaging barrier in flatpak format. Distros like [Fedora Atomic Workstation](https://www.projectatomic.io/blog/2018/02/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.

gitea-mirror

2026-05-05 04:44:35 -06:00

closed this issue
added the
build-infra

linux

installer/package
labels

gitea-mirror commented

2026-05-05 04:44:44 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 22, 2018):

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!

@walker0643 commented on GitHub (Apr 22, 2018): 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!

gitea-mirror commented

2026-05-05 04:44:47 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 22, 2018):

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

@AdrianKoshka commented on GitHub (Apr 22, 2018): 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).

gitea-mirror commented

2026-05-05 04:44:50 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 22, 2018):

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

@AdrianKoshka commented on GitHub (Apr 22, 2018): Seems avahi libraries aren't part of the KDE/FreeDesktop runtime, what version of avahi is barrier 2.0.0 built against?

gitea-mirror commented

2026-05-05 04:44:54 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 24, 2018):

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.

@AdrianKoshka commented on GitHub (Apr 24, 2018): 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.

gitea-mirror commented

2026-05-05 04:44:56 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 24, 2018):

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?

@AdrianKoshka commented on GitHub (Apr 24, 2018): > 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?

gitea-mirror commented

2026-05-05 04:44:59 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 24, 2018):

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

@walker0643 commented on GitHub (Apr 24, 2018): 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).

gitea-mirror commented

2026-05-05 04:45:02 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 24, 2018):

Thanks for the info.

@AdrianKoshka commented on GitHub (Apr 24, 2018): Thanks for the info.

gitea-mirror commented

2026-05-05 04:45:06 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 24, 2018):

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

@AdrianKoshka commented on GitHub (Apr 24, 2018): Do you know anything about building avahi (or it's libraries rather)?

gitea-mirror commented

2026-05-05 04:45:09 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 25, 2018):

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

@walker0643 commented on GitHub (Apr 25, 2018): I've not built it yet; so far the target platforms have all had usable packages. Are you running into trouble?

gitea-mirror commented

2026-05-05 04:45:13 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 25, 2018):

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

@AdrianKoshka commented on GitHub (Apr 25, 2018): 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).

gitea-mirror commented

2026-05-05 04:45:16 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): Thanks to @lathiat, I was able to get avahi to at least compile. Though still working out some stuff.

gitea-mirror commented

2026-05-05 04:45:19 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): 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>`)

gitea-mirror commented

2026-05-05 04:45:21 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

Also use XDG_DATA_HOME to store the SSL certs?

@AdrianKoshka commented on GitHub (Apr 26, 2018): Also use `XDG_DATA_HOME` to store the SSL certs?

gitea-mirror commented

2026-05-05 04:45:25 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): http://docs.flatpak.org/en/latest/conventions.html#xdg-base-directories

gitea-mirror commented

2026-05-05 04:45:27 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): 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 ```

gitea-mirror commented

2026-05-05 04:45:28 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): 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: ```json "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](https://github.com/AdrianKoshka/flathub/blob/com.gituhb.debauchee.barrier/com.github.debauchee.barrier.json)

gitea-mirror commented

2026-05-05 04:45:30 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 26, 2018):

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.

@walker0643 commented on GitHub (Apr 26, 2018): 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.

gitea-mirror commented

2026-05-05 04:45:33 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 26, 2018):

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

@walker0643 commented on GitHub (Apr 26, 2018): as far as the config file locations, can you create a new issue for that so it can be addressed separately?

gitea-mirror commented

2026-05-05 04:45:35 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

Can do.

@AdrianKoshka commented on GitHub (Apr 26, 2018): Can do.

gitea-mirror commented

2026-05-05 04:45:39 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

Issue #31 created.

@AdrianKoshka commented on GitHub (Apr 26, 2018): Issue #31 created.

gitea-mirror commented

2026-05-05 04:45:42 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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.

@AdrianKoshka commented on GitHub (Apr 26, 2018): > 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.

gitea-mirror commented

2026-05-05 04:45:46 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): ```json "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.

gitea-mirror commented

2026-05-05 04:45:51 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): Setting it in the higher-level section of the build-manifest via: ```json "build-options": { "cflags": "-O2 -g", "cxxflags": "-O2 -g", "env": { "V": "1", "BONJOUR_SDK_HOME": "/app/include" ``` doesn't work either...

gitea-mirror commented

2026-05-05 04:45:54 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 26, 2018):

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

@AdrianKoshka commented on GitHub (Apr 26, 2018): 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 ```

gitea-mirror commented

2026-05-05 04:45:59 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 27, 2018):

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

because:

The env variable works just fine in a shell module
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...

@AdrianKoshka commented on GitHub (Apr 27, 2018): 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... ```

gitea-mirror commented

2026-05-05 04:46:01 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 27, 2018):

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?

@walker0643 commented on GitHub (Apr 27, 2018): oops that was my bad... BONJOUR_SDK_HOME only works on windows. sorry :stuck_out_tongue: 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?

gitea-mirror commented

2026-05-05 04:46:03 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 27, 2018):

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.

@AdrianKoshka commented on GitHub (Apr 27, 2018): 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](http://docs.flatpak.org/en/latest/conventions.html#filesystem-layout).

gitea-mirror commented

2026-05-05 04:46:06 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 27, 2018):

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

@AdrianKoshka commented on GitHub (Apr 27, 2018): I actually probably won't test that it works until #31 is solved, I don't feel like opening the sandbox.

gitea-mirror commented

2026-05-05 04:46:07 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

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

@AdrianKoshka commented on GitHub (Apr 28, 2018): 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 ```

gitea-mirror commented

2026-05-05 04:46:09 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

@AdrianKoshka commented on GitHub (Apr 28, 2018): ![picture of barrier running via flatpak run](https://imgur.com/4yno90B.png)

gitea-mirror commented

2026-05-05 04:46:11 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

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

@AdrianKoshka commented on GitHub (Apr 28, 2018): I added `--device=dri` (enables OpenGL rendering) to the `finish-args` section of the manifest, and it no-longer complains about the DRI stuff.

gitea-mirror commented

2026-05-05 04:46:14 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

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.

@AdrianKoshka commented on GitHub (Apr 28, 2018): 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.

gitea-mirror commented

2026-05-05 04:46:16 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 28, 2018):

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 😄

@walker0643 commented on GitHub (Apr 28, 2018): 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 :smile:

gitea-mirror commented

2026-05-05 04:46:19 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

I guess what needs to be done now is:

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

@AdrianKoshka commented on GitHub (Apr 28, 2018): I guess what needs to be done now is: - [ ] Write an appstream file - [X] take care of #31 - [ ] Some more testing - [ ] PR to flathub?

gitea-mirror commented

2026-05-05 04:46:20 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 29, 2018):

Here's a rough-draft of the appstream metadta

@AdrianKoshka commented on GitHub (Apr 29, 2018): [Here's a rough-draft of the appstream metadta](https://github.com/AdrianKoshka/flathub/blob/com.github.debauchee.barrier/com.github.debauchee.barrier.appdata.xml)

gitea-mirror commented

2026-05-05 04:46:23 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 29, 2018):

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.

@AdrianKoshka commented on GitHub (Apr 29, 2018): 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. ![32-bit barrier flatpak running](https://imgur.com/c0NWQVu.png)

gitea-mirror commented

2026-05-05 04:46:25 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 29, 2018):

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]):

@AdrianKoshka commented on GitHub (Apr 29, 2018): 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]): ![32-bit flatpak netbook](https://imgur.com/wWajhsM.png)

gitea-mirror commented

2026-05-05 04:46:31 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 22, 2018):

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.

@AdrianKoshka commented on GitHub (May 22, 2018): 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.

gitea-mirror commented

2026-05-05 04:46:34 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 22, 2018):

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

@AdrianKoshka commented on GitHub (May 22, 2018): Thanks for b43581c2f54ebb38eefe635352a8ae4ac980407e, I was able to [remove a section from my manifest](https://github.com/AdrianKoshka/flathub/commit/e74fd81b9cc27a31d3e067077e6766e8253316a7).

gitea-mirror commented

2026-05-05 04:46:35 -06:00

Author

Owner

@johnny-mac commented on GitHub (May 23, 2018):

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.

@johnny-mac commented on GitHub (May 23, 2018): 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.

gitea-mirror commented

2026-05-05 04:46:38 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 23, 2018):

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

@AdrianKoshka commented on GitHub (May 23, 2018): 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

gitea-mirror commented

2026-05-05 04:46:41 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 23, 2018):

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

@AdrianKoshka commented on GitHub (May 23, 2018): So far, the easiest way to build the flatpak is: ```shell $ 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: ```shell $ flatpak --user remote-add --no-gpg-verify lbr /full/path/to/repo/ $ flatpak --user install lbr com.github.debauchee.barrier ```

gitea-mirror commented

2026-05-05 04:46:44 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jun 30, 2018):

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.

@AdrianKoshka commented on GitHub (Jun 30, 2018): 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.

gitea-mirror commented

2026-05-05 04:46:48 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 3, 2018):

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.

@AdrianKoshka commented on GitHub (Jul 3, 2018): 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.

gitea-mirror commented

2026-05-05 04:46:53 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 3, 2018):

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

@AdrianKoshka commented on GitHub (Jul 3, 2018): This means I can finally start moving forward again, probably start working on the appstream data.

gitea-mirror commented

2026-05-05 04:46:57 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 3, 2018):

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

@AdrianKoshka commented on GitHub (Jul 3, 2018): How do you properly pass the version of barrier to the buildsystem? I have: ```json { "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 ```

gitea-mirror commented

2026-05-05 04:47:02 -06:00

Author

Owner

@walker0643 commented on GitHub (Sep 8, 2018):

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

@walker0643 commented on GitHub (Sep 8, 2018): 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??

gitea-mirror commented

2026-05-05 04:47:04 -06:00

Author

Owner

@ugtar commented on GitHub (Dec 31, 2018):

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.

@ugtar commented on GitHub (Dec 31, 2018): 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.

gitea-mirror commented

2026-05-05 04:47:07 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 31, 2018):

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.

@AdrianKoshka commented on GitHub (Dec 31, 2018): 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.

gitea-mirror commented

2026-05-05 04:47:08 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 31, 2018):

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

@AdrianKoshka commented on GitHub (Dec 31, 2018): @ugtar If your intention is to make avahi an optional build component (which it [seems to be, partially](https://github.com/debauchee/barrier/blob/master/CMakeLists.txt#L199-L201)), then open another issue instead of piggy-backing off of this one.

Rows
Columns

[GH-ISSUE #30] Flatpak package #21