Becoming a sponsorer

[Paul Howarth]

Paul F. Johnson wrote:
> Hi,
>  
>> It's not an architecture issue because it builds OK on my x86 box 
>> but fails in mock on the very same x86 box. I thought at first it 
>> was a missing buildreq but I can't think of anything appropriate to 
>> add. So it's probably something to do with the mock environment 
>> itself. Unfortunately the assertion failure is pretty unhelpful in 
>> terms of diagnostics.
> 
> It certainly would point to a mock problem. Which architecture are you try to
> get mock to build it as?

Mock on x86 can only build x86 packages (unlike x64_64).

>>> and change the make install to 
>>>
>>> make DESTDIR=%{buildroot} install
>> Huh? That's what it already is (except with the macro version of 
>> "make" used)
> 
> Just removing the possibility of a macro problem

%{__make} definitely expands to /usr/bin/make so that's not going to be 
the issue.

>>> Mono is a strange beast which (from what I can see) has little respect for
>>> where things should be placed! ;-)
>> Yeah, I noticed.
> 
> I normally work it like this to eliminate problems. Build with /usr/lib set
> statically, do a basic build (%configure and make DESTDIR install without any
> other parameters). If that builds, move it to my x86_64 box and build. If
> that's happy then I try with mock.
> 
> With each build, it's tested to ensure things aren't broken[1].
> 
> Once the builds are happy like that, then I move it to mock.

Not an option for me at the moment as I don't have access to an x86_64 
box running anything later than RHEL3.

> Now, if the build fails (as has happened with monodevelop on quite a few
> occassions), then I start looking at where it fails and check the makefile.

In this case it's failing when running /usr/bin/mcs (whatever that is).

> [1] The problem here is that I tend to have a large number of packages on my
> test system, so I don't always pick up on missing deps (see my submission for
> gtksourceview-sharp)

This is why I do local mock builds, which find missing deps very quickly.

Paul.