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

Chris Cunningham cunningham.cb at gmail.com
Wed Jan 9 22:43:07 UTC 2019

Yeah, but why is it only an issue if we have a .mcd file around?  that
causes the error - otherwise, there is no error.
So, I suspect now that you've copied over the 116 over, if I had a
114-117.cmcd file, it would complain about not having 114 available. Maybe.


On Wed, Jan 9, 2019 at 2:38 PM Chris Muller <asqueaker at gmail.com> wrote:

> 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/ad29cd88/attachment.html>

More information about the Squeak-dev mailing list