I've just been making a SqueakMap entry for the WeatherStation (it's been a long time since I last added a package!) and it seems we have some issue with calculating the sha1 checksums.
The attempt to load from SM failed and initially looked like something had prevented the server from responding (the error message was a complaint from HttpUrl>>#normalizeContents:) but the Transcript also shewed "(http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...) failed with this exception: Incorrect SHA checksum of file from original URL Trying server cache instead."
Digging in to the debugger tells us that the smpackagerelease has a sha1 of 1044864536495630331656691098454436905765045645695 but the calculated value for the (correctly!) downloaded install file is 401855207151508086727566629532522206807045316227 - so things start to go wrong in SMPackageRelease>>#correctSha1sum:
Loading some older packages seems to work. Checking the squeakmap web page shows that the sha1 value is indeed 1044864..... Looking at the stored sha1 values for 'Command Shell' for example tells me that they match what is calculated by #correctSha1sum: for the downloaded install scripts. Checking in a 5.3 image for the sha1 of the downloaded install script agrees with my trunk image.
I tried marking the package as 'published' in case I had simply forgotten sometihng; no change
IIRC the SM image is ancient and I could imagine we've changed sometihng that would affect this but this is very odd. I'd almost think line-ends but the script was written and saved in Squeak.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
Hi Tim,
I think I've run into this before. Your SMFileCache might be out of sync with the server file of the same name. It's possible looking into SMFileCache might lead to the cause / solution.
Best, Chris
On Fri, Sep 29, 2023 at 12:48 PM Tim Rowledge tim@rowledge.org wrote:
I've just been making a SqueakMap entry for the WeatherStation (it's been a long time since I last added a package!) and it seems we have some issue with calculating the sha1 checksums.
The attempt to load from SM failed and initially looked like something had prevented the server from responding (the error message was a complaint from HttpUrl>>#normalizeContents:) but the Transcript also shewed "( http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...) failed with this exception: Incorrect SHA checksum of file from original URL Trying server cache instead."
Digging in to the debugger tells us that the smpackagerelease has a sha1 of 1044864536495630331656691098454436905765045645695 but the calculated value for the (correctly!) downloaded install file is 401855207151508086727566629532522206807045316227 - so things start to go wrong in SMPackageRelease>>#correctSha1sum:
Loading some older packages seems to work. Checking the squeakmap web page shows that the sha1 value is indeed 1044864..... Looking at the stored sha1 values for 'Command Shell' for example tells me that they match what is calculated by #correctSha1sum: for the downloaded install scripts. Checking in a 5.3 image for the sha1 of the downloaded install script agrees with my trunk image.
I tried marking the package as 'published' in case I had simply forgotten sometihng; no change
IIRC the SM image is ancient and I could imagine we've changed sometihng that would affect this but this is very odd. I'd almost think line-ends but the script was written and saved in Squeak.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
Disregard. Just catching up on squeak-dev chronologically. I saw you got it fixed.
On Tue, Oct 3, 2023 at 10:11 PM Chris Muller asqueaker@gmail.com wrote:
Hi Tim,
I think I've run into this before. Your SMFileCache might be out of sync with the server file of the same name. It's possible looking into SMFileCache might lead to the cause / solution.
Best, Chris
On Fri, Sep 29, 2023 at 12:48 PM Tim Rowledge tim@rowledge.org wrote:
I've just been making a SqueakMap entry for the WeatherStation (it's been a long time since I last added a package!) and it seems we have some issue with calculating the sha1 checksums.
The attempt to load from SM failed and initially looked like something had prevented the server from responding (the error message was a complaint from HttpUrl>>#normalizeContents:) but the Transcript also shewed "( http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...) failed with this exception: Incorrect SHA checksum of file from original URL Trying server cache instead."
Digging in to the debugger tells us that the smpackagerelease has a sha1 of 1044864536495630331656691098454436905765045645695 but the calculated value for the (correctly!) downloaded install file is 401855207151508086727566629532522206807045316227 - so things start to go wrong in SMPackageRelease>>#correctSha1sum:
Loading some older packages seems to work. Checking the squeakmap web page shows that the sha1 value is indeed 1044864..... Looking at the stored sha1 values for 'Command Shell' for example tells me that they match what is calculated by #correctSha1sum: for the downloaded install scripts. Checking in a 5.3 image for the sha1 of the downloaded install script agrees with my trunk image.
I tried marking the package as 'published' in case I had simply forgotten sometihng; no change
IIRC the SM image is ancient and I could imagine we've changed sometihng that would affect this but this is very odd. I'd almost think line-ends but the script was written and saved in Squeak.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
On 2023-10-03, at 8:42 PM, Chris Muller asqueaker@gmail.com wrote:
Disregard. Just catching up on squeak-dev chronologically. I saw you got it fixed.
Oh, not this issue. Marcel solved the can't-load-the-map thing but this is different. What is happening here is that the SHA1 for the install file as saved on the SM server is quite different to the value that the image will calculate.
On Tue, Oct 3, 2023 at 10:11 PM Chris Muller asqueaker@gmail.com wrote: Hi Tim,
I think I've run into this before. Your SMFileCache might be out of sync with the server file of the same name. It's possible looking into SMFileCache might lead to the cause / solution.
Best, Chris
On Fri, Sep 29, 2023 at 12:48 PM Tim Rowledge tim@rowledge.org wrote: I've just been making a SqueakMap entry for the WeatherStation (it's been a long time since I last added a package!) and it seems we have some issue with calculating the sha1 checksums.
The attempt to load from SM failed and initially looked like something had prevented the server from responding (the error message was a complaint from HttpUrl>>#normalizeContents:) but the Transcript also shewed "(http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...) failed with this exception: Incorrect SHA checksum of file from original URL Trying server cache instead."
Digging in to the debugger tells us that the smpackagerelease has a sha1 of 1044864536495630331656691098454436905765045645695 but the calculated value for the (correctly!) downloaded install file is 401855207151508086727566629532522206807045316227 - so things start to go wrong in SMPackageRelease>>#correctSha1sum:
Loading some older packages seems to work. Checking the squeakmap web page shows that the sha1 value is indeed 1044864..... Looking at the stored sha1 values for 'Command Shell' for example tells me that they match what is calculated by #correctSha1sum: for the downloaded install scripts. Checking in a 5.3 image for the sha1 of the downloaded install script agrees with my trunk image.
I tried marking the package as 'published' in case I had simply forgotten sometihng; no change
IIRC the SM image is ancient and I could imagine we've changed sometihng that would affect this but this is very odd. I'd almost think line-ends but the script was written and saved in Squeak.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Calm down -- it's only ones and zeros.
Catching up on this after the fun of setting up a new Pi5 -
I deleted the package from squeakmap. created a new one added a release set a break in SMPackageRelease>>#correctSha1sum: hit 'install' in the squeakmap UI The SHA checksum shown on http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/packa... is
SHA checksum: 408150253344322942111647329956763736439063597806
The value calculated in #correctSha1sum: is 431361985680180180283642449121365025913699917031
... which isn't really quite the same.
However, because the checksum value held in the downloader object involved is nil, we actually skip that comparison and load the package. And on the Pi5 it loads so fast I thought sometihng had gone wrong!
There's still an issue here though; why is the checksum not matching? And why was the value in the downloader object not nil in past tests?
Anyway, it should now be possible to load this from SM to play with.
On 2023-10-03, at 10:05 PM, Tim Rowledge tim@rowledge.org wrote:
On 2023-10-03, at 8:42 PM, Chris Muller asqueaker@gmail.com wrote:
Disregard. Just catching up on squeak-dev chronologically. I saw you got it fixed.
Oh, not this issue. Marcel solved the can't-load-the-map thing but this is different. What is happening here is that the SHA1 for the install file as saved on the SM server is quite different to the value that the image will calculate.
On Tue, Oct 3, 2023 at 10:11 PM Chris Muller asqueaker@gmail.com wrote: Hi Tim,
I think I've run into this before. Your SMFileCache might be out of sync with the server file of the same name. It's possible looking into SMFileCache might lead to the cause / solution.
Best, Chris
On Fri, Sep 29, 2023 at 12:48 PM Tim Rowledge tim@rowledge.org wrote: I've just been making a SqueakMap entry for the WeatherStation (it's been a long time since I last added a package!) and it seems we have some issue with calculating the sha1 checksums.
The attempt to load from SM failed and initially looked like something had prevented the server from responding (the error message was a complaint from HttpUrl>>#normalizeContents:) but the Transcript also shewed "(http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...) failed with this exception: Incorrect SHA checksum of file from original URL Trying server cache instead."
Digging in to the debugger tells us that the smpackagerelease has a sha1 of 1044864536495630331656691098454436905765045645695 but the calculated value for the (correctly!) downloaded install file is 401855207151508086727566629532522206807045316227 - so things start to go wrong in SMPackageRelease>>#correctSha1sum:
Loading some older packages seems to work. Checking the squeakmap web page shows that the sha1 value is indeed 1044864..... Looking at the stored sha1 values for 'Command Shell' for example tells me that they match what is calculated by #correctSha1sum: for the downloaded install scripts. Checking in a 5.3 image for the sha1 of the downloaded install script agrees with my trunk image.
I tried marking the package as 'published' in case I had simply forgotten sometihng; no change
IIRC the SM image is ancient and I could imagine we've changed sometihng that would affect this but this is very odd. I'd almost think line-ends but the script was written and saved in Squeak.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Calm down -- it's only ones and zeros.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Almost exactly
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Tim Rowledge