#8558 EL8 libssh2
Closed: Fixed 4 years ago by kevin. Opened 4 years ago by pghmcfc.

In RHEL 8.0, libssh2 was available in the AppStream repo as part of the virt module. No devel package was shipped though so it was not possible to build anything using libssh2, nor was it possible to build libssh2 for EPEL.

In RHEL 8.1 the libssh2 package has been dropped so it should now be possible to build libssh2 for EPEL-8 (https://bugzilla.redhat.com/show_bug.cgi?id=1792625). However, the Fedora Infrastructure database (https://infrastructure.fedoraproject.org/repo/json/pkg_el8.json) that fedpkg checks against when requesting a branch for epel8 still includes entries for libssh2 and hence I cannot request the branch.

Is this intentional, and what would be the best way to proceed?


I believe this is going to be a releng issue versus an infrastructure issue. The contents in the pdc is what is going to block your ability to request a branch.. infrastructure just runs the server versus what the contents or the over-rides are in it. [That said there is a lot of overlap so I am not sure. ]

@mohanboddu or @pingou do either of you know what may be needed here?

Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

4 years ago

This is from the cron job we have on batcave01 /etc/cron.d/repo2json.cron which populates /srv/web/repo/json/pkg_el8.json with all the el8 packages.

In there we can see:

"libssh2": {"channels": {"codeready-builder-for-rhel-8-aarch64-rpms": [{"release": "7.mod
ule+el8+2833+c7d6d092", "epoch": "0", "versions": "1.8.0"}, {"release": "7.module+el8+2833+c7d6d092", "epoch": "0", "vers
ions": "1.8.0"}, {"release": "8.module+el8.0.0+4084+cceb9f44.1", "epoch": "0", "versions": "1.8.0"}, {"release": "8.modul
e+el8.0.0+4084+cceb9f44.1", "epoch": "0", "versions": "1.8.0"}], "rhel-8-for-ppc64le-appstream-rpms"...

So, it's still available in modules. Perhaps we need to supress the modular rpms for el8 here? Or put them in a seperate json file that fedscm-admin doesn't check?

So this is going to be like ansible in EL7. There will ALWAYS be a libssh2 available as a module in codeready. It just isn't the latest version of said module.

So this is going to be like ansible in EL7. There will ALWAYS be a libssh2 available as a module in codeready. It just isn't the latest version of said module.

Would a compat package be the way to go then?

So how what is done to allow for ansible to be built in RHEL-7. The package still exists in channels so it should be blocked.. but something was done to allow it and other packages over time.

A compat package won't be correct because the libssh2 we would be building is probably newer than the one inside the module.

Gentlemen - Has there been any update on this?

We are going to need a policy decision from the EPEL Steering Committee to implement something. I will open an email on the epel-devel@lists.fedoraproject.org to get that. Please follow along there.

OK the problem is that how the CDN presents what is available says that libssh2 is still there even if it isn't. We have not been able to find a way to filter this out and need help from the modularity or other teams for a fix if possible.

The old modularity team has passed the torch of development and support over to the dnf team. I believe they are called the "Software Management" team now. Anyway, I contacted them, asking where I should put this issue so it could be discussed, and they said to open a bugzilla for RHEL8 / dnf. Seemed appropriate, so here is the bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=1805260

Is that the right bugzilla url? Seems to be unrelated.

Is that the right bugzilla url? Seems to be unrelated.
Sorry, bad cut-and-paste. Thanks for catching that.

In a separate email I was told that the work around is to create a module (in this case libssh2 or something similar) and put libssh2 in that module, with a higher NVR than the one in the old RHEL8 module.

I propose we create a libssh2 module in EPEL8. There would just be one package in the module, which would be libssh2. It would not be a default module.

Pros:
libssh2, along with libssh2-devel would be available to users and packagers.

Cons:
Users would have to enable that module to use libssh2.
I think that packagers would have to create a module to use libssh2 for building.

Another proposal was brought up at the EPEL Steering Committee meeting.

Create both a libssh2 module AND a regular libssh2 package.

Pros:
It would allow people to build using libssh2 without a module.
People who are affected could enable the module, and it would work the same on both RHEL and CentOS.

Cons:
Twice the updating each time an update is needed.
Possibly confusing if peopel see both.

@pghmcfc are you still interested in creating the libssh2 package in EPEL8?

If you are still interested, the EPEL Steering Committee approved the above measure of building both a regular package, as well as a libssh2 module. The module should have only libssh2 in it, and it should be the same package as the regular EPEL8 libssh2.

If you are still interested, please request libssh2 for epel8 via the usual steps. The infrastructure team will have to create the branches via --force. You shouldn't need to worry about that, but if it automatically get's closed, you will need to remind people.
After that, the build for the regular package, and module package should progress like normal.

Note: This is a one time exception due to the strange circumstances of libssh2. This is not a general approval for adding RHEL packages into EPEL. If someone see's something similar for a package they want in EPEL, please bring it to the EPEL committe and it will be investigated and discussed.

I'm fine with doing the regular package but I'm not interested in supporting a module myself. If it's considered better that the same person maintains both, I'm fine with someone else maintaining libssh2 in EPEL-8.

Oh, and I can't request the branch via the usual steps because of the reasons outlined in this ticket originally:

$ fedpkg request-branch epel8
Could not execute request_branch: This package is already an EL package and is built on all supported arches, therefore, it cannot be in EPEL. If this is a mistake or you have an exception, please contact the Release Engineering team.

Yep, sorry about that.
We'll get someone from infrastructure to get that branched.

Hi all,

This is the second time I hit the need for this regular libssh2 rpm for EL8.
Was that unblocked so @pghmcfc can proceed with the build ?

Regards,
Xavier

Ugg, I'm sorry. I totally dropped the ball. I asked infrastructure, they said to open a ticket, and then things came up, and then I dropped it.
Opening ticket now.

No, that won't work. Please file a releng ticket. Or I guess we could just use this one...

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Note that this is the regular rpm version only; if anyone needs a module, that will need to be done by someone else - I'm not comfortable supporting a module even in Fedora, let alone EPEL.

Login to comment on this ticket.

Metadata