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 insta
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 fail
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 hi
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 r
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
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 gl
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
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
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.o
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 Universi
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
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
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
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 'R
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 understandin
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 p
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,
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
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
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, Itha
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,
21 matches
Mail list logo
