Hi, 

yes, Iceberg will solve this problem by not having it, but it would be nice to 
be able to unzip bigger files from Pharo too (ok, maybe not a priority, but it 
would be cool anyway :P) 

Esteban

> On 15 Mar 2017, at 13:07, Pavel Krivanek <[email protected]> wrote:
> 
> To clone the repository from Pharo we can use Iceberg:
> 
> IceRepositoryCreator new 
>       remote: (IceRemote url: 'https://github.com/guillep/pharo-core.git' 
> <https://github.com/guillep/pharo-core.git'>);
>       location: ('pharo-core' asFileReference ensureCreateDirectory);
>       createRepository.
> 
> 2017-03-15 11:31 GMT+01:00 Thierry Goubier <[email protected] 
> <mailto:[email protected]>>:
> Hi Pavel,
> 
> Which means command like these:
> 
> cd pharo; mkdir filetree; cd filetree; wget -O - 
> https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev 
> <https://api.github.com/repos/dalehenrich/filetree/tarball/pharo6.0_dev> | 
> tar xz --strip-components=1
> 
> ./pharo-cli pharo/Pharo.image --no-default-preferences eval --save Metacello 
> new baseline: \'FileTree\'\; repository: 
> \'filetree:///`pwd`/pharo/filetree/repository\'\; load: \'Git\'.
> 
> recovering the tarball can be a lot faster than doing a local clone, and 
> FileTree is not interested in the git history anyway...
> 
> Thierry
> 
> 
> 2017-03-15 11:18 GMT+01:00 Pavel Krivanek <[email protected] 
> <mailto:[email protected]>>:
> Hi,
> 
> our current Compression package does not support Zip64 which is limiting us 
> in usage of Metacello together with Git. When we use the Metacello for 
> installing of a baseline like:
> 
> Metacello new
>   baseline: 'IDE';
>   repository: 'github://guillep/pharo-core';
>   load.
> 
> then the Metacello downloads the corresponding archive from Github. However 
> the standard Zip archives have count limit of 65535 members but the 
> pharo-core repository and some others contain much more than this (pharo-core 
> has 125021 files). The Zip64 extension is used for them during compression 
> which we cannot read now.
> 
> So if you will see Error: bad signature 16r... at position ..., then it has 
> this reason. The workaround for now is to load projects from a local clone of 
> such big repositories.
> 
> Cheers,
> -- Pavel
> 
> 

Reply via email to