SCIENTIFIC-LINUX-USERS Archives

January 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Thu, 13 Jan 2011 11:29:49 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
Morten P.D. Stevens wrote:
> Hi Troy,
> 
> Thanks for this this information.
> 
> Which release has the higher priority? SL 6.0 or SL 5.6?
> 

SL 6.0 has higher priority.

But we know the process of building SL 5, so it's easier.
We should be able to do both without too much trouble.

Troy

> Thank you for your work on SL Linux.
> 
> Best regards,
> 
> Morten
> 
>> -----Original Message-----
>> From: [log in to unmask] [mailto:owner-
>> [log in to unmask]] On Behalf Of Troy Dawson
>> Sent: Thursday, January 13, 2011 5:11 PM
>> To: [log in to unmask]
>> Subject: SL policy on errata that came out with the 5.6 release
>>
>> Hello,
>> Since there are many people new to the SL mailing list since the last
>> update, I figure I should send out an email explaining the procedure
>> for
>> security errata that comes out when a new release comes out.
>>
>> First, the kernel.
>> As a policy, we do not release the kernel that comes out with a new
>> release as a security errata.  In this case, the kernel is
>> 2.6.18-238.el5.  This kernel will not go out as a security errata for
>> the other SL5 releases.  We will build it, and it will go into the 5.6
>> alpha, so people can get it there if they want.
>>
>> Security errata.
>> We do build and push out the other security errata, as long as they are
>> not tied to the kernel.
>>
>> Note 1: Because there is a huge amount of packages to build with the
>> beginning of a release, it takes more time to actually build the
>> packages.  So be patient.
>>
>> Note 2: The Upstream Vendor doesn't test these security updates on
>> their
>> earlier updates, so dependencies often creep in.  Because of that,
>> these
>> security updates require alot of testing, and take longer to get done.
>>
>> Thank You
>> Troy Dawson
>> --
>> __________________________________________________
>> Troy Dawson  [log in to unmask]  (630)840-6468
>> Fermilab  ComputingDivision/SCF/FEF/SLSMS Group
>> __________________________________________________


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________

ATOM RSS1 RSS2