> On 11 Jul 2018, at 19:50, Norbert Hartl <[email protected]> wrote:
>
> Thank you Sven. That fixed my first problem. Sadly the other problem is more
> persitent than this.
I would guess that the other problem (the ZipArchive usage) might be related to
the recent file/stream changes in Pharo 7 and not related to the loading of
Zinc. The bug might be a binary/text stream mixup or the usage of deprecated
code.
> Norbert
>
>> Am 11.07.2018 um 16:46 schrieb Sven Van Caekenberghe <[email protected]>:
>>
>> FWIW, I created a new #stable version 2.9.3 that includes a newer
>> Zinc-FileSystem-SvenVanCaekenberghe.16 - maybe this helps.
>>
>> ===
>> Name: Zinc-FileSystem-SvenVanCaekenberghe.16
>> Author: SvenVanCaekenberghe
>> Time: 11 July 2018, 4:30:36.923152 pm
>> UUID: 830fbcd3-1b2d-0d00-bd45-164704867404
>> Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.15
>>
>> Force an update (class comment changed)
>> ===
>>
>>> On 10 Jul 2018, at 09:17, Max Leske <[email protected]> wrote:
>>>
>>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote:
>>>
>>>> Max,
>>>>
>>>> thanks for taking the effort.
>>>
>>> No worries.
>>>
>>>>
>>>>> 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.
>>>
>>> Let me know once you have something and I'll try to help out.
>>>
>>>>
>>>> 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
>>
>>
>
>
