[Vm-dev] missing dependency ftp://.../libpng-1.6.29.tar.gz

[Ben Coman]

On Sun, 23 Dec 2018 at 01:56, Fabio Niephaus <lists at fniephaus.com> wrote:

>
> Hi all,
>
> On Sat, Dec 22, 2018 at 6:28 PM Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
> >
> >
> > Submodule is also a possibility. If the repo is not on github, we could
> clone it under opensmalltalk in order to reduce web failures.
> >
> > Le sam. 22 déc. 2018 à 14:45, Eliot Miranda <eliot.miranda at gmail.com> a
> écrit :
> >>
> >>
> >> Hi Ben,
> >>
> >> On Dec 22, 2018, at 5:09 AM, Ben Coman <btc at openinworld.com> wrote:
> >>
> >> It funny when the system seems to fight back.
> >> Just as I think I resolve my freetype build issues,
> >> my Windows build started failing as follows...
> >> > wget -q --no-check-certificate  -O
> ../../.thirdparty-cache/libpng-1.6.29.tar.gz
> ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/libpng-1.6.29.tar.gz
> >> > make: *** [../third-party/Makefile.libpng:19:
> ../../.thirdparty-cache/libpng-1.6.29.tar.gz] Error 8
> >>
> >> What I see at ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/
> >> is...
> >> Name                           Size   Date Modified
> >> libpng-1.6.34-LICENSE.txt    4.9 kB   29/09/2017, 08:00:00
> >> libpng-1.6.34-README.txt      96 3B   29/09/2017, 08:00:00
> >> libpng-1.6.34.tar.gz         1.4 MB   29/09/2017, 08:00:00
> >> libpng-1.6.34.tar.gz.asc      819 B   29/09/2017, 08:00:00
> >> libpng-1.6.34.tar.xz         975 kB   29/09/2017, 08:00:00
> >> libpng-1.6.34.tar.xz.asc      819 B   29/09/2017, 08:00:00
> >> lpng1634.7z                  734 kB   29/09/2017, 08:00:00
> >> lpng1634.7z.asc               819 B   29/09/2017, 08:00:00
> >> lpng1634.zip                 1.3 MB   29/09/2017, 08:00:00
> >> lpng1634.zip.asc              819 B   29/09/2017, 08:00:00
> >>
> >> So did version 1.6.29 exist yesterday but not today?
> >> or am I going crazy?
> >>
> >>
> >> :-(
> >>
> >> Anyway, should our builds avoid referencing external resources not
> under our control?  Or would it be be better to copy the required tar files
> to a server our community controls, (either files.opensmalltalk.org or
> file.pharo.org)?
> >>
> >>
> >> I don’t see how the former is possible :-(. Do some variation of the
> latter is necessary.  I like your suggestion of files.pharo.org;
> files.opensmalltalk.org doesn’t exist and do would need funding.  I think
> adding the tar files to opensmalltalk-vm itself would be a huge mistake; it
> would cause the repository to bloat quite quickly right?


Yes. I agree.


> So what are the logistics of using files.pharo.org?
>

That would be up to Esteban, et al,
but Fabio's suggestion might be a better way to go...


> How about something like this:
> https://github.com/OpenSmalltalk/opensmalltalk-vm-dependencies
>
> We basically maintain a second repository with links to all
> dependencies and mirror corresponding files as part of a single GitHub
> release (see [1] for limitations). Advantages: free plus TravisCI and
> AppVeyor optimize their network connection to GitHub.


> Example release:
> https://github.com/OpenSmalltalk/opensmalltalk-vm-dependencies/releases
>
> Example download link:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm-dependencies/releases/download/latest/libpng-1.6.29.tar.gz


... but actually, like Nicolas suggests I've often thought keeping a local
fork of dependencies
 to be a pragmatic safety measure (e.g. under a branch called "mirror").
But since we end up with dll and so files
I wonder if there is another path than using submodules.  When a newcomer
freshly clones opensmalltalk-vm
the majority of build time for pharo.cog.spur is the third-party
libraries.  This seems a bit of a waste
when those dependencies don't change often.  If we have a repo per
dependency a CI build
could "release" built dependent dll and so files.  So these could be
downloaded rather than built each time.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181223/c965f474/attachment.html>