Max, thanks for taking the effort.
> Am 10.07.2018 um 08:37 schrieb Max Leske <[email protected]>: > > I did my best to reproduce the issue but didn't have any luck. I really need > access to a Linux VM to debug this. So I'm praying that Apple fixes the > access restrictions to kernel extensions in their next beta... > > BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is > indeed a chance that something goes wrong during download of the zip archive > and that something may be tied to a difference in the versions of Zinc > (although I still think that's unlikely). > Yes there is potential but I don‘t see it. I take a fresh 6.1 image and load my project into. I‘m not sure but I think zinc 2.9.2 is loaded rather early in that process. So I wonder why it does not go wrong in the first phase. And also not if I load the test group within the first phase. It must be either the second Metacello invocation or the stopping, copying and starting of the image. I try to isolate this case more and provide a script that goes wrong on my machine. But it will take some time because I needed to stop trying to solve this as I wasted nearly two days on that already. Norbert > Max > > > On 9 Jul 2018, at 19:43, Norbert Hartl wrote: > > > >> Am 09.07.2018 um 19:10 schrieb Max Leske <[email protected]>: >> >> I checked the Parasol Archive and it does not appear to be in Zip64 format >> (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can >> read the Parasol zip). So my next guess is that there's either a problem >> with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness >> problem or non-binary stream data). It would therefore be helpful to find >> out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is >> passed / opened, is it binary, does the file exist and is it still the >> correct file. >> >> > I couldn’t see anything obvious. The file in the debug message exists, it is > a readable zip file. The way Metacello uses it it is a StandardFileStream. It > switches it to binary in the code. > But the only difference between a working and non-working build is the > upgrade to zinc 2.9.2. > > Norbert > >> I'd debug it myself but I can't run VirtualBox at the moment because I'm on >> the macOS beta and it won't start... >> >> Max >> >> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >> >> Hi Max, >> >> >>> Am 09.07.2018 um 18:18 schrieb Max Leske <[email protected]>: >>> >>> Hi Norbert, >>> >>> This is a bit of a guess, but it's possible that the archive that is >>> downloaded from github is in Zip64 format and that the libraries for >>> extracting Zip64 are missing on your Linux. That would of course contradict >>> the experience that the same operation appears to work in 6.1. >>> >>> >> to be honest I don’t know what Zip64 format is. I thought the Zip classes >> are pure smalltalk for unpacking. >>> Try extracting the archive manually on your Linux machine with the same >>> method that Metacello uses (I assume, Metacello uses the ZipPlugin, which >>> will probably use the system libraries). >>> >>> >> >> I have no ZipPlugin as library in any of my vms. >> >> But there are zips downloaded and unpacked. I start the image the first time >> loading all the code of my project. Then it is saved, copied to a new name >> and reopened to load the tests and then it fails. I did try to load the >> tests in the first run and then it works. >> >> I’m running out of ideas >> >> thanks, >> >> Norbert >>> Cheers, >>> Max >>> >>> >>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>> >>> With the help of Esteban I got one step further. If I do >>> >>> MCWorkingCopy >>> managersForClass: ZnFileSystemUtils >>> do: [ :each | each ancestry initialize ] >>> >>> before loading my project it updates Zinc-FileSystem as well. Sadly it >>> still does not work for me because I get >>> >>> Loading baseline of BaselineOfMobilityMap... >>> ...RETRY->BaselineOfParasol >>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>> >>> and I don’t know why. zip file is downloaded from github and present but it >>> fails and only on my jenkins on linux. On my Mac this works. >>> >>> I try a few things but then I’m back on pharo6.1 for the time being :( >>> >>> Norbert >>> >>> >>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl <[email protected]>: >>>> >>>> Really? I thought the same but then I didn’t believe it works like that. >>>> >>>> Anyway this would be very easy to solve. We just need to ask Sven if he is >>>> fine with doing an empty .16 version for Zinc-FileSystem and does an >>>> in-place version reset of 2.9.2 or a new 2.9.3. I’m not fully convinced >>>> that will solve it but the cost won’t be very high. >>>> >>>> Norbert >>>> >>>> >>>>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot <[email protected]>: >>>>>> >>>>>> >>>>> >>>>>> Need to investigate more. There are two .15 versions but there is 1 year >>>>>> in between (if you didn’t notice TheIntegratior.15 is from 2017). Just >>>>>> want to have more context information because I can only see that this >>>>>> is strange but lacking insight. >>>>>> >>>>>> I’m trying to figure out why it does not update Zinc-FileSystem. No >>>>>> matter what I do I cannot get Metacello to load the newer package. That >>>>>> would fix the issue because I’m loading 2.9.2 which should have >>>>>> Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>>>>> >>>>>> I think this is important for everyone that has a product based on 6.1 >>>>>> and that want to migrate someday to pharo7. This way it is impossible to >>>>>> do it step by step. >>>>> >>>>> If there is a package .15 in the image and a package .15 in the repo, I >>>>> think Metacello will not update because it rely on the numbers to know >>>>> when to update. If it find a .15 and currently have a .15 I think >>>>> Metacello will think they are at the same version. >>>>> >>>>>> >>>>>> >>>>>> Norbert >>>>>> >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>> -- >>>>> Cyril Ferlicot >>>>> https://ferlicot.fr >>>> >>> >> >
