MC 'check all packages for changes' fails because WebClient-Core-ul.116 is missing

On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
>
>
> > On 2019-01-08, at 2:21 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> >
> > Did you download a fresh image? Unfortunately, we had two images released as 5.2 with different content.
>
> An excellent question. I am pretty sure I had the latest but to be sure I downloaded the very latest 5.2 image and compared to the one I was using and it appears to be identical. Just to test, I used the new image to run the clean packages check on my iMac and it worked. This made me wonder about maybe the contents of package-cache, so I copied the new image to the Pi (where I had been having the problem - almost all my Squeak work is on a Pi just to keep testing the ARM cog), deleted the Pi version of package-cache and tried - no problem. I even tried the older-but-the-same image and it worked.
>
> So, it looks like maybe there is some edge case where the contents of package-cache interferes a little. Just in case it suggests anything to a keen MC implementor, I generally have many images in a single Squeak directory and thus a single package-cache directory that all of them write to. Perhaps this has some bearing?
>

In addition to the disk-based package cache, there is a good deal of
in-image caching that can lead to bizarre problems.

If you are able to reproduce your original problem, try doing
"MCFileBasedRepository flushAllCaches" and see if the problem goes
away.

In my experience, the package-cache rarely causes problems, except in
cases like (for example) an empty and therefore corrupt package version
left in the package-cache folder after a failure of some sort.

On the other hand, the in-image caching is a source of frequent problems,
and I am in the habit of flushing the caches whenever I run into any
kind of oddity related to MC versions.

Dave

I'm curious if you could reproduce it with a clean copy, except put a  WebClient-Core-pre.117(ul.116).mcd (or the, correct, one) into your package-cache.  Wonder if that had something to do with it failing.

On Tue, Jan 8, 2019 at 5:50 PM David T. Lewis <[hidden email]> wrote:

On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
>
>
> > On 2019-01-08, at 2:21 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> >
> > Did you download a fresh image? Unfortunately, we had two images released as 5.2 with different content.
>
> An excellent question. I am pretty sure I had the latest but to be sure I downloaded the very latest 5.2 image and compared to the one I was using and it appears to be identical. Just to test, I used the new image to run the clean packages check on my iMac and it worked. This made me wonder about maybe the contents of package-cache, so I copied the new image to the Pi (where I had been having the problem - almost all my Squeak work is on a Pi just to keep testing the ARM cog), deleted the Pi version of package-cache and tried - no problem. I even tried the older-but-the-same image and it worked.
>
> So, it looks like maybe there is some edge case where the contents of package-cache interferes a little. Just in case it suggests anything to a keen MC implementor, I generally have many images in a single Squeak directory and thus a single package-cache directory that all of them write to. Perhaps this has some bearing?
>

In addition to the disk-based package cache, there is a good deal of
in-image caching that can lead to bizarre problems.

If you are able to reproduce your original problem, try doing
"MCFileBasedRepository flushAllCaches" and see if the problem goes
away.

In my experience, the package-cache rarely causes problems, except in
cases like (for example) an empty and therefore corrupt package version
left in the package-cache folder after a failure of some sort.

On the other hand, the in-image caching is a source of frequent problems,
and I am in the habit of flushing the caches whenever I run into any
kind of oddity related to MC versions.

Dave

Yep, just verified (I had the .mcd lying around from another image).  

* Downloaded current Windows Squeak 5.2

* unzipped into a folder

* created new sub-folder 'package-cache'

* copied 'WebClient-Core-pre.117(ul.116).mcd' into that folder

* Started Squeak, cancelled out of setting up the image

* opened MonticelloBrowser

* clicked 'check all packages for changes'

it ran for a while, then errored out right where you said it would, Tim.

Interestingly, this new image does have trunk and inbox in the repository list.

And, Dave, 'MCFileBasedRepository flushAllCaches' does not make the problem go away - it pops up again with no changes.

However, removing 'WebClient-Core-pre.117(ul.116).mcd' from 'package-cache' does solve the issue, and it continues on without hitch after that.

I suspect something is going on with the .mcd handling.

-cbc

On Tue, Jan 8, 2019 at 6:46 PM Chris Cunningham <[hidden email]> wrote:

I'm curious if you could reproduce it with a clean copy, except put a  WebClient-Core-pre.117(ul.116).mcd (or the, correct, one) into your package-cache.  Wonder if that had something to do with it failing.

On Tue, Jan 8, 2019 at 5:50 PM David T. Lewis <[hidden email]> wrote:

On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
>
>
> > On 2019-01-08, at 2:21 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> >
> > Did you download a fresh image? Unfortunately, we had two images released as 5.2 with different content.
>
> An excellent question. I am pretty sure I had the latest but to be sure I downloaded the very latest 5.2 image and compared to the one I was using and it appears to be identical. Just to test, I used the new image to run the clean packages check on my iMac and it worked. This made me wonder about maybe the contents of package-cache, so I copied the new image to the Pi (where I had been having the problem - almost all my Squeak work is on a Pi just to keep testing the ARM cog), deleted the Pi version of package-cache and tried - no problem. I even tried the older-but-the-same image and it worked.
>
> So, it looks like maybe there is some edge case where the contents of package-cache interferes a little. Just in case it suggests anything to a keen MC implementor, I generally have many images in a single Squeak directory and thus a single package-cache directory that all of them write to. Perhaps this has some bearing?
>

In addition to the disk-based package cache, there is a good deal of
in-image caching that can lead to bizarre problems.

If you are able to reproduce your original problem, try doing
"MCFileBasedRepository flushAllCaches" and see if the problem goes
away.

In my experience, the package-cache rarely causes problems, except in
cases like (for example) an empty and therefore corrupt package version
left in the package-cache folder after a failure of some sort.

On the other hand, the in-image caching is a source of frequent problems,
and I am in the habit of flushing the caches whenever I run into any
kind of oddity related to MC versions.

Dave

Guys, isn't the error message clear?  Tim, you had it figured out in your initial message of this thread.

Then I wrote:

> it's because WebClient-Core-ul.116 isn't in the /squeak52 repository.  

The build process should ensure we have at least the initial ancestor of each package in the release repository, but currently doesn't.

I just copied WebClient-Core-ul.116 to /squeak52 for you, so it should either work or fail on the next error (since I didn't have time to copy them all).

Best,

  Chris Muller

On Tue, Jan 8, 2019 at 8:59 PM Chris Cunningham <[hidden email]> wrote:

Yep, just verified (I had the .mcd lying around from another image).  

* Downloaded current Windows Squeak 5.2

* unzipped into a folder

* created new sub-folder 'package-cache'

* copied 'WebClient-Core-pre.117(ul.116).mcd' into that folder

* Started Squeak, cancelled out of setting up the image

* opened MonticelloBrowser

* clicked 'check all packages for changes'

it ran for a while, then errored out right where you said it would, Tim.

Interestingly, this new image does have trunk and inbox in the repository list.

And, Dave, 'MCFileBasedRepository flushAllCaches' does not make the problem go away - it pops up again with no changes.

However, removing 'WebClient-Core-pre.117(ul.116).mcd' from 'package-cache' does solve the issue, and it continues on without hitch after that.

I suspect something is going on with the .mcd handling.

-cbc

On Tue, Jan 8, 2019 at 6:46 PM Chris Cunningham <[hidden email]> wrote:

I'm curious if you could reproduce it with a clean copy, except put a  WebClient-Core-pre.117(ul.116).mcd (or the, correct, one) into your package-cache.  Wonder if that had something to do with it failing.

On Tue, Jan 8, 2019 at 5:50 PM David T. Lewis <[hidden email]> wrote:

On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
>
>
> > On 2019-01-08, at 2:21 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> >
> > Did you download a fresh image? Unfortunately, we had two images released as 5.2 with different content.
>
> An excellent question. I am pretty sure I had the latest but to be sure I downloaded the very latest 5.2 image and compared to the one I was using and it appears to be identical. Just to test, I used the new image to run the clean packages check on my iMac and it worked. This made me wonder about maybe the contents of package-cache, so I copied the new image to the Pi (where I had been having the problem - almost all my Squeak work is on a Pi just to keep testing the ARM cog), deleted the Pi version of package-cache and tried - no problem. I even tried the older-but-the-same image and it worked.
>
> So, it looks like maybe there is some edge case where the contents of package-cache interferes a little. Just in case it suggests anything to a keen MC implementor, I generally have many images in a single Squeak directory and thus a single package-cache directory that all of them write to. Perhaps this has some bearing?
>

In addition to the disk-based package cache, there is a good deal of
in-image caching that can lead to bizarre problems.

If you are able to reproduce your original problem, try doing
"MCFileBasedRepository flushAllCaches" and see if the problem goes
away.

In my experience, the package-cache rarely causes problems, except in
cases like (for example) an empty and therefore corrupt package version
left in the package-cache folder after a failure of some sort.

On the other hand, the in-image caching is a source of frequent problems,
and I am in the habit of flushing the caches whenever I run into any
kind of oddity related to MC versions.

Dave