Thank you Sven. That fixed my first problem. Sadly the other problem is more persitent than this.
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 > >
