Hi all, just to warn that my last commits to trunk did not generate a mail report this evening. |
> On 2020-05-12, at 3:47 PM, Nicolas Cellier <[hidden email]> wrote: > > Hi all, > just to warn that my last commits to trunk did not generate a mail report this evening. > Just casual hex. No commitment. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim After a number of decimal places, nobody gives a damn. |
In reply to this post by Nicolas Cellier
On Wed, May 13, 2020 at 12:47:22AM +0200, Nicolas Cellier wrote:
> Hi all, > just to warn that my last commits to trunk did not generate a mail report > this evening. > Hmm... Most likely I am the guilty party. I restarted the source.squeak.org image yesterday after applying the following updates from the http://source.squeak.org/ss repository: MonticelloConfigurations-dtl.161 TinyWiki-tpr.12 SqueakSource-tpr.1124 SqueakSource-tpr.1125 SqueakSource-tpr.1126 SqueakSource-tpr.1127 SqueakSource-dtl.1128 Of these updates, two of them include changes that could affect mail delivery. The possibly relevant parts of the commit notices are: SqueakSource-tpr.1125 Use the admin email address when sending out error page reports; 'box-admins' is confusing. SqueakSource-tpr.1127 add support for using the email server user name and password; update the settings page @tim - can you please check these and see if either update might be dangerous? I'll wait until tomorrow for guidance, but if in doubt I'll revert any of the updates that might be questionable. Dave |
Tim,
Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes #deliverMailFrom:to:text: and the changed method now calls an unimplemented method: SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: Tim, if you have the missing method available, can you please commit it to the ss repository? Dave On Tue, May 12, 2020 at 08:10:10PM -0400, David T. Lewis wrote: > On Wed, May 13, 2020 at 12:47:22AM +0200, Nicolas Cellier wrote: > > Hi all, > > just to warn that my last commits to trunk did not generate a mail report > > this evening. > > > > Hmm... Most likely I am the guilty party. > > I restarted the source.squeak.org image yesterday after applying the > following updates from the http://source.squeak.org/ss repository: > > MonticelloConfigurations-dtl.161 > TinyWiki-tpr.12 > SqueakSource-tpr.1124 > SqueakSource-tpr.1125 > SqueakSource-tpr.1126 > SqueakSource-tpr.1127 > SqueakSource-dtl.1128 > > Of these updates, two of them include changes that could affect mail > delivery. The possibly relevant parts of the commit notices are: > > SqueakSource-tpr.1125 > Use the admin email address when sending out error page reports; > 'box-admins' is confusing. > > SqueakSource-tpr.1127 > add support for using the email server user name and password; update > the settings page > > @tim - can you please check these and see if either update might be > dangerous? I'll wait until tomorrow for guidance, but if in doubt I'll > revert any of the updates that might be questionable. > > Dave > > |
> On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > Tim, > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > method: > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: Hmm. According to the history I see before me this is in Network-tpr.238 in trunk. It's in my running 19666 level image and MC swears it has not been removed. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Any sufficiently advanced bug is indistinguishable from a feature. |
On Tue, May 12, 2020 at 05:55:53PM -0700, tim Rowledge wrote:
> > > > On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > > > Tim, > > > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > > method: > > > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: > > Hmm. According to the history I see before me this is in Network-tpr.238 > in trunk. It's in my running 19666 level image and MC swears it has not > been removed. > Ok, that makes sense. When I updated the source.squeak.org image, I updated the packages that I found in the ss repository. I did not update the other packages in the image (it is based on a Squeak 5.2 release image) and I should not do that. I cannot follow up tonight, but it sounds like the best thing is for me to revert any non-essential changes, and restart the image with just the essential changes (Chris' patch.st to fix moving packages from inbox to treated or trunk, plus my update for commented MCMs). Sorry for the mail problem, I will get it straightened out tomorrow. Dave |
I restarted source.squeak.org and am not having difficulties getting it
restarted. I'll report back as soon as possible. Dave On Tue, May 12, 2020 at 09:39:05PM -0400, David T. Lewis wrote: > On Tue, May 12, 2020 at 05:55:53PM -0700, tim Rowledge wrote: > > > > > > > On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > > > > > Tim, > > > > > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > > > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > > > method: > > > > > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: > > > > Hmm. According to the history I see before me this is in Network-tpr.238 > > in trunk. It's in my running 19666 level image and MC swears it has not > > been removed. > > > > Ok, that makes sense. When I updated the source.squeak.org image, > I updated the packages that I found in the ss repository. I did not > update the other packages in the image (it is based on a Squeak 5.2 > release image) and I should not do that. > > I cannot follow up tonight, but it sounds like the best thing is for > me to revert any non-essential changes, and restart the image with > just the essential changes (Chris' patch.st to fix moving packages > from inbox to treated or trunk, plus my update for commented MCMs). > > Sorry for the mail problem, I will get it straightened out tomorrow. > > Dave > > |
Thank you, Dave!
On Wed, May 13, 2020 at 4:41 PM David T. Lewis <[hidden email]> wrote: > > I restarted source.squeak.org and am not having difficulties getting it > restarted. I'll report back as soon as possible. > > Dave > > > On Tue, May 12, 2020 at 09:39:05PM -0400, David T. Lewis wrote: > > On Tue, May 12, 2020 at 05:55:53PM -0700, tim Rowledge wrote: > > > > > > > > > > On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > Tim, > > > > > > > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > > > > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > > > > method: > > > > > > > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: > > > > > > Hmm. According to the history I see before me this is in Network-tpr.238 > > > in trunk. It's in my running 19666 level image and MC swears it has not > > > been removed. > > > > > > > Ok, that makes sense. When I updated the source.squeak.org image, > > I updated the packages that I found in the ss repository. I did not > > update the other packages in the image (it is based on a Squeak 5.2 > > release image) and I should not do that. > > > > I cannot follow up tonight, but it sounds like the best thing is for > > me to revert any non-essential changes, and restart the image with > > just the essential changes (Chris' patch.st to fix moving packages > > from inbox to treated or trunk, plus my update for commented MCMs). > > > > Sorry for the mail problem, I will get it straightened out tomorrow. > > > > Dave > > > > > |
I must be overlooking something.
A process listing shows this: root 671 665 0 2017 ? 00:00:00 readproctitle service errors: ..............................................................................................................................................................................................................................................................................................................................................svscan: warning: unable to stat squeaksource: file does not exist And I can see the squeaksource image being endlessly restarted. What changed: I stopped the service (sudo -d /service/squeaksource), replaced the image, and started it again (sudo -u /service/squeaksource). I restored the previously working image, and still have the same problem (I put the right image back after that verification). I can't spot what I am overlooking here. I'll see if I can get it running manually outside of the supervise system. :-/ Dave On Wed, May 13, 2020 at 04:42:18PM +0200, Fabio Niephaus wrote: > Thank you, Dave! > > On Wed, May 13, 2020 at 4:41 PM David T. Lewis <[hidden email]> wrote: > > > > I restarted source.squeak.org and am not having difficulties getting it > > restarted. I'll report back as soon as possible. > > > > Dave > > > > > > On Tue, May 12, 2020 at 09:39:05PM -0400, David T. Lewis wrote: > > > On Tue, May 12, 2020 at 05:55:53PM -0700, tim Rowledge wrote: > > > > > > > > > > > > > On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > > > Tim, > > > > > > > > > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > > > > > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > > > > > method: > > > > > > > > > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: > > > > > > > > Hmm. According to the history I see before me this is in Network-tpr.238 > > > > in trunk. It's in my running 19666 level image and MC swears it has not > > > > been removed. > > > > > > > > > > Ok, that makes sense. When I updated the source.squeak.org image, > > > I updated the packages that I found in the ss repository. I did not > > > update the other packages in the image (it is based on a Squeak 5.2 > > > release image) and I should not do that. > > > > > > I cannot follow up tonight, but it sounds like the best thing is for > > > me to revert any non-essential changes, and restart the image with > > > just the essential changes (Chris' patch.st to fix moving packages > > > from inbox to treated or trunk, plus my update for commented MCMs). > > > > > > Sorry for the mail problem, I will get it straightened out tomorrow. > > > > > > Dave > > > > > > > > > |
OK, it should be back now, and hopefully the mail delivery will be working again.
I don't know the details, but it looks like the startup script is looking for a file called "patch.st" to load. Chris had previously told me to rename that file to "patch.st.old", which I had done. But today I wanted to undo my earlier changes, and I renamed patch.st.old to patch.st. That was entirely my mistake, I should not have done that. When I manually started the run script, I got an abort error dump with this message at the end: ^^^^^^^^^^^^^^^^^^ Error: patch.st file is older than the image file. Aborting. ^^^^^^^^^^^^^^^^^^ So apparently the startup script saw the patch.st was old relative to the image, and decided that it would be a good idea to abort (as opposed to say just don't load the old patch file). When running under supervise, the error condition was not obvious, and supervise just went into an endless abort/retry loop. Meanwhile, I still see this in the process listing: root 671 665 0 2017 ? 00:00:00 readproctitle service errors: ..............................................................................................................................................................................................................................................................................................................................................svscan: warning: unable to stat squeaksource: file does not exist I cannot figure out where that error is coming from, but apparently it is a red herring and had nothing to do with the restart problem. Ugh. Sorry for the disruption. Dave On Wed, May 13, 2020 at 10:55:11AM -0400, David T. Lewis wrote: > I must be overlooking something. > > A process listing shows this: > root 671 665 0 2017 ? 00:00:00 readproctitle service errors: ..............................................................................................................................................................................................................................................................................................................................................svscan: warning: unable to stat squeaksource: file does not exist > > And I can see the squeaksource image being endlessly restarted. > > What changed: I stopped the service (sudo -d /service/squeaksource), replaced > the image, and started it again (sudo -u /service/squeaksource). > > I restored the previously working image, and still have the same problem (I > put the right image back after that verification). > > I can't spot what I am overlooking here. I'll see if I can get it running > manually outside of the supervise system. > > :-/ > > Dave > > > On Wed, May 13, 2020 at 04:42:18PM +0200, Fabio Niephaus wrote: > > Thank you, Dave! > > > > On Wed, May 13, 2020 at 4:41 PM David T. Lewis <[hidden email]> wrote: > > > > > > I restarted source.squeak.org and am not having difficulties getting it > > > restarted. I'll report back as soon as possible. > > > > > > Dave > > > > > > > > > On Tue, May 12, 2020 at 09:39:05PM -0400, David T. Lewis wrote: > > > > On Tue, May 12, 2020 at 05:55:53PM -0700, tim Rowledge wrote: > > > > > > > > > > > > > > > > On 2020-05-12, at 5:45 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > > > > > > Tim, > > > > > > > > > > > > Indeed, the SqueakSource-tpr.1127 update looks suspicious. It changes > > > > > > #deliverMailFrom:to:text: and the changed method now calls an unimplemented > > > > > > method: > > > > > > > > > > > > SMTPClient>>deliverMailFrom:to:text:usingServer:userName:password: > > > > > > > > > > Hmm. According to the history I see before me this is in Network-tpr.238 > > > > > in trunk. It's in my running 19666 level image and MC swears it has not > > > > > been removed. > > > > > > > > > > > > > Ok, that makes sense. When I updated the source.squeak.org image, > > > > I updated the packages that I found in the ss repository. I did not > > > > update the other packages in the image (it is based on a Squeak 5.2 > > > > release image) and I should not do that. > > > > > > > > I cannot follow up tonight, but it sounds like the best thing is for > > > > me to revert any non-essential changes, and restart the image with > > > > just the essential changes (Chris' patch.st to fix moving packages > > > > from inbox to treated or trunk, plus my update for commented MCMs). > > > > > > > > Sorry for the mail problem, I will get it straightened out tomorrow. > > > > > > > > Dave > > > > > > > > > > > > > > |
Hi Dave,
On Wed, May 13, 2020 at 10:24 AM David T. Lewis <[hidden email]> wrote: > > OK, it should be back now, and hopefully the mail delivery will be working again. > > I don't know the details, but it looks like the startup script is looking for > a file called "patch.st" to load. Chris had previously told me to rename that > file to "patch.st.old", which I had done. But today I wanted to undo my > earlier changes, and I renamed patch.st.old to patch.st. "Undoing your changes" would also mean undoing the image, which I assume you had renamed to ".old"...? > When I manually started the run script, I got an abort error dump with > this message at the end: > > ^^^^^^^^^^^^^^^^^^ Error: patch.st file is older than the image file. Aborting. ^^^^^^^^^^^^^^^^^^ > > So apparently the startup script saw the patch.st was old relative to the > image, and decided that it would be a good idea to abort (as opposed to say > just don't load the old patch file). The patch mechanism is there to patch a production issue until a new image can be deployed. Deploying a new image but keeping an old patch file makes no sense, and no safe assumption can be made by the system about whether the patch is needed or not needed. The only safe thing it can do is refuse to run and make the user aware immediately that they're not running the configuration they thought they were (unpatched? despite the presence of patch.st?). Dave, I'm really sorry, but we're not done. What's serving the community now is a hacked together image that cannot be built from first-principles, like before. It's yet another "custom image" like the one's running squeaksource.com and squeakmap. I can't bear to run this way. What needs to happen is you backport your MCConfigurations enhancement to the Monticello version in 5.2, then clone the SqueakMap entry for Personal SqueakSource and increment the version number. Then *load that into a clean 5.2 image* and deploy it (with no patch.st). I appreciate the new feature you want to bring to MC Configurations, truly, but it's more important to me for this production system to retain the process maturity it had before. - Chris - Chris |
On Wed, May 13, 2020 at 05:50:54PM -0500, Chris Muller wrote:
> Hi Dave, > > On Wed, May 13, 2020 at 10:24 AM David T. Lewis <[hidden email]> wrote: > > > > OK, it should be back now, and hopefully the mail delivery will be working again. > > > > I don't know the details, but it looks like the startup script is looking for > > a file called "patch.st" to load. Chris had previously told me to rename that > > file to "patch.st.old", which I had done. But today I wanted to undo my > > earlier changes, and I renamed patch.st.old to patch.st. > > "Undoing your changes" would also mean undoing the image, which I > assume you had renamed to ".old"...? > No. I renamed the Sept 9, 2019 image per your direction, and I have not changed that. As I said in my original mail: > I renamed patch.st.old to patch.st. That was entirely my mistake, I > should not have done that. But something is badly broken. I assume that the design intent of the patch.st loader is to support patching server images. A server image is likely to be run headless and also to be managed by a tool like supervise. That configuration should not go into full meltdown mode in response to a simple error. A patch.st file with modification date older than the image modification date is treated as an error. That happened today, and the error put the system into a death spiral. The SmalltalkImage>>run: method has an error handler block that looks particularly suspicious. It prints the error log message, then does this: self isHeadless ifTrue: [ self snapshot: false andQuit: true ] So the image exits, supervise restarts it, repeat forever. That is exactly what happened this morning on source.squeak.org. This is a serious failure mode and needs to be fixed. Dave |
Dave,
The normal response of any application with a boostrap failure is to exit. And as long as you have supervise instructed to keep the server running, that's what it will do. It's not a "death spiral". :) > > On Wed, May 13, 2020 at 10:24 AM David T. Lewis <[hidden email]> wrote: > > > > > > OK, it should be back now, and hopefully the mail delivery will be working again. > > > > > > I don't know the details, but it looks like the startup script is looking for > > > a file called "patch.st" to load. Chris had previously told me to rename that > > > file to "patch.st.old", which I had done. But today I wanted to undo my > > > earlier changes, and I renamed patch.st.old to patch.st. > > > > "Undoing your changes" would also mean undoing the image, which I > > assume you had renamed to ".old"...? > > > > No. I renamed the Sept 9, 2019 image per your direction, and I have not changed that. I was referring to the proper way to "undo your changes". If the system doesn't come right up and it isn't obvious, just execute your backout plan to backout 100% and regroup. Putting the system into some "third" state on-the-fly that is neither what you tested, nor what the system was beforehand, is a recipe for problems. A new system with an old patch is an invalid state for Personal SqueakSource. Removing that file is part of the normal deployment process. I'm sorry if it was confusing, but the system worked exactly as designed by refusing to run an invalid configuration. The message in the log was clear, and you knew instantly what to do once you saw it. What needs fixing at this point is that image -- we need to be using one built fresh with your MCConfigurations enhancement, so we know what code our server is running, can maintain and collaborate on it and be able to make fresh instantiations of it. - Chris - Chris |
Hi Chris,
On Thu, May 14, 2020 at 12:38:20AM -0500, Chris Muller wrote: > Dave, > > The normal response of any application with a boostrap failure is to > exit. And as long as you have supervise instructed to keep the server > running, that's what it will do. It's not a "death spiral". :) > > > > On Wed, May 13, 2020 at 10:24 AM David T. Lewis <[hidden email]> wrote: > > > > > > > > OK, it should be back now, and hopefully the mail delivery will be working again. > > > > > > > > I don't know the details, but it looks like the startup script is looking for > > > > a file called "patch.st" to load. Chris had previously told me to rename that > > > > file to "patch.st.old", which I had done. But today I wanted to undo my > > > > earlier changes, and I renamed patch.st.old to patch.st. > > > > > > "Undoing your changes" would also mean undoing the image, which I > > > assume you had renamed to ".old"...? > > > > > > > No. I renamed the Sept 9, 2019 image per your direction, and I have not changed that. > > I was referring to the proper way to "undo your changes". If the > system doesn't come right up and it isn't obvious, just execute your > backout plan to backout 100% and regroup. Putting the system into > some "third" state on-the-fly that is neither what you tested, nor > what the system was beforehand, is a recipe for problems. > > A new system with an old patch is an invalid state for Personal > SqueakSource. Removing that file is part of the normal deployment > process. I'm sorry if it was confusing, but the system worked exactly > as designed by refusing to run an invalid configuration. The message > in the log was clear, and you knew instantly what to do once you saw > it. > > What needs fixing at this point is that image -- we need to be using > one built fresh with your MCConfigurations enhancement, so we know > what code our server is running, can maintain and collaborate on it > and be able to make fresh instantiations of it. > I'm not sure where to go with this. The ss repository already contained copies of a number of MonticelloConfigurations packages, so I assumed that you were keeping them there. Thus, I put a copy of the updated package MonticelloConfigurations-dtl.161 on the ss repository. But looking that the configurations that you published for Personal SqueakSource on SqueakMap, you are not referencing any of the copies in the ss repository. If you're building on a Squeak 5.2 release image, you would either need to add a reference to the new copy in the ss repository, or you would have to backport it to the squeak52 repository (I don't know if that's a good thing to do). Your patch (the one in the patch.st file) is a bit more complicated. I added it to the head of the updates as SqueakSource-dtl.1128. However, that version is incompatible with the Squeak 5.2 release image due to some intermediate changes, so it cannot be used in the source.squeak.org image. I think this means that if you want a SqueakSource package that contains your patch, and if you want to run it on a Squeak 5.2 image, then you would need to branch the packages (i.e. make a package with SqueakSource-cmm.1123 as the parent, and save it as SqueakSource.squeak52-cmm.1124). Alternatively, you could just reinstate the patch.sh file on the server and update its time stamp. I'm happy to restore the patch.st file if you think that's the right thing to do, but the rest of this stuff is a bit beyond my patience threshold. Dave |
> But looking that the configurations that you published for Personal
> SqueakSource on SqueakMap, you are not referencing any of the copies > in the ss repository. The fixed versions used to run source.squeak.org do pull from /ss. "5.2.1" is the current. You're right that the head (development) version is pulling from squeaksource.com. This is for instances besides source.squeak.org but the goal is for source.squeak.org to stay with it if it can. > If you're building on a Squeak 5.2 release > image, you would either need to add a reference to the new copy in > the ss repository, or you would have to backport it to the squeak52 > repository (I don't know if that's a good thing to do). Yeah, I like your conservatism regarding backporting, that might actually be too aggressive for this feature. So, simply adding a line to load it from a copy of the 5.2 script should work. > Your patch (the one in the patch.st file) is a bit more complicated. > I added it to the head of the updates as SqueakSource-dtl.1128. > However, that version is incompatible with the Squeak 5.2 release > image due to some intermediate changes, so it cannot be used in the > source.squeak.org image. Yes, but aren't those "incompatibilities" rather trivial? Just pass the email id and repository from the repository instead? (sorry I only had time to glance at it, didn't analyze...) > I think this means that if you want a SqueakSource package that > contains your patch, and if you want to run it on a Squeak 5.2 image, > then you would need to branch the packages (i.e. make a package > with SqueakSource-cmm.1123 as the parent, and save it as > SqueakSource.squeak52-cmm.1124). > > Alternatively, you could just reinstate the patch.sh file on the > server and update its time stamp. I hope we could just fix whatever's wrong with the intermediate versions.. > I'm happy to restore the patch.st file if you think that's the right > thing to do, but the rest of this stuff is a bit beyond my patience > threshold. Cleaning and scraping requires a lot of patience when all you want to do is get to the fun painting part, but it's necessary for the best results. If your enhancement isn't eventually properly integrated, it could suddenly disappear one day if another fix or enhancement became necessary that resulted in a new 5.2-based SqueakSource image. Really, I think just adding the one line incantation to a new "5.2.2" Release is all that's needed, but the only way to know is for someone to try it, load it, upload it to andreas and restart the server. This is what I thought your original plan was. - Chris |
Hi Chris,
I do not want to get involved in maintaining Personal SqueakSource, or in publishing Personal SqueakSource releases to SqueakMap. Nor am I interested in figuring out how to make the latest SqueakSource package version work on a Squeak 5.2 image. It all sounds like great stuff for somebody to do, but it needs to be somebody other than me. If you want me to roll the image back to your original version and put the updates into a patch.st file, I can do that. Please let me know. Dave On Fri, May 15, 2020 at 07:37:45PM -0500, Chris Muller wrote: > > But looking that the configurations that you published for Personal > > SqueakSource on SqueakMap, you are not referencing any of the copies > > in the ss repository. > > The fixed versions used to run source.squeak.org do pull from /ss. > "5.2.1" is the current. > > You're right that the head (development) version is pulling > from squeaksource.com. This is for instances besides > source.squeak.org but the goal is for source.squeak.org to > stay with it if it can. > > > If you're building on a Squeak 5.2 release > > image, you would either need to add a reference to the new copy in > > the ss repository, or you would have to backport it to the squeak52 > > repository (I don't know if that's a good thing to do). > > Yeah, I like your conservatism regarding backporting, that might > actually be too aggressive for this feature. > > So, simply adding a line to load it from a copy of the 5.2 script should work. > > > Your patch (the one in the patch.st file) is a bit more complicated. > > I added it to the head of the updates as SqueakSource-dtl.1128. > > However, that version is incompatible with the Squeak 5.2 release > > image due to some intermediate changes, so it cannot be used in the > > source.squeak.org image. > > Yes, but aren't those "incompatibilities" rather trivial? Just pass > the email id and repository from the repository instead? (sorry I > only had time to glance at it, didn't analyze...) > > > I think this means that if you want a SqueakSource package that > > contains your patch, and if you want to run it on a Squeak 5.2 image, > > then you would need to branch the packages (i.e. make a package > > with SqueakSource-cmm.1123 as the parent, and save it as > > SqueakSource.squeak52-cmm.1124). > > > > Alternatively, you could just reinstate the patch.sh file on the > > server and update its time stamp. > > I hope we could just fix whatever's wrong with the intermediate versions.. > > > I'm happy to restore the patch.st file if you think that's the right > > thing to do, but the rest of this stuff is a bit beyond my patience > > threshold. > > Cleaning and scraping requires a lot of patience when all you want to > do is get to the fun painting part, but it's necessary for the best > results. If your enhancement isn't eventually properly integrated, it > could suddenly disappear one day if another fix or enhancement became > necessary that resulted in a new 5.2-based SqueakSource image. > > Really, I think just adding the one line incantation to a new "5.2.2" > Release is all that's needed, but the only way to know is for someone > to try it, load it, upload it to andreas and restart the server. This > is what I thought your original plan was. > > - Chris > |
Hi Dave,
> If you want me to roll the image back to your original version and put > the updates into a patch.st file, I can do that. Please let me know. Yes, please revert it back to the production image with patch.st for now, then. - Chris |
Free forum by Nabble | Edit this page |