Re: SL7x and the 'epel' repo
On 29/03/15 14:44, Tom H wrote: On Fri, Mar 27, 2015 at 6:04 AM, John Pilkington wrote: On 27/03/15 08:53, Tom H wrote: Point releases are just a snapshot of the packages at a certain point in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. RHEL offers its customers an EUS program for them to remain at a point release and get security updates but it doesn't publish the EUS sources in the same way that it doesn't publish the ELS sources. But my original point was that glib2-2.36.3-5, which I see in SL7x, was incompatible with the new (in epel-testing) qtwebkit, which needed glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 If it's in "epel-testing", why shouldn't only work with 7rolling? Even if it were in "epel", since RH released 7.1 threee weeks ago and it's EPEL's target, why should EPEL care about SL (and CentOS) being behind the curve? I wasn't making a complaint. I found something I didn't expect and thought it worth a 'heads-up.'
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 11:45 AM, Steve Gaarder wrote: > > In that case, I'm thinking that it could be useful to maintain an EPEL > mirror that does not get updated between TUV's release and the SL release. I > could do that for my own use or it could be a community effort. Thoughts? I was going to suggest the same two emails earlier but I didn't because I couldn't think of an appropriate cut-off date to stop rsyncing (When TUV publishes the point release? Would that be too late? If yes to the latter, then when?). I assume that you restart rsyncing once SL publishes the point release.
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 10:47 AM, Steve Gaarder wrote: > On Fri, 27 Mar 2015, Steve Gaarder wrote: >> >> I see this also with libgtop2. I currently cannot install the Mate >> group because the packages in EPEL require libgtop-2.0.so.10, which is >> in the package libgtop2-2.28.4-7.el7.x86_64.rpm, which in turn is only >> in SL7rolling. This suggests that EPEL is built against 7rolling, >> which seems like a really bad idea. > > Thinking about this some more, I assume that EPEL is actually built against > the latest from TUV, so 7.1 in this case. Correct? If that is true, then I > just need to be patient and wait for SL to release 7.1. Then the question > is: how patient do I need to be? Until SL 7.1 is released?
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 6:04 AM, John Pilkington wrote: > On 27/03/15 08:53, Tom H wrote: >> >> Point releases are just a snapshot of the packages at a certain point >> in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. >> >> RHEL offers its customers an EUS program for them to remain at a point >> release and get security updates but it doesn't publish the EUS >> sources in the same way that it doesn't publish the ELS sources. > > But my original point was that glib2-2.36.3-5, which I see in SL7x, was > incompatible with the new (in epel-testing) qtwebkit, which needed > glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 If it's in "epel-testing", why shouldn't only work with 7rolling? Even if it were in "epel", since RH released 7.1 threee weeks ago and it's EPEL's target, why should EPEL care about SL (and CentOS) being behind the curve?
Re: SL7x and the 'epel' repo
On 27/03/15 18:33, John Pilkington wrote: On 27/03/15 18:01, Steve Gaarder wrote: On Fri, 27 Mar 2015, Akemi Yagi wrote: One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems < 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Au contraire - right now, for example, I cannot install marco from EPEL: Packages presumably vary, but the bugzilla comments indicated that the only real condition now for EPEL is compatibility with RHEL 7.1; what concerned me was that there was no warning during installation that qtwebkit would fail. In fact the failure was total, but with other (hypothetical) packages it might not have been so clearcut. From the bugzilla report relating to the original qtwebkit problem, today, https://bugzilla.redhat.com/show_bug.cgi?id=1202735 --- Comment #11 from Rex Dieter --- Marking ON_QA, recent builds add a versioned glib2 runtime dependency
Re: SL 7.1 schedule? (was Re: SL7x and the 'epel' repo)
On 03/27/2015 01:39 PM, Steve Gaarder wrote: It would be very helpful to me if I could have some idea of when SL 7.1 is likely to emerge. That will tell me whether I can just wait or need to come up with some kind of workaround for the EPEL problem. thanks, Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu The BETA build was just posted for testing on March 23. It doesn't look like much has changed, so I would expect it out in the very near future, unless testing shows problems of course.
SL 7.1 schedule? (was Re: SL7x and the 'epel' repo)
It would be very helpful to me if I could have some idea of when SL 7.1 is likely to emerge. That will tell me whether I can just wait or need to come up with some kind of workaround for the EPEL problem. thanks, Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu
Re: SL7x and the 'epel' repo
On 27/03/15 18:01, Steve Gaarder wrote: On Fri, 27 Mar 2015, Akemi Yagi wrote: One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems < 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Au contraire - right now, for example, I cannot install marco from EPEL: Packages presumably vary, but the bugzilla comments indicated that the only real condition now for EPEL is compatibility with RHEL 7.1; what concerned me was that there was no warning during installation that qtwebkit would fail. In fact the failure was total, but with other (hypothetical) packages it might not have been so clearcut.
Re: SL7x and the 'epel' repo
On Fri, 27 Mar 2015, Akemi Yagi wrote: One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems < 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Au contraire - right now, for example, I cannot install marco from EPEL: # yum install marco Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * epel: mirrors.rit.edu * sl: ftp2.scientificlinux.org * sl-fastbugs: ftp2.scientificlinux.org * sl-security: ftp2.scientificlinux.org 3 packages excluded due to repository priority protections Resolving Dependencies --> Running transaction check ---> Package marco.x86_64 0:1.8.3-1.el7 will be installed --> Processing Dependency: libgtop-2.0.so.10()(64bit) for package: marco-1.8.3-1.el7.x86_64 --> Finished Dependency Resolution Error: Package: marco-1.8.3-1.el7.x86_64 (epel) Requires: libgtop-2.0.so.10()(64bit) libgtop-2.0.so.10 is in the libgtop2 package in 7.1. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 9:02 AM, Tim Kanuka wrote: > I think having a EPEL mirror in the way described by Steve is an excellent > idea. It exactly parallels my own requirement (and I suppose any site's > requirement) of managing updates to many machines. The only way to guarantee > that you are not going to break something with an update is to test your > applications on an updated *test* environment. The only way to guarantee that > your *production* environment is updated in the same way as the *test* > environment is to have a mirror repo that is not changing unexpectedly. I'd like to note that EPEL is not the only 3rd party repository. :-) In the case of ELRepo, it was also debated when to release the 7.1-based packages. They are all built against RHEL 7.1 like EPEL's. One thing that is different from EPEL is that ELRepo's el7.1 packages that are _not_ backward compatible will not install on systems < 7.1. yum will complain. My understanding is that EPEL packages do not have such 'Requires'. Akemi
RE: SL7x and the 'epel' repo
I think having a EPEL mirror in the way described by Steve is an excellent idea. It exactly parallels my own requirement (and I suppose any site's requirement) of managing updates to many machines. The only way to guarantee that you are not going to break something with an update is to test your applications on an updated *test* environment. The only way to guarantee that your *production* environment is updated in the same way as the *test* environment is to have a mirror repo that is not changing unexpectedly. Tim Kanuka Canadian Light Source -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Steve Gaarder Sent: Friday, March 27, 2015 09:45 To: Akemi Yagi Cc: SL Users Subject: Re: SL7x and the 'epel' repo In that case, I'm thinking that it could be useful to maintain an EPEL mirror that does not get updated between TUV's release and the SL release. I could do that for my own use or it could be a community effort. Thoughts? Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 27 Mar 2015, Akemi Yagi wrote: > On Fri, Mar 27, 2015 at 7:47 AM, Steve Gaarder > wrote: > > >> Thinking about this some more, I assume that EPEL is actually built >> against the latest from TUV, so 7.1 in this case. Correct? > > Yes, that is correct. There is a similar discussion thread on the > CentOS mailing list: > > http://lists.centos.org/pipermail/centos/2015-March/150945.html > > Akemi >
Re: SL7x and the 'epel' repo
In that case, I'm thinking that it could be useful to maintain an EPEL mirror that does not get updated between TUV's release and the SL release. I could do that for my own use or it could be a community effort. Thoughts? Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 27 Mar 2015, Akemi Yagi wrote: On Fri, Mar 27, 2015 at 7:47 AM, Steve Gaarder wrote: Thinking about this some more, I assume that EPEL is actually built against the latest from TUV, so 7.1 in this case. Correct? Yes, that is correct. There is a similar discussion thread on the CentOS mailing list: http://lists.centos.org/pipermail/centos/2015-March/150945.html Akemi
Re: SL7x and the 'epel' repo
On Fri, Mar 27, 2015 at 7:47 AM, Steve Gaarder wrote: > Thinking about this some more, I assume that EPEL is actually built against > the latest from TUV, so 7.1 in this case. Correct? Yes, that is correct. There is a similar discussion thread on the CentOS mailing list: http://lists.centos.org/pipermail/centos/2015-March/150945.html Akemi
Re: SL7x and the 'epel' repo
On Fri, 27 Mar 2015, Steve Gaarder wrote: On Fri, 27 Mar 2015, John Pilkington wrote: But my original point was that glib2-2.36.3-5, which I see in SL7x, was incompatible with the new (in epel-testing) qtwebkit, which needed glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 It seems that what I see as SL7x is still 7.0. The naming of the download sites may have me confused. I'm using yumex. I see this also with libgtop2. I currently cannot install the Mate group because the packages in EPEL require libgtop-2.0.so.10, which is in the package libgtop2-2.28.4-7.el7.x86_64.rpm, which in turn is only in SL7rolling. This suggests that EPEL is built against 7rolling, which seems like a really bad idea. Thinking about this some more, I assume that EPEL is actually built against the latest from TUV, so 7.1 in this case. Correct? If that is true, then I just need to be patient and wait for SL to release 7.1. Then the question is: how patient do I need to be? thanks, Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu
Re: SL7x and the 'epel' repo
On Fri, 27 Mar 2015, John Pilkington wrote: But my original point was that glib2-2.36.3-5, which I see in SL7x, was incompatible with the new (in epel-testing) qtwebkit, which needed glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 It seems that what I see as SL7x is still 7.0. The naming of the download sites may have me confused. I'm using yumex. I see this also with libgtop2. I currently cannot install the Mate group because the packages in EPEL require libgtop-2.0.so.10, which is in the package libgtop2-2.28.4-7.el7.x86_64.rpm, which in turn is only in SL7rolling. This suggests that EPEL is built against 7rolling, which seems like a really bad idea. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu
Re: SL7x and the 'epel' repo
On 27/03/15 08:53, Tom H wrote: On Thu, Mar 26, 2015 at 7:28 AM, Nico Kadel-Garcia wrote: On Thu, Mar 26, 2015 at 5:59 AM, Tom H wrote: On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski wrote: The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL 7.1. And because the glib2 library does not use symbol versioning, rpm cannot automatically add the proper requires/provides to avoid installing incompatible libraries. So, this has nothing to do with EPEL, per se, but just normal issues that can occur with any update to RHEL. Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the RH bugzilla instance doesn't add a "dev" icon to developers' names like the Gentoo one) explains in comments 5 and 7 why they don't do this. They don't need to because sticking to a specific point release is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't hit this qtwebkit/glib problem and EPEL's developers don't waste their time ensuring that's it works. What? No, SL and CentOS *inherit* this behavior from Red Hat's minor point releases. Our favorite upstream vendor has moved away from the old practice, long before RHEL, of the point releases being supported individually long term, but they certainly publish new installation media with the new point releases. The big difference is that SL and CentOS continue to publish the point releases in different web accessible directories, so you can still see the point releases and updates segregated by time, and releases they were compatible with. RHEL publishes all the updates since the first point release in a giant pool, more like the SL 6x and 7x repositories: it can provide some really useful information about the point releases to compare thei contents among them. I agree with your last point. RHEL and CentOS use the equivalent of SL's 6x/7x by default and don't give the option of using 6.y/7.z. Point releases are just a snapshot of the packages at a certain point in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. RHEL offers its customers an EUS program for them to remain at a point release and get security updates but it doesn't publish the EUS sources in the same way that it doesn't publish the ELS sources. - But my original point was that glib2-2.36.3-5, which I see in SL7x, was incompatible with the new (in epel-testing) qtwebkit, which needed glib2-2.40.0-4 from SL7rolling built off TUV's 7.1 It seems that what I see as SL7x is still 7.0. The naming of the download sites may have me confused. I'm using yumex.
Re: SL7x and the 'epel' repo
On Thu, Mar 26, 2015 at 7:28 AM, Nico Kadel-Garcia wrote: > On Thu, Mar 26, 2015 at 5:59 AM, Tom H wrote: >> On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski wrote: >>> >>> The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL >>> 7.1. And because the glib2 library does not use symbol versioning, rpm >>> cannot >>> automatically add the proper requires/provides to avoid installing >>> incompatible libraries. So, this has nothing to do with EPEL, per se, but >>> just normal issues that can occur with any update to RHEL. >> >> Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the >> RH bugzilla instance doesn't add a "dev" icon to developers' names >> like the Gentoo one) explains in comments 5 and 7 why they don't do >> this. They don't need to because sticking to a specific point release >> is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't >> hit this qtwebkit/glib problem and EPEL's developers don't waste their >> time ensuring that's it works. > > What? No, SL and CentOS *inherit* this behavior from Red Hat's minor > point releases. Our favorite upstream vendor has moved away from the > old practice, long before RHEL, of the point releases being supported > individually long term, but they certainly publish new installation > media with the new point releases. The big difference is that SL and > CentOS continue to publish the point releases in different web > accessible directories, so you can still see the point releases and > updates segregated by time, and releases they were compatible with. > RHEL publishes all the updates since the first point release in a > giant pool, more like the SL 6x and 7x repositories: it can provide > some really useful information about the point releases to compare > thei contents among them. I agree with your last point. RHEL and CentOS use the equivalent of SL's 6x/7x by default and don't give the option of using 6.y/7.z. Point releases are just a snapshot of the packages at a certain point in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x. RHEL offers its customers an EUS program for them to remain at a point release and get security updates but it doesn't publish the EUS sources in the same way that it doesn't publish the ELS sources.
Re: SL7x and the 'epel' repo
On Thu, Mar 26, 2015 at 5:59 AM, Tom H wrote: > On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski wrote: >> The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL >> 7.1. And because the glib2 library does not use symbol versioning, rpm cannot >> automatically add the proper requires/provides to avoid installing >> incompatible libraries. So, this has nothing to do with EPEL, per se, but >> just normal issues that can occur with any update to RHEL. > > Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the > RH bugzilla instance doesn't add a "dev" icon to developers' names > like the Gentoo one) explains in comments 5 and 7 why they don't do > this. They don't need to because sticking to a specific point release > is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't > hit this qtwebkit/glib problem and EPEL's developers don't waste their > time ensuring that's it works. What? No, SL and CentOS *inherit* this behavior from Red Hat's minor point releases. Our favorite upstream vendor has moved away from the old practice, long before RHEL, of the point releases being supported individually long term, but they certainly publish new installation media with the new point releases. The big difference is that SL and CentOS continue to publish the point releases in different web accessible directories, so you can still see the point releases and updates segregated by time, and releases they were compatible with. RHEL publishes all the updates since the first point release in a giant pool, more like the SL 6x and 7x repositories: it can provide some really useful information about the point releases to compare thei contents among them. When you lack the QA and pre-release testing of a major vendor, it can be really helpful to keep things seggregated, especially when you're always playing catch-up with upstream and the point releases contain a large mass of updates which may take you some time to resolve.
Re: SL7x and the 'epel' repo
On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski wrote: > On 03/19/2015 03:34 AM, John Pilkington wrote: >> >> I had been under the impression that it was likely to be safe to use 'epel' >> packages, so, wishing to provide feedback, I installed a new version of >> qtwebkit from epel-testing. No hint of problems during installation, but >> programs using it failed. I now have them apparently working after installing >> glib2 from SL7rolling in place of the earlier build in SL7x, but I'm less >> than >> happy about such cherry-picking. >> >> I'm told that epel packages support the current upstream release, 7.1, so it >> seems to me that systems based on the recommended SL7x and using epel will be >> at risk. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1202735 > > The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL > 7.1. And because the glib2 library does not use symbol versioning, rpm cannot > automatically add the proper requires/provides to avoid installing > incompatible libraries. So, this has nothing to do with EPEL, per se, but > just normal issues that can occur with any update to RHEL. Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the RH bugzilla instance doesn't add a "dev" icon to developers' names like the Gentoo one) explains in comments 5 and 7 why they don't do this. They don't need to because sticking to a specific point release is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't hit this qtwebkit/glib problem and EPEL's developers don't waste their time ensuring that's it works.
Re: SL7x and the 'epel' repo
On 03/19/2015 03:34 AM, John Pilkington wrote: > I had been under the impression that it was likely to be safe to use 'epel' > packages, so, wishing to provide feedback, I installed a new version of > qtwebkit from epel-testing. No hint of problems during installation, but > programs using it failed. I now have them apparently working after installing > glib2 from SL7rolling in place of the earlier build in SL7x, but I'm less than > happy about such cherry-picking. > > I'm told that epel packages support the current upstream release, 7.1, so it > seems to me that systems based on the recommended SL7x and using epel will be > at risk. > > https://bugzilla.redhat.com/show_bug.cgi?id=1202735 The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL 7.1. And because the glib2 library does not use symbol versioning, rpm cannot automatically add the proper requires/provides to avoid installing incompatible libraries. So, this has nothing to do with EPEL, per se, but just normal issues that can occur with any update to RHEL. Thanks for the heads up though. I suspect many other glib2 using libraries may be affected as more epel updates come out. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
SL7x and the 'epel' repo
I had been under the impression that it was likely to be safe to use 'epel' packages, so, wishing to provide feedback, I installed a new version of qtwebkit from epel-testing. No hint of problems during installation, but programs using it failed. I now have them apparently working after installing glib2 from SL7rolling in place of the earlier build in SL7x, but I'm less than happy about such cherry-picking. I'm told that epel packages support the current upstream release, 7.1, so it seems to me that systems based on the recommended SL7x and using epel will be at risk. https://bugzilla.redhat.com/show_bug.cgi?id=1202735
