Thanks Chris,

I am willing to do the update, but I want to confirm the procedure
before I touch anything.

My assumptions:

The image to be updated is /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.image,
and a backup copy of the current ss.image/changes should be saved.

The image can be updated off line by copying to my local system, applying
the patch, and copying back to the server.

Restarting the source.squeak.org image will restart it using the updated ss.image.

Clean shutdown should be done with sudo svc -d /service/squeaksource.

Startup is done with sudo svc -u /service/squeaksource.

The supervise script will restart the image, starting with ss.image and
loading everything back from the Magma backing store.

If anything goes wrong with the above steps, I can restore the saved
ss.image, restart it, and all would be well.

Does that sound right? If so I will plan to do the update tomorrow.

With your permission, I will also apply an update to MonticelloConfigurations
to enable versioning of MCM maps.

Also, if there is a VNC connection available for either the image or
for the dan.box.squeak.org server, I would feel more comfortable if you
can tell me how to open that connection.

Thanks,
Dave


On Sat, May 09, 2020 at 06:27:19PM -0500, Chris Muller wrote:
> Okay, I went ahead and applied the one-line patch directly in the
> production server.  The Move function should be fast now.  I don't
> have time to build and deploy a new image right now.  Anyone is
> welcome to do that if they wish.  Fix is currently in
> andreas:/srv/sourcesqueakorg/box4/squeaksource/webserver/patch.st,
> I'll make a commit to /ss when I can get around to it..
> 
>  - Chris
> 
> 
> On Sat, May 9, 2020 at 11:34 AM Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> 
> >
> >
> >
> > Le sam. 9 mai 2020 ?? 17:52, David T. Lewis <lewis at mail.msen.com> a ??crit :
> >>
> >> On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:
> >> > Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
> >> > nicolas.cellier.aka.nice at gmail.com> a ??crit :
> >> >
> >> > > Hi all,
> >> > > when I review some inbox contribution, I make an effort to move accepted
> >> > > to trunk and rejected to treated via web interface.
> >> > > However, this is tedious, and I have the impression that some of the
> >> > > package that I moved did come back which is quite discouraging... Is it
> >> > > possible?
> >> > >
> >> >
> >> > An example is Graphics-ct.411.
> >> > I integrated that in trunk by moving the package thru web API (pretty sure
> >> > i did that).
> >> > Then I saw it back in Inbox.
> >> > I can't delete, so I moved it to Treated Inbox via web API (pretty sure
> >> > it's me who did that too).
> >> > Now I see a Graphics-ct.411 in inbox again...
> >> > That's annoying, because IMO we should have the inbox list as short as
> >> > possible
> >> > (it's like having tons of pending merge requests).
> >> > Graphics-ct.411 has been treated and should not lie in inbox any longer.
> >> >
> >>
> >> I just moved 11 of my inbox packages to the treated inbox using the web
> >> interface. The web interface locked up and timed out each time, requiring
> >> me to log back in to a new session each time it did this.
> >>
> > Yes, I experienced similar problems, it's not a pleasure...
> > Except yesterday, I was able to move 3 packages in a row
> > (well, I mean without relogging, not without waiting...)
> >
> >> The actual packages did get moved, and no longer appear in inbox. I'll
> >> check back later to see if they are still gone.
> >>
> >> Dave
> >>
> >>
> >
>