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

[Fabio Niephaus]

On Sun, 23 Dec 2018 at 1:34 pm, Ben Coman <btc at openinworld.com> wrote:

>
>
>
> 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.
>

Agreed. Git is not designed to store large files and removing large files
from the history was the most annoying part when we migrated from SVN to
Git.


>
>> 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...
>

I'm in favor of keeping the VM as independent as possible, so I'd like a
solution everyone can easily contribute to.


>
>> 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
>

I hope third party libs only need to be compiled once after a fresh
checkout. To avoid this overhead, we cache all of this on CI. But I agree,
the real problem is that some external plugins require third party libs and
are part of the OSVM repo. Why do we have a VM which is easy to extend if
we don't use that mechanism? So +1 for externalizing external plugins into
other repos under the OpenSmallalk umbrella. This way, breaking a plugin
doesn't break the rest of the VM.

Fabio

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