Hmmm, this appears to be some kind of issue with SSL authorization
when accessing the github repository. It seems to be failing in

  MCGitHubReposistory class((MCGitBasedNetworkRepository class)>>projectDirectoryFrom:version:

from

  MCGitHubReposistory(MCGitBasedNetworkRepository)>>directory

from

  MCGitHubRepository(MCFileTreeRepository)>>allFileNames

and it is caused by a primitive failure in SqueakSSL>>primitiveSSLCreate.

Evaluating "SqueakSSL new" gives me the same error. So the problem is
probably something to do with the VM I am running, or with the runtime
packages that I have installed on my PC. I will follow up on this later.

Thanks,
Dave


On Sun, Dec 16, 2018 at 08:07:16PM -0500, David T. Lewis wrote:
> Hi Max,
> 
> I'm on ubuntu 16.04 LTS.
> 
> But it's probably some mistake that I am making. One thing I noticed - when
> I do the checkout of the Seaside version, I end up with a detached head, is
> this expected? Here is what I see on the terminal:
> 
>   lewis at lewis-Gazelle-Pro:~/squeak/Squeak5.2/Seaside-TEST/Seaside$ git status
>   On branch master
>   Your branch is up-to-date with 'origin/master'.
>   nothing to commit, working directory clean
>   lewis at lewis-Gazelle-Pro:~/squeak/Squeak5.2/Seaside-TEST/Seaside$ git checkout -f master
>   Already on 'master'
>   Your branch is up-to-date with 'origin/master'.
>   lewis at lewis-Gazelle-Pro:~/squeak/Squeak5.2/Seaside-TEST/Seaside$ git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
>   Note: checking out '9cb54a7b14cd254ef318294905c4e8dda8dd9f79'.
>   
>   You are in 'detached HEAD' state. You can look around, make experimental
>   changes and commit them, and you can discard any commits you make in this
>   state without impacting any branches by performing another checkout.
>   
>   If you want to create a new branch to retain commits you create, you may
>   do so (now or later) by using -b with the checkout command again. Example:
>   
>     git checkout -b <new-branch-name>
>   
>   HEAD is now at 9cb54a7... Merge pull request #1071 from jecisc/1070-Seaside-Tests-REST-is-never-referenced
>   lewis at lewis-Gazelle-Pro:~/squeak/Squeak5.2/Seaside-TEST/Seaside$ 
> 
> I may not have time to follow up on this in the next couple of days,
> but the problem that you spotted does sound serious. It suggests that
> the changes file is getting corrupted, and that is not supposed to
> be possible.
> 
> Dave
> 
> 
> 
> On Sun, Dec 16, 2018 at 11:04:11PM +0100, Max Leske wrote:
> > (resending because of wrong subject, sorry)
> > 
> > Hi Dave,
> > 
> > I just retested loading in Ubuntu 17.04 (32-bits) without problems. 
> > Maybe you didn't checkout the commit I referenced? I realise there's a 
> > `cd Seaside` missing before the `git checkout`.
> > 
> > What's the load error about? What system are you using exactly?
> > 
> > 
> > Cheers,
> > Max
> > 
> > On 16 Dec 2018, at 20:12, squeak-dev-request at lists.squeakfoundation.org 
> > wrote:
> > 
> > >I'm running into an error related to Metacello loading when I do the
> > >run.sh script in the recipe below, screen shot attached. I am running
> > >on Linux.
> > >
> > >It looks like I am missing something in the intial setup, can you give
> > >me a pointer?
> > >
> > >Thanks.
> > >Dave
> > >
> > >On Sun, Dec 16, 2018 at 06:14:47PM +0100, Max Leske wrote:
> > >
> > >>Hi,
> > >>
> > >>We have an issue in Seaside where a loaded test method holds a bad
> > >>source pointer. We only noticed because this method accesses the
> > >>debugger map.
> > >>
> > >>How to reproduce:
> > >>
> > >>1. clone SmalltalkCI:
> > >>	git clone git at github.com:hpi-swa/smalltalkCI.git
> > >>2. clone Seaside:
> > >>	git clone git at github.com:SeasideSt/Seaside.git;
> > >>	git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
> > >>3. install Seaside in Squeak5.2:
> > >>	<path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to
> > >>Seaside>/.smalltalk.ston
> > >>4. Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a
> > >>debugger pop up for an UndeclaredVariable. The source lookup is
> > >>performed in the changes file but in the middle of a chunk of binary
> > >>(font) data.
> > >>
> > >>I can can only speculate that some of that binary data introduces 
> > >>random
> > >>chunks which messes with the offsets.
> > >>
> > >>We're adding a workaround for that particular test for now.
> > >>
> > >>
> > >>Let me know if I can help track down the issue.
> > >>
> > >>Cheers,
> > >>Max
> 
> >