On 03/12/2012 03:51 AM, Stephan Wiesand wrote:
> On Mar 9, 2012, at 22:11 , Pat Riehecky wrote:
>
>> Scientific Linux "SL 5.8" Alpha 1                         March 9, 2012
>>
>> See SL.documentation for Upstream vendor release notes.
>>
>> Send comments/issues/test reports to [log in to unmask]
> Our usual x86_64 kickstart installation (on bare metal) worked well, but there are a few minor issues:
>
> Some of the i386 gcc subpackages are still at their old version:
>
> SL/5rolling % find ./ -name libgomp\*.rpm
> ./x86_64/SL/libgomp-4.4.4-13.el5.i386.rpm
> ./x86_64/SL/libgomp-4.4.6-3.el5.1.x86_64.rpm
> ./i386/SL/libgomp-4.4.4-13.el5.i386.rpm
> SL/5rolling % ls i386/SL/*-4.4.6-3.el5.1.*
> i386/SL/gcc44-4.4.6-3.el5.1.i386.rpm
> i386/SL/gcc44-c++-4.4.6-3.el5.1.i386.rpm
> i386/SL/gcc44-gfortran-4.4.6-3.el5.1.i386.rpm
> SL/5rolling % ls i386/SL/*-4.4.4-13.el5.*
> i386/SL/libgfortran44-4.4.4-13.el5.i386.rpm
> i386/SL/libgomp-4.4.4-13.el5.i386.rpm
> i386/SL/libstdc++44-devel-4.4.4-13.el5.i386.rpm
>
> I haven't done any systematic check for similar problems.
>
> [...]
The next 5.8 should have this fixed.
>> -----------------------------------------------------------------------------
>> CHANGES from SL 5.7
>> -----------------------------------------------------------------------------
>> - OpenAFS
>>
>>     This version fixes a minor locking bug.
>>
>>        openafs-1.4.14-80.sl5
>>        openafs-authlibs-1.4.14-80.sl5
>>        openafs-authlibs-devel-1.4.14-80.sl5
>>        openafs-client-1.4.14-80.sl5
>>        openafs-compat-1.4.14-80.sl5
>>        openafs-debug-1.4.14-80.sl5
>>        openafs-devel-1.4.14-80.sl5
>>        openafs-kernel-source-1.4.14-80.sl5
>>        openafs-kpasswd-1.4.14-80.sl5
>>        openafs-krb5-1.4.14-80.sl5
>>        openafs-server-1.4.14-80.sl5
>>        kernel-module-openafs-2.6.18-308.1.1.el5-1.4.14-80.1.sl5
>>        kernel-module-openafs-2.6.18-308.1.1.el5PAE-1.4.14-80.1.sl5
>>        kernel-module-openafs-2.6.18-308.1.1.el5xen-1.4.14-80.1.sl5
> These should all be -80.1.sl5 . The 32bit userland packages seem to be at their old version.
The next 5.8 should have this fixed.
>
>> - sl-release
>>
>>     lsb_release -a now reports the same as SL6.
>>     Was $ lsb_release -a ->  ScientificSL
>>     Is  $ lsb_release -a ->  Scientific
>>     Please notify us if this change effects you negatively
> This one doesn't, but
>
> # lsb_release -rs
> 5.rolling
>
> does. Testing would be easier if this returned 5.8 .
>
> [...]
The next 5.8 should have a change in for this.

# lsb_release -rs
5.8.rolling

>
>> -------------------------------------------------------------------------
>> REMOVED compared to Enterprise 5
>> -------------------------------------------------------------------------
>>
>> We have removed the RHN tools as they cannot be used for SL
>>        rhel-instnum
>>        rhn-check
>>        rhn-client-tools
>>        rhnlib
>>        rhnsd
>>        rhn-setup
>>        rhn-setup-gnome
>>        subscription-manager
>>        subscription-manager-firstboot
>>        subscription-manager-gnome
>>        yum-rhn-plugin
> I may be wrong here, but aren't some of those required on Spacewalk clients?
>
Some of these are required for spacewalk clients.  While spacewalk does 
provide a yum repo with these (http://spacewalk.redhat.com/yum/), you're 
right it would be nice to have them right in the tree.

I've put rhn-check, rhn-client-tools, rhnlib rhn-setup, rhn-setup-gnome, 
and yum-rhn-plugin back in for the next 5.8 test release as those are in 
the spacewalk tree.

Pat

-- 
Pat Riehecky
Scientific Linux Developer