SCIENTIFIC-LINUX-DEVEL Archives

May 2005

SCIENTIFIC-LINUX-DEVEL@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:
Mon, 23 May 2005 09:06:38 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (118 lines)
Hi Stephan,

Stephan Wiesand wrote:
> Hi All,
> 
> I wonder whether there'll be an SL 3.0.5 release now that RHEL3U5 is out?
> 

Yep, we're working on it right now.  We hopefully will have a beta, that 
just has the newer rpm's in it, out sometime this week.  Though we 
probrubly won't release 305 until the first kernel update comes out.

> If so, maybe on this occasion I could sneak in a few more modifications 
> to the openafs packages:
> 

I was going to ask you about openafs this morning.  Looks like you beat 
me to it.

> - switch to upstream release 1.2.13
> 
>   [ I'm about to deploy SL3-based AFS fileservers. 1.2.13 has major
>     bugs fixed on the server side. It also has at least one fix for
>     lockups on SMP clients. We have been using ist for months here
>     on both servers and clients (our pre-SL systems), and it has
>     been very stable. ]
> 
> - enable configure options bitmap_later, bos_restricted_mode, fast_restart
> 
>   [ Again, we want bitmap_later and fast_restart for the fileservers.
>     bos_restricted_mode just adds a little functionality ]
> 

Do the bitmap_later and fast_restart do anything to the clients?

> - add macros for bos_new_config and full_vos_listvol_switch, and enabled
>   them
> 
>   [ Again, just additional options. ]
> 
> - add optional openafs-debug package with additional tools
> 
>   [ Useful for debugging/understanding servers and client behaviour,
>     and in emergencies. Cheap and completely optional. ]
> 

If this is the same as the extra debug stuff we have in 1.3.xx, I've 
noticed that it builds debug stuff also whenever each kernel module is 
built.  It's not a problem, it's just that I never know which one to put 
up.  Do you want the debug rpm from when I build the smp, or the normal 
kernel module?  Or does it really matter?

> 
> I made a source rpm and put it here:
> 
> http://www-zeuthen.desy.de/~wiesand/SL3/openafs-1.2.13-15.15.SL.src.rpm
> 
> or
> 
> /afs/ifh.de/user/w/wiesand/public/www/SL3/openafs-1.2.13-15.15.SL.src.rpm
> 
> It's based on the SRPM from SL3.0.4 (which seems not to be exactly the 
> one used for building the binary packages, but I think I recreated the few
> missing changes).
> 

Thanks.
We'll see how Jarek feels.  He might have a change or two as well.  But 
unless he has some objections, I'll put this in the beta and we'll see 
how it shakes out.

> This is the rest of the changelog, besides what's described above:
> 
> - this spec can now be used with --target ia32e, in which case only the
>   kernel module for this platform will be built

whoo hoo ... thanks.  That really was a pain in the rear.

> - added the livesys & kdump executables to main package
> - updated CellServDB to today's version from grand.central.org

Also thanks.

> - moved wget requirement from main to client package

Good idea.
Though I think the one change we might do is see about getting wget out, 
replaced with a real AFS program.  I know Jarek had some good functions 
but we had already set things up last time.  We'll have to give them 
some testing while we're in beta.

> - introduced a macro for additional afsd options (set -dynroot -fakestat
>   yet)
> - removed packager tag (much credit for this package still belongs to
>   Jarek Polok, but he shouldn't be blamed for my changes ;-)
> - strip "smp" from automatically determined kernel version
> - added versioned build requirements for kernel and kernel-source
> 
> This package was successfully built and is currently running on a few test
> systems under SL 3.0.4 with the latest errata kernel (2.4.21-32.EL), on
> these architectures: i686/UP, i686/SMP, ia32e, x86_64/SMP .
> 
> Any opinions?
> 
> Cheers,
>     Stephan
> 

I'll work on getting it into the beta, unless Jarek has some changes 
before then.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________

ATOM RSS1 RSS2