Ah, my fault, I was using an obsolete MCM location:

MCMcmUpdater updateFromRepositories: #(
		'http://squeaksource.com/MCUpdateTest'
	).

I guess it did work so long because I updated frequently...
I retried successfully with:

MCMcmUpdater updateFromRepositories: #(
		'http://source.squeak.org/trunk'
	).

Thanks

Nicolas

2009/9/10 Andreas Raab <andreas.raab at gmx.de>:
> Nicolas Cellier wrote:
>>
>> I guess the order of loading matters...
>> Behavior might differ whether you update every day or every few weeks...
>> Doesn't this require an intermediate configuration map?
>
> No, there is something strange in your image. From the debug log it is clear
> that the failure is in Parser>>method:context:encoder: sending #new to nil.
> The only send to #new in that method is the very first line saying:
>
>        properties := AdditionalMethodState new.
>
> So for some reason AdditionalMethodState must be undefined in your image.
> And that is *very* odd since AdditionalMethodState is defined way earlier
> (in Kernel-eem.242 loaded via update-ar.14.mcm) than the
> Parser>>method:context:encoder: (in Compiler-eem.79 loaded via
> update-ar.15.mcm). So the load order should be precisely:
>
> * update-ar.14: Loads Kernel-eem.242 introducing AdditionalMethodState
> * update-ar.15: Loads Compiler-eem.79 using AdditionalMethodState
> * update-ar.16: Loads Compiler-ar.81 recompiling everything
>
> Can you try updating again to see if this may have been an intermittant
> problem (keeping an eye on the transcript to see if there are any server
> timeout messages etc). If you still get the problem, can you try loading the
> update MCMs manually to see if this makes any difference?
>
> Thanks,
>  - Andreas
>
>
>