Re: RFC: Page size on PPC/PPC64 builders

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday 02 March 2008, Tom Lane wrote:
> David Woodhouse <dwmw2@xxxxxxxxxxxxx> writes:
> > I already see people who should know better complaining about how
> > building for PPC is 'painful' -- and that kind of attitude has
> > contributed to the idiocy of letting 'secondary architecture' builds
> > fail _without_ aborting the main build. I don't want to make matters
> > worse by increasing the perception that building for PPC is hard.
>
> I've used many non-Intel arches for long enough to not particularly
> worry about one versus another.  However, it took me darn near two
> months to puzzle out the mysql bug that started this thread, and that
> was way too painful.  The problems I see that we need to work on are:
>
> 1. It's impossible to reproduce the Koji build environment accurately
> without access to PPC64 hardware; widely available stuff like Apple
> Macs isn't PPC64 and won't show page-size-related problems.
>
> 2. There is pitifully little opportunity for Fedora developers to
> get at such hardware.  As far as I've found out, there is exactly
> one PPC64 machine available, its location is documented nowhere
> public (eventually I found out that the magic incantation is "ask
> David Woodhouse"), and it's down at the moment.
>
> 3. It was not at all obvious that the problem stemmed from changing
> the build farm machines' underlying kernels from RHEL4 to RHEL5.
> I wasted a great deal of time on the assumption that I was looking
> for a consequence of a recent rawhide change, when in fact there was
> no such change.
actually they changed from FC-6 to RHEL-5  and it was announced loudly before 
I made the change. FC-6 also had 64KiB pages,   though the builders had been 
yum updated from FC-5 to FC-6  so we may have picked up an artifact from 
that.

> Next time we make a change in the buildfarm's underlying kernels,
> I respectfully suggest that that be treated as forcing a mass
> rebuild, just like we do when there are other toolchain changes.
> If I'd seen the breakage first occur in a context like that, it
> would have been much clearer what to look for.

again in december we said what we were doing.  it involved a 24 hour 
buildsystem outage while we rebuilt all the boxes.

> As for the other points, if we can't provide (and document) the
> ability for developers to test on a secondary arch, that arch
> needs to be removed from Fedora completely.  It's useless to
> expect developers to magically fix things they can't debug.
you are able to do scratch builds on each and every secondary arch.  that's 
one of the requirements that we have.  currently mysql does not build on 
sparc  and i need to file a bug for it.  its failing some tests.   we have 
documentation on how to setup a scratch box for secondary arches and tie it 
into fas so that any fedora user will be able to log in and do mock builds.

Dennis

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux