Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

6.2.20190226 release in EPEL updates-testing? #71

Closed
jbasney opened this issue Mar 13, 2019 · 8 comments
Closed

6.2.20190226 release in EPEL updates-testing? #71

jbasney opened this issue Mar 13, 2019 · 8 comments

Comments

@jbasney
Copy link
Contributor

jbasney commented Mar 13, 2019

Passing along a question I received from Derek Simmel:

Jim,

I was trying to install various parts from the current gct release today...

The webpage at https://github.com/gridcf/gct/releases/tag/v6.2.20190226 says that precompiled packages are available in the EPEL updates-testing repo:

• EPEL (for Red Hat Enterprise Linux, CentOS and Scientific Linux 6 and 7 (currently in EPEL updates-testing!))

but I can't seem to find where one gets the updates-testing repo from... the epel-testing repo does not have the most current packages in it.

Can you please direct me to where I may find the updates-testing repo?

Thanks -

  • Derek
@fscheiner
Copy link
Member

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.

@dsimmel
Copy link

dsimmel commented Mar 13, 2019 via email

@jbasney
Copy link
Contributor Author

jbasney commented Mar 13, 2019

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

@fscheiner
Copy link
Member

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

@dsimmel
Copy link

dsimmel commented Mar 13, 2019 via email

@fscheiner
Copy link
Member

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

@matyasselmeci
Copy link
Contributor

matyasselmeci commented Mar 13, 2019 •
edited
Loading

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.

@dsimmel
Copy link

dsimmel commented Mar 13, 2019 via email

@fscheiner fscheiner mentioned this issue Sep 19, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jbasney @dsimmel @fscheiner @matyasselmeci