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 <cunningham.cb at gmail.com>
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.
>
> [image: image.png]
> 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 <cunningham.cb at gmail.com>
> 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 <lewis at mail.msen.com>
>> wrote:
>>
>>> On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
>>> >
>>> >
>>> > > On 2019-01-08, at 2:21 PM, Levente Uzonyi <leves at caesar.elte.hu>
>>> 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
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190109/010021a8/attachment.html>