From hs at nhn.ou.edu Thu Nov 1 00:47:02 2018 From: hs at nhn.ou.edu (Horst Severini) Date: Wed, 31 Oct 2018 19:47:02 -0500 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: References: Message-ID: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> Hi all, we noticed that on our 64-bit RHEL6 Server nodes, whenever there's a firefox update, the 64-bit firefox RPM is being replaced with an updated 32-bit RPM. I dug a little deeper, and I think the issue might be that while there are both 32- and 64-bit versions in the rhel-6-server-rpms repo, only the 32-bit version is in the rhel-6-server-optional-rpms. At least that's what I gather from the output of 'yum list firefox': Installed Packages firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms Available Packages firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms Actually, it's even weirder than that. If I uninstall firefox, then I get this: yum --disablerepo=rhel-6-server-optional-rpms list firefox Available Packages firefox.i686 31.1.0-5.el6_5 rhel-6-server-rpms firefox.x86_64 60.3.0-1.el6 rhel-6-server-rpms yum --disablerepo=rhel-6-server-rpms list firefox Available Packages firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms Is there a reason for that? I would've expected that either both of them should be provided by and updated in the same repo, or there should only be a 64-bit version at all, like there is for thunderbird: yum list thunderbird Available Packages thunderbird.x86_64 52.9.1-1.el6 rhel-6-server-optional-rpms Is there a way to fix this in the repos? If not, what would be the easiest way to fix it on the client side? I suppose I could add some 'exclude=firefox' statement to the [rhel-6-server-optional-rpms] section in /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort to a hack like that. Or are there other yum priority tweaks that could address this? The weird thing is that during a fresh install, it picks the 64-bit version, so I'm not sure why an updated 'favors' the 32-bit version. Maybe rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, and therefore the 'yum update' can only find the updated 32-bit version, and therefore chooses that one? Thanks a lot, Horst From solarflow99 at gmail.com Sat Nov 3 02:45:52 2018 From: solarflow99 at gmail.com (solarflow99) Date: Fri, 2 Nov 2018 19:45:52 -0700 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> Message-ID: in the yum repo file it usually has a $basearch in the URL On Wed, Oct 31, 2018 at 5:55 PM Horst Severini wrote: > Hi all, > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's > a firefox update, the 64-bit firefox RPM is being replaced with an > updated 32-bit RPM. I dug a little deeper, and I think the issue > might be that while there are both 32- and 64-bit versions > in the rhel-6-server-rpms repo, only the 32-bit version is > in the rhel-6-server-optional-rpms. > > At least that's what I gather from the output of 'yum list firefox': > > Installed Packages > firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms > > Available Packages > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > Actually, it's even weirder than that. If I uninstall firefox, > then I get this: > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > Available Packages > firefox.i686 31.1.0-5.el6_5 > rhel-6-server-rpms > firefox.x86_64 60.3.0-1.el6 > rhel-6-server-rpms > > yum --disablerepo=rhel-6-server-rpms list firefox > > Available Packages > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > Is there a reason for that? I would've expected that either both of them > should be provided by and updated in the same repo, or there should only > be a 64-bit version at all, like there is for thunderbird: > > yum list thunderbird > > Available Packages > thunderbird.x86_64 52.9.1-1.el6 > rhel-6-server-optional-rpms > > Is there a way to fix this in the repos? If not, what would be the easiest > way to fix it on the client side? I suppose I could add some > 'exclude=firefox' > statement to the [rhel-6-server-optional-rpms] section in > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort > to a hack like that. > > Or are there other yum priority tweaks that could address this? > > The weird thing is that during a fresh install, it picks the 64-bit > version, > so I'm not sure why an updated 'favors' the 32-bit version. Maybe > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, > and therefore the 'yum update' can only find the updated 32-bit version, > and therefore chooses that one? > > Thanks a lot, > > Horst > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stan.Hearn at nscorp.com Thu Nov 8 12:28:44 2018 From: Stan.Hearn at nscorp.com (Hearn, Stan J.) Date: Thu, 8 Nov 2018 12:28:44 +0000 Subject: [rhelv6-list] EPEL History Message-ID: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> I just realized that the EPEL repository purges older versions of rpms periodically. For instance, the version of a package that I installed in July 2017 is no longer in the repository. Without that version of the package being in the repository, I can't back out a newer version install. I'd like to update several EPEL RPMs but if I don't know if I can back them out it is risky. What are my options? I could create a reposync and this would solve it from today onward, but how can I access older versions? Has someone already created a RHEL repo that keeps every package forever? Regards, Stan From smooge at gmail.com Thu Nov 8 14:03:29 2018 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 Nov 2018 09:03:29 -0500 Subject: [rhelv6-list] EPEL History In-Reply-To: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> Message-ID: On Thu, 8 Nov 2018 at 07:29, Hearn, Stan J. wrote: > > I just realized that the EPEL repository purges older versions of rpms periodically. > > For instance, the version of a package that I installed in July 2017 is no longer in the repository. Without that version of the package being in the repository, I can't back out a newer version install. > What is the package you were needing? If it was in the repository it should still be in the koji build system. > I'd like to update several EPEL RPMs but if I don't know if I can back them out it is risky. > > What are my options? I could create a reposync and this would solve it from today onward, but how can I access older versions? Has someone already created a RHEL repo that keeps every package forever? > This can end up with problems but I will see if I can come up with a solution. > Regards, > Stan > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -- Stephen J Smoogen. From thomas at redhat.com Thu Nov 8 14:30:14 2018 From: thomas at redhat.com (thomas at redhat.com) Date: Thu, 8 Nov 2018 08:30:14 -0600 Subject: [rhelv6-list] EPEL History In-Reply-To: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> Message-ID: <922fdfb8-830f-d428-b911-8066c0b0dacc@redhat.com> On 11/8/18 6:28 AM, Hearn, Stan J. wrote: > I just realized that the EPEL repository purges older versions of rpms periodically. > > For instance, the version of a package that I installed in July 2017 is no longer in the repository. Without that version of the package being in the repository, I can't back out a newer version install. > > I'd like to update several EPEL RPMs but if I don't know if I can back them out it is risky. > > What are my options? I could create a reposync and this would solve it from today onward, but how can I access older versions? Has someone already created a RHEL repo that keeps every package forever? Hi, Stan! I am absolutely *not* minimizing your concern, but... I am trying to remember the number of times I've needed a really old version of a package, and I just can't. I've been using Linux since 1995. While I've definitely had to do downgrades, it's typically within days of upgrades, after a problem is exposed. I don't believe the EPEL packages are purged that quickly. How often have you needed to roll back a package from a year ago? Again - I'm not poo-pooing your concern. I totally get where you're coming from. I'm just trying to understand how often this comes up. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Senior Principal Cloud Evangelist, Red Hat +1-512-241-0774 office / +1-512-585-5631 cell / IRC: choirboy "It's too big a world to be in competition with everybody. The only guy I have to get better than is who I am right now." -- Colonel Potter, M*A*S*H From hs at nhn.ou.edu Thu Nov 8 14:30:24 2018 From: hs at nhn.ou.edu (Horst Severini) Date: Thu, 8 Nov 2018 08:30:24 -0600 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> Message-ID: <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> Hi again, I never received any response to this email. Are my emails going through to the list at all? I never even got my own email back. Thanks, Horst On 10/31/18 7:47 PM, Horst Severini wrote: > Hi all, > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's > a firefox update, the 64-bit firefox RPM is being replaced with an > updated 32-bit RPM. I dug a little deeper, and I think the issue > might be that while there are both 32- and 64-bit versions > in the rhel-6-server-rpms repo, only the 32-bit version is > in the rhel-6-server-optional-rpms. > > At least that's what I gather from the output of 'yum list firefox': > > Installed Packages > firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms > Available Packages > firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms > > Actually, it's even weirder than that. If I uninstall firefox, > then I get this: > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > Available Packages > firefox.i686 31.1.0-5.el6_5 rhel-6-server-rpms > firefox.x86_64 60.3.0-1.el6 rhel-6-server-rpms > > yum --disablerepo=rhel-6-server-rpms list firefox > > Available Packages > firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms > > Is there a reason for that? I would've expected that either both of them > should be provided by and updated in the same repo, or there should only > be a 64-bit version at all, like there is for thunderbird: > > yum list thunderbird > > Available Packages > thunderbird.x86_64 52.9.1-1.el6 rhel-6-server-optional-rpms > > Is there a way to fix this in the repos? If not, what would be the easiest > way to fix it on the client side? I suppose I could add some 'exclude=firefox' > statement to the [rhel-6-server-optional-rpms] section in > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort > to a hack like that. > > Or are there other yum priority tweaks that could address this? > > The weird thing is that during a fresh install, it picks the 64-bit version, > so I'm not sure why an updated 'favors' the 32-bit version. Maybe > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, > and therefore the 'yum update' can only find the updated 32-bit version, > and therefore chooses that one? > > Thanks a lot, > > Horst > From smooge at gmail.com Thu Nov 8 15:04:15 2018 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 Nov 2018 10:04:15 -0500 Subject: [rhelv6-list] EPEL History In-Reply-To: <922fdfb8-830f-d428-b911-8066c0b0dacc@redhat.com> References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> <922fdfb8-830f-d428-b911-8066c0b0dacc@redhat.com> Message-ID: On Thu, 8 Nov 2018 at 09:59, thomas at redhat.com wrote: > > On 11/8/18 6:28 AM, Hearn, Stan J. wrote: > > I just realized that the EPEL repository purges older versions of rpms periodically. > > > > For instance, the version of a package that I installed in July 2017 is no longer in the repository. Without that version of the package being in the repository, I can't back out a newer version install. > > > > I'd like to update several EPEL RPMs but if I don't know if I can back them out it is risky. > > > > What are my options? I could create a reposync and this would solve it from today onward, but how can I access older versions? Has someone already created a RHEL repo that keeps every package forever? > > Hi, Stan! > > I am absolutely *not* minimizing your concern, but... I am trying to > remember the number of times I've needed a really old version of a > package, and I just can't. I've been using Linux since 1995. While I've > definitely had to do downgrades, it's typically within days of upgrades, > after a problem is exposed. I don't believe the EPEL packages are purged > that quickly. > Usually it comes from rebuilding a system. If your kickstart needed xyz-foo and it is no longer in EPEL but you only find out at 2am when you rebuilt because the raid array died.. you end up in a bad spot. > How often have you needed to roll back a package from a year ago? > > Again - I'm not poo-pooing your concern. I totally get where you're > coming from. I'm just trying to understand how often this comes up. > -- > Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX > Senior Principal Cloud Evangelist, Red Hat > +1-512-241-0774 office / +1-512-585-5631 cell / IRC: choirboy > > "It's too big a world to be in competition with everybody. The only guy > I have to get better than is who I am right now." -- Colonel Potter, M*A*S*H > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -- Stephen J Smoogen. From gsgatlin at ncsu.edu Thu Nov 8 15:13:16 2018 From: gsgatlin at ncsu.edu (Gary Gatling) Date: Thu, 8 Nov 2018 10:13:16 -0500 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> Message-ID: I don't use RHEL 6 any longer for desktops so I have no answer concerning firefox and 32 vs 64 bit rpms. But I did want to mention I saw your message. On Thu, Nov 8, 2018 at 9:59 AM Horst Severini wrote: > Hi again, > > I never received any response to this email. Are my emails going through > to the list at all? I never even got my own email back. > > Thanks, > > Horst > > On 10/31/18 7:47 PM, Horst Severini wrote: > > Hi all, > > > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's > > a firefox update, the 64-bit firefox RPM is being replaced with an > > updated 32-bit RPM. I dug a little deeper, and I think the issue > > might be that while there are both 32- and 64-bit versions > > in the rhel-6-server-rpms repo, only the 32-bit version is > > in the rhel-6-server-optional-rpms. > > > > At least that's what I gather from the output of 'yum list firefox': > > > > Installed Packages > > firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms > > Available Packages > > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > > > Actually, it's even weirder than that. If I uninstall firefox, > > then I get this: > > > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > > > Available Packages > > firefox.i686 31.1.0-5.el6_5 > rhel-6-server-rpms > > firefox.x86_64 60.3.0-1.el6 > rhel-6-server-rpms > > > > yum --disablerepo=rhel-6-server-rpms list firefox > > > > Available Packages > > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > > > Is there a reason for that? I would've expected that either both of them > > should be provided by and updated in the same repo, or there should only > > be a 64-bit version at all, like there is for thunderbird: > > > > yum list thunderbird > > > > Available Packages > > thunderbird.x86_64 52.9.1-1.el6 > rhel-6-server-optional-rpms > > > > Is there a way to fix this in the repos? If not, what would be the > easiest > > way to fix it on the client side? I suppose I could add some > 'exclude=firefox' > > statement to the [rhel-6-server-optional-rpms] section in > > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort > > to a hack like that. > > > > Or are there other yum priority tweaks that could address this? > > > > The weird thing is that during a fresh install, it picks the 64-bit > version, > > so I'm not sure why an updated 'favors' the 32-bit version. Maybe > > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, > > and therefore the 'yum update' can only find the updated 32-bit version, > > and therefore chooses that one? > > > > Thanks a lot, > > > > Horst > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at redhat.com Thu Nov 8 15:16:56 2018 From: thomas at redhat.com (thomas at redhat.com) Date: Thu, 8 Nov 2018 09:16:56 -0600 Subject: [rhelv6-list] EPEL History In-Reply-To: References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> <922fdfb8-830f-d428-b911-8066c0b0dacc@redhat.com> Message-ID: On 11/8/18 9:04 AM, Stephen John Smoogen wrote: > Usually it comes from rebuilding a system. If your kickstart needed > xyz-foo and it is no longer in EPEL but you only find out at 2am when > you rebuilt because the raid array died.. you end up in a bad spot. Ah, great point. I would still recommend you keep your systems up to date instead of using outdated packages, but I now understand the scenario better. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Senior Principal Cloud Evangelist, Red Hat +1-512-241-0774 office / +1-512-585-5631 cell / IRC: choirboy "It's too big a world to be in competition with everybody. The only guy I have to get better than is who I am right now." -- Colonel Potter, M*A*S*H From marco.shaw at gmail.com Thu Nov 8 15:22:30 2018 From: marco.shaw at gmail.com (Marco Shaw) Date: Thu, 8 Nov 2018 11:22:30 -0400 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> Message-ID: Received. Archives here: https://www.redhat.com/archives/rhelv6-list/ On Thu, Nov 8, 2018 at 10:59 AM Horst Severini wrote: > Hi again, > > I never received any response to this email. Are my emails going through > to the list at all? I never even got my own email back. > > Thanks, > > Horst > > On 10/31/18 7:47 PM, Horst Severini wrote: > > Hi all, > > > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's > > a firefox update, the 64-bit firefox RPM is being replaced with an > > updated 32-bit RPM. I dug a little deeper, and I think the issue > > might be that while there are both 32- and 64-bit versions > > in the rhel-6-server-rpms repo, only the 32-bit version is > > in the rhel-6-server-optional-rpms. > > > > At least that's what I gather from the output of 'yum list firefox': > > > > Installed Packages > > firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms > > Available Packages > > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > > > Actually, it's even weirder than that. If I uninstall firefox, > > then I get this: > > > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > > > Available Packages > > firefox.i686 31.1.0-5.el6_5 > rhel-6-server-rpms > > firefox.x86_64 60.3.0-1.el6 > rhel-6-server-rpms > > > > yum --disablerepo=rhel-6-server-rpms list firefox > > > > Available Packages > > firefox.i686 60.3.0-1.el6 > rhel-6-server-optional-rpms > > > > Is there a reason for that? I would've expected that either both of them > > should be provided by and updated in the same repo, or there should only > > be a 64-bit version at all, like there is for thunderbird: > > > > yum list thunderbird > > > > Available Packages > > thunderbird.x86_64 52.9.1-1.el6 > rhel-6-server-optional-rpms > > > > Is there a way to fix this in the repos? If not, what would be the > easiest > > way to fix it on the client side? I suppose I could add some > 'exclude=firefox' > > statement to the [rhel-6-server-optional-rpms] section in > > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort > > to a hack like that. > > > > Or are there other yum priority tweaks that could address this? > > > > The weird thing is that during a fresh install, it picks the 64-bit > version, > > so I'm not sure why an updated 'favors' the 32-bit version. Maybe > > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, > > and therefore the 'yum update' can only find the updated 32-bit version, > > and therefore chooses that one? > > > > Thanks a lot, > > > > Horst > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsawyers at vt.edu Thu Nov 8 15:32:24 2018 From: bsawyers at vt.edu (Brandon Sawyers) Date: Thu, 8 Nov 2018 10:32:24 -0500 Subject: [rhelv6-list] EPEL History In-Reply-To: References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> <922fdfb8-830f-d428-b911-8066c0b0dacc@redhat.com> Message-ID: We have answered this by running a local pulp server and keeping a local copy of the EPEL repo locked in place. On Thu, Nov 8, 2018 at 10:29 AM thomas at redhat.com wrote: > On 11/8/18 9:04 AM, Stephen John Smoogen wrote: > > Usually it comes from rebuilding a system. If your kickstart needed > > xyz-foo and it is no longer in EPEL but you only find out at 2am when > > you rebuilt because the raid array died.. you end up in a bad spot. > > Ah, great point. I would still recommend you keep your systems up to > date instead of using outdated packages, but I now understand the > scenario better. > > -- > Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX > Senior Principal Cloud Evangelist, Red Hat > +1-512-241-0774 office / +1-512-585-5631 cell / IRC: choirboy > > "It's too big a world to be in competition with everybody. The only guy > I have to get better than is who I am right now." -- Colonel Potter, > M*A*S*H > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -- *Brandon Sawyers* NI&S (MC0214) Virginia Tech 1700 Pratt Drive Blacksburg, VA 24060 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfairchild at brocku.ca Thu Nov 8 15:54:49 2018 From: cfairchild at brocku.ca (Cale Fairchild) Date: Thu, 8 Nov 2018 15:54:49 +0000 Subject: [rhelv6-list] question about Firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos Message-ID: It certainly seems that RedHat has moved the Firefox 32-bit client updates from the server repository to the optional as any server I have which is not subscribed to rhel-6-server-optional-rpms will also find the old firefox-31.1.0-5.el6_5.i686 package. I also recall noticing that one of my servers wanted to switch over to the i686 version on an upgrade but I can not recall what I did to fix it, and that same server performed the upgrade to 6.10 without that being an issue. Perhaps a 'yum clear all' would help as that is the only thing I can think that I would have done to resolve it? Regards, Cale Fairchild -----Original Message----- From: rhelv6-list-bounces at redhat.com On Behalf Of Horst Severini Sent: Thursday, November 8, 2018 9:30 AM To: rhelv6-list at redhat.com Subject: Re: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos Hi again, I never received any response to this email. Are my emails going through to the list at all? I never even got my own email back. Thanks, Horst On 10/31/18 7:47 PM, Horst Severini wrote: > Hi all, > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's a > firefox update, the 64-bit firefox RPM is being replaced with an > updated 32-bit RPM. I dug a little deeper, and I think the issue might > be that while there are both 32- and 64-bit versions in the > rhel-6-server-rpms repo, only the 32-bit version is in the > rhel-6-server-optional-rpms. > > At least that's what I gather from the output of 'yum list firefox': > > Installed Packages > firefox.x86_64 60.3.0-1.el6 @rhel-6-server-rpms > Available Packages > firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms > > Actually, it's even weirder than that. If I uninstall firefox, then I > get this: > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > Available Packages > firefox.i686 31.1.0-5.el6_5 rhel-6-server-rpms > firefox.x86_64 60.3.0-1.el6 rhel-6-server-rpms > > yum --disablerepo=rhel-6-server-rpms list firefox > > Available Packages > firefox.i686 60.3.0-1.el6 rhel-6-server-optional-rpms > > Is there a reason for that? I would've expected that either both of > them should be provided by and updated in the same repo, or there > should only be a 64-bit version at all, like there is for thunderbird: > > yum list thunderbird > > Available Packages > thunderbird.x86_64 52.9.1-1.el6 rhel-6-server-optional-rpms > > Is there a way to fix this in the repos? If not, what would be the > easiest way to fix it on the client side? I suppose I could add some 'exclude=firefox' > statement to the [rhel-6-server-optional-rpms] section in > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to resort > to a hack like that. > > Or are there other yum priority tweaks that could address this? > > The weird thing is that during a fresh install, it picks the 64-bit > version, so I'm not sure why an updated 'favors' the 32-bit version. > Maybe rhel-6-server-optional-rpms is updated before > rhel-6-server-rpms, and therefore the 'yum update' can only find the > updated 32-bit version, and therefore chooses that one? > > Thanks a lot, > > Horst > _______________________________________________ rhelv6-list mailing list rhelv6-list at redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-list From hs at nhn.ou.edu Thu Nov 8 15:57:11 2018 From: hs at nhn.ou.edu (Horst Severini) Date: Thu, 8 Nov 2018 09:57:11 -0600 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> Message-ID: <9a584830-adad-d7dd-9598-c5d1734e1b38@nhn.ou.edu> Thanks Marco! I just looked at the archive, and there is a reply from solarflow99 las Friday, which I for some reason never got! > in the yum repo file it usually has a $basearch in the URL Yes, I see that in all the URLs in /etc/yum.repos.d/redhat.repo, but it's not clear to me where/how that is set. It's presumably set to x86_64, though, since these are all 64-bit servers: [hs at ouhep5 ~]$ uname -a Linux ouhep5.nhn.ou.edu 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 10:29:08 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux [hs at ouhep5 ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.10 (Santiago) But in a 64-bit server, there are plenty of 32-bit RPMs -- which are of course necessary -- and firefox is one of the ones which come in both flavors, so I'm not sure why the rhel-6-server-rpms repo only contains the 64-bit version (plus a really old 32-bit version), while the rhel-6-server-optional-rpms repo only contains the 32-bit version. That seems like an oversight. Who is in charge of these repos? I would think that firefox should be in one or the other, but not both -- and particularly not different flavors in each? Thanks a lot, Horst On 11/8/18 9:22 AM, Marco Shaw wrote: > Received.? Archives here: > https://www.redhat.com/archives/rhelv6-list/ > > On Thu, Nov 8, 2018 at 10:59 AM Horst Severini > wrote: > > Hi again, > > I never received any response to this email. Are my emails going > through > to the list at all? I never even got my own email back. > > Thanks, > > ? ? ? ? Horst > > On 10/31/18 7:47 PM, Horst Severini wrote: > > Hi all, > > > > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's > > a firefox update, the 64-bit firefox RPM is being replaced with an > > updated 32-bit RPM. I dug a little deeper, and I think the issue > > might be that while there are both 32- and 64-bit versions > > in the rhel-6-server-rpms repo, only the 32-bit version is > > in the rhel-6-server-optional-rpms. > > > > At least that's what I gather from the output of 'yum list firefox': > > > > Installed Packages > > firefox.x86_64? ? ? ? ? ? ?60.3.0-1.el6 > @rhel-6-server-rpms > > Available Packages > > firefox.i686? ? ? ? ? ? ? ?60.3.0-1.el6 > rhel-6-server-optional-rpms > > > > Actually, it's even weirder than that. If I uninstall firefox, > > then I get this: > > > > yum --disablerepo=rhel-6-server-optional-rpms list firefox > > > > Available Packages > > firefox.i686? ? ? ? ? ? ? ? ? ?31.1.0-5.el6_5 > ?rhel-6-server-rpms > > firefox.x86_64? ? ? ? ? ? ? ? ?60.3.0-1.el6 > ?rhel-6-server-rpms > > > > yum --disablerepo=rhel-6-server-rpms list firefox > > > > Available Packages > > firefox.i686? ? ? ? ? ? ? 60.3.0-1.el6 > ?rhel-6-server-optional-rpms > > > > Is there a reason for that? I would've expected that either both > of them > > should be provided by and updated in the same repo, or there > should only > > be a 64-bit version at all, like there is for thunderbird: > > > > yum list thunderbird > > > > Available Packages > > thunderbird.x86_64? ? ? ? ? ?52.9.1-1.el6 > rhel-6-server-optional-rpms > > > > Is there a way to fix this in the repos? If not, what would be > the easiest > > way to fix it on the client side? I suppose I could add some > 'exclude=firefox' > > statement to the [rhel-6-server-optional-rpms] section in > > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to > resort > > to a hack like that. > > > > Or are there other yum priority tweaks that could address this? > > > > The weird thing is that during a fresh install, it picks the > 64-bit version, > > so I'm not sure why an updated 'favors' the 32-bit version. Maybe > > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, > > and therefore the 'yum update' can only find the updated 32-bit > version, > > and therefore chooses that one? > > > > Thanks a lot, > > > >? ? ? ?Horst > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > From hs at nhn.ou.edu Thu Nov 8 16:20:02 2018 From: hs at nhn.ou.edu (Horst Severini) Date: Thu, 8 Nov 2018 10:20:02 -0600 Subject: [rhelv6-list] question about firefox 32- vs. 64-bit RPMs in rhel-6-server-rpms and rhel-6-server-optional-rpms repos In-Reply-To: <9a584830-adad-d7dd-9598-c5d1734e1b38@nhn.ou.edu> References: <201811010047.wA10l2jl852819@particle.nhn.ou.edu> <8a3ede8e-1554-cd3d-94aa-212283e9db66@nhn.ou.edu> <9a584830-adad-d7dd-9598-c5d1734e1b38@nhn.ou.edu> Message-ID: <6d4e3527-e10a-7fb9-dac7-a38b7d8c95ac@nhn.ou.edu> Hi again, I just saw another reply from Cale in the archive, which I also didn't get. Why am I not getting emails from a thread that I started, while I'm getting all others (like the EPEL thread earlier today)? That seems very strange. Anyway, Cale's reply: > It certainly seems that RedHat has moved the Firefox 32-bit client > updates from the server repository to the optional as any server I > have which is not subscribed to rhel-6-server-optional-rpms will also > find the old firefox-31.1.0-5.el6_5.i686 package. I also recall > noticing that one of my servers wanted to switch over to the i686 > version on an upgrade but I can not recall what I did to fix it, and > that same server performed the upgrade to 6.10 without that being an > issue. Perhaps a 'yum clear all' would help as that is the only thing > I can think that I would have done to resolve it? I tried 'yum clean all', but I don't think that has any effect here, since it still sees the 32-bit firefox RPM, and therefore any update where the 32-bit firefox appears in rhel-6-server-optional-rpms before the 64-bit firefox appears in rhel-6-server-rpms will cause it to revert back to 32-bit. Can that be fixed in the repos? Ah, I finally got Cale's reply email, great! Thanks again! Cheers, Horst On 11/8/18 9:57 AM, Horst Severini wrote: > Thanks Marco! > > I just looked at the archive, and there is a reply from solarflow99 las > Friday, which I for some reason never got! > > > in the yum repo file it usually has a $basearch in the URL > > Yes, I see that in all the URLs in /etc/yum.repos.d/redhat.repo, but > it's not clear to me where/how that is set. It's presumably set to > x86_64, though, since these are all 64-bit servers: > > [hs at ouhep5 ~]$ uname -a > Linux ouhep5.nhn.ou.edu 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 > 10:29:08 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux > [hs at ouhep5 ~]$ cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.10 (Santiago) > > But in a 64-bit server, there are plenty of 32-bit RPMs -- which are of > course necessary -- and firefox is one of the ones which come in both > flavors, so I'm not sure why the rhel-6-server-rpms repo only contains > the 64-bit version (plus a really old 32-bit version), while the > rhel-6-server-optional-rpms repo only contains the 32-bit version. That > seems like an oversight. > > Who is in charge of these repos? I would think that firefox should be in > one or the other, but not both -- and particularly not different flavors > in each? > > Thanks a lot, > > ????Horst > > On 11/8/18 9:22 AM, Marco Shaw wrote: >> Received.? Archives here: >> https://www.redhat.com/archives/rhelv6-list/ >> >> On Thu, Nov 8, 2018 at 10:59 AM Horst Severini > > wrote: >> >> ??? Hi again, >> >> ??? I never received any response to this email. Are my emails going >> ??? through >> ??? to the list at all? I never even got my own email back. >> >> ??? Thanks, >> >> ???? ? ? ? ? Horst >> >> ??? On 10/31/18 7:47 PM, Horst Severini wrote: >> ???? > Hi all, >> ???? > >> ???? > we noticed that on our 64-bit RHEL6 Server nodes, whenever there's >> ???? > a firefox update, the 64-bit firefox RPM is being replaced with an >> ???? > updated 32-bit RPM. I dug a little deeper, and I think the issue >> ???? > might be that while there are both 32- and 64-bit versions >> ???? > in the rhel-6-server-rpms repo, only the 32-bit version is >> ???? > in the rhel-6-server-optional-rpms. >> ???? > >> ???? > At least that's what I gather from the output of 'yum list >> firefox': >> ???? > >> ???? > Installed Packages >> ???? > firefox.x86_64? ? ? ? ? ? ?60.3.0-1.el6 ??? @rhel-6-server-rpms >> ???? > Available Packages >> ???? > firefox.i686? ? ? ? ? ? ? ?60.3.0-1.el6 >> rhel-6-server-optional-rpms >> ???? > >> ???? > Actually, it's even weirder than that. If I uninstall firefox, >> ???? > then I get this: >> ???? > >> ???? > yum --disablerepo=rhel-6-server-optional-rpms list firefox >> ???? > >> ???? > Available Packages >> ???? > firefox.i686? ? ? ? ? ? ? ? ? ?31.1.0-5.el6_5 >> ?rhel-6-server-rpms >> ???? > firefox.x86_64? ? ? ? ? ? ? ? ?60.3.0-1.el6 >> ?rhel-6-server-rpms >> ???? > >> ???? > yum --disablerepo=rhel-6-server-rpms list firefox >> ???? > >> ???? > Available Packages >> ???? > firefox.i686? ? ? ? ? ? ? 60.3.0-1.el6 >> ?rhel-6-server-optional-rpms >> ???? > >> ???? > Is there a reason for that? I would've expected that either both >> ??? of them >> ???? > should be provided by and updated in the same repo, or there >> ??? should only >> ???? > be a 64-bit version at all, like there is for thunderbird: >> ???? > >> ???? > yum list thunderbird >> ???? > >> ???? > Available Packages >> ???? > thunderbird.x86_64? ? ? ? ? ?52.9.1-1.el6 >> rhel-6-server-optional-rpms >> ???? > >> ???? > Is there a way to fix this in the repos? If not, what would be >> ??? the easiest >> ???? > way to fix it on the client side? I suppose I could add some >> ??? 'exclude=firefox' >> ???? > statement to the [rhel-6-server-optional-rpms] section in >> ???? > /etc/yum.repos.d/redhat.repo, but I was hoping I didn't have to >> ??? resort >> ???? > to a hack like that. >> ???? > >> ???? > Or are there other yum priority tweaks that could address this? >> ???? > >> ???? > The weird thing is that during a fresh install, it picks the >> ??? 64-bit version, >> ???? > so I'm not sure why an updated 'favors' the 32-bit version. Maybe >> ???? > rhel-6-server-optional-rpms is updated before rhel-6-server-rpms, >> ???? > and therefore the 'yum update' can only find the updated 32-bit >> ??? version, >> ???? > and therefore chooses that one? >> ???? > >> ???? > Thanks a lot, >> ???? > >> ???? >? ? ? ?Horst >> ???? > >> >> ??? _______________________________________________ >> ??? rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> > From leonfauster at googlemail.com Thu Nov 8 17:03:44 2018 From: leonfauster at googlemail.com (Leon Fauster) Date: Thu, 8 Nov 2018 18:03:44 +0100 Subject: [rhelv6-list] EPEL History In-Reply-To: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> References: <1f097de7516b46bdb1600329ba174531@GATUCEXCH35S.nscorp.AD.NSCORP.COM> Message-ID: <9D8BE651-0114-4675-8D02-9A873A154C57@googlemail.com> > Am 08.11.2018 um 13:28 schrieb Hearn, Stan J. : > > I just realized that the EPEL repository purges older versions of rpms periodically. > > For instance, the version of a package that I installed in July 2017 is no longer in the repository. Without that version of the package being in the repository, I can't back out a newer version install. > > I'd like to update several EPEL RPMs but if I don't know if I can back them out it is risky. > > What are my options? I could create a reposync and this would solve it from today onward, but how can I access older versions? Has someone already created a RHEL repo that keeps every package forever? maybe here? https://archive.fedoraproject.org/pub/epel/ -- LF