Stephan Wiesand wrote:
> Hi Troy,
>
> On Wed, 28 Jan 2009, Troy Dawson wrote:
>
>> Dr Andrew C Aitchison wrote:
>>> On Tue, 27 Jan 2009, Troy Dawson wrote:
> [...]
>>>> NOTE: I haven't gotten XFS (the file system) to compile yet for it.
>
> Removing the now conflicting definitions from the xfs header seems correct
> to me. Something like adding
>
> grep -q 'BH_Unwritten' %{kernel_src_path}/include/linux/buffer_head.h && \
> sed -i '/^BUFFER_FNS.*unwritten/d' linux-2.6/xfs_linux.h
>
> to %prep. It's hard to fix it with a patch without breaking builds for
> the older kernels. An SRPM with this hack is
>
> http://www-zeuthen.desy.de/~wiesand/SL5/xfs-0.4-2.sl5.src.rpm
>
> It builds and survives light testing with the new kernel.
>
Thanks Stephan.
I'll give it a try and hopefully we will have something this afternoon.
> [...]
>>>> yum --enablerepo=sl-testing update kernel\*
>>> --> Processing Conflict: kernel conflicts ecryptfs-utils < 44
>>>
>>> (only a problem if ecryptfs-utils is installed ...)
>>>
>> I now have the newer ecryptfs-utils (and ecryptfs-utils-devel) in the testing
>> area.
>
> There's a similar issue with cpuspeed. The new conflict doesn't work
> because they missed that cpuspeed has epoch=1, but things may still break
> if that isn't updated along with the kernel. It probably only affects
> AMD CPUs only.
>
So, the question is. Do we put cpuspeed into the security errata area, or just
leave it at SL 5.3?
From what I read, these AMD CPU's weren't really getting their cpu speed
changed anyway because it was broken before and not really turned on. When
they turned it on, they then found bugs.
The problem is, which fixes the turning it on, and which fixes the new bugs.
Since cpuspeed isn't excluded, I'm a bit nervous to put it out into the
security area.
> Any ETA for 5.3? ;-)
>
Everything compiled very nicely. My hat's off to RedHat for that.
I tried to get the Alpha out yesterday, but the installer isn't cooperating.
For the Alpha, we usually don't do anything with the installer and everything
works. but this time it's giving us some grief. I think it's a combination of
yum, python, and rpm all being changed.
Connie is still on vacation, and she's really the installer expert. I'm going
to poke and prod around and hopefully get something working, but if not, we
won't be able to get the alpha out until next week.
> - Stephan
>
>> You might have to do a "yum --enablerepo=sl-testing clean all" but it should
>> work now.
>> Thanks for testing
>> Troy
>>
>
Oh, I also put the e4fsprogs in the testing area with the kernel. I figured if
we were going to have ext4 in the kernel, we might as well have the programs
that go with it.
Troy
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
