<div dir="ltr">Hola Guillaume,<div><br></div><div>Thank you for uploading the new packages!</div><div><br></div><div>I've just tested Ubuntu 20.04 and Centos 8</div><br>1) Ubuntu<div>1.1) curl -s <a href="https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.deb.sh">https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.deb.sh</a> | sudo bash<br>1.2) apt install varnish - installs 20200615.weekly<div>All is OK!</div><br>2) Centos<br>2.1) curl -s <a href="https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.rpm.sh">https://packagecloud.io/install/repositories/varnishcache/varnish-weekly/script.rpm.sh</a> | sudo bash<br>This adds varnishcache_varnish-weekly and varnishcache_varnish-weekly-source YUM repositories<br>2.2) yum install varnish - installs 6.0.2<br>2.3) yum --disablerepo="*" --enablerepo="varnishcache_varnish-weekly" list available  <br>Last metadata expiration check: 0:01:53 ago on Wed 17 Jun 2020 07:33:55 AM UTC.<br><br></div><div>there are no packages in the new yum repository!</div><br>2.4) I was able to localinstall it though <br>2.4.1) yum install jemalloc<br>2.4.2) wget --content-disposition <a href="https://packagecloud.io/varnishcache/varnish-weekly/packages/el/8/varnish-20200615.weekly-0.0.el8.aarch64.rpm/download.rpm">https://packagecloud.io/varnishcache/varnish-weekly/packages/el/8/varnish-20200615.weekly-0.0.el8.aarch64.rpm/download.rpm</a><br>2.4.3) yum localinstall varnish-20200615.weekly-0.0.el8.aarch64.rpm/download.rpm<div><br></div><div>Do I miss some step with the PackageCloud repository or there is some issue ?<br><br>Gracias,<br>Emilio</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 16 jun. 2020 a las 18:39, Guillaume Quintard (<<a href="mailto:guillaume@varnish-software.com">guillaume@varnish-software.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ola,<div><br></div><div>Pål just pushed Monday's batch, so you get amd64 and aarch64 packages for all the platforms. Go forth and test, the paint is still very wet.</div><div><br></div><div>Bonne journée!</div><div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 5:28 AM Emilio Fernandes <<a href="mailto:emilio.fernandes70@gmail.com" target="_blank">emilio.fernandes70@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,</div><div><br></div><div>When we could expect the new aarch64 binaries at <a href="https://packagecloud.io/varnishcache/varnish-weekly" target="_blank">https://packagecloud.io/varnishcache/varnish-weekly</a> ?</div><div><br></div><div>Gracias!</div><div>Emilio</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 15 abr. 2020 a las 14:33, Emilio Fernandes (<<a href="mailto:emilio.fernandes70@gmail.com" target="_blank">emilio.fernandes70@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue., 26 mar. 2020 a las 10:15, Martin Grigorov (<<a href="mailto:martin.grigorov@gmail.com" target="_blank">martin.grigorov@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>Here is the PR: <a href="https://github.com/varnishcache/varnish-cache/pull/3263" target="_blank">https://github.com/varnishcache/varnish-cache/pull/3263</a></div><div>I will add some more documentation about the new setup.</div><div>Any feedback is welcome!</div></div></blockquote><div><br></div><div>Nice work, Martin!</div><div><br></div><div>Gracias!</div><div>Emilio</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Martin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 9:55 PM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi, <br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020, 20:15 Guillaume Quintard <<a href="mailto:guillaume@varnish-software.com" target="_blank">guillaume@varnish-software.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">is that script running as root?</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. </div><div dir="auto">I also added 'USER root' to its Dockerfile and '-u 0' to 'docker run' arguments but it still doesn't work. </div><div dir="auto">The x86 build is OK. </div><div dir="auto">It must be something in the base docker image. </div><div dir="auto">I've disabled the Alpine aarch64 job for now. </div><div dir="auto">I'll send a PR tomorrow! </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Martin </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><div><div><div dir="ltr"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 2:30 AM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I've moved 'dist' job to be executed in parallel with 'tar_pkg_tools' and the results from both are shared in the workspace for the actual packing jobs.<br>Now the new error for aarch64-apk job is:<br><br>abuild: varnish >>> varnish: Updating the sha512sums in APKBUILD...<br> ]0; DEBUG: 4<br> ]0;abuild: varnish >>> varnish: Building /varnish 6.4.0-r1 (using abuild 3.5.0-r0) started Wed, 25 Mar 2020 09:22:02 +0000<br>>>> varnish: Checking sanity of /package/APKBUILD...<br>>>> WARNING: varnish: No maintainer<br>>>> varnish: Analyzing dependencies...<br>  0%                                             % ############################################>>> varnish: Installing for build: build-base gcc libc-dev libgcc pcre-dev ncurses-dev libedit-dev py-docutils linux-headers libunwind-dev python py3-sphinx<br>Waiting for repository lock<br>ERROR: Unable to lock database: Bad file descriptor<br>ERROR: Failed to open apk database: Bad file descriptor<br>>>> ERROR: varnish: builddeps failed<br> ]0; >>> varnish: Uninstalling dependencies...<br>Waiting for repository lock<br>ERROR: Unable to lock database: Bad file descriptor<br>ERROR: Failed to open apk database: Bad file descriptor</div><div><br></div><div>Google suggested to do this:<br>   rm -rf /var/cache/apk<br>   mkdir /var/cache/apk<br></div><div><br></div><div>It fails at 'abuild -r' - <a href="https://github.com/martin-g/varnish-cache/blob/b62c357b389c0e1e31e9c001cbffb55090c2e49f/.circleci/make-apk-packages.sh#L61" rel="noreferrer" target="_blank">https://github.com/martin-g/varnish-cache/blob/b62c357b389c0e1e31e9c001cbffb55090c2e49f/.circleci/make-apk-packages.sh#L61</a></div><div><br></div><div>Any hints ?</div><div><br></div><div>Martin</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 2:39 AM Guillaume Quintard <<a href="mailto:guillaume@varnish-software.com" rel="noreferrer" target="_blank">guillaume@varnish-software.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>So, you are pointing at the `dist` job, whose sole role is to provide us with a dist tarball, so we don't need that command line to work for everyone, just for that specific platform.</div><div><br></div><div>On the other hand, <a href="https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/.circleci/config.yml#L168" rel="noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/.circleci/config.yml#L168</a> is closer to what you want, `distcheck` will be call on all platform, and you can see that it has the `--with-unwind` argument.<br clear="all"><div><div dir="ltr"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 3:05 PM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020, 17:19 Guillaume Quintard <<a href="mailto:guillaume@varnish-software.com" rel="noreferrer" target="_blank">guillaume@varnish-software.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Compare your configure line with what's currently in use (or the apkbuild file), there are a few options (with-unwind, without-jemalloc, etc.) That need to be set</div></blockquote></div></div><div dir="auto"><br></div><div>The configure line comes from "./autogen.des": <a href="https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/autogen.des#L35-L42" rel="noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/autogen.des#L35-L42</a></div><div>It is called at:</div><div><a href="https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/.circleci/config.yml#L40" rel="noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/4f9d8bed6b24bf9ee900c754f37615fdba1c44db/.circleci/config.yml#L40</a></div><div>In my branch at:</div><div><a href="https://github.com/martin-g/varnish-cache/blob/4b4626ee9cc366b032a45f27b54d77176125ef03/.circleci/make-apk-packages.sh#L26" rel="noreferrer" target="_blank">https://github.com/martin-g/varnish-cache/blob/4b4626ee9cc366b032a45f27b54d77176125ef03/.circleci/make-apk-packages.sh#L26</a><br></div><div><br></div><div dir="auto">It fails only on aarch64 for Alpine Linux. The x86_64 build for Alpine is fine. </div><div dir="auto">AARCH64 for CentOS 7 and Ubuntu 18.04 are also fine.</div><div dir="auto"><br></div><div>Martin</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020, 08:05 Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 11:00 AM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Guillaume,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 8:01 PM Guillaume Quintard <<a href="mailto:guillaume@varnish-software.com" rel="noreferrer noreferrer noreferrer" target="_blank">guillaume@varnish-software.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Martin,<div><br></div><div>Thank you for that.</div><div>A few remarks and questions:</div><div>- how much time does the "docker build" step takes? We can possibly speed things up by push images to the dockerhub, as they don't need to change very often.</div></div></blockquote><div><br></div><div>Definitely such optimization would be a good thing to do!</div><div>At the moment, with 'machine' executor it fetches the base image and then builds all the Docker layers again and again.</div><div>Here are the timings:</div><div>1) Spinning up a VM - around 10secs</div><div>2) prepare env variables - 0secs</div><div>3) checkout code (varnish-cache) - 5secs</div><div>4) activate QEMU - 2secs</div><div>5) build packages</div><div>5.1) x86 deb - 3m 30secs</div><div>5.2) x86 rpm - 2m 50secs</div><div>5.3) aarch64 rpm - 35mins</div><div>5.4) aarch64 deb - 45mins</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- any reason why you clone pkg-varnish-cache in each job? The idea was to have it cloned once in tar-pkg-tools for consistency and reproducibility, which we lose here.</div></div></blockquote><div><br></div><div>I will extract the common steps once I see it working. This is my first CircleCI project and I still find my ways in it!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- do we want to change things for the amd64 platforms for the sake of consistency?</div></div></blockquote><div><br></div><div>So far there is nothing specific for amd4 or aarch64, except the base Docker images.</div><div>For example make-deb-packages.sh is reused for both amd64 and aarch64 builds. Same for -rpm- and now for -apk- (alpine).</div><div><br></div><div>Once I feel the change is almost finished I will open a Pull Request for more comments!</div><div><br></div><div>Martin</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><div><div><div dir="ltr"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 6:25 AM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 18, 2020 at 5:31 PM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 4:35 PM Martin Grigorov <<a href="mailto:martin.grigorov@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">martin.grigorov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Guillaume,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 3:23 PM Guillaume Quintard <<a href="mailto:guillaume@varnish-software.com" rel="noreferrer noreferrer noreferrer" target="_blank">guillaume@varnish-software.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>Offering arm64 packages requires a few things:</div><div>- arm64-compatible code (all good in <a href="https://github.com/varnishcache/varnish-cache" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache</a>)</div><div>- arm64-compatible package framework (all good in <a href="https://github.com/varnishcache/pkg-varnish-cache" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/varnishcache/pkg-varnish-cache</a>)</div><div>- infrastructure to build the packages (uhoh, see below)</div><div>- infrastructure to store and deliver (<a href="https://packagecloud.io/varnishcache" rel="noreferrer noreferrer noreferrer" target="_blank">https://packagecloud.io/varnishcache</a>)</div><div><br></div><div>So, everything is in place, expect for the third point. At the moment, there are two concurrent CI implementations:</div><div>- travis: <a href="https://github.com/varnishcache/varnish-cache/blob/master/.travis.yml" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/master/.travis.yml</a> It's the historical one, and currently only runs compilation+test for OSX</div></div></div></blockquote><div><br></div><div>Actually it tests Linux AMD64 and ARM64 too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>- circleci: <a href="https://github.com/varnishcache/varnish-cache/blob/master/.circleci/config.yml" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/master/.circleci/config.yml</a> the new kid on the block, that builds all the packages and distchecks for all the packaged platforms</div><div><br></div><div>The issue is that cirecleci doesn't support arm64 containers (for now?), so we would need to re-implement the packaging logic in Travis. It's not a big problem, but it's currently not a priority on my side.</div><div><br></div><div>However, I am totally ready to provide help if someone wants to take that up. The added benefit it that Travis would be able to handle everything and we can retire the circleci experiment</div></div></div></blockquote><div><br></div><div>I will take a look in the coming days and ask you if I need help!</div></div></div></blockquote><div><br></div><div>I've took a look at the current setup and here is what I've found as problems and possible solutions:</div><div><br></div><div>1) Circle CI</div><div>1.1) problem - the 'machine' and 'Docker' executors run on x86_64, so there is no way to build the packages in a "native" environment</div><div>1.2) possible solutions</div><div>1.2.1) use multiarch cross build</div><div>1.2.2) use 'machine' executor that registers QEMU via <a href="https://hub.docker.com/r/multiarch/qemu-user-static/" rel="noreferrer noreferrer noreferrer" target="_blank">https://hub.docker.com/r/multiarch/qemu-user-static/</a> and then builds and runs a custom Docker image that executes a shell script with the build steps</div><div>It will look something like <a href="https://github.com/yukimochi-containers/alpine-vpnserver/blob/69bb0a612c9df3e4ba78064d114751b760f0df9d/.circleci/config.yml#L19-L38" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/yukimochi-containers/alpine-vpnserver/blob/69bb0a612c9df3e4ba78064d114751b760f0df9d/.circleci/config.yml#L19-L38</a> but instead of uploading the Docker image as a last step it will run it.</div><div>The RPM and DEB build related code from current config.yml will be extracted into shell scripts which will be copied in the custom Docker images </div><div><br></div><div>From these two possible ways I have better picture in my head how to do 1.2.2, but I don't mind going deep in 1.2.1 if this is what you'd prefer.</div></div></div></blockquote><div><br></div><div>I've decided to stay with Circle CI and use 'machine' executor with QEMU.</div><div><br></div><div>The changed config.yml could be seen at <a href="https://github.com/martin-g/varnish-cache/tree/feature/aarch64-packages/.circleci" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/martin-g/varnish-cache/tree/feature/aarch64-packages/.circleci</a> and the build at <a href="https://app.circleci.com/pipelines/github/martin-g/varnish-cache/71/workflows/3a275d79-62a9-48b4-9aef-1585de1c87c8" rel="noreferrer noreferrer noreferrer" target="_blank">https://app.circleci.com/pipelines/github/martin-g/varnish-cache/71/workflows/3a275d79-62a9-48b4-9aef-1585de1c87c8</a></div><div>The builds on x86 arch take 3-4 mins, but for aarch64 (emulation!) ~40mins</div><div>For now the jobs just build the .deb & .rpm packages for CentOS 7 and Ubuntu 18.04, both amd64 and aarch64. </div><div>TODOs:</div><div>- migrate Alpine</div></div></div></blockquote></div></blockquote></div></div></blockquote><div><br></div><div>Build on Alpine aarch64 fails with:</div><div>...<br>automake: this behaviour will change in future Automake versions: they will<br>automake: unconditionally cause object files to be placed in the same subdirectory<br>automake: of the corresponding sources.<br>automake: project, to avoid future incompatibilities.<br>parallel-tests: installing 'build-aux/test-driver'<br>lib/libvmod_debug/Makefile.am:12: warning: libvmod_debug_la_LDFLAGS multiply defined in condition TRUE ...<br>lib/libvmod_debug/<a href="http://automake_boilerplate.am:19" rel="noreferrer noreferrer noreferrer" target="_blank">automake_boilerplate.am:19</a>: ... 'libvmod_debug_la_LDFLAGS' previously defined here<br>lib/libvmod_debug/Makefile.am:9:   'lib/libvmod_debug/<a href="http://automake_boilerplate.am" rel="noreferrer noreferrer noreferrer" target="_blank">automake_boilerplate.am</a>' included from here<br>+ autoconf<br>+ CONFIG_SHELL=/bin/sh<br>+ export CONFIG_SHELL<br>+ ./configure '--prefix=/opt/varnish' '--mandir=/opt/varnish/man' --enable-maintainer-mode --enable-developer-warnings --enable-debugging-symbols --enable-dependency-tracking --with-persistent-storage --quiet<br>configure: WARNING: dot not found - build will fail if svg files are out of date.<br>configure: WARNING: No system jemalloc found, using system malloc<br>configure: error: Could not find backtrace() support</div><div><br></div><div>Does anyone know a workaround ?</div><div>I use multiarch/alpine:aarch64-edge as a base Docker image </div><div><br></div><div>Martin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- store the packages as CircleCI artifacts</div><div>- anything else that is still missing</div><div><br></div><div>Adding more architectures would be as easy as adding a new Dockerfile with a base image from the respective type.</div><div><br></div><div>Martin</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>2) Travis CI</div><div>2.1) problems</div><div>2.1.1) generally Travis is slower than Circle! </div><div>Althought if we use CircleCI 'machine' executor it will be slower than the current 'Docker' executor!</div><div>2.1.2) Travis supports only Ubuntu</div><div>Current setup at CircleCI uses CentOS 7.</div><div>I guess the build steps won't have problems on Ubuntu.</div><div><br></div><div>3) GitHub Actions</div><div>GH Actions does not support ARM64 but it supports self hosted ARM64 runners</div><div>3.1) The problem is that there is no way to make a self hosted runner really private. I.e. if someone forks Varnish Cache any commit in the fork will trigger builds on the arm64 node. There is no way to reserve the runner only for commits against</div><div><a href="https://github.com/varnishcache/varnish-cache" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache</a><br></div><div><br></div><div>Do you see other problems or maybe different ways ?</div><div>Do you have preferences which way to go ?</div><div><br></div><div>Regards,</div><div>Martin</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Regards,</div><div>Martin</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div><div><div dir="ltr"><div dir="ltr"><div>-- <br></div>Guillaume Quintard</div></div></div></div></div></div>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org" rel="noreferrer noreferrer noreferrer" target="_blank">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div></div>
</div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>