Failing tests in trunk, gearing up for 4.4 release
Locked
12
12
Failing tests in trunk, gearing up for 4.4 release
 
|
Hi,
I meant to nag a lot more about the failing tests, and I haven't. Sorry for not being sufficiently annoying! We still have a bunch of failing tests - KernelTests.Chronology.TimeStampTest.testFromSeconds CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting KernelTests.Chronology.TimeStampTest.testReadFromA1 NetworkTests.Kernel.SocketTest.testSendTimeout Tests.Localization.LocaleTest.testLocaleChanged Tests.Monticello.MCFileInTest.testStWriter Tests.Monticello.MCMczInstallerTest.testInstallFromFile Tests.Monticello.MCMczInstallerTest.testInstallFromStream Tests.Release.ReleaseTest.testNoObsoleteClasses Tests.Release.ReleaseTest.testUndeclared - and I'd really like them to be green for a release. The Monticello tests cause noise, and so the ReleaseTests should pass if we don't run the MC tests. The SocketTest is, as I understand it, an issue specific to Linux, and doesn't occur on Window. If I _have_ to, I'll move the tests into "expected failures", and re-enable them when we start work on 4.5. One big gap in our testing infrastructure is testing on non-Linux platforms. I would like a kind soul to take up CI-like duties and commit to run the entire suite on OS X and Windows reasonably often. Any takers? (Ideally we'd have build slaves for this, but...) frank |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 4 September 2012 11:41, Frank Shearar <[hidden email]> wrote:
> Hi, > > I meant to nag a lot more about the failing tests, and I haven't. > Sorry for not being sufficiently annoying! > > We still have a bunch of failing tests - > > KernelTests.Chronology.TimeStampTest.testFromSeconds > CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting > KernelTests.Chronology.TimeStampTest.testReadFromA1 > NetworkTests.Kernel.SocketTest.testSendTimeout > Tests.Localization.LocaleTest.testLocaleChanged > Tests.Monticello.MCFileInTest.testStWriter > Tests.Monticello.MCMczInstallerTest.testInstallFromFile > Tests.Monticello.MCMczInstallerTest.testInstallFromStream > Tests.Release.ReleaseTest.testNoObsoleteClasses > Tests.Release.ReleaseTest.testUndeclared Correction: 11 tests. KernelTests.Numbers.LargeNegativeIntegerTest.testMinimumNegativeIntegerArithmetic fails: http://squeakci.org/job/UpdateFromLastRelease/lastCompletedBuild/testReport/KernelTests.Numbers/LargeNegativeIntegerTest/testMinimumNegativeIntegerArithmetic/ frank > - and I'd really like them to be green for a release. The Monticello > tests cause noise, and so the ReleaseTests should pass if we don't run > the MC tests. The SocketTest is, as I understand it, an issue specific > to Linux, and doesn't occur on Window. > > If I _have_ to, I'll move the tests into "expected failures", and > re-enable them when we start work on 4.5. > > One big gap in our testing infrastructure is testing on non-Linux > platforms. I would like a kind soul to take up CI-like duties and > commit to run the entire suite on OS X and Windows reasonably often. > Any takers? (Ideally we'd have build slaves for this, but...) > > frank |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
On Tue, Sep 04, 2012 at 11:41:50AM +0100, Frank Shearar wrote:
> Hi, > > I meant to nag a lot more about the failing tests, and I haven't. > Sorry for not being sufficiently annoying! > > We still have a bunch of failing tests - > > KernelTests.Chronology.TimeStampTest.testFromSeconds > CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting > KernelTests.Chronology.TimeStampTest.testReadFromA1 > NetworkTests.Kernel.SocketTest.testSendTimeout > Tests.Localization.LocaleTest.testLocaleChanged > Tests.Monticello.MCFileInTest.testStWriter > Tests.Monticello.MCMczInstallerTest.testInstallFromFile > Tests.Monticello.MCMczInstallerTest.testInstallFromStream > Tests.Release.ReleaseTest.testNoObsoleteClasses > Tests.Release.ReleaseTest.testUndeclared > > - and I'd really like them to be green for a release. The Monticello > tests cause noise, and so the ReleaseTests should pass if we don't run > the MC tests. The SocketTest is, as I understand it, an issue specific > to Linux, and doesn't occur on Window. SocketTest>>testSendTimeout fails on my Linux system, although I cannot say if it is a real failure or if it is due to a difference in the way networking functions on unix versus windows. In any case, if it is a real problem, it is certainly not a *new* problem, and it should not stand in the way of an image release. But labeling as an expected failure would not be right, because the test presumably will succeed on many platforms. On my Linux system, I also get a failure on SocketTest.testSocketReuse because it tests for a feature that does not exist on this platform (setting the socket option option 'SO_REUSEPORT'). Apparently this option must be supported on our test platform, but FYI it is likely that other users will see this "failure" when they run the tests. > > If I _have_ to, I'll move the tests into "expected failures", and > re-enable them when we start work on 4.5. > > One big gap in our testing infrastructure is testing on non-Linux > platforms. I would like a kind soul to take up CI-like duties and > commit to run the entire suite on OS X and Windows reasonably often. > Any takers? (Ideally we'd have build slaves for this, but...) > > frank |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
On Tue, Sep 04, 2012 at 11:55:17AM +0100, Frank Shearar wrote:
> On 4 September 2012 11:41, Frank Shearar <[hidden email]> wrote: > > Hi, > > > > I meant to nag a lot more about the failing tests, and I haven't. > > Sorry for not being sufficiently annoying! > > > > We still have a bunch of failing tests - > > > > KernelTests.Chronology.TimeStampTest.testFromSeconds > > CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting > > KernelTests.Chronology.TimeStampTest.testReadFromA1 > > NetworkTests.Kernel.SocketTest.testSendTimeout > > Tests.Localization.LocaleTest.testLocaleChanged > > Tests.Monticello.MCFileInTest.testStWriter > > Tests.Monticello.MCMczInstallerTest.testInstallFromFile > > Tests.Monticello.MCMczInstallerTest.testInstallFromStream > > Tests.Release.ReleaseTest.testNoObsoleteClasses > > Tests.Release.ReleaseTest.testUndeclared > > Correction: 11 tests. > KernelTests.Numbers.LargeNegativeIntegerTest.testMinimumNegativeIntegerArithmetic > fails: http://squeakci.org/job/UpdateFromLastRelease/lastCompletedBuild/testReport/KernelTests.Numbers/LargeNegativeIntegerTest/testMinimumNegativeIntegerArithmetic/ > This is a newly added test that documents a problem in all currently distributed VMs. The problem will not be corrected in time for the next image release. Nicolas Cellier identified the problem and provided a fix for the VM issue, which has been discussed on the vm-dev list. Pointers are at http://bugs.squeak.org/view.php?id=7705. Dave > frank > > > - and I'd really like them to be green for a release. The Monticello > > tests cause noise, and so the ReleaseTests should pass if we don't run > > the MC tests. The SocketTest is, as I understand it, an issue specific > > to Linux, and doesn't occur on Window. > > > > If I _have_ to, I'll move the tests into "expected failures", and > > re-enable them when we start work on 4.5. > > > > One big gap in our testing infrastructure is testing on non-Linux > > platforms. I would like a kind soul to take up CI-like duties and > > commit to run the entire suite on OS X and Windows reasonably often. > > Any takers? (Ideally we'd have build slaves for this, but...) > > > > frank |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 4 September 2012 13:11, David T. Lewis <[hidden email]> wrote:
> On Tue, Sep 04, 2012 at 11:55:17AM +0100, Frank Shearar wrote: >> On 4 September 2012 11:41, Frank Shearar <[hidden email]> wrote: >> > Hi, >> > >> > I meant to nag a lot more about the failing tests, and I haven't. >> > Sorry for not being sufficiently annoying! >> > >> > We still have a bunch of failing tests - >> > >> > KernelTests.Chronology.TimeStampTest.testFromSeconds >> > CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting >> > KernelTests.Chronology.TimeStampTest.testReadFromA1 >> > NetworkTests.Kernel.SocketTest.testSendTimeout >> > Tests.Localization.LocaleTest.testLocaleChanged >> > Tests.Monticello.MCFileInTest.testStWriter >> > Tests.Monticello.MCMczInstallerTest.testInstallFromFile >> > Tests.Monticello.MCMczInstallerTest.testInstallFromStream >> > Tests.Release.ReleaseTest.testNoObsoleteClasses >> > Tests.Release.ReleaseTest.testUndeclared >> >> Correction: 11 tests. >> KernelTests.Numbers.LargeNegativeIntegerTest.testMinimumNegativeIntegerArithmetic >> fails: http://squeakci.org/job/UpdateFromLastRelease/lastCompletedBuild/testReport/KernelTests.Numbers/LargeNegativeIntegerTest/testMinimumNegativeIntegerArithmetic/ >> > > This is a newly added test that documents a problem in all currently > distributed VMs. The problem will not be corrected in time for the > next image release. > > Nicolas Cellier identified the problem and provided a fix for the VM > issue, which has been discussed on the vm-dev list. Pointers are at > http://bugs.squeak.org/view.php?id=7705. Thanks. I knew it was Nicolas' commit without even looking at author initials :) but then I think that for the 4.4 release we should mark it as an expected failure (and mark it as a test requiring addressing in 4.5, at http://wiki.squeak.org/squeak/6188) I suppose I'm semi-asking permission from the community to move these failing tests into expected failures so I can get a green bar. frank > Dave > >> frank >> >> > - and I'd really like them to be green for a release. The Monticello >> > tests cause noise, and so the ReleaseTests should pass if we don't run >> > the MC tests. The SocketTest is, as I understand it, an issue specific >> > to Linux, and doesn't occur on Window. >> > >> > If I _have_ to, I'll move the tests into "expected failures", and >> > re-enable them when we start work on 4.5. >> > >> > One big gap in our testing infrastructure is testing on non-Linux >> > platforms. I would like a kind soul to take up CI-like duties and >> > commit to run the entire suite on OS X and Windows reasonably often. >> > Any takers? (Ideally we'd have build slaves for this, but...) >> > >> > frank > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
On Tue, 4 Sep 2012, Frank Shearar wrote:
> Hi, > > I meant to nag a lot more about the failing tests, and I haven't. > Sorry for not being sufficiently annoying! > > We still have a bunch of failing tests - > > KernelTests.Chronology.TimeStampTest.testFromSeconds It's an issue with the timezones again (UTC vs local). I vaguely recall Chris Muller saying that TimeStamp should be removed or so. > CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting This one should be expected failure since it's testing a non-existing feature. > KernelTests.Chronology.TimeStampTest.testReadFromA1 Same as #testFromSeconds. > NetworkTests.Kernel.SocketTest.testSendTimeout This is something related to the new network code. With Network-ul.136 the likeliness of this happening got a lot lower. I started debugging this when I found that the variable got added back to the image. This doesn't fail in Squeak 4.3 btw. But it fails on windows too in 4.4. > Tests.Localization.LocaleTest.testLocaleChanged This is something related to the GetText integration, should be debugged. > Tests.Monticello.MCFileInTest.testStWriter > Tests.Monticello.MCMczInstallerTest.testInstallFromFile > Tests.Monticello.MCMczInstallerTest.testInstallFromStream Old MC bugs, to be debugged. > Tests.Release.ReleaseTest.testNoObsoleteClasses It's the TestRunner's fault. > Tests.Release.ReleaseTest.testUndeclared We should rewrite this to give more information, it doesn't fail on windows. > > - and I'd really like them to be green for a release. The Monticello > tests cause noise, and so the ReleaseTests should pass if we don't run > the MC tests. The SocketTest is, as I understand it, an issue specific > to Linux, and doesn't occur on Window. > > If I _have_ to, I'll move the tests into "expected failures", and > re-enable them when we start work on 4.5. > > One big gap in our testing infrastructure is testing on non-Linux > platforms. I would like a kind soul to take up CI-like duties and On windows, FileDirectoryTest >> #testRelativeNameIfAbsoluteFor is failing (with an error), because FileDirectory >> #relativeNameIfAbsoluteFor: is assuming that the full path begins with a path delimiter, but this is not true on windows, since the first character is the drive letter there (C:\...). Levente > commit to run the entire suite on OS X and Windows reasonably often. > Any takers? (Ideally we'd have build slaves for this, but...) > > frank > > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 4 September 2012 15:58, Levente Uzonyi <[hidden email]> wrote:
> On Tue, 4 Sep 2012, Frank Shearar wrote: > >> Hi, >> >> I meant to nag a lot more about the failing tests, and I haven't. >> Sorry for not being sufficiently annoying! >> >> We still have a bunch of failing tests - >> >> KernelTests.Chronology.TimeStampTest.testFromSeconds > > > It's an issue with the timezones again (UTC vs local). I vaguely recall > Chris Muller saying that TimeStamp should be removed or so. > >> CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting > > > This one should be expected failure since it's testing a non-existing > feature. > >> KernelTests.Chronology.TimeStampTest.testReadFromA1 > > > Same as #testFromSeconds. > >> NetworkTests.Kernel.SocketTest.testSendTimeout > > > This is something related to the new network code. With Network-ul.136 the > likeliness of this happening got a lot lower. I started debugging this when > I found that the variable got added back to the image. This doesn't fail in > Squeak 4.3 btw. But it fails on windows too in 4.4. > >> Tests.Localization.LocaleTest.testLocaleChanged > > > This is something related to the GetText integration, should be debugged. > >> Tests.Monticello.MCFileInTest.testStWriter >> Tests.Monticello.MCMczInstallerTest.testInstallFromFile >> Tests.Monticello.MCMczInstallerTest.testInstallFromStream > > > Old MC bugs, to be debugged. > >> Tests.Release.ReleaseTest.testNoObsoleteClasses > > > It's the TestRunner's fault. Ah, you'd said last time I nagged that the TestRunner's hanging onto the TestCases that failed that hang onto obsolete classes left over from the MC tests that SHOULD generate obsolete classes, if I recall correctly? I'm not sure I'd pin the blame entirely on TestRunner, but the PROPER thing to do would be to run those kinds of tests - and Browser could do with more tests like this - in a pristine Environment that could be thrown away. In that Environment one could add/remove classes at will without affecting external code. >> Tests.Release.ReleaseTest.testUndeclared > > > We should rewrite this to give more information, it doesn't fail on windows. > > >> >> - and I'd really like them to be green for a release. The Monticello >> tests cause noise, and so the ReleaseTests should pass if we don't run >> the MC tests. The SocketTest is, as I understand it, an issue specific >> to Linux, and doesn't occur on Window. >> >> If I _have_ to, I'll move the tests into "expected failures", and >> re-enable them when we start work on 4.5. >> >> One big gap in our testing infrastructure is testing on non-Linux >> platforms. I would like a kind soul to take up CI-like duties and > > > On windows, FileDirectoryTest >> #testRelativeNameIfAbsoluteFor is failing > (with an error), because FileDirectory >> #relativeNameIfAbsoluteFor: is > assuming that the full path begins with a path delimiter, but this is not > true on windows, since the first character is the drive letter there > (C:\...). Exactly: we can have reasonable confidence that 4.4 runs on Linux, but right now there's no real evidence that it runs properly on _any_ other OS. (Because "but it works on MY machine" isn't really evidence!) frank > Levente > > >> commit to run the entire suite on OS X and Windows reasonably often. >> Any takers? (Ideally we'd have build slaves for this, but...) >> >> frank >> >> > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
Happy to test on FreeBSD. Just set up a box with 9.1 RC1 and Enlightenment WM without Gnome. Just got Squeak working a few minutes ago, in fact. Where do I get a test image? And how do I execute the test suit? I know I did this a few years back ... old age, you know, can't recall any details.
On Tue, Sep 4, 2012 at 12:41 AM, Frank Shearar <[hidden email]> wrote: Hi, -- Gary Dunn Honolulu |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
Hi Gary,
Am 04.09.2012 23:59, schrieb Gary Dunn: > Happy to test on FreeBSD. Just set up a box with 9.1 RC1 and > Enlightenment WM without Gnome. Just got Squeak working a few minutes > ago, in fact. Where do I get a test image? And how do I execute the > test suit? I know I did this a few years back ... old age, you know, > can't recall any details. First step: download the Squeak all in one from Squeak site. From the top menu bar choose "Apps" "Preference browser". In the search field write "update" and change the last part of the "Update Url" from "Squeak..." to trunk. World Menu, "Help", "Update code from Server", have a cup of tea. Remember to punch the necessary holes into the firewall so squeak can act as a server, can't help with this. After Squeak finished the update goto "Tools" in the top Menu bar, select "Test runner", right click (middle click) in both lists, choose "select all" then press "run selected". Cheers, Herbert |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
Hi Everyone,
I had originally emailed Frank saying that I could help out with running the tests on my Mac laptop as well as the Windows desktop I have access to. Seeing as how people were already making a great start on testing for windows I decided to focus on Mac. My initial plan of attack was to do what Herbert suggested above, and simply grab the image, manually update it and run the tests. Then I realized that I might be able to adapt the squeak-ci infrastructure to run on Mac, what with it's Unix userland. So I quickly hacked up something and sent a pull request to Frank. In the meantime I have a directory full of XML results from the tests running and a SqueakDebug.log resulting from a socket exception in the r2585 Cog vm, from Eliot's site. So I guess my question is: What would be most helpful? Should I just run the tests manually and send the results to the squeak-dev mailing list? Does someone want or know where I should upload the directory of result files I get from running the CI process? Can someone point out where I have gone horribly wrong in the CI process by taking a look at my pull request on github? Anyway, I am eager to help and get builds going on both Windows and Mac, but I am unsure of how best to forward my results to the list. Any preferences or guidance would be greatly accepted. Thanks for your time, Jeff G. On Tue, Sep 4, 2012 at 10:29 PM, Herbert König <[hidden email]> wrote: Hi Gary, |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 2012-09-05, at 07:02, Jeff Gonis <[hidden email]> wrote: > Hi Everyone, > > I had originally emailed Frank saying that I could help out with running the tests on my Mac laptop as well as the Windows desktop I have access to. Seeing as how people were already making a great start on testing for windows I decided to focus on Mac. > > My initial plan of attack was to do what Herbert suggested above, and simply grab the image, manually update it and run the tests. Then I realized that I might be able to adapt the squeak-ci infrastructure to run on Mac, what with it's Unix userland. So I quickly hacked up something and sent a pull request to Frank. In the meantime I have a directory full of XML results from the tests running and a SqueakDebug.log resulting from a socket exception in the r2585 Cog vm, from Eliot's site. > > So I guess my question is: What would be most helpful? Should I just run the tests manually and send the results to the squeak-dev mailing list? Does someone want or know where I should upload the directory of result files I get from running the CI process? Can someone point out where I have gone horribly wrong in the CI process by taking a look at my pull request on github? > > Anyway, I am eager to help and get builds going on both Windows and Mac, but I am unsure of how best to forward my results to the list. Any preferences or guidance would be greatly accepted. > > Thanks for your time, > Jeff G. Awesome! Thanks :) - Bert - |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Jeff Gonis-2
On 5 September 2012 06:02, Jeff Gonis <[hidden email]> wrote:
> Hi Everyone, > > I had originally emailed Frank saying that I could help out with running the > tests on my Mac laptop as well as the Windows desktop I have access to. > Seeing as how people were already making a great start on testing for > windows I decided to focus on Mac. > > My initial plan of attack was to do what Herbert suggested above, and simply > grab the image, manually update it and run the tests. Then I realized that > I might be able to adapt the squeak-ci infrastructure to run on Mac, what > with it's Unix userland. So I quickly hacked up something and sent a pull > request to Frank. In the meantime I have a directory full of XML results > from the tests running and a SqueakDebug.log resulting from a socket > exception in the r2585 Cog vm, from Eliot's site. I've merged in the pull request, so if we ever have an OS X build agent hooked up to Jenkins (or anything Hudson-like), the OS X stuff should Just Work(tm). frank > So I guess my question is: What would be most helpful? Should I just run > the tests manually and send the results to the squeak-dev mailing list? > Does someone want or know where I should upload the directory of result > files I get from running the CI process? Can someone point out where I have > gone horribly wrong in the CI process by taking a look at my pull request on > github? > > Anyway, I am eager to help and get builds going on both Windows and Mac, but > I am unsure of how best to forward my results to the list. Any preferences > or guidance would be greatly accepted. > > Thanks for your time, > Jeff G. > > > On Tue, Sep 4, 2012 at 10:29 PM, Herbert König <[hidden email]> > wrote: >> >> Hi Gary, >> >> Am 04.09.2012 23:59, schrieb Gary Dunn: >> >>> Happy to test on FreeBSD. Just set up a box with 9.1 RC1 and >>> Enlightenment WM without Gnome. Just got Squeak working a few minutes ago, >>> in fact. Where do I get a test image? And how do I execute the test suit? I >>> know I did this a few years back ... old age, you know, can't recall any >>> details. >> >> >> First step: >> download the Squeak all in one from Squeak site. From the top menu bar >> choose "Apps" "Preference browser". In the search field write "update" and >> change the last part of the "Update Url" from "Squeak..." to trunk. >> >> World Menu, "Help", "Update code from Server", have a cup of tea. Remember >> to punch the necessary holes into the firewall so squeak can act as a >> server, can't help with this. >> >> After Squeak finished the update goto "Tools" in the top Menu bar, select >> "Test runner", right click (middle click) in both lists, choose "select all" >> then press "run selected". >> >> Cheers, >> >> Herbert >> > > > > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Herbert König
On 5 September 2012 05:29, Herbert König <[hidden email]> wrote:
> Hi Gary, > > Am 04.09.2012 23:59, schrieb Gary Dunn: > >> Happy to test on FreeBSD. Just set up a box with 9.1 RC1 and Enlightenment >> WM without Gnome. Just got Squeak working a few minutes ago, in fact. Where >> do I get a test image? And how do I execute the test suit? I know I did this >> a few years back ... old age, you know, can't recall any details. > > > First step: > download the Squeak all in one from Squeak site. From the top menu bar > choose "Apps" "Preference browser". In the search field write "update" and > change the last part of the "Update Url" from "Squeak..." to trunk. > > World Menu, "Help", "Update code from Server", have a cup of tea. Remember > to punch the necessary holes into the firewall so squeak can act as a > server, can't help with this. Please rather test the image that the CI builds: http://squeakci.org/job/UpdateFromLastRelease/lastSuccessfulBuild/artifact/*zip*/archive.zip This is a clean, no-tests-yet-run, fully up-to-date image, so you (-) don't have time for a cup of tea but (+) also test the precise image that the build server tests. frank > After Squeak finished the update goto "Tools" in the top Menu bar, select > "Test runner", right click (middle click) in both lists, choose "select all" > then press "run selected". > > Cheers, > > Herbert > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
Hi,
Am 05.09.2012 12:38, schrieb Frank Shearar: > On 5 September 2012 05:29, Herbert König <[hidden email]> wrote: > Please rather test the image that the CI builds: > http://squeakci.org/job/UpdateFromLastRelease/lastSuccessfulBuild/artifact/*zip*/archive.zip > This is a clean, no-tests-yet-run, fully up-to-date image, so you (-) > don't have time for a cup of tea but (+) also test the precise image > that the build server tests. frank just downloaded the image in my break and Squeak wouldn't open it ifen after renaming image and changes to a shorter name. Neiter method nor the access via ini file works. Is it a Cog VM image? I'll try again after work. Cheers Herbert |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 5 September 2012 13:29, Herbert König <[hidden email]> wrote:
> Hi, > Am 05.09.2012 12:38, schrieb Frank Shearar: >> >> On 5 September 2012 05:29, Herbert König <[hidden email]> wrote: >> Please rather test the image that the CI builds: >> http://squeakci.org/job/UpdateFromLastRelease/lastSuccessfulBuild/artifact/*zip*/archive.zip >> This is a clean, no-tests-yet-run, fully up-to-date image, so you (-) don't >> have time for a cup of tea but (+) also test the precise image that the >> build server tests. frank > > just downloaded the image in my break and Squeak wouldn't open it ifen after > renaming image and changes to a shorter name. > Neiter method nor the access via ini file works. > > Is it a Cog VM image? Yes, it is a Cog VM. If you clone https://github.com/frankshearar/squeak-ci/ you'll get the VMs used for Linux and OS X. I haven't yet included the Windows VM but can if you want. > I'll try again after work. Thanks! frank > Cheers > > Herbert > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
Hi,
Am 05.09.2012 14:34, schrieb Frank Shearar: > Yes, it is a Cog VM. If you clone > https://github.com/frankshearar/squeak-ci/ you'll get the VMs used for > Linux and OS X. I haven't yet included the Windows VM but can if you > want. >> I'll try again after work. > I never used git (just SVN for some time) so I used the r2545 from Eliot's prebuilt VM's. I run AidaWeb in this image. I will download any Win VM you can provide though. Ok, used the downloaded image, wait was after 17 tests. 17 expected failures, 9 failures, 21 errors, 0 unexpected passes Image saved. Results: http://minus.com/lggUMtsOCsihW Tomorrow is my last workday, then I can respond during working hours. Cheers, Herbert |
Deleted: Test Runner.png (250 bytes)
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 5 September 2012 19:14, Herbert König <[hidden email]> wrote:
> Hi, > > Am 05.09.2012 14:34, schrieb Frank Shearar: > >> Yes, it is a Cog VM. If you clone >> https://github.com/frankshearar/squeak-ci/ you'll get the VMs used for >> Linux and OS X. I haven't yet included the Windows VM but can if you >> want. >>> >>> I'll try again after work. >> >> > I never used git (just SVN for some time) so I used the r2545 from Eliot's > prebuilt VM's. I run AidaWeb in this image. I will download any Win VM you > can provide though. OK. You can download a zip of the repository from https://github.com/frankshearar/squeak-ci/zipball/master, if that's more convenient. I hadn't added the Windows version of Cog, but I'll do so shortly. It's important we try minimise the differences between the different "build agents". (Quotes, because a large chunk of our testing is now being done by volunteers, rather than machines.) > Ok, used the downloaded image, wait was after 17 tests. > 17 expected failures, 9 failures, 21 errors, 0 unexpected passes > Image saved. Results: http://minus.com/lggUMtsOCsihW Those error tests are probably because of that thing Levente mentioned earlier today: you have to mark your machine as being able to act as a server. It's been a long while since I had a Windows box, so I'm unfamiliar with the concept. > Tomorrow is my last workday, then I can respond during working hours. Great! Thanks! frank > Cheers, > > Herbert > > > > |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
On Wed, Sep 5, 2012 at 12:38 AM, Frank Shearar <[hidden email]> wrote:
> On 5 September 2012 05:29, Herbert König <[hidden email]> wrote: >> Hi Gary, >> >> Am 04.09.2012 23:59, schrieb Gary Dunn: >> >>> Happy to test on FreeBSD. Just set up a box with 9.1 RC1 and Enlightenment >>> WM without Gnome. Just got Squeak working a few minutes ago, in fact. Where >>> do I get a test image? And how do I execute the test suit? I know I did this >>> a few years back ... old age, you know, can't recall any details. >> >> >> First step: >> download the Squeak all in one from Squeak site. From the top menu bar >> choose "Apps" "Preference browser". In the search field write "update" and >> change the last part of the "Update Url" from "Squeak..." to trunk. >> >> World Menu, "Help", "Update code from Server", have a cup of tea. Remember >> to punch the necessary holes into the firewall so squeak can act as a >> server, can't help with this. > > Please rather test the image that the CI builds: > http://squeakci.org/job/UpdateFromLastRelease/lastSuccessfulBuild/artifact/*zip*/archive.zip > This is a clean, no-tests-yet-run, fully up-to-date image, so you (-) > don't have time for a cup of tea but (+) also test the precise image > that the build server tests. > > frank Downloaded the zip, unpacked with file-roller, moved image and changes to my images folder, ran the image, ran the tests. Took a really long time for anything to start, I thought it hung. Results: 3221 run, 3162 passes, 19 expected failures, 12 failures, 26 errors, 2 unexpected passes Tried the "Run failures" button, that really did hand the process, had to kill the window. How do I report in more detail what the errors were? For the record: FreeBSD 9.1 RC1 on a Dell Optiplex 745 xorg-7.5.2 enlightenment-0.16.999.65643,2 $ squeak -version 4.4.7-2375 #1 XShm Wed Mar 30 16:50:13 PDT 2011 gcc 4.2.1 FreeBSD freebsd.piumarta.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 [hidden email]:/usr/obj/usr/src/sys/GENERIC i386 plugin path: /usr/local/lib/squeak/4.4.7-2375 [default: /usr/local/lib/squeak/4.4.7-2375/] -- Gary Dunn Honolulu |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
In reply to this post by Frank Shearar-3
Am 05.09.2012 22:46, schrieb Frank Shearar:
> OK. You can download a zip of the repository from > https://github.com/frankshearar/squeak-ci/zipball/master, if that's > more convenient. > Ok I'll look from time to time until I find a Windows VM there. > Those error tests are probably because of that thing Levente mentioned > earlier today: you have to mark your machine as being able to act as a > server. It's been a long while since I had a Windows box, so I'm > unfamiliar with the concept. In Windows if you start a program that listens the firewall pops up and asks if it shall block that application or not. If you allow access, afaik the application is granted full access. So I'm puzzled because I run an Aida Webserver from this directory on this VM and in the firewall I find rules for the croquet.exe of the folder I run the tests in. But the socket tests fail because the socket cannot connect. If in the meantime someone with more knowledge can hint on what to try with the windows firewall, I'll gladly listen, otherwise I'll go searching myself later. If nothing helps I'll take the computer from the network and disable the firewall. I checked under XP in a VM and I don't get the socket test errors. Same procedure, start up a VM with a n image running a web server, grant access through the firewall, start the VM with the new image, run the tests. Off to work maybe someone can shed some light on the Win7 firewall mysteries. Cheers, Herbert |
Re: Failing tests in trunk, gearing up for 4.4 release
|
|
On 9/6/12, Herbert König <[hidden email]> wrote:
> Am 05.09.2012 22:46, schrieb Frank Shearar: >> OK. You can download a zip of the repository from >> https://github.com/frankshearar/squeak-ci/zipball/master, if that's >> more convenient. >> > > Ok I'll look from time to time until I find a Windows VM there. > >> Those error tests are probably because of that thing Levente mentioned >> earlier today: you have to mark your machine as being able to act as a >> server. It's been a long while since I had a Windows box, so I'm >> unfamiliar with the concept. > > In Windows if you start a program that listens the firewall pops up and > asks if it shall block that application or not. If you allow access, > afaik the application is granted full access. So I'm puzzled because I > run an Aida Webserver from this directory on this VM and in the firewall > I find rules for the croquet.exe of the folder I run the tests in. But > the socket tests fail because the socket cannot connect. > > If in the meantime someone with more knowledge can hint on what to try > with the windows firewall, I'll gladly listen, otherwise I'll go > searching myself later. If nothing helps I'll take the computer from the > network and disable the firewall. Frank, Levente and others, Do the tests use the internet or can they be run on a machine disconnected from the internet? If yes it is straightforward to disconnect a MSwindows test machine and disable the firewall completely... I have realized that I have about 6 entries with 'croquet.exe' in my Windows 7 Ultimate Firewall rule set with various things checked and not checked. This is because I just copied the original folder with everything in it (updated image and VM) to run another test. I have realised as well that after starting TestRunner with all tests there is a long pause (I felt several minutes) where nothing seems to go on. This is not good. We need a strategy to create a reproducable http://en.wikipedia.org/wiki/Testbed setup. Second question: Is there another way to post the test results besides a screen copy like Herbert did with his last test ? http://minus.com/lggUMtsOCsihW There might be as well the need to only run part of the tests (e.g. the Kernel Tests on which people currently work) --Hannes > I checked under XP in a VM and I don't get the socket test errors. Same > procedure, start up a VM with a n image running a web server, grant > access through the firewall, start the VM with the new image, run the > tests. > > Off to work maybe someone can shed some light on the Win7 firewall > mysteries. > > Cheers, > > Herbert > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |