Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-48099

The redhat "jenkins-stable" yum repo points to "jenkins", leading to a broken repo

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Component/s: packaging
    • Labels:
      None
    • Environment:
      Amazon Linux AMI 2015.03
    • Similar Issues:

      Description

      As per the instructions here, https://pkg.jenkins.io/redhat-stable/, it has you download the https://pkg.jenkins.io/redhat-stable/jenkins.repo file.  This file's header line is "[jenkins]".  This causes yum to think that it should be grabbing the latest "jenkins" mirror version, which isn't available in the "jenkins-stable" mirror.

      Workaround:
      Change the first line in the downloaded "/etc/yum.repos.d/jenkins.repo" file to read:
      [jenkins-stable]

      The output of attempting to install jenkins after using this repo file is below:
      Downloading packages:
      http://pkg.jenkins.io/redhat-stable/jenkins-2.89-1.1.noarch.rpm: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
      Trying other mirror.

      Error downloading packages:
      jenkins-2.89-1.1.noarch: failure: jenkins-2.89-1.1.noarch.rpm from jenkins: [Errno 256] No more mirrors to try.

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment -

            Does this issue only occur when both repos are installed on a system? Otherwise I expect we'd have learned about this long ago. How can this be reproduced?

            Show
            danielbeck Daniel Beck added a comment - Does this issue only occur when both repos are installed on a system? Otherwise I expect we'd have learned about this long ago. How can this be reproduced?
            Hide
            markewaite Mark Waite added a comment - - edited

            I can't duplicate the problem as described. Steps I took in my attempt:

            1. Update my CentOS 7 machine to latest with:
              yum update
            2. Confirm the Jenkins repo is not in the repolist with:
              sudo yum repolist | grep jenkins
            3. Install jenkins.repo into /etc/yum.repos.d/ with:
              sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
            4. Install the Jenkins repository signature with:
              sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
            5. Confirm the Jenkins repo is in the repolist with:
              sudo yum repolist | grep jenkins
            6. Install Jenkins and confirm it is latest LTS (2.73.3) with:
              sudo yum install jenkins

            The message reported by the Scott Glajch looks similar to messages I've seen when a mirror was temporarily unavailable. Does the reported problem still appear? Does it continue if you use a different mirror?

            Show
            markewaite Mark Waite added a comment - - edited I can't duplicate the problem as described. Steps I took in my attempt: Update my CentOS 7 machine to latest with: yum update Confirm the Jenkins repo is not in the repolist with: sudo yum repolist | grep jenkins Install jenkins.repo into /etc/yum.repos.d/ with: sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo Install the Jenkins repository signature with: sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key Confirm the Jenkins repo is in the repolist with: sudo yum repolist | grep jenkins Install Jenkins and confirm it is latest LTS (2.73.3) with: sudo yum install jenkins The message reported by the Scott Glajch looks similar to messages I've seen when a mirror was temporarily unavailable. Does the reported problem still appear? Does it continue if you use a different mirror?
            Hide
            danielbeck Daniel Beck added a comment -

            Mark Waite Note the version it tries to download, 2.89 isn't stable.

            Perhaps installing both repos as my comment suggests works?

            Show
            danielbeck Daniel Beck added a comment - Mark Waite Note the version it tries to download, 2.89 isn't stable. Perhaps installing both repos as my comment suggests works?
            Hide
            markewaite Mark Waite added a comment -

            Daniel Beck I agree that the description from Scott Glajch says that his download was attempting 2.89, and if that is the version being attempted from "stable", then that is a bug.

            My results were that it downloaded 2.73.3 as I expected. I am unable to duplicate the bug as reported. Have you been able to duplicate the bug as reported?

            Show
            markewaite Mark Waite added a comment - Daniel Beck I agree that the description from Scott Glajch says that his download was attempting 2.89, and if that is the version being attempted from "stable", then that is a bug. My results were that it downloaded 2.73.3 as I expected. I am unable to duplicate the bug as reported. Have you been able to duplicate the bug as reported?
            Hide
            markewaite Mark Waite added a comment -

            Daniel Beck I don't know how Red Hat thinks about packages, but I believe the Debian and Ubuntu packages don't use a separate name for the long term support release of something as compared to weekly releases.  I assumed the same for Red Hat, since the package name is "jenkins" in both cases. 

            I assume that it is expected the user will choose one package source or the other.  Choosing both package sources seems like a "recipe for chaos", since then the same package name can be delivered from multiple repositories.

            Am I understanding your line of thinking, that possibly Scott Glajch had configured both the stable and the weekly repositories of Jenkins on a single machine, then requested a jenkins installation without specifying a package version to install?

            Show
            markewaite Mark Waite added a comment - Daniel Beck I don't know how Red Hat thinks about packages, but I believe the Debian and Ubuntu packages don't use a separate name for the long term support release of something as compared to weekly releases.  I assumed the same for Red Hat, since the package name is "jenkins" in both cases.  I assume that it is expected the user will choose one package source or the other.  Choosing both package sources seems like a "recipe for chaos", since then the same package name can be delivered from multiple repositories. Am I understanding your line of thinking, that possibly Scott Glajch had configured both the stable and the weekly repositories of Jenkins on a single machine, then requested a jenkins installation without specifying a package version to install?
            Hide
            glajchs Scott Glajch added a comment -

            Hi, sorry for the delay in response. I was fairly sure that I had only configured the stable repo entry for jenkins on the machine in question, however my "yum-fu" is not super great. I'm used to the debian package managers. I ran "sudo yum repolist enabled" and I only found the one entry for "jenkins-stable". Listing the disabled repos didn't list any other jenkins repos.

            That being said, this machine is really old, and did have a very old verison of jenkins installed on it. I can't find the actual version now but it's 1.5x. This was done a few years ago, and I'm pretty sure at the time I had used the RPM file directly to install, and not a yum repo.

            Again this an amazon-linux machine, which is RHEL based, but they do a bunch of custom stuff to those images so I'm not sure how much that plays into this. I'm not sure I can instantiate a new machine and dig into this too much more, but at the very least since this issue is limited to some set of machines or configurations, you might want to bump it down from major to normal priority.

            Here is a gist of the output of the yum repolist command, and the machine/release info: https://gist.github.com/glajchs/1da67cb5b16577558b64c36f7d957c7b

            Show
            glajchs Scott Glajch added a comment - Hi, sorry for the delay in response. I was fairly sure that I had only configured the stable repo entry for jenkins on the machine in question, however my "yum-fu" is not super great. I'm used to the debian package managers. I ran "sudo yum repolist enabled" and I only found the one entry for "jenkins-stable". Listing the disabled repos didn't list any other jenkins repos. That being said, this machine is really old, and did have a very old verison of jenkins installed on it. I can't find the actual version now but it's 1.5x. This was done a few years ago, and I'm pretty sure at the time I had used the RPM file directly to install, and not a yum repo. Again this an amazon-linux machine, which is RHEL based, but they do a bunch of custom stuff to those images so I'm not sure how much that plays into this. I'm not sure I can instantiate a new machine and dig into this too much more, but at the very least since this issue is limited to some set of machines or configurations, you might want to bump it down from major to normal priority. Here is a gist of the output of the yum repolist command, and the machine/release info: https://gist.github.com/glajchs/1da67cb5b16577558b64c36f7d957c7b
            Hide
            danielbeck Daniel Beck added a comment -

            Not sure there's something to gain from a continued investigation when the system config could just be messed up somehow, and we cannot reproduce it.

            Show
            danielbeck Daniel Beck added a comment - Not sure there's something to gain from a continued investigation when the system config could just be messed up somehow, and we cannot reproduce it.

              People

              • Assignee:
                danielbeck Daniel Beck
                Reporter:
                glajchs Scott Glajch
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: