Re: [PATCH] CI: travis-ci: disable arm64 builds

[Martin Grigorov]

Hi Илья,

On Mon, Aug 9, 2021 at 12:45 PM Илья Шипицин  wrote:

> I'm using arm64 in Oracle Cloud Ampere A1 Compute | Oracle
> 
>

Yes!
OCI has an ARM64 VM in their free tier!
They also provide easy integration with GitHub Actions -
https://blogs.oracle.com/cloud-infrastructure/post/announcing-github-actions-arm-runners-for-the-arm-compute-platform-on-oracle-cloud-infrastructure
But the issue here is that GitHub Actions self-hosted runners are not
recommended for public/OSS projects because bad people can execute malware
on your VM via (meaningless) Pull Requests.


>
>
> also, I've found promising approach (using ARM on Github Actions)  Bump
> Bootstrap version from 5.0.2 to 5.1.0 · phpmyadmin/phpmyadmin@c90affe
> (github.com) 
>

This setup uses QEMU -
https://github.com/phpmyadmin/phpmyadmin/blob/c90affe793b56fb6f5e1c7eed676ec9031fb1480/.github/workflows/tests.yml#L51
.
It works but it is much slower than using a real ARM64 machine/VM.

Martin


> пн, 9 авг. 2021 г. в 14:29, Willy Tarreau :
>
>> Hi Martin,
>>
>> On Mon, Aug 09, 2021 at 11:04:34AM +0300, Martin Grigorov wrote:
>> > TravisCI just announced some improvements related to 'arch: arm64'
>> (using
>> > Equnix Metal machines) -
>> https://blog.travis-ci.com/2021-08-06-oss-equinix.
>>
>> Thanks for the info!
>>
>> > But I also had some similar problems with them recently and replaced the
>> > config with 'arch: arm64-graviton2; group: edge; virt: vm;', i.e. AWS
>> > Graviton2 machines. In my experience they behave more stable!
>>
>> Yeah, these machines are really fantastic. The real problem anyway is
>> likely that nowadays everyone is interested in testing on arm and very
>> few have one available, let alone even a cross-compiler, so I suspect
>> that these days a lot of people enable arm builds in such CI environments
>> because it's the only way they have to make sure their code builds there
>> at all.
>>
>> Cheers,
>> Willy
>>
>

Re: [PATCH] CI: travis-ci: disable arm64 builds

[Martin Grigorov]

Hi Willy,

On Mon, Aug 9, 2021 at 12:29 PM Willy Tarreau  wrote:

> Hi Martin,
>
> On Mon, Aug 09, 2021 at 11:04:34AM +0300, Martin Grigorov wrote:
> > TravisCI just announced some improvements related to 'arch: arm64' (using
> > Equnix Metal machines) -
> https://blog.travis-ci.com/2021-08-06-oss-equinix.
>
> Thanks for the info!
>
> > But I also had some similar problems with them recently and replaced the
> > config with 'arch: arm64-graviton2; group: edge; virt: vm;', i.e. AWS
> > Graviton2 machines. In my experience they behave more stable!
>
> Yeah, these machines are really fantastic. The real problem anyway is
> likely that nowadays everyone is interested in testing on arm and very
> few have one available, let alone even a cross-compiler, so I suspect
> that these days a lot of people enable arm builds in such CI environments
> because it's the only way they have to make sure their code builds there
> at all.
>

I am not sure whether you understood me. Or maybe I didn't understand you.
Anyway, let me rephrase:
TravisCI provides two types of ARM64 VMs - arm64 (powered by Equinix Metal)
and arm64-graviton2 (by AWS Graviton2).
You, as a user, can use any or both of them in your .travis.yml.
I prefer the AWS Graviton2 instances because there are less issues with
them.
So, instead of disabling the ARM64 CI job I suggest to try with
arm64-graviton2. Here is a sample setup for it -
https://github.com/apache/wicket/blob/270a5a43970cd975539331b21a34bd83a59c9c39/.travis.yml#L18-L22
More info about it at https://blog.travis-ci.com/2020-09-11-arm-on-aws

Martin


>
> Cheers,
> Willy
>

Re: [PATCH] CI: travis-ci: disable arm64 builds

[Илья Шипицин]

I'm using arm64 in Oracle Cloud Ampere A1 Compute | Oracle



also, I've found promising approach (using ARM on Github Actions)  Bump
Bootstrap version from 5.0.2 to 5.1.0 · phpmyadmin/phpmyadmin@c90affe
(github.com) 

пн, 9 авг. 2021 г. в 14:29, Willy Tarreau :

> Hi Martin,
>
> On Mon, Aug 09, 2021 at 11:04:34AM +0300, Martin Grigorov wrote:
> > TravisCI just announced some improvements related to 'arch: arm64' (using
> > Equnix Metal machines) -
> https://blog.travis-ci.com/2021-08-06-oss-equinix.
>
> Thanks for the info!
>
> > But I also had some similar problems with them recently and replaced the
> > config with 'arch: arm64-graviton2; group: edge; virt: vm;', i.e. AWS
> > Graviton2 machines. In my experience they behave more stable!
>
> Yeah, these machines are really fantastic. The real problem anyway is
> likely that nowadays everyone is interested in testing on arm and very
> few have one available, let alone even a cross-compiler, so I suspect
> that these days a lot of people enable arm builds in such CI environments
> because it's the only way they have to make sure their code builds there
> at all.
>
> Cheers,
> Willy
>

Re: [PATCH] CI: travis-ci: disable arm64 builds

[Willy Tarreau]

Hi Martin,

On Mon, Aug 09, 2021 at 11:04:34AM +0300, Martin Grigorov wrote:
> TravisCI just announced some improvements related to 'arch: arm64' (using
> Equnix Metal machines) - https://blog.travis-ci.com/2021-08-06-oss-equinix.

Thanks for the info!

> But I also had some similar problems with them recently and replaced the
> config with 'arch: arm64-graviton2; group: edge; virt: vm;', i.e. AWS
> Graviton2 machines. In my experience they behave more stable!

Yeah, these machines are really fantastic. The real problem anyway is
likely that nowadays everyone is interested in testing on arm and very
few have one available, let alone even a cross-compiler, so I suspect
that these days a lot of people enable arm builds in such CI environments
because it's the only way they have to make sure their code builds there
at all.

Cheers,
Willy

Re: [PATCH] CI: travis-ci: disable arm64 builds

[Martin Grigorov]

Hi,

On Sat, Aug 7, 2021 at 8:31 AM Willy Tarreau  wrote:

> Hi Ilya,
>
> On Tue, Aug 03, 2021 at 02:58:40PM +0500,  ??? wrote:
> > Hello,
> >
> > it looks like "something on travis-ci side".
> >
> > CC  src/raw_sock.o
> > gcc: fatal error: Killed signal terminated program cc1
> > compilation terminated.
> >
> > let us disable arm64 for a while.
>

TravisCI just announced some improvements related to 'arch: arm64' (using
Equnix Metal machines) - https://blog.travis-ci.com/2021-08-06-oss-equinix.
But I also had some similar problems with them recently and replaced the
config with 'arch: arm64-graviton2; group: edge; virt: vm;', i.e. AWS
Graviton2 machines. In my experience they behave more stable!

Regards,
Martin


>
> Yes I noticed a few of these lately, and sometimes it even looked like
> impossible downloads. I suspect that github assigns a maximum runtime
> to these VMs and that they're simply overloaded and victims of their
> success. I could be wrong of course.
>
> Now applied, thank you!
> Willy
>
>

Re: [PATCH] CI: travis-ci: disable arm64 builds

[Willy Tarreau]

Hi Ilya,

On Tue, Aug 03, 2021 at 02:58:40PM +0500,  ??? wrote:
> Hello,
> 
> it looks like "something on travis-ci side".
> 
> CC  src/raw_sock.o
> gcc: fatal error: Killed signal terminated program cc1
> compilation terminated.
> 
> let us disable arm64 for a while.

Yes I noticed a few of these lately, and sometimes it even looked like
impossible downloads. I suspect that github assigns a maximum runtime
to these VMs and that they're simply overloaded and victims of their
success. I could be wrong of course.

Now applied, thank you!
Willy

[PATCH] CI: travis-ci: disable arm64 builds

[Илья Шипицин]

Hello,

it looks like "something on travis-ci side".

CC  src/raw_sock.o
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.


let us disable arm64 for a while.

Ilya
From a06f34da9d0eb50a95776aafa097341ea1459430 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Tue, 3 Aug 2021 14:54:09 +0500
Subject: [PATCH] CI: travis-ci: temporarily disable arm64 builds

few recent builds failed with "gcc: fatal error: Killed signal
terminated program cc1", let us disable arm64 builds until investigation
---
 .travis.yml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 3083e302c..7f5110e32 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -22,10 +22,10 @@ matrix:
 arch: ppc64le
 compiler: gcc
 if: type == cron
-  - os: linux
-arch: arm64
-compiler: gcc
-if: type == cron
+#  - os: linux
+#arch: arm64
+#compiler: gcc
+#if: type == cron
   - os: linux
 arch: arm64-graviton2
 group: edge
-- 
2.29.2.windows.2

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Hi Willy,

On Fri, May 15, 2020 at 6:07 PM Willy Tarreau  wrote:

> Ilya,
>
> > also, I'd suggest to purge travis-ci cache (if you are build in your own
> > fork).
> > some travis related issue might be related when something is took from
> > cache (which was not supposed to happen)
>
> Could you please handle Martin's patch, possibly cut it into several
> pieces if relevant and add a commit message indicating what it does
> (and why) ? Martin is not at ease with Git (which is not a problem),
> and it seems only him and you understand how the reasons of the changes
> in his patch. At least it's totally unclear to me why there's a new
> install target for arm64 and why there's a special "make" invocation
> there.
>

Let me explain the change.
At
https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L113-L117
you
may see the default 'install' phase.
At
https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L12-L19
is
the default environment.
They are used by every job from the matrix (
https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L35
).
But each job can override the default environment and any of the phases
(before_install, install, after_install, script).
For the ARM64 build I overwrote the 'install' phase by copying the default
one and removing the execution of the build_ssl() function (the one that
builds OpenSSL from source) and I also overwrote the environment to update
the values of SSL_INC and SSL_LIB variables.
'openssl' and 'libssl-dev' packages are already installed in the Ubuntu
image used by TravisCI so there is nothing to install manually.. I've added
a comment (
https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L47)
to remind us how it works.


> Feel free to add your "purge cache" change as an extra patch if needed.
> But in any case, please make sure it's still possible to follow the
> impact of each change, because we've touched many things blindly for
> a while on this arm64 issue and most of the changes were basically
> "let's see if this helps", which is a real mess :-/
>
> Thanks!
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Thank you for applying the patch!

The ARM64 build passed at
https://travis-ci.com/github/haproxy/haproxy/jobs/335338296 !
But it passes only for the builds which have 'haproxy-mirror' :
https://travis-ci.com/github/haproxy/haproxy/builds
I am not sure what exactly "haproxy-mirror" is in the TravisCI config.
The builds which do not have "haproxy-mirror" next to the branch name also
do not have ARM64 build at all, e.g.
https://travis-ci.com/github/haproxy/haproxy/builds/166573019.

One thing that I notice is that the successful link above has *jobs *and
the failing one: *builds *before the job/build id.

On Fri, May 15, 2020 at 9:53 PM Willy Tarreau  wrote:

> On Fri, May 15, 2020 at 11:44:48PM +0500,  ??? wrote:
> > commit message adjusted
>
> Many thanks for this, Ilya, now pushed!
>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 15, 2020 at 11:44:48PM +0500,  ??? wrote:
> commit message adjusted

Many thanks for this, Ilya, now pushed!

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

commit message adjusted

пт, 15 мая 2020 г. в 22:02, Илья Шипицин :

>
>
> пт, 15 мая 2020 г. в 20:07, Willy Tarreau :
>
>> Ilya,
>>
>> > also, I'd suggest to purge travis-ci cache (if you are build in your own
>> > fork).
>> > some travis related issue might be related when something is took from
>> > cache (which was not supposed to happen)
>>
>> Could you please handle Martin's patch, possibly cut it into several
>> pieces if relevant and add a commit message indicating what it does
>> (and why) ? Martin is not at ease with Git (which is not a problem),
>> and it seems only him and you understand how the reasons of the changes
>> in his patch. At least it's totally unclear to me why there's a new
>> install target for arm64 and why there's a special "make" invocation
>> there.
>>
>> Feel free to add your "purge cache" change as an extra patch if needed.
>> But in any case, please make sure it's still possible to follow the
>> impact of each change, because we've touched many things blindly for
>> a while on this arm64 issue and most of the changes were basically
>> "let's see if this helps", which is a real mess :-/
>>
>
> I will resend a patch with detailed information.
>
>
> as for "purge a cache", it was a suggestion to Martin to purge it manually
> in his own travis-ci project.
> it usually helps to find caveats (for example, you still get files from
> cache which is not desireable)
>
> it's just for pre-checkin test.
>
>
>
>>
>> Thanks!
>> Willy
>>
>
From 98849dc14e08f1c1fb8899145e1ed24118bb1d8b Mon Sep 17 00:00:00 2001
From: Martin Tzvetanov Grigorov 
Date: Fri, 15 May 2020 23:34:46 +0500
Subject: [PATCH] CI: travis-ci: switch arm64 builds to use openssl from distro

there are ongoing arm64 failures in travis-ci. we suspect that
build stucks on scripts/build-ssl.sh which is called during build.
let us try to use openssl from ubuntu distro and not build it
ourselves. to achive that we add "install" section without
build-ssl.sh
---
 .travis.yml | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index ea7168624..e2a32a2b7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -44,14 +44,15 @@ matrix:
 compiler: clang
 env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
   - os: linux
+# The ARM64 build uses openssl and libssl-dev from Ubuntu repository. They come preinstalled by TravisCI!
 arch: arm64
 if: type == push
 compiler: clang
-env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
-addons:
-  apt:
-update: true
-packages: [ liblua5.3-dev, libsystemd-dev, clang-9, socat ]
+env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9 SSL_LIB=/usr/lib SSL_INC=/usr/include
+install:
+  - git clone https://github.com/VTest/VTest.git ../vtest
+  # Special flags due to: https://github.com/vtest/VTest/issues/12
+  - make -C ../vtest FLAGS="-O2 -s -Wall"
   - os: linux
 arch: s390x
 if: type == push
@@ -113,7 +114,7 @@ install:
   - git clone https://github.com/VTest/VTest.git ../vtest
   # Special flags due to: https://github.com/vtest/VTest/issues/12
   - make -C ../vtest FLAGS="-O2 -s -Wall"
-  - travis_wait 60 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1)
+  - travis_wait bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1)
 
 script:
   - if [ "${CC%-*}"  = "clang" ]; then export FLAGS="$FLAGS USE_OBSOLETE_LINKER=1" DEBUG_CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"; fi
-- 
2.26.2

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 15 мая 2020 г. в 20:07, Willy Tarreau :

> Ilya,
>
> > also, I'd suggest to purge travis-ci cache (if you are build in your own
> > fork).
> > some travis related issue might be related when something is took from
> > cache (which was not supposed to happen)
>
> Could you please handle Martin's patch, possibly cut it into several
> pieces if relevant and add a commit message indicating what it does
> (and why) ? Martin is not at ease with Git (which is not a problem),
> and it seems only him and you understand how the reasons of the changes
> in his patch. At least it's totally unclear to me why there's a new
> install target for arm64 and why there's a special "make" invocation
> there.
>
> Feel free to add your "purge cache" change as an extra patch if needed.
> But in any case, please make sure it's still possible to follow the
> impact of each change, because we've touched many things blindly for
> a while on this arm64 issue and most of the changes were basically
> "let's see if this helps", which is a real mess :-/
>

I will resend a patch with detailed information.


as for "purge a cache", it was a suggestion to Martin to purge it manually
in his own travis-ci project.
it usually helps to find caveats (for example, you still get files from
cache which is not desireable)

it's just for pre-checkin test.



>
> Thanks!
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

Ilya,

> also, I'd suggest to purge travis-ci cache (if you are build in your own
> fork).
> some travis related issue might be related when something is took from
> cache (which was not supposed to happen)

Could you please handle Martin's patch, possibly cut it into several
pieces if relevant and add a commit message indicating what it does
(and why) ? Martin is not at ease with Git (which is not a problem),
and it seems only him and you understand how the reasons of the changes
in his patch. At least it's totally unclear to me why there's a new
install target for arm64 and why there's a special "make" invocation
there.

Feel free to add your "purge cache" change as an extra patch if needed.
But in any case, please make sure it's still possible to follow the
impact of each change, because we've touched many things blindly for
a while on this arm64 issue and most of the changes were basically
"let's see if this helps", which is a real mess :-/

Thanks!
Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

that should work indeed.


also, I'd suggest to purge travis-ci cache (if you are build in your own
fork).
some travis related issue might be related when something is took from
cache (which was not supposed to happen)

пт, 15 мая 2020 г. в 15:26, Martin Grigorov :

> Those are set to new values at
> https://github.com/haproxy/haproxy/pull/630/files#diff-354f30a63fb0907d4ad57269548329e3R51
>
> On Fri, May 15, 2020 at 1:11 PM Илья Шипицин  wrote:
>
>> or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script
>>
>> пт, 15 мая 2020 г. в 15:09, Илья Шипицин :
>>
>>> probably, you also need to unset SSL_LIB and SSL_INC
>>>
>>>
>>>
>>> btw, I got an answer how to grant travis-ci rights (for triggering build
>>> manually)
>>>
>>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>>>
>>>
>>> пт, 15 мая 2020 г. в 14:57, Martin Grigorov :
>>>
 Hi,

 I've created https://github.com/haproxy/haproxy/pull/630
 With this change the build passed successfully for 5 mins and 7 secs
 for ARM64.

 Please let me know if you prefer me to send it as an attached .patch
 file here. (I haven't used `git format-patch` before :-/).

 Martin

 On Mon, May 11, 2020 at 12:38 PM Илья Шипицин 
 wrote:

>
>
> сб, 9 мая 2020 г. в 11:45, Willy Tarreau :
>
>> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
>> >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
>> >
>> > >> > Let's increase the timeout to see if it has a chance to
>> finish, no ?
>> > >> >
>> > >>
>> > >> yes
>> > >
>> > > OK now pushed. It's really annoying to work blindly like this. The
>> > > build model Travis uses is broken by design. Requiring to commit
>> > > something for testing is utterly wrong. And doing so within the
>> > > project that's supposed to being test is further wrong. We already
>> > > have 44 patches only on .travis.yml! If this continues like this,
>> > > I predict that a "pre-CI" solution will appear to test if your
>> > > change is likely to trigger a travis error before it gets
>> merged...
>> >
>> > You can push changes to a (throwable) branch instead.
>>
>> Good point, that can also be a solution. But it remains completely
>> hackish. It's basically abusing a versioning system to use it as a
>> messaging system to indicate "please build with this".
>>
>> Willy
>>
>
>
> I created several topics (no answer yet).
>
> as for travis-ci rights, it's totally undocumented. but I suspect
> travis grants
> rights based on github rights. i.e. github admin becomes travis admin
> as well.
>
> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529
>
>
> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>
>
> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528
>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Those are set to new values at
https://github.com/haproxy/haproxy/pull/630/files#diff-354f30a63fb0907d4ad57269548329e3R51

On Fri, May 15, 2020 at 1:11 PM Илья Шипицин  wrote:

> or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script
>
> пт, 15 мая 2020 г. в 15:09, Илья Шипицин :
>
>> probably, you also need to unset SSL_LIB and SSL_INC
>>
>>
>>
>> btw, I got an answer how to grant travis-ci rights (for triggering build
>> manually)
>>
>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>>
>>
>> пт, 15 мая 2020 г. в 14:57, Martin Grigorov :
>>
>>> Hi,
>>>
>>> I've created https://github.com/haproxy/haproxy/pull/630
>>> With this change the build passed successfully for 5 mins and 7 secs for
>>> ARM64.
>>>
>>> Please let me know if you prefer me to send it as an attached .patch
>>> file here. (I haven't used `git format-patch` before :-/).
>>>
>>> Martin
>>>
>>> On Mon, May 11, 2020 at 12:38 PM Илья Шипицин 
>>> wrote:
>>>


 сб, 9 мая 2020 г. в 11:45, Willy Tarreau :

> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
> >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
> >
> > >> > Let's increase the timeout to see if it has a chance to finish,
> no ?
> > >> >
> > >>
> > >> yes
> > >
> > > OK now pushed. It's really annoying to work blindly like this. The
> > > build model Travis uses is broken by design. Requiring to commit
> > > something for testing is utterly wrong. And doing so within the
> > > project that's supposed to being test is further wrong. We already
> > > have 44 patches only on .travis.yml! If this continues like this,
> > > I predict that a "pre-CI" solution will appear to test if your
> > > change is likely to trigger a travis error before it gets merged...
> >
> > You can push changes to a (throwable) branch instead.
>
> Good point, that can also be a solution. But it remains completely
> hackish. It's basically abusing a versioning system to use it as a
> messaging system to indicate "please build with this".
>
> Willy
>


 I created several topics (no answer yet).

 as for travis-ci rights, it's totally undocumented. but I suspect
 travis grants
 rights based on github rights. i.e. github admin becomes travis admin
 as well.

 https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529


 https://travis-ci.community/t/undocumented-require-admin-permissions/8530


 https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528


>>>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script

пт, 15 мая 2020 г. в 15:09, Илья Шипицин :

> probably, you also need to unset SSL_LIB and SSL_INC
>
>
>
> btw, I got an answer how to grant travis-ci rights (for triggering build
> manually)
>
> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>
>
> пт, 15 мая 2020 г. в 14:57, Martin Grigorov :
>
>> Hi,
>>
>> I've created https://github.com/haproxy/haproxy/pull/630
>> With this change the build passed successfully for 5 mins and 7 secs for
>> ARM64.
>>
>> Please let me know if you prefer me to send it as an attached .patch file
>> here. (I haven't used `git format-patch` before :-/).
>>
>> Martin
>>
>> On Mon, May 11, 2020 at 12:38 PM Илья Шипицин 
>> wrote:
>>
>>>
>>>
>>> сб, 9 мая 2020 г. в 11:45, Willy Tarreau :
>>>
 On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
 >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
 >
 > >> > Let's increase the timeout to see if it has a chance to finish,
 no ?
 > >> >
 > >>
 > >> yes
 > >
 > > OK now pushed. It's really annoying to work blindly like this. The
 > > build model Travis uses is broken by design. Requiring to commit
 > > something for testing is utterly wrong. And doing so within the
 > > project that's supposed to being test is further wrong. We already
 > > have 44 patches only on .travis.yml! If this continues like this,
 > > I predict that a "pre-CI" solution will appear to test if your
 > > change is likely to trigger a travis error before it gets merged...
 >
 > You can push changes to a (throwable) branch instead.

 Good point, that can also be a solution. But it remains completely
 hackish. It's basically abusing a versioning system to use it as a
 messaging system to indicate "please build with this".

 Willy

>>>
>>>
>>> I created several topics (no answer yet).
>>>
>>> as for travis-ci rights, it's totally undocumented. but I suspect travis
>>> grants
>>> rights based on github rights. i.e. github admin becomes travis admin as
>>> well.
>>>
>>> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529
>>>
>>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>>>
>>>
>>> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528
>>>
>>>
>>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

probably, you also need to unset SSL_LIB and SSL_INC



btw, I got an answer how to grant travis-ci rights (for triggering build
manually)

https://travis-ci.community/t/undocumented-require-admin-permissions/8530


пт, 15 мая 2020 г. в 14:57, Martin Grigorov :

> Hi,
>
> I've created https://github.com/haproxy/haproxy/pull/630
> With this change the build passed successfully for 5 mins and 7 secs for
> ARM64.
>
> Please let me know if you prefer me to send it as an attached .patch file
> here. (I haven't used `git format-patch` before :-/).
>
> Martin
>
> On Mon, May 11, 2020 at 12:38 PM Илья Шипицин 
> wrote:
>
>>
>>
>> сб, 9 мая 2020 г. в 11:45, Willy Tarreau :
>>
>>> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
>>> >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
>>> >
>>> > >> > Let's increase the timeout to see if it has a chance to finish,
>>> no ?
>>> > >> >
>>> > >>
>>> > >> yes
>>> > >
>>> > > OK now pushed. It's really annoying to work blindly like this. The
>>> > > build model Travis uses is broken by design. Requiring to commit
>>> > > something for testing is utterly wrong. And doing so within the
>>> > > project that's supposed to being test is further wrong. We already
>>> > > have 44 patches only on .travis.yml! If this continues like this,
>>> > > I predict that a "pre-CI" solution will appear to test if your
>>> > > change is likely to trigger a travis error before it gets merged...
>>> >
>>> > You can push changes to a (throwable) branch instead.
>>>
>>> Good point, that can also be a solution. But it remains completely
>>> hackish. It's basically abusing a versioning system to use it as a
>>> messaging system to indicate "please build with this".
>>>
>>> Willy
>>>
>>
>>
>> I created several topics (no answer yet).
>>
>> as for travis-ci rights, it's totally undocumented. but I suspect travis
>> grants
>> rights based on github rights. i.e. github admin becomes travis admin as
>> well.
>>
>> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529
>>
>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>>
>>
>> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528
>>
>>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Hi,

I've created https://github.com/haproxy/haproxy/pull/630
With this change the build passed successfully for 5 mins and 7 secs for
ARM64.

Please let me know if you prefer me to send it as an attached .patch file
here. (I haven't used `git format-patch` before :-/).

Martin

On Mon, May 11, 2020 at 12:38 PM Илья Шипицин  wrote:

>
>
> сб, 9 мая 2020 г. в 11:45, Willy Tarreau :
>
>> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
>> >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
>> >
>> > >> > Let's increase the timeout to see if it has a chance to finish, no
>> ?
>> > >> >
>> > >>
>> > >> yes
>> > >
>> > > OK now pushed. It's really annoying to work blindly like this. The
>> > > build model Travis uses is broken by design. Requiring to commit
>> > > something for testing is utterly wrong. And doing so within the
>> > > project that's supposed to being test is further wrong. We already
>> > > have 44 patches only on .travis.yml! If this continues like this,
>> > > I predict that a "pre-CI" solution will appear to test if your
>> > > change is likely to trigger a travis error before it gets merged...
>> >
>> > You can push changes to a (throwable) branch instead.
>>
>> Good point, that can also be a solution. But it remains completely
>> hackish. It's basically abusing a versioning system to use it as a
>> messaging system to indicate "please build with this".
>>
>> Willy
>>
>
>
> I created several topics (no answer yet).
>
> as for travis-ci rights, it's totally undocumented. but I suspect travis
> grants
> rights based on github rights. i.e. github admin becomes travis admin as
> well.
>
> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529
>
> https://travis-ci.community/t/undocumented-require-admin-permissions/8530
>
>
> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528
>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

сб, 9 мая 2020 г. в 11:45, Willy Tarreau :

> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
> >  ?  8 mai 2020 14:25 +02, Willy Tarreau:
> >
> > >> > Let's increase the timeout to see if it has a chance to finish, no ?
> > >> >
> > >>
> > >> yes
> > >
> > > OK now pushed. It's really annoying to work blindly like this. The
> > > build model Travis uses is broken by design. Requiring to commit
> > > something for testing is utterly wrong. And doing so within the
> > > project that's supposed to being test is further wrong. We already
> > > have 44 patches only on .travis.yml! If this continues like this,
> > > I predict that a "pre-CI" solution will appear to test if your
> > > change is likely to trigger a travis error before it gets merged...
> >
> > You can push changes to a (throwable) branch instead.
>
> Good point, that can also be a solution. But it remains completely
> hackish. It's basically abusing a versioning system to use it as a
> messaging system to indicate "please build with this".
>
> Willy
>


I created several topics (no answer yet).

as for travis-ci rights, it's totally undocumented. but I suspect travis
grants
rights based on github rights. i.e. github admin becomes travis admin as
well.

https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529

https://travis-ci.community/t/undocumented-require-admin-permissions/8530

https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote:
>  ?  8 mai 2020 14:25 +02, Willy Tarreau:
> 
> >> > Let's increase the timeout to see if it has a chance to finish, no ?
> >> >
> >> 
> >> yes
> >
> > OK now pushed. It's really annoying to work blindly like this. The
> > build model Travis uses is broken by design. Requiring to commit
> > something for testing is utterly wrong. And doing so within the
> > project that's supposed to being test is further wrong. We already
> > have 44 patches only on .travis.yml! If this continues like this,
> > I predict that a "pre-CI" solution will appear to test if your
> > change is likely to trigger a travis error before it gets merged...
> 
> You can push changes to a (throwable) branch instead.

Good point, that can also be a solution. But it remains completely
hackish. It's basically abusing a versioning system to use it as a
messaging system to indicate "please build with this".

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Vincent Bernat]

 ❦  8 mai 2020 14:25 +02, Willy Tarreau:

>> > Let's increase the timeout to see if it has a chance to finish, no ?
>> >
>> 
>> yes
>
> OK now pushed. It's really annoying to work blindly like this. The
> build model Travis uses is broken by design. Requiring to commit
> something for testing is utterly wrong. And doing so within the
> project that's supposed to being test is further wrong. We already
> have 44 patches only on .travis.yml! If this continues like this,
> I predict that a "pre-CI" solution will appear to test if your
> change is likely to trigger a travis error before it gets merged...

You can push changes to a (throwable) branch instead.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 06:14:28PM +0500,  ??? wrote:
> > You can avoid this by making changes to .travis.yml directly in Travis UI.
> > At the right-top part of the page there is "More options" menu. Select
> > "Trigger build" and in the dialog you can paste "Custom config". Once you
> > are happy with the outcome you can push it in your Git repo.

Awesome, thanks Martin! I wish we'd found this earlier!

> that's nice idea.
> Willy, can you grant me rights (in travis) to do so ? It requires "admin"
> travis permissions

I wish I could. I've visited all visible menus and even settings under
my face, and couldn't find anything related to user management nor
permissions :-(  It's fairly possible it's hidden somewhere, I'm not
good at spotting hidden menus in modern interfaces. So for now I'm a
bit stuck :-(

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 18:04, Martin Grigorov :

>
>
> On Fri, May 8, 2020 at 3:25 PM Willy Tarreau  wrote:
>
>> On Fri, May 08, 2020 at 05:04:43PM +0500,  ??? wrote:
>> > > Let's increase the timeout to see if it has a chance to finish, no ?
>> > >
>> >
>> > yes
>>
>> OK now pushed. It's really annoying to work blindly like this. The
>> build model Travis uses is broken by design. Requiring to commit
>> something for testing is utterly wrong. And doing so within the
>> project that's supposed to being test is further wrong. We already
>> have 44 patches only on .travis.yml! If this continues like this,
>> I predict that a "pre-CI" solution will appear to test if your
>> change is likely to trigger a travis error before it gets merged...
>>
>
> You can avoid this by making changes to .travis.yml directly in Travis UI.
> At the right-top part of the page there is "More options" menu. Select
> "Trigger build" and in the dialog you can paste "Custom config". Once you
> are happy with the outcome you can push it in your Git repo.
>
>
that's nice idea.
Willy, can you grant me rights (in travis) to do so ? It requires "admin"
travis permissions



> Back to the main topic:
> Now it fails with totally new reason. It doesn't even start installing the
> dependencies.
>

it does start. you can see in "raw logs"

https://api.travis-ci.com/v3/job/329899528/log.txt



> It started failing this way since:
> https://github.com/haproxy/haproxy/commit/8d76af55e10f018ab3d482125433be4992884372
> You can try the "manual approach" by reverting this change! ;-)
>

>
>>
>> Willy
>>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 17:25, Willy Tarreau :

> On Fri, May 08, 2020 at 05:04:43PM +0500,  ??? wrote:
> > > Let's increase the timeout to see if it has a chance to finish, no ?
> > >
> >
> > yes
>
> OK now pushed. It's really annoying to work blindly like this. The
> build model Travis uses is broken by design. Requiring to commit
> something for testing is utterly wrong. And doing so within the
> project that's supposed to being test is further wrong. We already
> have 44 patches only on .travis.yml! If this continues like this,
> I predict that a "pre-CI" solution will appear to test if your
> change is likely to trigger a travis error before it gets merged...
>

usual way of doing so is pull request



>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 16:45, Willy Tarreau :

> On Fri, May 08, 2020 at 04:17:18PM +0500,  ??? wrote:
> > as far as I understand, arm64 is run inside containers. something like
> > docker or lxd.
> >
> > "Processing triggers for dbus (1.12.2-1ubuntu1.1) ..."
> >
> >
> > dbus is not supposed to be available from container, right ?
>
> No idea but if it works on your repo it should there as well. I
> really think that the logs are just shown a bit further as Martin
> and I predicted :-)
>
> Let's increase the timeout to see if it has a chance to finish, no ?
>

yes


>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 04:17:18PM +0500,  ??? wrote:
> as far as I understand, arm64 is run inside containers. something like
> docker or lxd.
> 
> "Processing triggers for dbus (1.12.2-1ubuntu1.1) ..."
> 
> 
> dbus is not supposed to be available from container, right ?

No idea but if it works on your repo it should there as well. I
really think that the logs are just shown a bit further as Martin
and I predicted :-)

Let's increase the timeout to see if it has a chance to finish, no ?

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

as far as I understand, arm64 is run inside containers. something like
docker or lxd.

"Processing triggers for dbus (1.12.2-1ubuntu1.1) ..."


dbus is not supposed to be available from container, right ?

пт, 8 мая 2020 г. в 16:15, Илья Шипицин :

> another travis-ci bug.
> UI does not show full log:
> https://api.travis-ci.com/v3/job/329873686/log.txt
>
>
>
> пт, 8 мая 2020 г. в 15:58, Willy Tarreau :
>
>> On Fri, May 08, 2020 at 03:29:26PM +0500,  ??? wrote:
>> > I attached a patch
>>
>> Pushed, thanks. Next step in 10 minutes :-)
>>
>
>
> it did not uncover any truth.
> let us set bigger timeout, I guess it does not matter 60 or 120, build
> will be limited to 60 anyway/\
>
>
>>
>> Willy
>>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

another travis-ci bug.
UI does not show full log:
https://api.travis-ci.com/v3/job/329873686/log.txt



пт, 8 мая 2020 г. в 15:58, Willy Tarreau :

> On Fri, May 08, 2020 at 03:29:26PM +0500,  ??? wrote:
> > I attached a patch
>
> Pushed, thanks. Next step in 10 minutes :-)
>


it did not uncover any truth.
let us set bigger timeout, I guess it does not matter 60 or 120, build will
be limited to 60 anyway/\


>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 03:29:26PM +0500,  ??? wrote:
> I attached a patch

Pushed, thanks. Next step in 10 minutes :-)

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 15:09, Willy Tarreau :

> On Fri, May 08, 2020 at 03:07:51PM +0500,  ??? wrote:
> > ??, 8 ??? 2020 ?. ? 14:55, Willy Tarreau :
> >
> > > On Fri, May 08, 2020 at 01:59:57PM +0500,  ??? wrote:
> > > > > We don't know how long it gets cached so if we increase it we'll
> have
> > > to
> > > > > leave it.
> > > > >
> > > >
> > > > it is cached forever, until cache is purged manually or some cache
> key
> > > > (e.g. openssl version) is changed
> > >
> > > OK, so do you want me to try increasing to 60 minutes before changing
> > > anything else ?
> > >
> >
> > I would start with disabling pcre2. It should change output and uncover
> > truth. I will send a patch in couple of days (if that won't help, we'll
> > play with timeouts)
>
> I'm pretty convinced it will only truncate on next line but sure, we
> can try :-)
>


I attached a patch


> Willy
>
From da6a92a4c71d97a0a3bd5963b7fbe96c51c78da4 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Fri, 8 May 2020 15:25:56 +0500
Subject: [PATCH] CI: travis-ci: skip pcre2 on arm64 build

currently arm64 stuck with some error related to pcre2. while we beleive
pcre2 is not related to error itself, we can try not to install it
---
 .travis.yml | 4 
 1 file changed, 4 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 0d7268791..59f3450fb 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -48,6 +48,10 @@ matrix:
 if: type == push
 compiler: clang
 env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
+addons:
+  apt:
+update: true
+packages: [ liblua5.3-dev, libsystemd-dev, clang-9, socat ]
   - os: linux
 arch: s390x
 if: type == push
-- 
2.25.4

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 03:07:51PM +0500,  ??? wrote:
> ??, 8 ??? 2020 ?. ? 14:55, Willy Tarreau :
> 
> > On Fri, May 08, 2020 at 01:59:57PM +0500,  ??? wrote:
> > > > We don't know how long it gets cached so if we increase it we'll have
> > to
> > > > leave it.
> > > >
> > >
> > > it is cached forever, until cache is purged manually or some cache key
> > > (e.g. openssl version) is changed
> >
> > OK, so do you want me to try increasing to 60 minutes before changing
> > anything else ?
> >
> 
> I would start with disabling pcre2. It should change output and uncover
> truth. I will send a patch in couple of days (if that won't help, we'll
> play with timeouts)

I'm pretty convinced it will only truncate on next line but sure, we
can try :-)

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 14:55, Willy Tarreau :

> On Fri, May 08, 2020 at 01:59:57PM +0500,  ??? wrote:
> > > We don't know how long it gets cached so if we increase it we'll have
> to
> > > leave it.
> > >
> >
> > it is cached forever, until cache is purged manually or some cache key
> > (e.g. openssl version) is changed
>
> OK, so do you want me to try increasing to 60 minutes before changing
> anything else ?
>

I would start with disabling pcre2. It should change output and uncover
truth. I will send a patch in couple of days (if that won't help, we'll
play with timeouts)

Martin, can you please try to contact travis support ?



>
> > build-ssl.sh is called from "install" section. we just need to add
> separate
> > "install" section for arm64
>
> OK!
>
> > > I think we can do it directly from the build-ssl script if needed.
> > > Basically something ugly more or less like this:
> > >
> > >if [ "$(uname -m)" = "aarch64" ]; then
> > >   apt install ...
> > >   ln -s /usr/lib64 $HOME/opt/lib
> > >   ln -s /usr/inculde $HOME/opt/include
> > >   exit 0
> > >fi
> > >
> >
> > please, no :)
>
> I'm pleased to see I'm not the only one not liking ugly stuff :-)
>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 01:59:57PM +0500,  ??? wrote:
> > We don't know how long it gets cached so if we increase it we'll have to
> > leave it.
> >
> 
> it is cached forever, until cache is purged manually or some cache key
> (e.g. openssl version) is changed

OK, so do you want me to try increasing to 60 minutes before changing
anything else ?

> build-ssl.sh is called from "install" section. we just need to add separate
> "install" section for arm64

OK!

> > I think we can do it directly from the build-ssl script if needed.
> > Basically something ugly more or less like this:
> >
> >if [ "$(uname -m)" = "aarch64" ]; then
> >   apt install ...
> >   ln -s /usr/lib64 $HOME/opt/lib
> >   ln -s /usr/inculde $HOME/opt/include
> >   exit 0
> >fi
> >
> 
> please, no :)

I'm pleased to see I'm not the only one not liking ugly stuff :-)

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 11:09:50AM +0300, Martin Grigorov wrote:
> I still believe the problem is in the time needed to build OpenSSL, not in
> apt[-get].

I agree that it's the most likely.

> We can increase temporarily the travis_wait to 60 just to cache the build
> of 1.1.1f and then remove '60' again.

We don't know how long it gets cached so if we increase it we'll have to
leave it.

> Although if this is the problem then
> 'travis_wait 60 ...' won't do any harm for the next builds because it will
> use the cache and return in few secs.

Sure.

> I like the idea to install openssl with apt but I am not sure whether we
> can do this *only* for ARM64.

I think we can do it directly from the build-ssl script if needed.
Basically something ugly more or less like this:

   if [ "$(uname -m)" = "aarch64" ]; then
  apt install ...
  ln -s /usr/lib64 $HOME/opt/lib
  ln -s /usr/inculde $HOME/opt/include
  exit 0
   fi

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

On Fri, May 8, 2020 at 10:54 AM Илья Шипицин  wrote:

>
>
> пт, 8 мая 2020 г. в 12:26, Willy Tarreau :
>
>> On Fri, May 08, 2020 at 09:34:32AM +0300, Martin Grigorov wrote:
>> > It must have started failing when you updated the version of OpenSSL.
>> > .travis.yml caches ~/opt folder between builds. After the update to
>> 1.1.1f
>> > the build doesn't see the OpenSSL binaries in the cache anymore and
>> tries
>> > to download it and build it.
>> > But as I've noticed in my attempt to build HAProxy with Docker+QEMU the
>> > build of OpenSSL is taking too long.
>> > The build of OpenSSL is wrapped with travis_wait to reduce the writes to
>> > stdout but the default time for travis_wait is 20 mins and this is not
>> > enough to build OpenSSL.
>>
>> That's very likely indeed.
>>
>
>
> it is not :)
> I provided link to my fork, openssl build takes 640 sec
>
>
>>
>> > Due to
>> >
>> https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630
>> > TravisCI
>> > does not properly report that the problem is at build_ssl() step but
>> shows
>> > the last chunk of the buffered response and this confuses us all.
>>
>> Ah, excellent, precisely what I was looking for. And some indicate
>> that the buffering further causes issues in the build system itself!
>>
>> > I think the build will become green if we extend travis_wait to a higher
>> > value (
>> >
>> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
>> ).
>> > I don't remember where I have read it but I think the upper limit is 120
>> > mins.
>> > @Willy: could you please change
>> > https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:
>> >
>> > travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' ||
>> (cat
>> > build-ssl.log && exit 1)
>> >
>> > i.e. add '120' after travis_wait
>>
>> We could, but 120 (2 hours) seems a bit extreme. It also means we can
>> steal
>> 2 hours of CPU there in case something goes wrong.
>>
>
> travis-ci limits build at 60 min.
>
>
>>
>> > This should give it the time to download and install OpenSSL 1.1.1f and
>> to
>> > cache it. If the build passes once then the next builds should be much
>> > faster because OpenSSL will be used from the cache.
>>
>> I'm wondering why instead we don't fallback on an already packaged version
>> of OpenSSL for this platform. I mean, sure it's convenient to test the
>> latest version but it's already tested on x86 and we could very well use
>> any other version already packaged on the distro present there. This would
>> solve the problem and even increase versions coverage.
>>
>> Ilya, what do you think ?
>>
>
> yes, there are few options to think about.
> I also provided options (numbered 1..4), Hopefully, I think on your
> suggestions, Martin will think on my suggestion ... and we will decide what
> next would be.
>

I still believe the problem is in the time needed to build OpenSSL, not in
apt[-get].

We can increase temporarily the travis_wait to 60 just to cache the build
of 1.1.1f and then remove '60' again. Although if this is the problem then
'travis_wait 60 ...' won't do any harm for the next builds because it will
use the cache and return in few secs.

I like the idea to install openssl with apt but I am not sure whether we
can do this *only* for ARM64.


>
>
>>
>> Thanks,
>> Willy
>>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 12:54:14PM +0500,  ??? wrote:
> > > The build of OpenSSL is wrapped with travis_wait to reduce the writes to
> > > stdout but the default time for travis_wait is 20 mins and this is not
> > > enough to build OpenSSL.
> >
> > That's very likely indeed.
> >
> 
> 
> it is not :)
> I provided link to my fork, openssl build takes 640 sec

But we don't even know if we all end up on the same build nodes, and
it's likely that it's not the case since yours finishes.

> > We could, but 120 (2 hours) seems a bit extreme. It also means we can steal
> > 2 hours of CPU there in case something goes wrong.
> >
> 
> travis-ci limits build at 60 min.

OK.

> > I'm wondering why instead we don't fallback on an already packaged version
> > of OpenSSL for this platform. I mean, sure it's convenient to test the
> > latest version but it's already tested on x86 and we could very well use
> > any other version already packaged on the distro present there. This would
> > solve the problem and even increase versions coverage.
> >
> > Ilya, what do you think ?
> >
> 
> yes, there are few options to think about.
> I also provided options (numbered 1..4), Hopefully, I think on your
> suggestions, Martin will think on my suggestion ... and we will decide what
> next would be.

Well, for #1 I don't think that changing pcre2 will have any impact there
because it's obvious that we're facing output buffer truncation and that
the problem happens after though we don't know how far after. For #2, not
using travis' apt, maybe we'd gain slightly better control, but it's not
even certain and it's possible we might not benefit from certain caches,
so I'm having doubts. For #3, interacting with their support channel, why
not, if you're willing to engage into this. If at least they can bring us
a complete untruncated output of a failed build, that would help.

I continue to think that avoiding building standard packages in the VMs
should be the priority. Our goal is not to test if openssl can be built
and used there but if haproxy can be built and used there. When it's the
only option to test integration with certain components, that's fine.
Here I think that openssl is sufficiently covered on other platforms so
we don't necessarily need to rebuild it ourselves and we can use the
distro's version.

Thanks,
Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 12:26, Willy Tarreau :

> On Fri, May 08, 2020 at 09:34:32AM +0300, Martin Grigorov wrote:
> > It must have started failing when you updated the version of OpenSSL.
> > .travis.yml caches ~/opt folder between builds. After the update to
> 1.1.1f
> > the build doesn't see the OpenSSL binaries in the cache anymore and tries
> > to download it and build it.
> > But as I've noticed in my attempt to build HAProxy with Docker+QEMU the
> > build of OpenSSL is taking too long.
> > The build of OpenSSL is wrapped with travis_wait to reduce the writes to
> > stdout but the default time for travis_wait is 20 mins and this is not
> > enough to build OpenSSL.
>
> That's very likely indeed.
>


it is not :)
I provided link to my fork, openssl build takes 640 sec


>
> > Due to
> >
> https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630
> > TravisCI
> > does not properly report that the problem is at build_ssl() step but
> shows
> > the last chunk of the buffered response and this confuses us all.
>
> Ah, excellent, precisely what I was looking for. And some indicate
> that the buffering further causes issues in the build system itself!
>
> > I think the build will become green if we extend travis_wait to a higher
> > value (
> >
> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
> ).
> > I don't remember where I have read it but I think the upper limit is 120
> > mins.
> > @Willy: could you please change
> > https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:
> >
> > travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' ||
> (cat
> > build-ssl.log && exit 1)
> >
> > i.e. add '120' after travis_wait
>
> We could, but 120 (2 hours) seems a bit extreme. It also means we can steal
> 2 hours of CPU there in case something goes wrong.
>

travis-ci limits build at 60 min.


>
> > This should give it the time to download and install OpenSSL 1.1.1f and
> to
> > cache it. If the build passes once then the next builds should be much
> > faster because OpenSSL will be used from the cache.
>
> I'm wondering why instead we don't fallback on an already packaged version
> of OpenSSL for this platform. I mean, sure it's convenient to test the
> latest version but it's already tested on x86 and we could very well use
> any other version already packaged on the distro present there. This would
> solve the problem and even increase versions coverage.
>
> Ilya, what do you think ?
>

yes, there are few options to think about.
I also provided options (numbered 1..4), Hopefully, I think on your
suggestions, Martin will think on my suggestion ... and we will decide what
next would be.


>
> Thanks,
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 09:34:32AM +0300, Martin Grigorov wrote:
> It must have started failing when you updated the version of OpenSSL.
> .travis.yml caches ~/opt folder between builds. After the update to 1.1.1f
> the build doesn't see the OpenSSL binaries in the cache anymore and tries
> to download it and build it.
> But as I've noticed in my attempt to build HAProxy with Docker+QEMU the
> build of OpenSSL is taking too long.
> The build of OpenSSL is wrapped with travis_wait to reduce the writes to
> stdout but the default time for travis_wait is 20 mins and this is not
> enough to build OpenSSL.

That's very likely indeed.

> Due to
> https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630
> TravisCI
> does not properly report that the problem is at build_ssl() step but shows
> the last chunk of the buffered response and this confuses us all.

Ah, excellent, precisely what I was looking for. And some indicate
that the buffering further causes issues in the build system itself!

> I think the build will become green if we extend travis_wait to a higher
> value (
> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received).
> I don't remember where I have read it but I think the upper limit is 120
> mins.
> @Willy: could you please change
> https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:
> 
> travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
> build-ssl.log && exit 1)
> 
> i.e. add '120' after travis_wait

We could, but 120 (2 hours) seems a bit extreme. It also means we can steal
2 hours of CPU there in case something goes wrong.

> This should give it the time to download and install OpenSSL 1.1.1f and to
> cache it. If the build passes once then the next builds should be much
> faster because OpenSSL will be used from the cache.

I'm wondering why instead we don't fallback on an already packaged version
of OpenSSL for this platform. I mean, sure it's convenient to test the
latest version but it's already tested on x86 and we could very well use
any other version already packaged on the distro present there. This would
solve the problem and even increase versions coverage.

Ilya, what do you think ?

Thanks,
Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 11:35, Martin Grigorov :

> Hi,
>
> I think I understand why it started failing.
> It must have started failing when you updated the version of OpenSSL.
> .travis.yml caches ~/opt folder between builds. After the update to 1.1.1f
> the build doesn't see the OpenSSL binaries in the cache anymore and tries
> to download it and build it.
> But as I've noticed in my attempt to build HAProxy with Docker+QEMU the
> build of OpenSSL is taking too long.
> The build of OpenSSL is wrapped with travis_wait to reduce the writes to
> stdout but the default time for travis_wait is 20 mins and this is not
> enough to build OpenSSL.
> Due to
> https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630
>  TravisCI
> does not properly report that the problem is at build_ssl() step but shows
> the last chunk of the buffered response and this confuses us all.
> I think the build will become green if we extend travis_wait to a higher
> value (
> https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received).
> I don't remember where I have read it but I think the upper limit is 120
> mins.
> @Willy: could you please change
> https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:
>
> travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
> build-ssl.log && exit 1)
>
> i.e. add '120' after travis_wait
>


https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056 - as you can
see full openssl build took 640s
it is longer than 10 minutes


>
> This should give it the time to download and install OpenSSL 1.1.1f and to
> cache it. If the build passes once then the next builds should be much
> faster because OpenSSL will be used from the cache.
>
> Regards,
> Martin
>
> On Fri, May 8, 2020 at 9:18 AM Willy Tarreau  wrote:
>
>> Hi Martin,
>>
>> On Fri, May 08, 2020 at 08:56:07AM +0300, Martin Grigorov wrote:
>> > Unfortunately it is not good:
>> > https://travis-ci.com/github/haproxy/haproxy/jobs/329657180
>>
>> Indeed it's still not fixed on Travis' side. However what Ilya did
>> actually worked, in that the status is not reported as a global
>> build failure anymore. This allows us to continue to monitor if
>> and when this issue finally resolves on the build infrastructure.
>> It's also possible that they're not aware of the problem due to
>> too few people using arm64. If someone has contacts there it might
>> be worth checking with them. All we know for now is that it seems
>> to stop moving while setting up libpcre2. Maybe there's a bug in
>> a script in this package, resulting in a prompt for a question
>> which never gets a response :-/  But that's something we can't
>> check since we don't have access to an interactive shell there
>> to diagnose.
>>
>> Willy
>>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 11:27, Willy Tarreau :

> On Fri, May 08, 2020 at 11:12:00AM +0500,  ??? wrote:
> > btw, in my fork it is green
> > https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056
>
> Cool, that tends to confirm the issue remains a bit random. There
> is actually something I don't like in the build report, which is
> that the "Setting up libpcre2" line is truncated. This definitely
> indicates that output is not line-buffered and that could mean that
> it in fact fails multiple lines later (processing triggers or any
> such thing) but that the successful operations were not properly
> logged. At this point I guess it's the apt-get utility which does
> not properly configure its stdout, but it could also be anything
> in between. In any case I doubt we'll have a big handle on this.
>

there are few options

1) setup separate "apt" key for "arm64", we do not use pcre2 here

2) use direct "apt-get" call, not travis "apt" plugin (maybe we can control
buffering that way)

3) interoperate with travis via support channel

4) wait until it is resolved by itself

Martin ?



>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Hi,

I think I understand why it started failing.
It must have started failing when you updated the version of OpenSSL.
.travis.yml caches ~/opt folder between builds. After the update to 1.1.1f
the build doesn't see the OpenSSL binaries in the cache anymore and tries
to download it and build it.
But as I've noticed in my attempt to build HAProxy with Docker+QEMU the
build of OpenSSL is taking too long.
The build of OpenSSL is wrapped with travis_wait to reduce the writes to
stdout but the default time for travis_wait is 20 mins and this is not
enough to build OpenSSL.
Due to
https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630
TravisCI
does not properly report that the problem is at build_ssl() step but shows
the last chunk of the buffered response and this confuses us all.
I think the build will become green if we extend travis_wait to a higher
value (
https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received).
I don't remember where I have read it but I think the upper limit is 120
mins.
@Willy: could you please change
https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:

travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
build-ssl.log && exit 1)

i.e. add '120' after travis_wait

This should give it the time to download and install OpenSSL 1.1.1f and to
cache it. If the build passes once then the next builds should be much
faster because OpenSSL will be used from the cache.

Regards,
Martin

On Fri, May 8, 2020 at 9:18 AM Willy Tarreau  wrote:

> Hi Martin,
>
> On Fri, May 08, 2020 at 08:56:07AM +0300, Martin Grigorov wrote:
> > Unfortunately it is not good:
> > https://travis-ci.com/github/haproxy/haproxy/jobs/329657180
>
> Indeed it's still not fixed on Travis' side. However what Ilya did
> actually worked, in that the status is not reported as a global
> build failure anymore. This allows us to continue to monitor if
> and when this issue finally resolves on the build infrastructure.
> It's also possible that they're not aware of the problem due to
> too few people using arm64. If someone has contacts there it might
> be worth checking with them. All we know for now is that it seems
> to stop moving while setting up libpcre2. Maybe there's a bug in
> a script in this package, resulting in a prompt for a question
> which never gets a response :-/  But that's something we can't
> check since we don't have access to an interactive shell there
> to diagnose.
>
> Willy
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

On Fri, May 08, 2020 at 11:12:00AM +0500,  ??? wrote:
> btw, in my fork it is green
> https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056

Cool, that tends to confirm the issue remains a bit random. There
is actually something I don't like in the build report, which is
that the "Setting up libpcre2" line is truncated. This definitely
indicates that output is not line-buffered and that could mean that
it in fact fails multiple lines later (processing triggers or any
such thing) but that the successful operations were not properly
logged. At this point I guess it's the apt-get utility which does
not properly configure its stdout, but it could also be anything
in between. In any case I doubt we'll have a big handle on this.

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

Hi Martin,

On Fri, May 08, 2020 at 08:56:07AM +0300, Martin Grigorov wrote:
> Unfortunately it is not good:
> https://travis-ci.com/github/haproxy/haproxy/jobs/329657180

Indeed it's still not fixed on Travis' side. However what Ilya did
actually worked, in that the status is not reported as a global
build failure anymore. This allows us to continue to monitor if
and when this issue finally resolves on the build infrastructure.
It's also possible that they're not aware of the problem due to
too few people using arm64. If someone has contacts there it might
be worth checking with them. All we know for now is that it seems
to stop moving while setting up libpcre2. Maybe there's a bug in
a script in this package, resulting in a prompt for a question
which never gets a response :-/  But that's something we can't
check since we don't have access to an interactive shell there
to diagnose.

Willy

Re: [PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

пт, 8 мая 2020 г. в 10:56, Martin Grigorov :

> Hi all,
>
> On Thu, May 7, 2020 at 11:56 PM Willy Tarreau  wrote:
>
>> Hi Ilya,
>>
>> On Thu, May 07, 2020 at 09:19:48PM +0500,  ??? wrote:
>> > Hello,
>> >
>> > let us enable arm64 builds back.
>>
>> Good idea, just merged now. Let's see how that ends up now.
>>
>
> Unfortunately it is not good:
> https://travis-ci.com/github/haproxy/haproxy/jobs/329657180
>

that's why it is marked as "allow to fail"


btw, in my fork it is green
https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056



>
> Martin
>
>
>>
>> Thanks,
>> Willy
>>
>>

Re: [PATCH] enable arm64 builds in travis-ci

[Martin Grigorov]

Hi all,

On Thu, May 7, 2020 at 11:56 PM Willy Tarreau  wrote:

> Hi Ilya,
>
> On Thu, May 07, 2020 at 09:19:48PM +0500,  ??? wrote:
> > Hello,
> >
> > let us enable arm64 builds back.
>
> Good idea, just merged now. Let's see how that ends up now.
>

Unfortunately it is not good:
https://travis-ci.com/github/haproxy/haproxy/jobs/329657180

Martin


>
> Thanks,
> Willy
>
>

Re: [PATCH] enable arm64 builds in travis-ci

[Willy Tarreau]

Hi Ilya,

On Thu, May 07, 2020 at 09:19:48PM +0500,  ??? wrote:
> Hello,
> 
> let us enable arm64 builds back.

Good idea, just merged now. Let's see how that ends up now.

Thanks,
Willy

[PATCH] enable arm64 builds in travis-ci

[Илья Шипицин]

Hello,

let us enable arm64 builds back.


Cheers,
Ilya Shipitcin
From 8c68b4494ba37469de86798fd7c492e38a2a8668 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Thu, 7 May 2020 20:57:26 +0500
Subject: [PATCH] CI: travis-ci: enable arm64 builds again

travis-ci arm64 were temporarily disabled due to travis instability.
let us enable them in "allowed to fail" mode.
---
 .travis.yml | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 345c08afe..0d7268791 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -43,13 +43,11 @@ matrix:
 if: type == push
 compiler: clang
 env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
-##
-## temporarily disabled, until arm64 runners become stable
-#  - os: linux
-#arch: arm64
-#if: type == push
-#compiler: clang
-#env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
+  - os: linux
+arch: arm64
+if: type == push
+compiler: clang
+env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
   - os: linux
 arch: s390x
 if: type == push
@@ -101,6 +99,11 @@ matrix:
 before_script:
   - git clone http://git.1wt.eu/git/libslz.git/
   - cd libslz && make && make PREFIX=${HOME}/opt install && cd ..
+  allow_failures:
+  - os: linux
+arch: arm64
+if: type == push
+compiler: clang
 
 install:
   - git clone https://github.com/VTest/VTest.git ../vtest
-- 
2.25.4

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

btw, I'm going to enable arm64 builds back soon :)


but your efforts are awesome.

ср, 6 мая 2020 г. в 17:18, Martin Grigorov :

> Hi,
>
> I've just created a PR (https://github.com/haproxy/haproxy/pull/617/files)
> that introduces testing on ARM64/AARCH64 at GitHub Actions.
> It almost works! There are few tests that fail. Any help finding the
> reason is very welcome!
>
> Martin
>
> On Mon, Mar 23, 2020 at 11:12 AM Martin Grigorov 
> wrote:
>
>> Hi Илья,
>>
>> On Sun, Mar 22, 2020 at 2:46 PM Илья Шипицин 
>> wrote:
>>
>>> Martin,
>>>
>>> as the one of the most interested in ARM64 builds, I've got news for you
>>>
>>>
>>> can you try
>>>
>>> travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' ||
>>> (cat build-ssl.log && exit 1)
>>>
>>> in travis ? (please not "travis_wait 30" instead of "travis_wait")
>>>
>>
>> it is running at the moment here:
>> https://travis-ci.org/github/martin-g/haproxy/builds/665770469
>>
>>
>>>
>>>
>>> also, it might be important to clear travis cache from time to time.
>>> as for myself, "travis_wait 30" helped me to resolve similar issue on
>>> another project (in my own fork haproxy on arm64 builds just fine)
>>>
>>> ср, 18 мар. 2020 г. в 23:35, Илья Шипицин :
>>>
>>>> well, there are several topics on travis-ci forum related to "output on
>>>> ARM64 got truncated in the mid of ..."
>>>> Let us disable ARM64 travis-ci builds for few months.
>>>>
>>>> Martin, I'll play with hosted github runner in order to find a way how
>>>> we can limit its builds to allowed only.
>>>>
>>>> ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :
>>>>
>>>>>
>>>>> Current master's build passed the problematic point in my TravisCI
>>>>> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
>>>>> Note: I use TravisCI .org while HAProxy's official project is at .com:
>>>>> https://travis-ci.com/github/haproxy/haproxy
>>>>> I also think this is a problem on TravisCI's end.
>>>>>
>>>>> Martin
>>>>>
>>>>> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин 
>>>>> wrote:
>>>>>
>>>>>> I will disable PR builds.
>>>>>>
>>>>>> On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:
>>>>>>
>>>>>>> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
>>>>>>> > let us calm down a bit :)
>>>>>>>
>>>>>>> Agreed, especially since the build on PRs already happens and already
>>>>>>> adds noise.
>>>>>>>
>>>>>>> > yes, I still believe it is because of buffering. I might have
>>>>>>> missed
>>>>>>> > something.
>>>>>>> > unless I will repair it, I'll drop arm64 support on travis (and we
>>>>>>> will
>>>>>>> > switch to self hosted github action runner)
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>> Willy
>>>>>>>
>>>>>>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Martin Grigorov]

Hi,

I've just created a PR (https://github.com/haproxy/haproxy/pull/617/files)
that introduces testing on ARM64/AARCH64 at GitHub Actions.
It almost works! There are few tests that fail. Any help finding the reason
is very welcome!

Martin

On Mon, Mar 23, 2020 at 11:12 AM Martin Grigorov 
wrote:

> Hi Илья,
>
> On Sun, Mar 22, 2020 at 2:46 PM Илья Шипицин  wrote:
>
>> Martin,
>>
>> as the one of the most interested in ARM64 builds, I've got news for you
>>
>>
>> can you try
>>
>> travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
>> build-ssl.log && exit 1)
>>
>> in travis ? (please not "travis_wait 30" instead of "travis_wait")
>>
>
> it is running at the moment here:
> https://travis-ci.org/github/martin-g/haproxy/builds/665770469
>
>
>>
>>
>> also, it might be important to clear travis cache from time to time.
>> as for myself, "travis_wait 30" helped me to resolve similar issue on
>> another project (in my own fork haproxy on arm64 builds just fine)
>>
>> ср, 18 мар. 2020 г. в 23:35, Илья Шипицин :
>>
>>> well, there are several topics on travis-ci forum related to "output on
>>> ARM64 got truncated in the mid of ..."
>>> Let us disable ARM64 travis-ci builds for few months.
>>>
>>> Martin, I'll play with hosted github runner in order to find a way how
>>> we can limit its builds to allowed only.
>>>
>>> ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :
>>>
>>>>
>>>> Current master's build passed the problematic point in my TravisCI
>>>> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
>>>> Note: I use TravisCI .org while HAProxy's official project is at .com:
>>>> https://travis-ci.com/github/haproxy/haproxy
>>>> I also think this is a problem on TravisCI's end.
>>>>
>>>> Martin
>>>>
>>>> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин 
>>>> wrote:
>>>>
>>>>> I will disable PR builds.
>>>>>
>>>>> On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:
>>>>>
>>>>>> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
>>>>>> > let us calm down a bit :)
>>>>>>
>>>>>> Agreed, especially since the build on PRs already happens and already
>>>>>> adds noise.
>>>>>>
>>>>>> > yes, I still believe it is because of buffering. I might have missed
>>>>>> > something.
>>>>>> > unless I will repair it, I'll drop arm64 support on travis (and we
>>>>>> will
>>>>>> > switch to self hosted github action runner)
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> Willy
>>>>>>
>>>>>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Martin Grigorov]

Hi Илья,

On Sun, Mar 22, 2020 at 2:46 PM Илья Шипицин  wrote:

> Martin,
>
> as the one of the most interested in ARM64 builds, I've got news for you
>
>
> can you try
>
> travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
> build-ssl.log && exit 1)
>
> in travis ? (please not "travis_wait 30" instead of "travis_wait")
>

it is running at the moment here:
https://travis-ci.org/github/martin-g/haproxy/builds/665770469


>
>
> also, it might be important to clear travis cache from time to time.
> as for myself, "travis_wait 30" helped me to resolve similar issue on
> another project (in my own fork haproxy on arm64 builds just fine)
>
> ср, 18 мар. 2020 г. в 23:35, Илья Шипицин :
>
>> well, there are several topics on travis-ci forum related to "output on
>> ARM64 got truncated in the mid of ..."
>> Let us disable ARM64 travis-ci builds for few months.
>>
>> Martin, I'll play with hosted github runner in order to find a way how we
>> can limit its builds to allowed only.
>>
>> ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :
>>
>>>
>>> Current master's build passed the problematic point in my TravisCI
>>> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
>>> Note: I use TravisCI .org while HAProxy's official project is at .com:
>>> https://travis-ci.com/github/haproxy/haproxy
>>> I also think this is a problem on TravisCI's end.
>>>
>>> Martin
>>>
>>> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин 
>>> wrote:
>>>
>>>> I will disable PR builds.
>>>>
>>>> On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:
>>>>
>>>>> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
>>>>> > let us calm down a bit :)
>>>>>
>>>>> Agreed, especially since the build on PRs already happens and already
>>>>> adds noise.
>>>>>
>>>>> > yes, I still believe it is because of buffering. I might have missed
>>>>> > something.
>>>>> > unless I will repair it, I'll drop arm64 support on travis (and we
>>>>> will
>>>>> > switch to self hosted github action runner)
>>>>>
>>>>> OK.
>>>>>
>>>>> Willy
>>>>>
>>>>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

Martin,

as the one of the most interested in ARM64 builds, I've got news for you


can you try

travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
build-ssl.log && exit 1)

in travis ? (please not "travis_wait 30" instead of "travis_wait")


also, it might be important to clear travis cache from time to time.
as for myself, "travis_wait 30" helped me to resolve similar issue on
another project (in my own fork haproxy on arm64 builds just fine)

ср, 18 мар. 2020 г. в 23:35, Илья Шипицин :

> well, there are several topics on travis-ci forum related to "output on
> ARM64 got truncated in the mid of ..."
> Let us disable ARM64 travis-ci builds for few months.
>
> Martin, I'll play with hosted github runner in order to find a way how we
> can limit its builds to allowed only.
>
> ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :
>
>>
>> Current master's build passed the problematic point in my TravisCI
>> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
>> Note: I use TravisCI .org while HAProxy's official project is at .com:
>> https://travis-ci.com/github/haproxy/haproxy
>> I also think this is a problem on TravisCI's end.
>>
>> Martin
>>
>> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин 
>> wrote:
>>
>>> I will disable PR builds.
>>>
>>> On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:
>>>
>>>> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
>>>> > let us calm down a bit :)
>>>>
>>>> Agreed, especially since the build on PRs already happens and already
>>>> adds noise.
>>>>
>>>> > yes, I still believe it is because of buffering. I might have missed
>>>> > something.
>>>> > unless I will repair it, I'll drop arm64 support on travis (and we
>>>> will
>>>> > switch to self hosted github action runner)
>>>>
>>>> OK.
>>>>
>>>> Willy
>>>>
>>>

Re: [PATCH] temporarily disable travis-ci arm64 builds

[Илья Шипицин]

oook.


I was about to add link to mailing list discussion and travis community
forum.

пт, 20 мар. 2020 г. в 15:57, Willy Tarreau :

> On Wed, Mar 18, 2020 at 11:58:09PM +0500,  ??? wrote:
> > Hello,
> >
> > due to arm64 instability, let us disable arm64 builds until this is
> > resolved.
>
> And applied as well, thanks!
> Willy
>

Re: [PATCH] temporarily disable travis-ci arm64 builds

[Willy Tarreau]

On Wed, Mar 18, 2020 at 11:58:09PM +0500,  ??? wrote:
> Hello,
> 
> due to arm64 instability, let us disable arm64 builds until this is
> resolved.

And applied as well, thanks!
Willy

Re: [PATCH] temporarily disable travis-ci arm64 builds

[William Lallemand]

On Wed, Mar 18, 2020 at 11:58:09PM +0500, Илья Шипицин wrote:
> Hello,
> 
> due to arm64 instability, let us disable arm64 builds until this is
> resolved.
> 
> Cheers,
> Ilya Shipitcin

> From b39b8a6e4ebcae5a28f497170d4ae8e6b208023f Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Wed, 18 Mar 2020 23:37:12 +0500
> Subject: [PATCH] CI: temporarily disable unstable travis arm64 builds
> 

Ilya,

The commit message is mandatory, we won't take your patches if you don't
make the effort to write it, could you add a little bit of explanation
there? For example you could explain what's the problem with travis,
link to a mailing thread where we discussed the problem etc.

Thanks!

-- 
William Lallemand

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

well, there are several topics on travis-ci forum related to "output on
ARM64 got truncated in the mid of ..."
Let us disable ARM64 travis-ci builds for few months.

Martin, I'll play with hosted github runner in order to find a way how we
can limit its builds to allowed only.

ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :

>
> Current master's build passed the problematic point in my TravisCI
> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
> Note: I use TravisCI .org while HAProxy's official project is at .com:
> https://travis-ci.com/github/haproxy/haproxy
> I also think this is a problem on TravisCI's end.
>
> Martin
>
> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин  wrote:
>
>> I will disable PR builds.
>>
>> On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:
>>
>>> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
>>> > let us calm down a bit :)
>>>
>>> Agreed, especially since the build on PRs already happens and already
>>> adds noise.
>>>
>>> > yes, I still believe it is because of buffering. I might have missed
>>> > something.
>>> > unless I will repair it, I'll drop arm64 support on travis (and we will
>>> > switch to self hosted github action runner)
>>>
>>> OK.
>>>
>>> Willy
>>>
>>

[PATCH] temporarily disable travis-ci arm64 builds

[Илья Шипицин]

Hello,

due to arm64 instability, let us disable arm64 builds until this is
resolved.

Cheers,
Ilya Shipitcin
From b39b8a6e4ebcae5a28f497170d4ae8e6b208023f Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 18 Mar 2020 23:37:12 +0500
Subject: [PATCH] CI: temporarily disable unstable travis arm64 builds

---
 .travis.yml | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index a1e71e35d..f500e02d3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -42,11 +42,13 @@ matrix:
 if: type == push
 compiler: clang
 env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1d CC=clang-9
-  - os: linux
-arch: arm64
-if: type == push
-compiler: clang
-env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1d CC=clang-9
+##
+## temporarily disabled, until arm64 runners become stable
+#  - os: linux
+#arch: arm64
+#if: type == push
+#compiler: clang
+#env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1d CC=clang-9
   - os: linux
 arch: s390x
 if: type == push
-- 
2.24.1

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

I will disable PR builds.

On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:

> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
> > let us calm down a bit :)
>
> Agreed, especially since the build on PRs already happens and already
> adds noise.
>
> > yes, I still believe it is because of buffering. I might have missed
> > something.
> > unless I will repair it, I'll drop arm64 support on travis (and we will
> > switch to self hosted github action runner)
>
> OK.
>
> Willy
>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Martin Grigorov]

Hi,

On Wed, Mar 18, 2020 at 3:29 PM Willy Tarreau  wrote:

> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
> > let us calm down a bit :)
>
> Agreed, especially since the build on PRs already happens and already
> adds noise.
>
> > yes, I still believe it is because of buffering. I might have missed
> > something.
> > unless I will repair it, I'll drop arm64 support on travis (and we will
> > switch to self hosted github action runner)
>

There is one major problem with GitHub Actions self hosted runners at the
moment - they are not really private.
I.e. if someone forks HAProxy and pushes something into their fork it will
trigger builds on your private node, i.e. it will consume its resources.
There is no way to say "this is my private node and I want it to build only
after commits in https://github.com/haproxy/haproxy;

If you find a way around this issue and you need an ARM64 VM then just let
me know!

Regards,
Martin


>
> OK.
>
> Willy
>
>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Willy Tarreau]

On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
> let us calm down a bit :)

Agreed, especially since the build on PRs already happens and already
adds noise.

> yes, I still believe it is because of buffering. I might have missed
> something.
> unless I will repair it, I'll drop arm64 support on travis (and we will
> switch to self hosted github action runner)

OK.

Willy

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

let us calm down a bit :)

yes, I still believe it is because of buffering. I might have missed
something.
unless I will repair it, I'll drop arm64 support on travis (and we will
switch to self hosted github action runner)

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Tim Düsterhus]

William,

Am 18.03.20 um 13:37 schrieb William Lallemand:
>> Yes, in fact Travis does this by default. You can check the list of pull
>> requests and see the checkmarks or crosses in the list:
>> https://github.com/haproxy/haproxy/pulls?q=is%3Apr+is%3Aclosed
>>
>> GitHub Actions would need to be explicitly enabled for pull requests.
>>
> 
> Good to know. But will it run the CI with the config file of the PR?
> 

Yes, I believe Travis does, because "private variables" are disabled in
pull requests. Otherwise someone could just add `echo $PRIVATE_TOKEN` to
the configuration within their pull requests.

Of course one could also simply add their own repository to Travis to
test it out without the need for a pull request. In fact I believe Ilya
does: https://travis-ci.com/github/chipitsine/haproxy

Best regards
Tim Düsterhus

Re: [PATCH] fix errored ARM64 builds in travis-ci

[William Lallemand]

On Wed, Mar 18, 2020 at 01:32:30PM +0100, Tim Düsterhus wrote:
> William,
> 
> Am 18.03.20 um 13:30 schrieb William Lallemand:
> > Actually I think it's possible to run the CI on the pull requests :-)
> > 
> 
> Yes, in fact Travis does this by default. You can check the list of pull
> requests and see the checkmarks or crosses in the list:
> https://github.com/haproxy/haproxy/pulls?q=is%3Apr+is%3Aclosed
> 
> GitHub Actions would need to be explicitly enabled for pull requests.
> 

Good to know. But will it run the CI with the config file of the PR?

-- 
William Lallemand

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Tim Düsterhus]

William,

Am 18.03.20 um 13:30 schrieb William Lallemand:
> Actually I think it's possible to run the CI on the pull requests :-)
> 

Yes, in fact Travis does this by default. You can check the list of pull
requests and see the checkmarks or crosses in the list:
https://github.com/haproxy/haproxy/pulls?q=is%3Apr+is%3Aclosed

GitHub Actions would need to be explicitly enabled for pull requests.

Best regards
Tim Düsterhus

Re: [PATCH] fix errored ARM64 builds in travis-ci

[William Lallemand]

On Wed, Mar 18, 2020 at 01:23:44PM +0100, William Lallemand wrote:
> On Wed, Mar 18, 2020 at 01:17:09PM +0100, Willy Tarreau wrote:
> > It's really annoying to have to constantly commits into the project
> > just to experiment with random fixes there. The problem could very
> > well be in the build-ssl script but it's hard to tell. I was thinking
> > about disabling this entry for now because it's a pain to constantly
> > see the build status in red while it's only the SSL build which fails,
> > something that's out of our scope.
> > 
> 
> Well, maybe we could have a temporary branch to run the reg-tests then
> merge this branch once the reg-tests pass. That's what CI guys does
> generally.
> 
> Or people could just run the CI on their own fork before submitting the
> patches, but I don't know how complex this is, and we will need some doc
> if we doc that.
> 

Actually I think it's possible to run the CI on the pull requests :-)

-- 
William Lallemand

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Tim Düsterhus]

Willy,

Am 18.03.20 um 13:17 schrieb Willy Tarreau:
> That was my first impression as well, but when seeing Ilya's fix I
> thought I had incorrectly analysed the situation and that we were
> just missing some part of the buffered output.

Ilya's fixes are correct, but apply at a later point in time.

> It's really annoying to have to constantly commits into the project
> just to experiment with random fixes there. The problem could very
> well be in the build-ssl script but it's hard to tell. I was thinking
> about disabling this entry for now because it's a pain to constantly
> see the build status in red while it's only the SSL build which fails,
> something that's out of our scope.

Yes I agree here. Travis is getting more and more unreliable. GitHub
Actions which we are already using for Cygwin and recently for the spell
check supports amd64 using GitHub's runners and ARM using self-hosted
runners:
https://github.blog/changelog/2019-12-03-github-actions-self-hosted-runners-on-arm-architectures/

It might be a good replacement. Especially when using self hosted
runners, because then we are not restricted by some overcrowded cloud
infrastructure. Someone would need to step up to provide the runners,
though.

I'm also using it for my haproxy-auth-request Lua script and VTest:
https://github.com/TimWolla/haproxy-auth-request/blob/master/.github/workflows/vtest.yml

Best regards
Tim Düsterhus

Re: [PATCH] fix errored ARM64 builds in travis-ci

[William Lallemand]

On Wed, Mar 18, 2020 at 01:17:09PM +0100, Willy Tarreau wrote:
> It's really annoying to have to constantly commits into the project
> just to experiment with random fixes there. The problem could very
> well be in the build-ssl script but it's hard to tell. I was thinking
> about disabling this entry for now because it's a pain to constantly
> see the build status in red while it's only the SSL build which fails,
> something that's out of our scope.
> 

Well, maybe we could have a temporary branch to run the reg-tests then
merge this branch once the reg-tests pass. That's what CI guys does
generally.

Or people could just run the CI on their own fork before submitting the
patches, but I don't know how complex this is, and we will need some doc
if we doc that.

-- 
William Lallemand

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Tim Düsterhus]

Ilya,

Am 18.03.20 um 10:27 schrieb Илья Шипицин:
> ср, 18 мар. 2020 г. в 13:41, Willy Tarreau :
> 
>> On Tue, Mar 17, 2020 at 08:59:46PM +0500,  ??? wrote:
>>> Hello,
>>>
>>> it is not trivial bash redirection misuse fix.
>>
>> Ah cool, thank you Ilya! I was also having a look at it not
>> understanding what was wrong there! Now pushed.
>>
> 
> https://travis-ci.com/github/haproxy/haproxy/jobs/299338559
> 
> it did not help.
> I'll have more look
>

The logs stop working during `apt` processing. This looks like an issue
on Travis' end to me. Maybe a bug report should be filed with their
support. It seems to consistently hang somewhere around the installation
of libpcre2.

Best regards
Tim Düsterhus

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

ср, 18 мар. 2020 г. в 13:41, Willy Tarreau :

> On Tue, Mar 17, 2020 at 08:59:46PM +0500,  ??? wrote:
> > Hello,
> >
> > it is not trivial bash redirection misuse fix.
>
> Ah cool, thank you Ilya! I was also having a look at it not
> understanding what was wrong there! Now pushed.
>

https://travis-ci.com/github/haproxy/haproxy/jobs/299338559

it did not help.
I'll have more look


>
> Willy
>

Re: [PATCH] fix errored ARM64 builds in travis-ci

[Willy Tarreau]

On Tue, Mar 17, 2020 at 08:59:46PM +0500,  ??? wrote:
> Hello,
> 
> it is not trivial bash redirection misuse fix.

Ah cool, thank you Ilya! I was also having a look at it not
understanding what was wrong there! Now pushed.

Willy

[PATCH] fix errored ARM64 builds in travis-ci

[Илья Шипицин]

Hello,

it is not trivial bash redirection misuse fix.

Cheers,
Ilya Shipitcin
From d405c779f1c9e5b37532d0ac95e441a0735899bb Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Tue, 17 Mar 2020 20:57:25 +0500
Subject: [PATCH] CI: proper group output redirection together with travis_wait

travis_wait is bash function, it was wrongly grouped with output
redirection which leads to ARM64 builds errors last week
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 5808386e3..c7dbf8d38 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -102,7 +102,7 @@ install:
   - git clone https://github.com/VTest/VTest.git ../vtest
   # Special flags due to: https://github.com/vtest/VTest/issues/12
   - make -C ../vtest FLAGS="-O2 -s -Wall"
-  - travis_wait scripts/build-ssl.sh > build-ssl.log 2>&1 || (cat build-ssl.log && exit 1)
+  - travis_wait bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1)
 
 script:
   - if [ "$CC"  = "clang" ]; then export FLAGS="$FLAGS USE_OBSOLETE_LINKER=1" DEBUG_CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"; fi
-- 
2.24.1

Re: arm64 builds?

[Willy Tarreau]

On Fri, Jan 24, 2020 at 10:31:14AM +0100, Willy Tarreau wrote:
> This is really annoying, so much time spent dealing with bogus warnings
> is really irritating. I'm going to work around it with a cast to unsigned
> short.
> 
> The worst part of it is that if it emits such a warning, who knows how valid
> is the code that it will produce given that it doesn't even seem to figure
> the code path :-(

So I could isolate the minimum code to reproduce the bug:

#include 

int nbt = 64;

struct srv {
void *a[5];
int **b;
};

void check_config_validity4(struct srv *srv, unsigned int *v)
{
int i;

for (i = 0; i < nbt; i++)
(*v)++;
 
srv->b = calloc(/*(unsigned int)*/nbt, sizeof(*srv->b));
for (i = 0; i < nbt; i++)
srv->b[i] = 0;
}

Just change the fields ordering in "struct srv" or the size of field "a"
and the bug disappears. Remove any of the loops or make it not depend on
nbt and the bug disappears. Casting nbt to unsigned has no effect. It
always emits the same warning as seen, and only on 32-bits.

When I have a bit of spare time I may file a bug to gcc with this excerpt,
unless someone wants to handle it, of course. Even once fixed it will
probably not flow down to distros given that it's not critical, so we'll
have to work around it as we can.

Willy

Re: arm64 builds?

[Willy Tarreau]

On Fri, Jan 24, 2020 at 07:12:49AM +0500,  ??? wrote:
> > it was ubuntu 18.04 + gcc8, I'll try 19.10 + gcc9
> >
> 
> gcc9 produces the same warning

OK, I've put my hands on an ubuntu-18.04 + gcc8 32 bits. And now I can
confirm it definitely is a gcc bug. The code is the same as a few lines
above.  The cast was added a first time to shut it up but it re-appears.
And if you just change the condition in the "for" loop a few lines above
that *walks* through global.nbthread, the warning disappears. Gcc seems
to believe that we cannot reach that point if we enter the loop, which
is obviously wrong.

This is really annoying, so much time spent dealing with bogus warnings
is really irritating. I'm going to work around it with a cast to unsigned
short.

The worst part of it is that if it emits such a warning, who knows how valid
is the code that it will produce given that it doesn't even seem to figure
the code path :-(

Willy

Re: arm64 builds?

[Willy Tarreau]

On Fri, Jan 24, 2020 at 07:12:49AM +0500,  ??? wrote:
> ??, 24 ???. 2020 ?. ? 01:04,  ??? :
> 
> >
> >
> > ??, 24 ???. 2020 ?. ? 00:54, Willy Tarreau :
> >
> >> On Fri, Jan 24, 2020 at 12:46:12AM +0500,  ??? wrote:
> >> > > diff --git a/Makefile b/Makefile
> >> > > index 8399f6ca35..4757bc77e6 100644
> >> > > --- a/Makefile
> >> > > +++ b/Makefile
> >> > > @@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call
> >> cc-opt,-Wshift-negative-value)
> >> > >  SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
> >> > >  SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
> >> > >  SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
> >> > > +SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
> >> > >
> >> >
> >> >
> >> >   CC  src/cfgparse.o
> >> > src/cfgparse.c: In function 'check_config_validity':
> >> > src/cfgparse.c:3642:33: warning: product '2147483648 * 8' of arguments 1
> >> > and 2 exceeds 'SIZE_MAX' [-Walloc-size-larger-than=]
> >>
> >> Pfff The only good news is that it takes -1 as SIZE_MAX.
> >>
> >> >  newsrv->idle_orphan_conns = calloc((unsigned int)global.nbthread,
> >> > sizeof(*newsrv->idle_orphan_conns));
> >> >
> >> >
> >> ^
> >> > src/cfgparse.c:3642:33: note: argument 1 in the range [2147483648,
> >> > 4294967295]
> >> (...)
> >> > why is it complaining about "product '2147483648 * 8" ?
> >>
> >> because calloc multiplies the two fields and gcc decided that the largest
> >> value we could possibly pass to the first one if we were as stupid as it
> >> is is 2147483648. Interestingly it took the largest negative value turned
> >> to positive and ignored the positive ones that can be turned to the second
> >> half that are negative if nbthread was negative.
> >>
> >> I really think this test is totally bogus and that there is no way to
> >> express it correctly. I mean, gcc only lets us use 8, 16, 32 or 64 bits.
> >> If you need to calloc a few megabytes, you'll be forced to apply a mask
> >> to the value just to shut it up, and *create* the overflow problem
> >> yourself
> >> when it didn't exist.
> >>
> >> Let's give up on this one if it doesn't cause too much trouble to you.
> >> Otherwise we might cheat doing this :
> >>
> >> calloc((unsigned short)global.nbthread, ...)
> >>
> >> But I really despise this given that we have to make the code wrong just
> >> to please this shitty compiler.
> >>
> >
> >
> > it was ubuntu 18.04 + gcc8, I'll try 19.10 + gcc9
> >
> 
> gcc9 produces the same warning

OK thanks.

Willy

Re: arm64 builds?

[Илья Шипицин]

пт, 24 янв. 2020 г. в 01:04, Илья Шипицин :

>
>
> пт, 24 янв. 2020 г. в 00:54, Willy Tarreau :
>
>> On Fri, Jan 24, 2020 at 12:46:12AM +0500,  ??? wrote:
>> > > diff --git a/Makefile b/Makefile
>> > > index 8399f6ca35..4757bc77e6 100644
>> > > --- a/Makefile
>> > > +++ b/Makefile
>> > > @@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call
>> cc-opt,-Wshift-negative-value)
>> > >  SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
>> > >  SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
>> > >  SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
>> > > +SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
>> > >
>> >
>> >
>> >   CC  src/cfgparse.o
>> > src/cfgparse.c: In function 'check_config_validity':
>> > src/cfgparse.c:3642:33: warning: product '2147483648 * 8' of arguments 1
>> > and 2 exceeds 'SIZE_MAX' [-Walloc-size-larger-than=]
>>
>> Pfff The only good news is that it takes -1 as SIZE_MAX.
>>
>> >  newsrv->idle_orphan_conns = calloc((unsigned int)global.nbthread,
>> > sizeof(*newsrv->idle_orphan_conns));
>> >
>> >
>> ^
>> > src/cfgparse.c:3642:33: note: argument 1 in the range [2147483648,
>> > 4294967295]
>> (...)
>> > why is it complaining about "product '2147483648 * 8" ?
>>
>> because calloc multiplies the two fields and gcc decided that the largest
>> value we could possibly pass to the first one if we were as stupid as it
>> is is 2147483648. Interestingly it took the largest negative value turned
>> to positive and ignored the positive ones that can be turned to the second
>> half that are negative if nbthread was negative.
>>
>> I really think this test is totally bogus and that there is no way to
>> express it correctly. I mean, gcc only lets us use 8, 16, 32 or 64 bits.
>> If you need to calloc a few megabytes, you'll be forced to apply a mask
>> to the value just to shut it up, and *create* the overflow problem
>> yourself
>> when it didn't exist.
>>
>> Let's give up on this one if it doesn't cause too much trouble to you.
>> Otherwise we might cheat doing this :
>>
>> calloc((unsigned short)global.nbthread, ...)
>>
>> But I really despise this given that we have to make the code wrong just
>> to please this shitty compiler.
>>
>
>
> it was ubuntu 18.04 + gcc8, I'll try 19.10 + gcc9
>

gcc9 produces the same warning


>
>
>>
>> Willy
>>
>

Re: arm64 builds?

[Илья Шипицин]

пт, 24 янв. 2020 г. в 00:54, Willy Tarreau :

> On Fri, Jan 24, 2020 at 12:46:12AM +0500,  ??? wrote:
> > > diff --git a/Makefile b/Makefile
> > > index 8399f6ca35..4757bc77e6 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call
> cc-opt,-Wshift-negative-value)
> > >  SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
> > >  SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
> > >  SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
> > > +SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
> > >
> >
> >
> >   CC  src/cfgparse.o
> > src/cfgparse.c: In function 'check_config_validity':
> > src/cfgparse.c:3642:33: warning: product '2147483648 * 8' of arguments 1
> > and 2 exceeds 'SIZE_MAX' [-Walloc-size-larger-than=]
>
> Pfff The only good news is that it takes -1 as SIZE_MAX.
>
> >  newsrv->idle_orphan_conns = calloc((unsigned int)global.nbthread,
> > sizeof(*newsrv->idle_orphan_conns));
> >
> >
> ^
> > src/cfgparse.c:3642:33: note: argument 1 in the range [2147483648,
> > 4294967295]
> (...)
> > why is it complaining about "product '2147483648 * 8" ?
>
> because calloc multiplies the two fields and gcc decided that the largest
> value we could possibly pass to the first one if we were as stupid as it
> is is 2147483648. Interestingly it took the largest negative value turned
> to positive and ignored the positive ones that can be turned to the second
> half that are negative if nbthread was negative.
>
> I really think this test is totally bogus and that there is no way to
> express it correctly. I mean, gcc only lets us use 8, 16, 32 or 64 bits.
> If you need to calloc a few megabytes, you'll be forced to apply a mask
> to the value just to shut it up, and *create* the overflow problem yourself
> when it didn't exist.
>
> Let's give up on this one if it doesn't cause too much trouble to you.
> Otherwise we might cheat doing this :
>
> calloc((unsigned short)global.nbthread, ...)
>
> But I really despise this given that we have to make the code wrong just
> to please this shitty compiler.
>


it was ubuntu 18.04 + gcc8, I'll try 19.10 + gcc9


>
> Willy
>

Re: arm64 builds?

[Willy Tarreau]

On Fri, Jan 24, 2020 at 12:46:12AM +0500,  ??? wrote:
> > diff --git a/Makefile b/Makefile
> > index 8399f6ca35..4757bc77e6 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call cc-opt,-Wshift-negative-value)
> >  SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
> >  SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
> >  SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
> > +SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
> >
> 
> 
>   CC  src/cfgparse.o
> src/cfgparse.c: In function 'check_config_validity':
> src/cfgparse.c:3642:33: warning: product '2147483648 * 8' of arguments 1
> and 2 exceeds 'SIZE_MAX' [-Walloc-size-larger-than=]

Pfff The only good news is that it takes -1 as SIZE_MAX.

>  newsrv->idle_orphan_conns = calloc((unsigned int)global.nbthread,
> sizeof(*newsrv->idle_orphan_conns));
> 
>  ^
> src/cfgparse.c:3642:33: note: argument 1 in the range [2147483648,
> 4294967295]
(...)
> why is it complaining about "product '2147483648 * 8" ?

because calloc multiplies the two fields and gcc decided that the largest
value we could possibly pass to the first one if we were as stupid as it
is is 2147483648. Interestingly it took the largest negative value turned
to positive and ignored the positive ones that can be turned to the second
half that are negative if nbthread was negative.

I really think this test is totally bogus and that there is no way to
express it correctly. I mean, gcc only lets us use 8, 16, 32 or 64 bits.
If you need to calloc a few megabytes, you'll be forced to apply a mask
to the value just to shut it up, and *create* the overflow problem yourself
when it didn't exist.

Let's give up on this one if it doesn't cause too much trouble to you.
Otherwise we might cheat doing this :

calloc((unsigned short)global.nbthread, ...)

But I really despise this given that we have to make the code wrong just
to please this shitty compiler.

Willy

Re: arm64 builds?

[Илья Шипицин]

чт, 23 янв. 2020 г. в 23:17, Willy Tarreau :

> On Thu, Jan 23, 2020 at 10:59:00PM +0500,  ??? wrote:
> > > Could you please try to use (size_t) instead of (unsigned int) ? If
> it's
> > > enough to shut it up, I'm fine with doing that change. Otherwise we'll
> > > probably get rid of that stupid warning.
> > >
> >
> >   CC  src/server.o
> >   CC  src/cfgparse.o
> > src/cfgparse.c: In function 'check_config_validity':
> > src/cfgparse.c:3642:33: warning: argument 1 range [2147483648,
> 4294967295]
> > exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
> >  newsrv->idle_orphan_conns = calloc((size_t)global.nbthread,
> > sizeof(*newsrv->idle_orphan_conns));
> >
> >  ^~~
> > In file included from src/cfgparse.c:24:
> > /usr/arm-linux-gnueabihf/include/stdlib.h:541:14: note: in a call to
> > allocation function 'calloc' declared here
> >  extern void *calloc (size_t __nmemb, size_t __size)
> >   ^~
> >   CC  src/checks.o
> > ^CMakefile:846: recipe for target 'src/checks.o' failed
> > make: *** [src/checks.o] Interrupt
>
> Thanks for the test! So basically this clearly proves we respect the
> calling convention but the compiler still complains. OK I'm seeing in
> the mad that it's for functions "decorated" with the "alloc_size"
> attribute. Thus in short they enforce constraints that cannot be
> expressed with available types. This is becoming totally ridiculous.
>
> We're getting a huge collection of stupid warnings to shut up. I
> suspect that the sum of all the code written to shut them is larger
> than what haproxy 1.0 used to be :-/
>
> The man page says we can disable this crap using
> -Walloc-size-larger-than=SIZE_MAX but on my compiler (8.2) it simply
> fails to build. However when passing explicit values not even that
> large, I don't get any such warning, so I'm starting to think that
> it's a real bug of GCC 9.2, because quite frankly, aside calling
> calloc() with a char or short in argument, there's almost no way out
> of this absurdity.
>
> For me, calling it with -Walloc-size-larger-than=-1 makes it stay
> silent. is it also the case for you ? You can patch your Makefile this
> way:
>
> diff --git a/Makefile b/Makefile
> index 8399f6ca35..4757bc77e6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call cc-opt,-Wshift-negative-value)
>  SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
>  SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
>  SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
> +SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
>


  CC  src/cfgparse.o
src/cfgparse.c: In function ‘check_config_validity’:
src/cfgparse.c:3642:33: warning: product ‘2147483648 * 8’ of arguments 1
and 2 exceeds ‘SIZE_MAX’ [-Walloc-size-larger-than=]
 newsrv->idle_orphan_conns = calloc((unsigned int)global.nbthread,
sizeof(*newsrv->idle_orphan_conns));

 ^
src/cfgparse.c:3642:33: note: argument 1 in the range [2147483648,
4294967295]
In file included from src/cfgparse.c:24:
/usr/arm-linux-gnueabihf/include/stdlib.h:541:14: note: in a call to
allocation function ‘calloc’ declared here
 extern void *calloc (size_t __nmemb, size_t __size)
  ^~
  CC  src/checks.o
  CC  src/backend.o




why is it complaining about "product ‘2147483648 * 8" ?




>
>   Memory usage tuning
>  # If small memory footprint is required, you can reduce the buffer size.
> There
>
> If it still fails, we'll have to ignore it and wait for this monstrosity
> to be fixed by their authors :-/
>
> Willy
>

Re: arm64 builds?

[Willy Tarreau]

On Thu, Jan 23, 2020 at 07:41:11PM +0100, Tim Düsterhus wrote:
> Willy,
> 
> Am 23.01.20 um 19:17 schrieb Willy Tarreau:
> > Thanks for the test! So basically this clearly proves we respect the
> > calling convention but the compiler still complains. OK I'm seeing in
> > the mad that it's for functions "decorated" with the "alloc_size"
> > attribute. Thus in short they enforce constraints that cannot be
> > expressed with available types. This is becoming totally ridiculous.
> 
> Googling for that error message says something about the *result*
> needing to fit into ptrdiff_t and also something about negative numbers.
> 
> Maybe it is sufficient to change `nbthread` from `int` to `unsigned
> int`?

That's essentially what the cast did. Also we don't do it because I think
I remember that we used to use value -1 to mean "unspecified" during the
parsing.

> Otherwise the compiler assumes that a negative nbthread casted to
> an unsigned value becomes too large.

No, the reality is only about the possible extent of the value. By
turning it to unsigned it it would still be allowed to cover 0..2^32-1.
It turns out the compiler knows nothing about this value and just says
"if you did something wrong, it could theorically do that". That's
exactly the problem with this type of warnings, they're utter shit
because they assume the compiler knows better than the developer what
the possible range of his numbers are but the compiler doesn't even
look where the values are assigned and knows nothing, so it only relies
on types.

Anyway it's obvious that stupid gcc warnings started to appear after
gcc developers stopped using it for themselves by rewriting it in C++,
so they don't care if they piss off their users. Possibly some of them
don't even read C anymore since they don't need to :-/

Willy

Re: arm64 builds?

[Tim Düsterhus]

Willy,

Am 23.01.20 um 19:17 schrieb Willy Tarreau:
> Thanks for the test! So basically this clearly proves we respect the
> calling convention but the compiler still complains. OK I'm seeing in
> the mad that it's for functions "decorated" with the "alloc_size"
> attribute. Thus in short they enforce constraints that cannot be
> expressed with available types. This is becoming totally ridiculous.

Googling for that error message says something about the *result*
needing to fit into ptrdiff_t and also something about negative numbers.

Maybe it is sufficient to change `nbthread` from `int` to `unsigned
int`? Otherwise the compiler assumes that a negative nbthread casted to
an unsigned value becomes too large. I didn't check whether the code
assumes that nbthread can be negative anywhere.

Best regards
Tim Düsterhus

Re: arm64 builds?

[Willy Tarreau]

On Thu, Jan 23, 2020 at 10:59:00PM +0500,  ??? wrote:
> > Could you please try to use (size_t) instead of (unsigned int) ? If it's
> > enough to shut it up, I'm fine with doing that change. Otherwise we'll
> > probably get rid of that stupid warning.
> >
> 
>   CC  src/server.o
>   CC  src/cfgparse.o
> src/cfgparse.c: In function 'check_config_validity':
> src/cfgparse.c:3642:33: warning: argument 1 range [2147483648, 4294967295]
> exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
>  newsrv->idle_orphan_conns = calloc((size_t)global.nbthread,
> sizeof(*newsrv->idle_orphan_conns));
> 
>  ^~~
> In file included from src/cfgparse.c:24:
> /usr/arm-linux-gnueabihf/include/stdlib.h:541:14: note: in a call to
> allocation function 'calloc' declared here
>  extern void *calloc (size_t __nmemb, size_t __size)
>   ^~
>   CC  src/checks.o
> ^CMakefile:846: recipe for target 'src/checks.o' failed
> make: *** [src/checks.o] Interrupt

Thanks for the test! So basically this clearly proves we respect the
calling convention but the compiler still complains. OK I'm seeing in
the mad that it's for functions "decorated" with the "alloc_size"
attribute. Thus in short they enforce constraints that cannot be
expressed with available types. This is becoming totally ridiculous.

We're getting a huge collection of stupid warnings to shut up. I
suspect that the sum of all the code written to shut them is larger
than what haproxy 1.0 used to be :-/

The man page says we can disable this crap using
-Walloc-size-larger-than=SIZE_MAX but on my compiler (8.2) it simply
fails to build. However when passing explicit values not even that
large, I don't get any such warning, so I'm starting to think that
it's a real bug of GCC 9.2, because quite frankly, aside calling
calloc() with a char or short in argument, there's almost no way out
of this absurdity.

For me, calling it with -Walloc-size-larger-than=-1 makes it stay
silent. is it also the case for you ? You can patch your Makefile this
way:

diff --git a/Makefile b/Makefile
index 8399f6ca35..4757bc77e6 100644
--- a/Makefile
+++ b/Makefile
@@ -199,6 +199,7 @@ SPEC_CFLAGS += $(call cc-opt,-Wshift-negative-value)
 SPEC_CFLAGS += $(call cc-opt,-Wshift-overflow=2)
 SPEC_CFLAGS += $(call cc-opt,-Wduplicated-cond)
 SPEC_CFLAGS += $(call cc-opt,-Wnull-dereference)
+SPEC_CFLAGS += $(call cc-opt,-Walloc-size-larger-than=-1)
 
  Memory usage tuning
 # If small memory footprint is required, you can reduce the buffer size. There

If it still fails, we'll have to ignore it and wait for this monstrosity
to be fixed by their authors :-/

Willy

Re: arm64 builds?

[Илья Шипицин]

чт, 23 янв. 2020 г. в 15:14, Willy Tarreau :

> On Thu, Jan 23, 2020 at 01:09:22PM +0500,  ??? wrote:
> > hello,
> >
> > I tried to build using cross compiler (arm32 on amd64).  sorry for
> > screenshot.
> > Willy, do you mean errors like that ?
>
> So for those not seeing the screenshot, it says:
> warning: argument 1 range [2147483648, 4294967295] exceeds maximum object
> size 2147483647 :
>
>  new->idle_orphan_conns = calloc((unsigned int)global.nbthread,
> sizeof(*new->idle_orphan_conns));
>
> Thus the cast to unsigned int was likely placed there to shut it up
> once. Looking at the man page, it says:
>
>void *calloc(size_t nmemb, size_t size);
>
> size_t is unsigned (unless you're using an older gcc < 2.4 on a unusual
> OS). I don't see how it can be said to have a maximum size of 2147483647.
>
> This is exactly the type of stupid warnings that causes us to add casts
> that hide real bugs :-/
>
> Could you please try to use (size_t) instead of (unsigned int) ? If it's
> enough to shut it up, I'm fine with doing that change. Otherwise we'll
> probably get rid of that stupid warning.
>

  CC  src/server.o
  CC  src/cfgparse.o
src/cfgparse.c: In function ‘check_config_validity’:
src/cfgparse.c:3642:33: warning: argument 1 range [2147483648, 4294967295]
exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
 newsrv->idle_orphan_conns = calloc((size_t)global.nbthread,
sizeof(*newsrv->idle_orphan_conns));

 ^~~
In file included from src/cfgparse.c:24:
/usr/arm-linux-gnueabihf/include/stdlib.h:541:14: note: in a call to
allocation function ‘calloc’ declared here
 extern void *calloc (size_t __nmemb, size_t __size)
  ^~
  CC  src/checks.o
^CMakefile:846: recipe for target 'src/checks.o' failed
make: *** [src/checks.o] Interrupt



>
> Thanks!
> Willy
>

Re: arm64 builds?

[Willy Tarreau]

On Thu, Jan 23, 2020 at 03:21:40PM +0500,  ??? wrote:
> also, can we treat warnings as errors for CI builds ? it would save a bunch
> of time, instead of
> looking at build log, we can watch for build status.

Yes definitely. You just have to add "ERR=1" to your "make" command line
and it will append -Werror. I do this on my builds as well. And I agree
it will save some time because quite frankly, analysing why a regtest
failed when we already have a build warning is pointless!

Willy

Re: arm64 builds?

[Илья Шипицин]

чт, 23 янв. 2020 г. в 15:14, Willy Tarreau :

> On Thu, Jan 23, 2020 at 01:09:22PM +0500,  ??? wrote:
> > hello,
> >
> > I tried to build using cross compiler (arm32 on amd64).  sorry for
> > screenshot.
> > Willy, do you mean errors like that ?
>
> So for those not seeing the screenshot, it says:
> warning: argument 1 range [2147483648, 4294967295] exceeds maximum object
> size 2147483647 :
>
>  new->idle_orphan_conns = calloc((unsigned int)global.nbthread,
> sizeof(*new->idle_orphan_conns));
>
> Thus the cast to unsigned int was likely placed there to shut it up
> once. Looking at the man page, it says:
>
>void *calloc(size_t nmemb, size_t size);
>
> size_t is unsigned (unless you're using an older gcc < 2.4 on a unusual
> OS). I don't see how it can be said to have a maximum size of 2147483647.
>
> This is exactly the type of stupid warnings that causes us to add casts
> that hide real bugs :-/
>
> Could you please try to use (size_t) instead of (unsigned int) ? If it's
> enough to shut it up, I'm fine with doing that change. Otherwise we'll
> probably get rid of that stupid warning.
>

yep.
I'll play with it a liitle bit, and hopefully we will add cross builds to
Github Actions.


also, can we treat warnings as errors for CI builds ? it would save a bunch
of time, instead of
looking at build log, we can watch for build status.


>
> Thanks!
> Willy
>

Re: arm64 builds?

[Willy Tarreau]

On Thu, Jan 23, 2020 at 01:09:22PM +0500,  ??? wrote:
> hello,
> 
> I tried to build using cross compiler (arm32 on amd64).  sorry for
> screenshot.
> Willy, do you mean errors like that ?

So for those not seeing the screenshot, it says:
warning: argument 1 range [2147483648, 4294967295] exceeds maximum object
size 2147483647 :

 new->idle_orphan_conns = calloc((unsigned int)global.nbthread, 
sizeof(*new->idle_orphan_conns));

Thus the cast to unsigned int was likely placed there to shut it up
once. Looking at the man page, it says:

   void *calloc(size_t nmemb, size_t size);

size_t is unsigned (unless you're using an older gcc < 2.4 on a unusual
OS). I don't see how it can be said to have a maximum size of 2147483647.

This is exactly the type of stupid warnings that causes us to add casts
that hide real bugs :-/

Could you please try to use (size_t) instead of (unsigned int) ? If it's
enough to shut it up, I'm fine with doing that change. Otherwise we'll
probably get rid of that stupid warning.

Thanks!
Willy

Re: arm64 builds?

[Илья Шипицин]

hello,

I tried to build using cross compiler (arm32 on amd64).  sorry for
screenshot.
Willy, do you mean errors like that ?


[image: Screenshot from 2020-01-23 13-03-49.png]


ср, 6 нояб. 2019 г. в 12:26, Willy Tarreau :

> Hi Ilya,
>
> On Tue, Nov 05, 2019 at 07:20:43PM +0500,  ??? wrote:
> > only arm64 are available.
> > we can try arm using cross build, for example.
>
> Then don't bother with this, it's likely then that they will not
> have all the environment available. Maybe even their hardware does
> not support arm32 at all. It was just a suggestion to try to optimize
> the solution but even arm64 is already nice to have.
>
> > is it common way to use cross build for building haproxy ?
>
> Yes it is. Actually I don't think I've built it natively for a very
> long time now, as even on my laptop I'm used to stick to the cross-
> compilers which are distributed on the distcc build farm running on
> the lab load generators :-)
>
> In practice just pass "CC=/path/to/gcc" and let it do its job. It will
> automatically use LD=$(CC) if you don't override it. You may have to
> pass PCRE_INC/PCRE_LIB, SSL_INC/SSL_LIB, LUA_INC/LUA_LIB but that's
> about all.
>
> Just for reference here's the command line I'm using when building
> (and a variant with -O0 which builds in 3.5 seconds). It may look
> large because I force all debugging options but it's in a script so
> I don't have to type it :-)
>
>PATH=/f/tc/x86_64-gcc47_glibc218-linux-gnu/bin:$PATH make -j 120
> TMPDIR=/dev/shm DISTCC_FALLBACK=0 DISTCC_SKIP_LOCAL_RETRY=0
> DISTCC_BACKOFF_PERIOD=0 DISTCC_PAUSE_TIME_MSEC=50
> DISTCC_HOSTS="--localslots_cpp=120 10.0.0.235/120,lzo"
> CC=/g/public/linux/master/x86_64-gcc47_glibc218-linux-gnu-gcc
> TARGET=linux-glibc DEP= USE_PCRE=1 PCREDIR=
> DEFINE="-DDEBUG_DONT_SHARE_POOLS -DDEBUG_MEMORY_POOLS -DDEBUG_UAF
> -DDEBUG_EXPR -DDEBUG_STRICT -DDEBUG_DEV" USE_OPENSSL=1 USE_ZLIB=1 USE_LUA=1
> LUA_LIB_NAME=lua EXTRA= USE_SLZ=1 SLZ_INC=/g/public/slz/src
> SLZ_LIB=/g/public/slz USE_ZLIB= USE_DEVICEATLAS=1
> DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1
> 51DEGREES_SRC=contrib/51d/src/trie USE_WURFL=1 WURFL_INC=contrib/wurfl
> WURFL_LIB=contrib/wurfl CPU_CFLAGS="-O2" "$@"
>
> When testing with various local openssl branches I do have another variant
> of this which uses the local, native pre-processor and linkers, and remote
> compilers. It's a bit ugly since they're not on the same version but in
> practice it works fine.
>
> Cheers,
> Willy
>

Re: arm64 builds?

[Willy Tarreau]

Hi Ionel,

On Mon, Nov 04, 2019 at 02:10:56PM +0100, GARDAIS Ionel wrote:
> FWIW, when I build for armhf (RaspberryPi 3b with Raspbian buster), I have to 
> add -latomic to the LD_FLAGS.

It's not the case for me but I had to add it for another one, I think
it was for the mips running in my build farm's controller. It's easy
to detect usually, if the linking fails with atomic operations you
know you need it.

Willy

Re: arm64 builds?

[Willy Tarreau]

Hi Ilya,

On Tue, Nov 05, 2019 at 07:20:43PM +0500,  ??? wrote:
> only arm64 are available.
> we can try arm using cross build, for example.

Then don't bother with this, it's likely then that they will not
have all the environment available. Maybe even their hardware does
not support arm32 at all. It was just a suggestion to try to optimize
the solution but even arm64 is already nice to have.

> is it common way to use cross build for building haproxy ?

Yes it is. Actually I don't think I've built it natively for a very
long time now, as even on my laptop I'm used to stick to the cross-
compilers which are distributed on the distcc build farm running on
the lab load generators :-)

In practice just pass "CC=/path/to/gcc" and let it do its job. It will
automatically use LD=$(CC) if you don't override it. You may have to
pass PCRE_INC/PCRE_LIB, SSL_INC/SSL_LIB, LUA_INC/LUA_LIB but that's
about all.

Just for reference here's the command line I'm using when building
(and a variant with -O0 which builds in 3.5 seconds). It may look
large because I force all debugging options but it's in a script so
I don't have to type it :-)

   PATH=/f/tc/x86_64-gcc47_glibc218-linux-gnu/bin:$PATH make -j 120 
TMPDIR=/dev/shm DISTCC_FALLBACK=0 DISTCC_SKIP_LOCAL_RETRY=0 
DISTCC_BACKOFF_PERIOD=0 DISTCC_PAUSE_TIME_MSEC=50 
DISTCC_HOSTS="--localslots_cpp=120 10.0.0.235/120,lzo" 
CC=/g/public/linux/master/x86_64-gcc47_glibc218-linux-gnu-gcc 
TARGET=linux-glibc DEP= USE_PCRE=1 PCREDIR= DEFINE="-DDEBUG_DONT_SHARE_POOLS 
-DDEBUG_MEMORY_POOLS -DDEBUG_UAF -DDEBUG_EXPR -DDEBUG_STRICT -DDEBUG_DEV" 
USE_OPENSSL=1 USE_ZLIB=1 USE_LUA=1 LUA_LIB_NAME=lua EXTRA= USE_SLZ=1 
SLZ_INC=/g/public/slz/src SLZ_LIB=/g/public/slz USE_ZLIB= USE_DEVICEATLAS=1 
DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1 
51DEGREES_SRC=contrib/51d/src/trie USE_WURFL=1 WURFL_INC=contrib/wurfl 
WURFL_LIB=contrib/wurfl CPU_CFLAGS="-O2" "$@"

When testing with various local openssl branches I do have another variant
of this which uses the local, native pre-processor and linkers, and remote
compilers. It's a bit ugly since they're not on the same version but in
practice it works fine.

Cheers,
Willy

Re: arm64 builds?

[Илья Шипицин]

пн, 4 нояб. 2019 г. в 17:49, Willy Tarreau :

> Hi Ilya,
>
> On Mon, Nov 04, 2019 at 12:18:49AM +0500,  ??? wrote:
> > hello,
> >
> > should we switch some builds to arm64?
> >
> > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
>
> Ah that's interesting! I frequently build for arm/arm64 but I agree
> it would be nice to have this done more frequently. The two main points
> I'm seeing are :
>   - unsigned chars, which occasionally trigger a warning somewhere
>   - non-x86 build, which can occasionally trigger a build error if
> we accidently rely on an arch-specific function
>
> In fact I would even suggest that we build for arm instead of arm64 so
> that we switch to 32 bits at the same time and have an opportunity to
> detect long vs int vs uint64t vs pointer vs size_t issues (typically
> places where printf uses "%lu" without a cast for uint64_t).
>


only arm64 are available.
we can try arm using cross build, for example. is it common way to use
cross build for building haproxy ?


>
> Thanks,
> Willy
>

Re: arm64 builds?

[GARDAIS Ionel]

Hi,

FWIW, when I build for armhf (RaspberryPi 3b with Raspbian buster), I have to 
add -latomic to the LD_FLAGS.

Ionel


- Mail original -
De: "Willy Tarreau" 
À: " ???" 
Cc: "haproxy" 
Envoyé: Lundi 4 Novembre 2019 13:48:57
Objet: Re: arm64 builds?

Hi Ilya,

On Mon, Nov 04, 2019 at 12:18:49AM +0500,  ??? wrote:
> hello,
> 
> should we switch some builds to arm64?
> 
> https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support

Ah that's interesting! I frequently build for arm/arm64 but I agree
it would be nice to have this done more frequently. The two main points
I'm seeing are :
  - unsigned chars, which occasionally trigger a warning somewhere
  - non-x86 build, which can occasionally trigger a build error if
we accidently rely on an arch-specific function

In fact I would even suggest that we build for arm instead of arm64 so
that we switch to 32 bits at the same time and have an opportunity to
detect long vs int vs uint64t vs pointer vs size_t issues (typically
places where printf uses "%lu" without a cast for uint64_t).
 
Thanks,
Willy
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301

Re: arm64 builds?

[Willy Tarreau]

Hi Ilya,

On Mon, Nov 04, 2019 at 12:18:49AM +0500,  ??? wrote:
> hello,
> 
> should we switch some builds to arm64?
> 
> https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support

Ah that's interesting! I frequently build for arm/arm64 but I agree
it would be nice to have this done more frequently. The two main points
I'm seeing are :
  - unsigned chars, which occasionally trigger a warning somewhere
  - non-x86 build, which can occasionally trigger a build error if
we accidently rely on an arch-specific function

In fact I would even suggest that we build for arm instead of arm64 so
that we switch to 32 bits at the same time and have an opportunity to
detect long vs int vs uint64t vs pointer vs size_t issues (typically
places where printf uses "%lu" without a cast for uint64_t).
 
Thanks,
Willy

arm64 builds?

[Илья Шипицин]

hello,

should we switch some builds to arm64?

https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support

thanks,
Ilya Shipitsin