First green ball

>
> /var/lib/jenkins
>
> drwxr-xr-x  2 jenkins     jenkins     4096 Aug  1 10:51 updates
> drwxr-xr-x  2 jenkins     jenkins     4096 Feb 29 09:51 userContent
> drwxr-xr-x  5 jenkins     jenkins     4096 Jul 20 12:49 users
> drwxr-xr-x  9 jenkins     jenkins     4096 Feb 29 09:50 war
> drwxr-xr-x  3 teamjenkins teamjenkins 4096 Jul 31 13:04 workspace
> -rw-r--r--  1 jenkins     jenkins        0 Aug  1 15:01 Workspace
> clean-up.log
>
> One of these things is not like the others. One of these things doesn't
> belong.
>
> drwxr-xr-x  2 jenkins jenkins 4096 Aug  1 10:51 updates
> drwxr-xr-x  2 jenkins jenkins 4096 Feb 29 09:51 userContent
> drwxr-xr-x  5 jenkins jenkins 4096 Jul 20 12:49 users
> drwxr-xr-x  9 jenkins jenkins 4096 Feb 29 09:50 war
> drwxr-xr-x  3 jenkins jenkins 4096 Jul 31 13:04 workspace
> -rw-r--r--  1 jenkins jenkins    0 Aug  1 15:01 Workspace clean-up.log
>
>
> Try it now.

> On 1 August 2012 23:28, Chris Cunnington <[hidden email]> wrote:
>>
>> /var/lib/jenkins
>>
>> drwxr-xr-x  2 jenkins     jenkins     4096 Aug  1 10:51 updates
>> drwxr-xr-x  2 jenkins     jenkins     4096 Feb 29 09:51 userContent
>> drwxr-xr-x  5 jenkins     jenkins     4096 Jul 20 12:49 users
>> drwxr-xr-x  9 jenkins     jenkins     4096 Feb 29 09:50 war
>> drwxr-xr-x  3 teamjenkins teamjenkins 4096 Jul 31 13:04 workspace
>> -rw-r--r--  1 jenkins     jenkins        0 Aug  1 15:01 Workspace
>> clean-up.log
>>
>> One of these things is not like the others. One of these things doesn't
>> belong.
>>
>> drwxr-xr-x  2 jenkins jenkins 4096 Aug  1 10:51 updates
>> drwxr-xr-x  2 jenkins jenkins 4096 Feb 29 09:51 userContent
>> drwxr-xr-x  5 jenkins jenkins 4096 Jul 20 12:49 users
>> drwxr-xr-x  9 jenkins jenkins 4096 Feb 29 09:50 war
>> drwxr-xr-x  3 jenkins jenkins 4096 Jul 31 13:04 workspace
>> -rw-r--r--  1 jenkins jenkins    0 Aug  1 15:01 Workspace clean-up.log
>>
>>
>> Try it now.
>
> OK, I think I've worked around the problem... by copying the job.
> Hint: don't put spaces in the job name, because it looks like cog's
> bin/squeak doesn't like spaces. I now have the test image firing up,
> and it fails (rightly) because HDTestReport's not in the image. In
> other words, tests.st must first load this before running the tests
> themselves. Not a trainsmash. Progress, in fact. Can anyone beat me to
> the punch and tell me from which Monticello repo I might grab such a
> class? An Installer script lying around anywhere?
>
> One thing that is screaming out at me is that we need to look at how
> Pharo do their testing. IIRC, they had some really nice handling of
> stdout. Right now I test the build script locally, headful and in the
> foreground, so I can actually see what's happening. I'd really really
> like the image to dump errors/stacktraces/etc. to stdout or stderr as
> appropriate. That would be really really useful for the builds so we
> can see what's actually going on.
>
> I'm happy for someone to say "but here's how you can do it right now!".
>
> frank

> On 2 August 2012 17:23, Frank Shearar <[hidden email]> wrote:
>> On 1 August 2012 23:28, Chris Cunnington <[hidden email]> wrote:
>>>
>>> /var/lib/jenkins
>>>
>>> drwxr-xr-x  2 jenkins     jenkins     4096 Aug  1 10:51 updates
>>> drwxr-xr-x  2 jenkins     jenkins     4096 Feb 29 09:51 userContent
>>> drwxr-xr-x  5 jenkins     jenkins     4096 Jul 20 12:49 users
>>> drwxr-xr-x  9 jenkins     jenkins     4096 Feb 29 09:50 war
>>> drwxr-xr-x  3 teamjenkins teamjenkins 4096 Jul 31 13:04 workspace
>>> -rw-r--r--  1 jenkins     jenkins        0 Aug  1 15:01 Workspace
>>> clean-up.log
>>>
>>> One of these things is not like the others. One of these things doesn't
>>> belong.
>>>
>>> drwxr-xr-x  2 jenkins jenkins 4096 Aug  1 10:51 updates
>>> drwxr-xr-x  2 jenkins jenkins 4096 Feb 29 09:51 userContent
>>> drwxr-xr-x  5 jenkins jenkins 4096 Jul 20 12:49 users
>>> drwxr-xr-x  9 jenkins jenkins 4096 Feb 29 09:50 war
>>> drwxr-xr-x  3 jenkins jenkins 4096 Jul 31 13:04 workspace
>>> -rw-r--r--  1 jenkins jenkins    0 Aug  1 15:01 Workspace clean-up.log
>>>
>>>
>>> Try it now.
>>
>> OK, I think I've worked around the problem... by copying the job.
>> Hint: don't put spaces in the job name, because it looks like cog's
>> bin/squeak doesn't like spaces. I now have the test image firing up,
>> and it fails (rightly) because HDTestReport's not in the image. In
>> other words, tests.st must first load this before running the tests
>> themselves. Not a trainsmash. Progress, in fact. Can anyone beat me to
>> the punch and tell me from which Monticello repo I might grab such a
>> class? An Installer script lying around anywhere?
>>
>> One thing that is screaming out at me is that we need to look at how
>> Pharo do their testing. IIRC, they had some really nice handling of
>> stdout. Right now I test the build script locally, headful and in the
>> foreground, so I can actually see what's happening. I'd really really
>> like the image to dump errors/stacktraces/etc. to stdout or stderr as
>> appropriate. That would be really really useful for the builds so we
>> can see what's actually going on.
>>
>> I'm happy for someone to say "but here's how you can do it right now!".
>>
>> frank
>
> Gah.
>
> (Installer repository: 'http://source.lukas-renggli.ch/hudson')
> install: 'HudsonBuildTools-lr.53'.
>
> Except that it uses Author, a Pharo class.

> On Thu, 2 Aug 2012, Frank Shearar wrote:
>
>> On 2 August 2012 17:23, Frank Shearar <[hidden email]> wrote:
>>>
>>> On 1 August 2012 23:28, Chris Cunnington <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>> /var/lib/jenkins
>>>>
>>>> drwxr-xr-x  2 jenkins     jenkins     4096 Aug  1 10:51 updates
>>>> drwxr-xr-x  2 jenkins     jenkins     4096 Feb 29 09:51 userContent
>>>> drwxr-xr-x  5 jenkins     jenkins     4096 Jul 20 12:49 users
>>>> drwxr-xr-x  9 jenkins     jenkins     4096 Feb 29 09:50 war
>>>> drwxr-xr-x  3 teamjenkins teamjenkins 4096 Jul 31 13:04 workspace
>>>> -rw-r--r--  1 jenkins     jenkins        0 Aug  1 15:01 Workspace
>>>> clean-up.log
>>>>
>>>> One of these things is not like the others. One of these things doesn't
>>>> belong.
>>>>
>>>> drwxr-xr-x  2 jenkins jenkins 4096 Aug  1 10:51 updates
>>>> drwxr-xr-x  2 jenkins jenkins 4096 Feb 29 09:51 userContent
>>>> drwxr-xr-x  5 jenkins jenkins 4096 Jul 20 12:49 users
>>>> drwxr-xr-x  9 jenkins jenkins 4096 Feb 29 09:50 war
>>>> drwxr-xr-x  3 jenkins jenkins 4096 Jul 31 13:04 workspace
>>>> -rw-r--r--  1 jenkins jenkins    0 Aug  1 15:01 Workspace clean-up.log
>>>>
>>>>
>>>> Try it now.
>>>
>>>
>>> OK, I think I've worked around the problem... by copying the job.
>>> Hint: don't put spaces in the job name, because it looks like cog's
>>> bin/squeak doesn't like spaces. I now have the test image firing up,
>>> and it fails (rightly) because HDTestReport's not in the image. In
>>> other words, tests.st must first load this before running the tests
>>> themselves. Not a trainsmash. Progress, in fact. Can anyone beat me to
>>> the punch and tell me from which Monticello repo I might grab such a
>>> class? An Installer script lying around anywhere?
>>>
>>> One thing that is screaming out at me is that we need to look at how
>>> Pharo do their testing. IIRC, they had some really nice handling of
>>> stdout. Right now I test the build script locally, headful and in the
>>> foreground, so I can actually see what's happening. I'd really really
>>> like the image to dump errors/stacktraces/etc. to stdout or stderr as
>>> appropriate. That would be really really useful for the builds so we
>>> can see what's actually going on.
>>>
>>> I'm happy for someone to say "but here's how you can do it right now!".
>>>
>>> frank
>>
>>
>> Gah.
>>
>> (Installer repository: 'http://source.lukas-renggli.ch/hudson')
>> install: 'HudsonBuildTools-lr.53'.
>>
>> Except that it uses Author, a Pharo class.
>
>
> This little change caused trouble so many times already. Maybe it's time to
> consider porting it to Squeak.

> On 2 August 2012 20:50, Levente Uzonyi <[hidden email]> wrote:
> Maybe. I've got Chris Cunnington's de-Authored HudsonBuildTools, and
> now get a more interesting failure:
> http://squeakci.org/job/GitTest/9/console which shows a segfault
> during a CompilerNotifyingTest:
>
> Smalltalk stack dump:
> 0xbf8b9880 I Clipboard>clipboardText 2012164252: a(n) Clipboard
> 0xbf8b98a0 I Clipboard class>clipboardText 2017668068: a(n) Clipboard class
> 0xbf8b98c0 I SmalltalkEditor(Editor)>clipboardText 2034626872: a(n)
> SmalltalkEditor
> 0xbf8b98e8 I SmalltalkEditor(TextEditor)>cut 2034626872: a(n) SmalltalkEditor
> 0xbf8b9910 I CompilerNotifyingTest>enumerateAllSelections 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9928 M CompilerNotifyingTest>testATempShadowingAnotherTemp
> 2033658260: a(n) CompilerNotifyingTest
> 0xbf8b9940 M CompilerNotifyingTest(TestCase)>performTest 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9958 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9974 M BlockClosure>on:do: 2034618632: a(n) BlockClosure
> 0xbf8b999c M [] in CompilerNotifyingTest(TestCase)>timeout:after:
> 2033658260: a(n) CompilerNotifyingTest
> 0xbf8b99bc M BlockClosure>ensure: 2034619948: a(n) BlockClosure
> 0xbf8b99e4 M CompilerNotifyingTest(TestCase)>timeout:after:
> 2033658260: a(n) CompilerNotifyingTest
> 0xbf8b9a04 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9a24 M BlockClosure>ensure: 2034616652: a(n) BlockClosure
> 0xbf8b9a40 M CompilerNotifyingTest(TestCase)>runCase 2033658260: a(n)
> CompilerNotifyingTest
> 0xbf8b9a5c M [] in HDTestReport>runCase: 2033663528: a(n) HDTestReport
>
> I'll go look at VM switches tomorrow, unless you beat me to
> understanding the problem. I'll rerun the test and see if it's
> intermittent; those results will be at
> http://squeakci.org/job/GitTest/9/console
>
> frank
>

> now get a more interesting failure:
> http://squeakci.org/job/GitTest/9/console which shows a segfault
> during a CompilerNotifyingTest:
>
> Smalltalk stack dump:
> 0xbf8b9880 I Clipboard>clipboardText 2012164252: a(n) Clipboard
> 0xbf8b98a0 I Clipboard class>clipboardText 2017668068: a(n) Clipboard class
> 0xbf8b98c0 I SmalltalkEditor(Editor)>clipboardText 2034626872: a(n)
> SmalltalkEditor
> 0xbf8b98e8 I SmalltalkEditor(TextEditor)>cut 2034626872: a(n) SmalltalkEditor
> 0xbf8b9910 I CompilerNotifyingTest>enumerateAllSelections 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9928 M CompilerNotifyingTest>testATempShadowingAnotherTemp
> 2033658260: a(n) CompilerNotifyingTest
> 0xbf8b9940 M CompilerNotifyingTest(TestCase)>performTest 2033658260:
> a(n) CompilerNotifyingTest
> 0xbf8b9958 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
> a(n) CompilerNotifyingTest

> On 02/08/12 5:56 PM, Frank Shearar wrote:
>>
>> now get a more interesting failure:
>> http://squeakci.org/job/GitTest/9/console which shows a segfault
>> during a CompilerNotifyingTest:
>>
>> Smalltalk stack dump:
>> 0xbf8b9880 I Clipboard>clipboardText 2012164252: a(n) Clipboard
>> 0xbf8b98a0 I Clipboard class>clipboardText 2017668068: a(n) Clipboard
>> class
>> 0xbf8b98c0 I SmalltalkEditor(Editor)>clipboardText 2034626872: a(n)
>> SmalltalkEditor
>> 0xbf8b98e8 I SmalltalkEditor(TextEditor)>cut 2034626872: a(n)
>> SmalltalkEditor
>> 0xbf8b9910 I CompilerNotifyingTest>enumerateAllSelections 2033658260:
>> a(n) CompilerNotifyingTest
>> 0xbf8b9928 M CompilerNotifyingTest>testATempShadowingAnotherTemp
>> 2033658260: a(n) CompilerNotifyingTest
>> 0xbf8b9940 M CompilerNotifyingTest(TestCase)>performTest 2033658260:
>> a(n) CompilerNotifyingTest
>> 0xbf8b9958 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
>> a(n) CompilerNotifyingTest
>
>
> I would disable the running of CompilerNotifyingTest, by changing your
> "tests.st". I've had trouble with an image running remotely on a Ubuntu
> server - when I simply paste text into the image (via VNC), the VM
> immediately exits. I've never looked further into it, because I was mainly
> trying to debug some other problem over VNC (i.e. I avoided doing a paste,
> while debugging).
>
> Another sanity check you can do in general is to download the workspace, and
> run it locally, to make sure it runs as expected. In fact, that's usually
> step two of my usual build debugging process. Step one is to run the build
> again - sometimes, the build happens to run, just when someone is in the
> middle of uploading a set of changed packages. (I been down that road a few
> times, where I debugged for an hour, to find a bug in the code, then
> eventually discover the fix in a newer package that was uploaded around the
> time of build).

> On 3 August 2012 03:14, Yanni Chiu <[hidden email]> wrote:
>> On 02/08/12 5:56 PM, Frank Shearar wrote:
>>>
>>> now get a more interesting failure:
>>> http://squeakci.org/job/GitTest/9/console which shows a segfault
>>> during a CompilerNotifyingTest:
>>>
>>> Smalltalk stack dump:
>>> 0xbf8b9880 I Clipboard>clipboardText 2012164252: a(n) Clipboard
>>> 0xbf8b98a0 I Clipboard class>clipboardText 2017668068: a(n) Clipboard
>>> class
>>> 0xbf8b98c0 I SmalltalkEditor(Editor)>clipboardText 2034626872: a(n)
>>> SmalltalkEditor
>>> 0xbf8b98e8 I SmalltalkEditor(TextEditor)>cut 2034626872: a(n)
>>> SmalltalkEditor
>>> 0xbf8b9910 I CompilerNotifyingTest>enumerateAllSelections 2033658260:
>>> a(n) CompilerNotifyingTest
>>> 0xbf8b9928 M CompilerNotifyingTest>testATempShadowingAnotherTemp
>>> 2033658260: a(n) CompilerNotifyingTest
>>> 0xbf8b9940 M CompilerNotifyingTest(TestCase)>performTest 2033658260:
>>> a(n) CompilerNotifyingTest
>>> 0xbf8b9958 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
>>> a(n) CompilerNotifyingTest
>>
>>
>> I would disable the running of CompilerNotifyingTest, by changing your
>> "tests.st". I've had trouble with an image running remotely on a Ubuntu
>> server - when I simply paste text into the image (via VNC), the VM
>> immediately exits. I've never looked further into it, because I was mainly
>> trying to debug some other problem over VNC (i.e. I avoided doing a paste,
>> while debugging).
>>
>> Another sanity check you can do in general is to download the workspace, and
>> run it locally, to make sure it runs as expected. In fact, that's usually
>> step two of my usual build debugging process. Step one is to run the build
>> again - sometimes, the build happens to run, just when someone is in the
>> middle of uploading a set of changed packages. (I been down that road a few
>> times, where I debugged for an hour, to find a bug in the code, then
>> eventually discover the fix in a newer package that was uploaded around the
>> time of build).
>
> I was going to do Chris' extreme, and run just VersionNumber, but yes:
> both you and Chris have given sound advice and will confirm that
> everything ELSE is working. I'm reasonably sure I've broken the back
> of setting up the _CI_ part. And then we can bisect until we find a
> problem package, and figure out things further. It might be as simple
> as needing to say -no-sound or whatever that particular switch is
> called.
>
> Another round in the CI Olympics!

> On 3 August 2012 07:23, Frank Shearar <[hidden email]> wrote:
>> On 3 August 2012 03:14, Yanni Chiu <[hidden email]> wrote:
>>> On 02/08/12 5:56 PM, Frank Shearar wrote:
>>>>
>>>> now get a more interesting failure:
>>>> http://squeakci.org/job/GitTest/9/console which shows a segfault
>>>> during a CompilerNotifyingTest:
>>>>
>>>> Smalltalk stack dump:
>>>> 0xbf8b9880 I Clipboard>clipboardText 2012164252: a(n) Clipboard
>>>> 0xbf8b98a0 I Clipboard class>clipboardText 2017668068: a(n) Clipboard
>>>> class
>>>> 0xbf8b98c0 I SmalltalkEditor(Editor)>clipboardText 2034626872: a(n)
>>>> SmalltalkEditor
>>>> 0xbf8b98e8 I SmalltalkEditor(TextEditor)>cut 2034626872: a(n)
>>>> SmalltalkEditor
>>>> 0xbf8b9910 I CompilerNotifyingTest>enumerateAllSelections 2033658260:
>>>> a(n) CompilerNotifyingTest
>>>> 0xbf8b9928 M CompilerNotifyingTest>testATempShadowingAnotherTemp
>>>> 2033658260: a(n) CompilerNotifyingTest
>>>> 0xbf8b9940 M CompilerNotifyingTest(TestCase)>performTest 2033658260:
>>>> a(n) CompilerNotifyingTest
>>>> 0xbf8b9958 M [] in CompilerNotifyingTest(TestCase)>runCase 2033658260:
>>>> a(n) CompilerNotifyingTest
>>>
>>>
>>> I would disable the running of CompilerNotifyingTest, by changing your
>>> "tests.st". I've had trouble with an image running remotely on a Ubuntu
>>> server - when I simply paste text into the image (via VNC), the VM
>>> immediately exits. I've never looked further into it, because I was mainly
>>> trying to debug some other problem over VNC (i.e. I avoided doing a paste,
>>> while debugging).
>>>
>>> Another sanity check you can do in general is to download the workspace, and
>>> run it locally, to make sure it runs as expected. In fact, that's usually
>>> step two of my usual build debugging process. Step one is to run the build
>>> again - sometimes, the build happens to run, just when someone is in the
>>> middle of uploading a set of changed packages. (I been down that road a few
>>> times, where I debugged for an hour, to find a bug in the code, then
>>> eventually discover the fix in a newer package that was uploaded around the
>>> time of build).
>>
>> I was going to do Chris' extreme, and run just VersionNumber, but yes:
>> both you and Chris have given sound advice and will confirm that
>> everything ELSE is working. I'm reasonably sure I've broken the back
>> of setting up the _CI_ part. And then we can bisect until we find a
>> problem package, and figure out things further. It might be as simple
>> as needing to say -no-sound or whatever that particular switch is
>> called.
>>
>> Another round in the CI Olympics!
>
> OK, that was quick. Yes, the CI part of things works just fine:
> http://www.squeakci.org/job/GitTest/11/console. Yes, the Compiler
> tests are breaking things:
> http://www.squeakci.org/job/GitTest/12/console

> On 3 August 2012 10:57, Frank Shearar <[hidden email]> wrote:
> Right. -vm-sound-null is what I was looking for. It seems to let the
> Compiler tests run!: http://www.squeakci.org/job/GitTest/13/console
>
> The crash comes because, I think, something's going "beep" during
> compilation/decompilation of something or other.
>
> This - http://www.squeakci.org/job/GitTest/13/testReport/? - shows the
> Compiler tests running, some of which are failing. That's probably
> because this is a dated image, #11925.
>
> Progress!
>
> frank