Mike.Sullivan at sun.com wrote:

Hi Mike,

Thanks Mike.  You have been a great help.  It is always nice to know 
what we can expect if builds get error.

Anyway, back to the good news part.  I tried env -i and looks like the 
build has been successful but I get
alot of of these type of errors:

Inconsistencies between pkgdefs and proto area:

Unit   T File Name                      Reloc/Sym name       perm owner group 
inode lnk maj min package(s)
------------------------------------------------------------------------------------------------------------
filea: f 
var/ruby/1.8/gem_home/doc/rubygems-0.9.4/ri/Gem/SourceInfoCache/cdesc-SourceInfoCache.yaml
 -                     644 -     -          0  1  -  -    SUNWruby18r
fileb: f 
var/ruby/1.8/gem_home/doc/rubygems-0.9.4/ri/Gem/SourceInfoCache/cdesc-SourceInfoCache.yaml
 -                     600 -     -          0  1  -  -    proto

Thanks.

colin


> >From sfwnv-discuss-bounces at opensolaris.org Sun Jun 29 21:44:25 2008
>
>   
>> My apology.  It is just a little bothersome.  I guess I am just 
>> wondering whether if we actually make sure that it builds before the 
>> rest of us get on .. like we run regression on them etc. upon upgrading.
>>     
>
> umm, ok.
>
> Before I upgrade the public ones I watch over, I've already built ON and SFW
> and the same bits on my machines (sometimes including the gate machines).
> That's part of the reason that they don't get upgraded quickly.
>
> I used to do builds on them after I upgraded them as well but since
> that just seems to eat up the disk space and cycles that others 
> actually need I don't do that anymore - if you prefer I can certainly
> shut them down for a while on upgrades. That just seems rude to me though,
> as things like this (way old leftover bits) should not generally
> be happening. What usually happens is what probably happened to you
> on zod - you have some variable set that I don't and my build would
> have worked, but yours wouldn't.
>
>   
>> Would you recommend other build systems?
>>     
>
> None that I own, clearly, if you feel I don't maintain them the
> way you'd like (you are of course welcome to take ownership of them :).
> But you don't have to use the public machines, they're there to help
> but if they don't you should use your own. Which is generally safest
> anyway if you can but then you need to keep it up to date as well.
>
>       Mike
>   


Reply via email to