<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On 23 Mar 2016, at 11:06, Fabrice Le Fessant <<a href="mailto:Fabrice.Le_fessant@inria.fr" class="">Fabrice.Le_fessant@inria.fr</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Anil,<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Mar 23, 2016 at 11:53 AM Anil Madhavapeddy <<a href="mailto:anil@recoil.org" class="">anil@recoil.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">The build bot looks like it could also benefit from the container infrastructure, since that takes care of depexts for a number of distributions.</div></div></blockquote><div class=""><br class=""></div><div class="">Currently, we use the same computer for all compilations (my personal server at OVH), which means we have only one configuration of external packages. It's both a good thing (we can re-use binaries from previous compilations) but also a limitation (we cannot compile two packages that would have conflicting external dependencies). Indeed, running the bot on a large number of distributions would solve that later issue.</div></div></div></div></blockquote><div><br class=""></div>Makes sense. If your server is running Linux, then you should be able to wrap the entire opam-builder in a Docker container. That will give you an environment in which you can install external dependencies without contaminating the host, and also run different Linux distributions. There are details of all the distribution images with OCaml and OPAM up at <a href="https://hub.docker.com/u/ocaml" class="">https://hub.docker.com/u/ocaml</a></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Before I look further at this, I just wanted to confirm that the licensing of the buildbot is intended to be fully AGPLv3. It looks like there's a fork of opamLib here: <a href="https://github.com/OCamlPro/opam-builder/tree/master/libs/copam" target="_blank" class="">https://github.com/OCamlPro/opam-builder/tree/master/libs/copam</a> renamed under the copam namespace.</div></div></blockquote><div class=""><br class=""></div><div class="">Yes, everything should be AGPLv3 with an attribution exception, except some LGPL files that should have kept their original license. Copam itself is not a copy of opamLib, but a wrapper around the opam command. There are maybe a few files which were taken from OPAM (the Debian versioning, the lexer and parser for OPAM files), they should be under LGPLv3. I will check that the original headers for these files were kept, indeed.</div></div></div></div></blockquote><br class=""></div><div>Thanks for clarifying. I'm unable to contribute to AGPLv3 code myself, so I won't be able to look at opam-builder directly. Others may be able to -- please let me know if you need <a href="http://ocaml.org" class="">ocaml.org</a> infrastructure provisioned for it.</div><div><br class=""></div><div>regards,</div><div>Anil</div><br class=""></body></html>