Ah, no, the build is still failing!
Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem
with:

MCClassDefinition>>createClass

I encountered this one while updating some of my old trunk images.
The definition changed in Monticello-cwp.589:
+                       inEnvironment: (CurrentEnvironment signal ifNil:
[superClass environment])
-                       inEnvironment: (EnvironmentRequest signal ifNil:
[superClass environment])

But there is no EnvironmentRequest anymore when loading this definition, so
we signal nil, and the load fails.
We would have expected this, it's just be renamed in:

Environments-cwp.47
Time: 22 March 2014, 7:53:17.666 pm
Rename EnvironmentRequest to CurrentEnvironment and use it to implement
Environment class>>current.

To be safe, the rename should have been performed in two stages:
1) create the new class and migrate customers from the old to the new one.
2) remove the old one
It would thus have required two updates.mcm and not a single one
(MC lacks a semantic #rename: so it does not work like in-image-tools)
Unfortunately, update-cwp.48 did perform the two operations at once...

Curiously, if I take an artefact from build server and update, the upgrade
is then processing fine... Don't ask why.
Since no one complained, I told to myself that it was me not following the
standard process, I patched my images manually and restarted the upgrade.
But I now see that it's not just me, there is a CI machine too using Squeak
trunk (anyone else???)

I have to cheat again with mcm surgery:
- publish an Environments-nice.47 that adds the CurrentEnvironment, but not
removes EnvironmentRequest
- patch update-cwp.48 to point to Environments-nice.47 rather than
Environments-cwp.47
That'll be in a few minutes...


2014-05-24 22:58 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
> Hi,
>> it seems that most of the builds are red for 2 months.
>> I checked the last artefact for squeak trunk:
>> http://build.squeak.org/job/SqueakTrunk/853/
>>
>> It's still blocked with the [Warning signal: 'About to serialize an
>> empty package.']
>> With this warning, a test never time out (I don't know why exactly, but
>> it seems that theProcess monitored by the timeout watchdog is already
>> suspended by the Warning)
>> As a result, the tests do never complete and are aborted after 20
>> minutes...
>>
>> Chris has fixed the problem since, but it seems that the CI does not
>> upload latest trunk.
>> Why?
>> It seems to be the same problem as the TestRunner: updating triggers the
>> same [Warning signal: 'About to serialize an empty package.']
>> Ah Chris, it's irony that it's you who precisely keep on fighting modal
>> UI ;)
>>
>> Now the question: how do we escape from this situation?
>> Shall I cheat and modify the update that is blocking?
>>
>>
>> So I decided to cheat:
> I brought update-eem.279 to the surgery block and reverted
> CommandLine-fbs.3 -> CommandLine-fbs.2
> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,
> but before it had a chance to load, it precisely triggered this Warning!!!
> Since this update is also bringing Chris fix, let's defer
> CommandLine-fbs.3 to next update (eem-280) and cross fingers...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140525/55f38969/attachment.htm