6 tests to go...
Locked
12
12
 
|
We're down to 6 failing unit tests on the Linux platform, one of which
is an expected failure and another of which is a known network issue for the Linux platform. Would my kind Windows and OSX build volunteers please run builds against the latest trunk image? (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) Note the new URL: that's thanks to Chris Cunnington, who has kindly moved Jenkins to its new home. That will no doubt shortly become the new squeakci.org. Windows users note please that you'll need to grant permission for the build executables etc to act as servers and to make connections: you can do this through the Windows Firewall configuration screens. (I'd give more detailed instructions, but my Windows machines are far away right now.) (Dale, this shouldn't affect you much, in the sense that you won't need any changes to builderCI or whatever once the DNS changes have been made. So if they _do_ affect you, they shouldn't affect you for very long.) It's about time I started with the more admin-y side of the release, making a Changelog and such. I'll make a start on this soon, docs/progress to be on http://wiki.squeak.org/squeak/6188 frank |
|
|
Hi Frank,
I made a stab at getting the new image to run on my OS X server, but the link below doesn't seem to do anything in a regular browser, or when I paste it into the update-image.st script as the update source. I'm probably completely misunderstanding what I should be doing... Can you give me a bigger hint? :). BTW, your message fell prey to my Postini spam filter, so it got delayed a day or so, until I spotted it in the quarantine summary. I've put your address and squeak-dev on my Postini approved list, so it shouldn't happen again. On 12/10/22 12:21, Frank Shearar wrote: > We're down to 6 failing unit tests on the Linux platform, one of which > is an expected failure and another of which is a known network issue > for the Linux platform. > > Would my kind Windows and OSX build volunteers please run builds > against the latest trunk image? > (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) > > Note the new URL: that's thanks to Chris Cunnington, who has kindly > moved Jenkins to its new home. That will no doubt shortly become the > new squeakci.org. > > Windows users note please that you'll need to grant permission for the > build executables etc to act as servers and to make connections: you > can do this through the Windows Firewall configuration screens. (I'd > give more detailed instructions, but my Windows machines are far away > right now.) > > (Dale, this shouldn't affect you much, in the sense that you won't > need any changes to builderCI or whatever once the DNS changes have > been made. So if they _do_ affect you, they shouldn't affect you for > very long.) > > It's about time I started with the more admin-y side of the release, > making a Changelog and such. I'll make a start on this soon, > docs/progress to be on http://wiki.squeak.org/squeak/6188 > > frank > > -- Tom Rushworth |
|
|
Hi Frank,
I return home tonight and I will have my Mac available to me at that point. I will run the tests and post my results to the list. I could also run them on my linux machine as well and post those results if no one has beat me to it. Jeff On Tue, Oct 23, 2012 at 10:34 AM, Tom Rushworth <[hidden email]> wrote: Hi Frank, |
|
|
In reply to this post by Tom Rushworth-2
On 23 October 2012 17:34, Tom Rushworth <[hidden email]> wrote:
> Hi Frank, > > I made a stab at getting the new image to run on my OS X server, but the > link below doesn't seem to do anything in a regular browser, or when I > paste it into the update-image.st script as the update source. > > I'm probably completely misunderstanding what I should be doing... > Can you give me a bigger hint? :). Right. This is the second time we've seen this. There's _supposed_ to be a zip there for you to download. Chris Cunnington (I'm not saying that with my Dad Voice; there are just lots of people sharing your name on the list), did you do anything to the build server? It looks like all the build history for SqueakTrunk just vanished. frank > BTW, your message fell prey to my Postini spam filter, so it got delayed > a day or so, until I spotted it in the quarantine summary. I've put > your address and squeak-dev on my Postini approved list, so it shouldn't > happen again. > > On 12/10/22 12:21, Frank Shearar wrote: >> We're down to 6 failing unit tests on the Linux platform, one of which >> is an expected failure and another of which is a known network issue >> for the Linux platform. >> >> Would my kind Windows and OSX build volunteers please run builds >> against the latest trunk image? >> (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) >> >> Note the new URL: that's thanks to Chris Cunnington, who has kindly >> moved Jenkins to its new home. That will no doubt shortly become the >> new squeakci.org. >> >> Windows users note please that you'll need to grant permission for the >> build executables etc to act as servers and to make connections: you >> can do this through the Windows Firewall configuration screens. (I'd >> give more detailed instructions, but my Windows machines are far away >> right now.) >> >> (Dale, this shouldn't affect you much, in the sense that you won't >> need any changes to builderCI or whatever once the DNS changes have >> been made. So if they _do_ affect you, they shouldn't affect you for >> very long.) >> >> It's about time I started with the more admin-y side of the release, >> making a Changelog and such. I'll make a start on this soon, >> docs/progress to be on http://wiki.squeak.org/squeak/6188 >> >> frank >> >> > > > -- > Tom Rushworth > |
|
|
On 12-10-23 1:15 PM, Frank Shearar wrote:
> On 23 October 2012 17:34, Tom Rushworth <[hidden email]> wrote: >> Hi Frank, >> >> I made a stab at getting the new image to run on my OS X server, but the >> link below doesn't seem to do anything in a regular browser, or when I >> paste it into the update-image.st script as the update source. >> >> I'm probably completely misunderstanding what I should be doing... >> Can you give me a bigger hint? :). > Right. This is the second time we've seen this. There's _supposed_ to > be a zip there for you to download. > > Chris Cunnington (I'm not saying that with my Dad Voice; there are > just lots of people sharing your name on the list), did you do > anything to the build server? It looks like all the build history for > SqueakTrunk just vanished. > > frank The completed build you're saying missing is #17. Remember when I said yesterday that I had a completed build called #16 and that it just... disappeared. Seems to have happened again. I have no idea why. I logged in and hit Build Now and that created #17. I just did that again. I expect build #18 should be along presently. Why does this happen? I have no idea. Chris |
|
|
In reply to this post by Frank Shearar-3
On 12-10-23 1:15 PM, Frank Shearar wrote:
> On 23 October 2012 17:34, Tom Rushworth <[hidden email]> wrote: >> Hi Frank, >> >> I made a stab at getting the new image to run on my OS X server, but the >> link below doesn't seem to do anything in a regular browser, or when I >> paste it into the update-image.st script as the update source. >> >> I'm probably completely misunderstanding what I should be doing... >> Can you give me a bigger hint? :). > Right. This is the second time we've seen this. There's _supposed_ to > be a zip there for you to download. > > Chris Cunnington (I'm not saying that with my Dad Voice; there are > just lots of people sharing your name on the list), did you do > anything to the build server? It looks like all the build history for > SqueakTrunk just vanished. > > frank Oh, and this is likely easier to use: http://www.squeakci.org Chris |
Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
I think I can sketch out a few details. 1. The first thing is that this is not a medical emergency. I'm saying that for my own peace of mind. System administration under duress is no fun at all. 2. The builds are still there. They don't disappear. They just aren't seen by the webpage. We are not alone in this. It has happened before. http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html 3. The problem may be in the reading of an XML file. The solution I've gleaned so far is that instead of creating another build, I could log in and press: "Reload Configuration from Disk" Or I could just try restarting. 4. This didn't happen on the older server. It won't last forever on this one. 5. God knows, somebody will come up with a better answer than I can. But since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is." Chris |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
Hi, Chris..
Just wanna add own 2 cents: yes, Jenkins quality remains to be an issue. We also experiencing problems with it time to time. I wonder if there any better alternatives.. >From other side, jenkins provides a rich set of features (many from plugins), which would be hard to match if one would start writing it from scratch. On 23 October 2012 20:00, Chris Cunnington <[hidden email]> wrote: > > I think I can sketch out a few details. > > 1. The first thing is that this is not a medical emergency. I'm saying that > for my own peace of mind. System administration under duress is no fun at > all. > > 2. The builds are still there. They don't disappear. They just aren't seen > by the webpage. We are not alone in this. It has happened before. > > http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html > > 3. The problem may be in the reading of an XML file. The solution I've > gleaned so far is that instead of creating another build, I could log in and > press: > > "Reload Configuration from Disk" > > Or I could just try restarting. > > 4. This didn't happen on the older server. It won't last forever on this > one. > > 5. God knows, somebody will come up with a better answer than I can. But > since you're all looking at me at this moment, I say this: "Don't panic. We > still know where our towel is." > > > Chris > > > -- Best regards, Igor Stasenko. |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
On 12-10-23 2:29 PM, Igor Stasenko wrote:
> Hi, Chris.. > > Just wanna add own 2 cents: > > yes, Jenkins quality remains to be an issue. > We also experiencing problems with it time to time. > > I wonder if there any better alternatives.. > >From other side, jenkins provides a rich set of features (many from plugins), > which would be hard to match if one would start writing it from scratch. I was just asking my self: "Do they have this problem at INRIA Lille? They have such a large collection of Jenkins jobs..." And so, it is nice of you to say that it happens sometimes at your site as well. Thanks for that. I figure this stuff will iron itself out over time. Chris |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
In reply to this post by Chris Cunnington
On 23 October 2012 19:00, Chris Cunnington
<[hidden email]> wrote: > > I think I can sketch out a few details. > > 1. The first thing is that this is not a medical emergency. I'm saying that > for my own peace of mind. System administration under duress is no fun at > all. Ideally one shouldn't do system adminstration when feeling under pressure :) > 2. The builds are still there. They don't disappear. They just aren't seen > by the webpage. We are not alone in this. It has happened before. > > http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html > > 3. The problem may be in the reading of an XML file. The solution I've > gleaned so far is that instead of creating another build, I could log in and > press: > > "Reload Configuration from Disk" > > Or I could just try restarting. > > 4. This didn't happen on the older server. It won't last forever on this > one. > > 5. God knows, somebody will come up with a better answer than I can. But > since you're all looking at me at this moment, I say this: "Don't panic. We > still know where our towel is." Not panicking. At least, not yet :) frank > Chris > > > |
|
|
In reply to this post by Chris Cunnington
It's time for our podcast recording session on Skype... -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS) |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
In reply to this post by Frank Shearar-3
Hi,
It's reliable enough that I did get a zip of the workspace contents :). I'll give them a go on OS X server in another 6 hours or so, I'm out of time right now. Thanks to both of you for your efforts on our behalf! On 12/10/23 12:19, Frank Shearar wrote: > On 23 October 2012 19:00, Chris Cunnington > <[hidden email]> wrote: >> >> I think I can sketch out a few details. [snip of a bunch of admin discussion] > > frank > >> Chris >> Regards, -- Tom Rushworth |
Re: 6 tests to go... Win7 results
|
|
In reply to this post by Frank Shearar-3
Hi,
> We're down to 6 failing unit tests on the Linux platform, one of which > is an expected failure and another of which is a known network issue > for the Linux platform. > > Would my kind Windows and OSX build volunteers please run builds > against the latest trunk image? > (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) > Yesterday (Oct 22) I could download build #17 and got a TrunkImage.image and .changes. Not the usual zip including the VM. This is update 12251 according to the system reporter. I disable IPV6 support via preferences and run all tests in the Cog VM I used for the previous tests. See http://minus.com/luZyqW2PRhIrq. I get 3222 run, 3178 passes, 18 expected failures, 5 failures, 21 errors, 0 unexpected passes, as if the network preference is ignored again. See http://minus.com/lpibYAKEi3bw5 I did this twice, as I didn't want to believe it. If I update this image to trunk, it loads some updates and again claims to be 12251 version. Tests like before result in 3219 run, 3195 passes, 18 expected failures, 5 failures, 1 errors, 0 unexpected passes. See: http://minus.com/l17FSZY5yOnhH I have no idea but I still have that image if someone wants it. http://minus.com/mbam1m6GnSJJJH is the complete Folder with the screenshots of all runs I published up to now. Cheers Herbert |
|
|
In reply to this post by Chris Cunnington
On 23 October 2012 18:21, Chris Cunnington
<[hidden email]> wrote: > On 12-10-23 1:15 PM, Frank Shearar wrote: >> >> On 23 October 2012 17:34, Tom Rushworth <[hidden email]> wrote: >>> >>> Hi Frank, >>> >>> I made a stab at getting the new image to run on my OS X server, but the >>> link below doesn't seem to do anything in a regular browser, or when I >>> paste it into the update-image.st script as the update source. >>> >>> I'm probably completely misunderstanding what I should be doing... >>> Can you give me a bigger hint? :). >> >> Right. This is the second time we've seen this. There's _supposed_ to >> be a zip there for you to download. >> >> Chris Cunnington (I'm not saying that with my Dad Voice; there are >> just lots of people sharing your name on the list), did you do >> anything to the build server? It looks like all the build history for >> SqueakTrunk just vanished. >> >> frank > > > Oh, and this is likely easier to use: > > http://www.squeakci.org Yay! frank > Chris > > |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
In reply to this post by Chris Cunnington
Isn't the issue simply that Jenkins is looking for the workspace at the
wrong place? When we first set up our Jenkins instance it created the workspace directory at a different place than what the documentation[1] says. There was a workspace directory in the JENKINS_HOME directory with subdirectories for each job IIRC. After the first restart it was looking for the workspace directory at the place suggested by the documentation, so our jobs "disappeared". We fixed the directory structure by hand and everything is fine since then. Levente [1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins On Tue, 23 Oct 2012, Chris Cunnington wrote: > > I think I can sketch out a few details. > > 1. The first thing is that this is not a medical emergency. I'm saying that for my own peace of mind. System administration under duress is no fun at all. > > 2. The builds are still there. They don't disappear. They just aren't seen by the webpage. We are not alone in this. It has happened before. > > http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html > > 3. The problem may be in the reading of an XML file. The solution I've gleaned so far is that instead of creating another build, I could log in and press: > > "Reload Configuration from Disk" > > Or I could just try restarting. > > 4. This didn't happen on the older server. It won't last forever on this one. > > 5. God knows, somebody will come up with a better answer than I can. But since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is." > > > Chris > > |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
On 12-10-23 6:43 PM, Levente Uzonyi wrote:
> Isn't the issue simply that Jenkins is looking for the workspace at > the wrong place? When we first set up our Jenkins instance it created > the workspace directory at a different place than what the > documentation[1] says. There was a workspace directory in the > JENKINS_HOME directory with subdirectories for each job IIRC. After > the first restart it was looking for the workspace directory at the > place suggested by the documentation, so our jobs "disappeared". We > fixed the directory structure by hand and everything is fine since then. > > > Levente > > [1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins > Chris |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
In reply to this post by Levente Uzonyi-2
Err, no.
A "workspace" is where slave doing its work. But artifacts made by job(s) are stored in separate place. By analogy to real life: you have a workshop where you produce things, and storage where you put them after. On 24 October 2012 00:43, Levente Uzonyi <[hidden email]> wrote: > Isn't the issue simply that Jenkins is looking for the workspace at the > wrong place? When we first set up our Jenkins instance it created the > workspace directory at a different place than what the documentation[1] > says. There was a workspace directory in the JENKINS_HOME directory with > subdirectories for each job IIRC. After the first restart it was looking for > the workspace directory at the place suggested by the documentation, so our > jobs "disappeared". We fixed the directory structure by hand and everything > is fine since then. > > > Levente > > [1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins > > > On Tue, 23 Oct 2012, Chris Cunnington wrote: > >> >> I think I can sketch out a few details. >> >> 1. The first thing is that this is not a medical emergency. I'm saying >> that for my own peace of mind. System administration under duress is no fun >> at all. >> >> 2. The builds are still there. They don't disappear. They just aren't seen >> by the webpage. We are not alone in this. It has happened before. >> >> >> http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html >> >> 3. The problem may be in the reading of an XML file. The solution I've >> gleaned so far is that instead of creating another build, I could log in and >> press: >> >> "Reload Configuration from Disk" >> >> Or I could just try restarting. >> >> 4. This didn't happen on the older server. It won't last forever on this >> one. >> >> 5. God knows, somebody will come up with a better answer than I can. But >> since you're all looking at me at this moment, I say this: "Don't panic. We >> still know where our towel is." >> >> >> Chris >> > > > -- Best regards, Igor Stasenko. |
Re: 6 tests to go... Win7 results
|
|
In reply to this post by Herbert König
On 23 October 2012 21:25, Herbert König <[hidden email]> wrote:
> Hi, >> >> We're down to 6 failing unit tests on the Linux platform, one of which >> is an expected failure and another of which is a known network issue >> for the Linux platform. >> >> Would my kind Windows and OSX build volunteers please run builds >> against the latest trunk image? >> (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) >> > Yesterday (Oct 22) I could download build #17 and got a TrunkImage.image and > .changes. Not the usual zip including the VM. The VM comes from the repository at https://github.com/frankshearar/squeak-ci. In particular, you can get a copy directly from here: https://github.com/frankshearar/squeak-ci/zipball/master Sorry, I thought I'd only need to mention the image location. > This is update 12251 according to the system reporter. I disable IPV6 > support via preferences and run all tests in the Cog VM I used for the > previous tests. See http://minus.com/luZyqW2PRhIrq. > > I get 3222 run, 3178 passes, 18 expected failures, 5 failures, 21 errors, 0 > unexpected passes, as if the network preference is ignored again. > See http://minus.com/lpibYAKEi3bw5 > I did this twice, as I didn't want to believe it. > > If I update this image to trunk, it loads some updates and again claims to > be 12251 version. > Tests like before result in 3219 run, 3195 passes, 18 expected failures, 5 > failures, 1 errors, 0 unexpected passes. See: > http://minus.com/l17FSZY5yOnhH > > I have no idea but I still have that image if someone wants it. > > http://minus.com/mbam1m6GnSJJJH is the complete Folder with the screenshots > of all runs I published up to now. Thanks very much for running the tests, Herbert. I appreciate it! This is actually what I _expected_, since one of the 6 failing tests is a network issue on the Linux platform. That is, I expect NetworkTests.Kernel.SocketTest.testSendTimeout to _pass_ on Windows. That error is news to me though: FileDirectoryTest.testRelativeNameIfAbsolut... Would you mind sending more details on that failed test? I'd like to see which assertion fails. Thanks again! frank > Cheers > > Herbert > > > > |
Re: 6 tests to go... Win7 results
|
|
On Wed, 24 Oct 2012, Frank Shearar wrote:
> On 23 October 2012 21:25, Herbert König <[hidden email]> wrote: >> Hi, >>> >>> We're down to 6 failing unit tests on the Linux platform, one of which >>> is an expected failure and another of which is a known network issue >>> for the Linux platform. >>> >>> Would my kind Windows and OSX build volunteers please run builds >>> against the latest trunk image? >>> (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/) >>> >> Yesterday (Oct 22) I could download build #17 and got a TrunkImage.image and >> .changes. Not the usual zip including the VM. > > The VM comes from the repository at > https://github.com/frankshearar/squeak-ci. In particular, you can get > a copy directly from here: > https://github.com/frankshearar/squeak-ci/zipball/master > > Sorry, I thought I'd only need to mention the image location. > >> This is update 12251 according to the system reporter. I disable IPV6 >> support via preferences and run all tests in the Cog VM I used for the >> previous tests. See http://minus.com/luZyqW2PRhIrq. >> >> I get 3222 run, 3178 passes, 18 expected failures, 5 failures, 21 errors, 0 >> unexpected passes, as if the network preference is ignored again. >> See http://minus.com/lpibYAKEi3bw5 >> I did this twice, as I didn't want to believe it. >> >> If I update this image to trunk, it loads some updates and again claims to >> be 12251 version. >> Tests like before result in 3219 run, 3195 passes, 18 expected failures, 5 >> failures, 1 errors, 0 unexpected passes. See: >> http://minus.com/l17FSZY5yOnhH >> >> I have no idea but I still have that image if someone wants it. >> >> http://minus.com/mbam1m6GnSJJJH is the complete Folder with the screenshots >> of all runs I published up to now. > > Thanks very much for running the tests, Herbert. I appreciate it! > > This is actually what I _expected_, since one of the 6 failing tests > is a network issue on the Linux platform. That is, I expect > NetworkTests.Kernel.SocketTest.testSendTimeout to _pass_ on Windows. that the test expects that if it fills up the send buffer of a socket, then all subsequent send requests will fail, but I think the OS somehow makes the send buffer larger, so while sending failed at a point in time, later it will work again. > > That error is news to me though: FileDirectoryTest.testRelativeNameIfAbsolut... > > Would you mind sending more details on that failed test? I'd like to > see which assertion fails. That's an "old" error on Windows. The method (#relativeNameIfAbsoluteFor:) expects that an absolute path begins with the path delimitar, which is obviously not true on windows (C:\... doesn't begin with \). There are several absolute path formats on windows, so I think the method has to be implementation in DosFileDirectory. Levente > > Thanks again! > > frank > >> Cheers >> >> Herbert >> >> >> >> > > |
Re: Jenkins reliability ( was Re: [squeak-dev] 6 tests to go...)
|
|
In reply to this post by Igor Stasenko
On Wed, 24 Oct 2012, Igor Stasenko wrote:
> Err, no. > A "workspace" is where slave doing its work. > But artifacts made by job(s) are stored in separate place. Right, but as I said, the directory structure created by Jenkins didn't match what the wiki says when we set up Jenkins. So, tt's still worth checking the directory structure. Levente > > By analogy to real life: you have a workshop where you produce things, > and storage where you put them after. > > On 24 October 2012 00:43, Levente Uzonyi <[hidden email]> wrote: >> Isn't the issue simply that Jenkins is looking for the workspace at the >> wrong place? When we first set up our Jenkins instance it created the >> workspace directory at a different place than what the documentation[1] >> says. There was a workspace directory in the JENKINS_HOME directory with >> subdirectories for each job IIRC. After the first restart it was looking for >> the workspace directory at the place suggested by the documentation, so our >> jobs "disappeared". We fixed the directory structure by hand and everything >> is fine since then. >> >> >> Levente >> >> [1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins >> >> >> On Tue, 23 Oct 2012, Chris Cunnington wrote: >> >>> >>> I think I can sketch out a few details. >>> >>> 1. The first thing is that this is not a medical emergency. I'm saying >>> that for my own peace of mind. System administration under duress is no fun >>> at all. >>> >>> 2. The builds are still there. They don't disappear. They just aren't seen >>> by the webpage. We are not alone in this. It has happened before. >>> >>> >>> http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-when-restarted-td4124991.html >>> >>> 3. The problem may be in the reading of an XML file. The solution I've >>> gleaned so far is that instead of creating another build, I could log in and >>> press: >>> >>> "Reload Configuration from Disk" >>> >>> Or I could just try restarting. >>> >>> 4. This didn't happen on the older server. It won't last forever on this >>> one. >>> >>> 5. God knows, somebody will come up with a better answer than I can. But >>> since you're all looking at me at this moment, I say this: "Don't panic. We >>> still know where our towel is." >>> >>> >>> Chris >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |