Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better red state: one that time out after 20 minutes because of the [Warning signal: 'About to serialize an empty package.']
(like I told in my first mail and like in builds http://build.squeak.org/job/SqueakTrunk/823/ to http://build.squeak.org/job/SqueakTrunk/833/)

So applying Chris' fix and repairing the update-stream was not enough to get rid of it.

The Warning is triggered by #testMcdSerialization

It appears that (self mockDiffyVersion) has no changes...

Though, mockDiffyVersion tries to change: #a toReturn: 'a2'.

Something in this test is not working as intended, but here I'll stop for tonight.

2014-05-25 0:48 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

OK, build.squeak.org, I have to admit, you win... http://build.squeak.org/job/SqueakTrunk/855/console
Ddin't we see this failure already?
Segmentation fault Sun May 25 00:39:10 2014


Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2 [Production ITHB VM]
Built from: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux
plugin path: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776 [default: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]


C stack backtrace:
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]
[0xf57fe40c]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]
[0x473c7848]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]


Smalltalk stack dump:
0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger
2014-05-25 0:06 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
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@gmail.com>:

2014-05-24 22:36 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@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...