> 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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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 <https://ferlicot.fr/> >> >
