[OpenAFS] Fedora & RHEL builds

[Simon Wilkinson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've recently made some improvements to our Fedora / RHEL build =20
system, which I thought I'd share with you all. These put the build =20
system on a more reliable footing - removing all bar one human step =20
from getting new kernel modules out into the world, and increase its =20
capacity for building for more operating systems.

Firstly, I should outline what I'm going to provide. In the stable =20
series, kernel modules will be built for the current and previous =20
release (so we're currently building 1.4.7 and 1.4.8) for all versions =20=

of RHEL newer than 4, and the current and previous 3 Fedora releases =20
(so we're building for RHEL4, RHEL5, and Fedoras 7 thru 10). Where =20
necessary, I'll pick up patches from the OpenAFS CVS to keep the =20
current release building on all of these platforms. I won't, however, =20=

update previous releases - as and when they stop building for a =20
particular architecture, I'll just stop building them (so we have =20
1.4.8 for every platform, but 1.4.7 isn't being built for Fedoras 9 or =20=

10). We're currently building for both i386 and x86_64 platforms.

Secondly, due to popular demand, packages coming out of the build =20
system are now being signed with a GPG key. The details of this key =20
are below. Note that this is intentionally not a personal, or =20
institutional, key. All that the presence of this key indicates is =20
that the package was successfully built on lochranza, and hasn't been =20=

tampered with since it left that system. No personal guarantees are =20
made, or should be implied. The key should be on the keyservers, and =20
has the following key ID and fingerprint:

pub   1024D/C19E4A0A 2008-11-21
       Key fingerprint =3D 7FD2 7090 17A6 457B C146  3B12 14F5 6B3F C19E =
=20
4A0A
uid                  OpenAFS builds from lochranza

Thirdly, the new system builds modules every evening at 17:30 UTC. =20
Copying modules over to the OpenAFS download site is still a manual =20
process, and there may be some latency between builds being generated, =20=

and them being copied and the relevant volumes released. Also, the =20
regeneration of the html distribution pages requires an additional =20
manual step. On many occasions new kernel module RPMs will be =20
available from the repository, but not listed in the distribution =20
pages. Browsing to /afs/grand.central.org/software/openafs/<version>/ =20=

will always let you see the latest RPMs available for your system. =20
Other factors that may cause delays are mirroring of kernel modules, =20
and the fact that we build from the Centos distribution, rather than =20
direct from RHEL. The Centos delay causes particular problems around =20
major and point operating system releases - for example, builds for =20
kernels in RHEL 5.3 will not become available until Centos 5.3 ships, =20=

which may be some weeks afterwards.

Finally, I'm also generating RPMs for the 1.5.x development release. =20
Please let me know if you're interested in using these RPMs to test =20
1.5.x at your site.

Cheers,

Simon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJKy2eqWndc26pXmcRAgVCAKCb7AzGCDlS8RvnNRHZKiygMYPvVACeLSl0
vXNuScaSXuJSLtOUZXS6QG4=3D
=3D9JHZ
-----END PGP SIGNATURE-----