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