Barrier: RHEL/CentOS 8 (and perhaps Fedora) RPM builds

[alexpdp7]

Operating Systems

Server: macOS Catalina

Client: RHEL 8

Barrier Version

2.3.2

Other info

This is not a bug. I have created a hackish repo that builds RHEL 8 Barrier packages:

https://github.com/alexpdp7/barrier-rpm

Would you be interested in some sort of cooperation? There is a wide spectrum of possibilities:

• I can help incorporate the RPM build into your CI. This way you could provide RPMs in your releases
• The same, but instead of putting releases in GitHub, I have some experience doing CI builds which push to Fedora COPR (it's like PPAs), so users could add the COPR as a package repo and get automated updates, etc.

It's likely that you are not interested in this; alternatively, I can work in a COPR and perhaps you could link it so users can easily find it?

Also my build has some issues:

• I need to sed the generated .spec file because it 2.3.2-snapshot apparently is not a correct RPM version
• Generated build doesn't have SSL interop (at least with macOS)
• It's ugly and terrible, because I have no clue about stuff

[shymega]

I think this would be a good idea. I would need to discuss integrating RPM builds into the CI, but I don't think its likely we would be able/willing to give you access to the actual UI for the CI, but you're more than welcome to make adjustments to /azure-pipelines.yml in the repo root.

I think for now though, maybe fix the current issues, and deploy to COPR. I have a bit of experience with writing RPM packages, not much, but I can take a look if you like. Maybe CC me in your bug tracker for anything that needs attention? Cheers.

[alexpdp7]

but I don't think its likely we would be able/willing to give you access to the actual UI for the CI

Yeah, that's the correct approach. I assume if I fork the repo I'll be able to run the Azure pipeline myself, so that will be fine.

(I just preferred to not fork and use my own separate repo because it seemed more "conservative" to me).

When I have some time, I'll fork your repo, adapt its existing pipeline to create a COPR package and send a PR.

If you later change your mind, that's OK :)

You might close this ticket if you want. I think it's nice for users to be able to find my repo, because it might be useful for them, but OTOH, having too many issues open is annoying.

[alexpdp7]

WIP:

https://github.com/alexpdp7/barrier/commit/1554ddaf5feb7a77f2c36483e6625da60ef8b8dc

Azure Pipeline is giving me odd errors, but it should work. Will try again tomorrow...

[alexpdp7]

Success! :) I had to use Ubuntu 18.04 instead of 16.04, but:

https://github.com/debauchee/barrier/commit/dbdabbf06c45f56c60c36fa933cb807c7f310909

now can build an RPM successfully and push it to COPR. SSL is working now (maybe I had PEBCAK earlier...). Package is at:

https://copr.fedorainfracloud.org/coprs/koalillo/barrier/

and can be installed by:

$ dnf copr enable koalillo/barrier
$ dnf install barrier

The Azure build can be seen at:

https://dev.azure.com/testaex/barrier/_build/results?buildId=10&view=logs&j=b1718ffc-ce3b-5616-8029-c04c1e3f7b23&t=b1718ffc-ce3b-5616-8029-c04c1e3f7b23

Remaining uglyness:

• Leaving blank the bind address does not work, you need to specify the bind address
• Build patches out -snapshot in the version name
• Build might be considered ugly; builds an SRPM in Azure using Docker, then pushes to COPR where the RPM is built from the SRPM. I think this is good (anyone can run the Azure build using Docker, you don't need a CentOS 8 system; also the COPR can be verified, I guess)

I'm not sure how this can be integrated into your release process, though.

(BTW, I think it might be "easy" to adapt this to make this build Fedora and older CentOS releases packages. COPR also supports Mageia and OpenSUSE, but I suspect that might be more difficult.

[aljazzair]

Hello
Thank you for taking this initiative.
Would it be possible to have updated builds on this repository?
The one currently posted has a bug that crashes the server when a client is disconnected.
It seems to have been resolved in later commits.

[alexpdp7]

Hi,

I've rebased my ugly patch over the 2.3.3 tag and now... it's even uglier.

I've managed to build an RPM but I get:

Package barrier-2.3.2-1.el8.x86_64 is already installed.
Error: 
 Problem: cannot install the best candidate for the job
  - nothing provides libQt5Core.so.5(Qt_5.12)(64bit) needed by barrier-2.3.3-1.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

I'm not sure what's the best way to hack this.

You can find the package on COPR. Source is at https://github.com/alexpdp7/barrier

[alexpdp7]

Scratch that, this is an issue because my test version is stuck on an odd version of RHEL 8.0. @aljazzair I would give it a try to the latest 2.3.3 package in the COPR repo.

[alexpdp7]

I just noticed EPEL now includes Barrier, which is good enough for me, so you can close this ticket.