6.2.20190226 release in EPEL updates-testing? about gct HOT 8 CLOSED

I believe the testing repo can be activated in the repo definitions in /etc/yum.repos.d. For example the EPEL6 RPM shows a file named epel-testing.repo where all repos are deactivated by default (enabled=0):

epel-testing.repo:

[epel-testing]
name=Extra Packages for Enterprise Linux 6 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-epel6&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

[epel-testing-debuginfo]
name=Extra Packages for Enterprise Linux 6 - Testing - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/testing/6/$basearch/debug
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-debug-epel6&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

[epel-testing-source]
name=Extra Packages for Enterprise Linux 6 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/6/SRPMS
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel6&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

So changing enabled=0 to enabled=1 for the [epel-testing] stanza and issuing yum update should do the trick and enable the use of the packages in epel-testing.

@jbasney
If that works for Derek, please close this issue.

from gct.

from gct.

I don't think myproxy-oauth was a Globus Toolkit package. I think that's a Globus Connect package.

from gct.

@dsimmel

I was attempting to install with epel-testing enabled, with the current epel repos, on a CentOS 7.6.1810 box, but the versions of some of the software (e.g. gsi-openssh) that came up did not seem to match what I expected in the latest release. Also, some elements were not found, e.g., myproxy-oauth, globus-proxy-utils - e.g., if I try: # yum --enablerepo=epel-testing install gsi-openssh gsi-openssh-server gsi-openssh-clients myproxy myproxy-oauth I get:
[...]
Comparing what's listed at https://github.com/gridcf/gct/releases/tag/v6.2.20190226, The dependencies look like the same versions in the release, except that globus-proxy-utils gets picked from epel instead of epel-testing. I tried running with --disablerepo=epel, but then globus-proxy-utils is missing:

Error: Package: myproxy-libs-6.2.4-1.el7.x86_64 (epel-testing) Requires: globus-proxy-utils

I think that's correct, as globus-proxy-utils wasn't changed since September 2018 (see https://repo.gridcf.org/gct6/sources/), so it will be in epel currently and not in epel-testing.

For the GSI-OpenSSH version, I think it always follows the OpenSSH version of the corresponding RHEL or RHEL compatible OS release, so the version might not be the same as in the GCT sources.

from gct.

from gct.

@dsimmel

OK - I'll pursue gsi-openssh separately.

Until we can fix #67, I'd recommend to use the version of your distribution.

I take it that NOT all *.rpm listed under Assets on https://github.com/gridcf/gct/releases/tag/v6.2.20190226 are available via the epel-testing repo, or are they supposed to be?

I only see source tarballs and RPMs under "Assets". I think the way they are created by the CI service for a new tag (e.g. v6.2.20190226) recreates all source tarballs and RPMs no matter something has changed for them or not.

@matyasselmeci
Am I correct with the last sentence above?

@dsimmel
The list of the actual new packages is shorter, see the notice in the release description:

NOTICE: Singular source packages of GCT components can be found on https://repo.gridcf.org/gct6/sources/. New packages for this release are dated 2019-02-26.

So you'll currently only find GCT packages in epel-testing whose source was changed on 2019-02-26. Sometime later (i.e. in 2 days actually) these will migrate to epel, see "Dates" on e.g. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-52b3e417c0.

from gct.

Yes, only the source tarballs and SRPMs get added to the GitHub release. We tried adding binary RPMs as well, but that GitHub does not behave well when we have too many files in a single release.
EDIT: And they all get recreated whenever a new tag is made.

from gct.

from gct.