github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #668] RHEL/CentOS 8 (and perhaps Fedora) RPM builds #527

New issue

Closed

opened 2026-05-05 06:36:09 -06:00 by gitea-mirror · 8 comments

gitea-mirror commented

2026-05-05 06:36:09 -06:00

Owner

Originally created by @alexpdp7 on GitHub (May 12, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/668

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

Originally created by @alexpdp7 on GitHub (May 12, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/668 ### 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

gitea-mirror

2026-05-05 06:36:09 -06:00

closed this issue
added the
build-infra
label

gitea-mirror commented

2026-05-05 06:36:14 -06:00

Author

Owner

@shymega commented on GitHub (May 12, 2020):

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.

@shymega commented on GitHub (May 12, 2020): 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.

gitea-mirror commented

2026-05-05 06:36:18 -06:00

Author

Owner

@alexpdp7 commented on GitHub (May 14, 2020):

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 commented on GitHub (May 14, 2020): > 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.

gitea-mirror commented

2026-05-05 06:36:20 -06:00

Author

Owner

@alexpdp7 commented on GitHub (May 14, 2020):

WIP:

1554ddaf5f

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

@alexpdp7 commented on GitHub (May 14, 2020): WIP: https://github.com/alexpdp7/barrier/commit/1554ddaf5feb7a77f2c36483e6625da60ef8b8dc Azure Pipeline is giving me odd errors, but it should work. Will try again tomorrow...

gitea-mirror commented

2026-05-05 06:36:23 -06:00

Author

Owner

@alexpdp7 commented on GitHub (May 15, 2020):

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

dbdabbf06c

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.

@alexpdp7 commented on GitHub (May 15, 2020): 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.

gitea-mirror commented

2026-05-05 06:36:26 -06:00

Author

Owner

@aljazzair commented on GitHub (Sep 18, 2020):

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.

@aljazzair commented on GitHub (Sep 18, 2020): 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.

gitea-mirror commented

2026-05-05 06:36:30 -06:00

Author

Owner

@alexpdp7 commented on GitHub (Sep 18, 2020):

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 commented on GitHub (Sep 18, 2020): 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

gitea-mirror commented

2026-05-05 06:36:32 -06:00

Author

Owner

@alexpdp7 commented on GitHub (Sep 18, 2020):

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 commented on GitHub (Sep 18, 2020): 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.

gitea-mirror commented

2026-05-05 06:36:35 -06:00

Author

Owner

@alexpdp7 commented on GitHub (Nov 15, 2020):

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

@alexpdp7 commented on GitHub (Nov 15, 2020): I just noticed EPEL now includes Barrier, which is good enough for me, so you can close this ticket.

No labels

Rows
Columns