| Message ID | 20170213200619.10535-1-gary.bisson@boundarydevices.com |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Mon, 13 Feb 2017 21:06:19 +0100, Gary Bisson wrote: > The package otherwise fails to build with a recent toolchain with GCC6 > (tested with Linaro ARM 2016.11). > > It used to fail at sqrt check during package configuration: > Checking for function sqrt : not found > The configuration failed > > Bumping version to latest HEAD fixes the issue as explained in the > following discussion: > https://github.com/glmark2/glmark2/issues/15 > > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> > --- > package/glmark2/glmark2.hash | 2 +- > package/glmark2/glmark2.mk | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Applied to master, thanks. However, I had to add a reference to an autobuilder issue (after checking that I could reproduce the issue, and that it was indeed fixed by your patch). Next time, could you make sure to include a reference to the autobuilder failure being fixed? Thanks! Thomas
Hi Thomas, On Mon, Feb 13, 2017 at 10:39 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Mon, 13 Feb 2017 21:06:19 +0100, Gary Bisson wrote: >> The package otherwise fails to build with a recent toolchain with GCC6 >> (tested with Linaro ARM 2016.11). >> >> It used to fail at sqrt check during package configuration: >> Checking for function sqrt : not found >> The configuration failed >> >> Bumping version to latest HEAD fixes the issue as explained in the >> following discussion: >> https://github.com/glmark2/glmark2/issues/15 >> >> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> >> --- >> package/glmark2/glmark2.hash | 2 +- >> package/glmark2/glmark2.mk | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) > > Applied to master, thanks. However, I had to add a reference to an > autobuilder issue (after checking that I could reproduce the issue, and > that it was indeed fixed by your patch). Next time, could you make sure > to include a reference to the autobuilder failure being fixed? Sure, I didn't know there was an autobuilder issue about it actually. I just ran into it myself. BTW, when we have such case, is it possible to drop the faulty defconfig somewhere so the autobuilder can try it later? Or is the best option is sending it on the ML or on IRC? Thanks, Gary
Hello, On Tue, 14 Feb 2017 09:27:43 +0100, Gary Bisson wrote: > > Applied to master, thanks. However, I had to add a reference to an > > autobuilder issue (after checking that I could reproduce the issue, and > > that it was indeed fixed by your patch). Next time, could you make sure > > to include a reference to the autobuilder failure being fixed? > > Sure, I didn't know there was an autobuilder issue about it actually. > I just ran into it myself. Ah, OK. > BTW, when we have such case, is it possible to drop the faulty > defconfig somewhere so the autobuilder can try it later? Not sure what you mean here. But probably you mean testing a specific defconfig with all the configurations tested by the autobuilders. Then if that's what you mean, have a look at support/scripts/test-pkg that was recently merged. It does exactly that: you provide a config snippet that enables a selection of packages, and it will build that selection of packages with all toolchain configurations used by the autobuilders. > Or is the best option is sending it on the ML or on IRC? There is no way to "inject" a specific package configuration in the autobuilders. The autobuilders simply build random selection of packages, all day long. Thomas
Hi Thomas, On Tue, Feb 14, 2017 at 9:44 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Tue, 14 Feb 2017 09:27:43 +0100, Gary Bisson wrote: > >> > Applied to master, thanks. However, I had to add a reference to an >> > autobuilder issue (after checking that I could reproduce the issue, and >> > that it was indeed fixed by your patch). Next time, could you make sure >> > to include a reference to the autobuilder failure being fixed? >> >> Sure, I didn't know there was an autobuilder issue about it actually. >> I just ran into it myself. > > Ah, OK. > >> BTW, when we have such case, is it possible to drop the faulty >> defconfig somewhere so the autobuilder can try it later? > > Not sure what you mean here. But probably you mean testing a specific > defconfig with all the configurations tested by the autobuilders. Then > if that's what you mean, have a look at support/scripts/test-pkg that > was recently merged. It does exactly that: you provide a config snippet > that enables a selection of packages, and it will build that selection > of packages with all toolchain configurations used by the autobuilders. > >> Or is the best option is sending it on the ML or on IRC? > > There is no way to "inject" a specific package configuration in the > autobuilders. The autobuilders simply build random selection of > packages, all day long. No that is what I meant, "injecting" a defconfig so that a problem that we see locally can be reproduced by a server and that we know there will be a trace of that issue somewhere (with all the proper information). I understand it would be a mess to maintain such infrastructure, but at least that would be a go-to response when someone says something is broken: put your defconfig on the server and we'll see. Thanks for your feedback. Gary
Hello, On Tue, 14 Feb 2017 09:49:09 +0100, Gary Bisson wrote: > No that is what I meant, "injecting" a defconfig so that a problem > that we see locally can be reproduced by a server and that we know > there will be a trace of that issue somewhere (with all the proper > information). > > I understand it would be a mess to maintain such infrastructure, but > at least that would be a go-to response when someone says something is > broken: put your defconfig on the server and we'll see. Well, in practice this is not really useful. If a given problem has been produced by the autobuilders, it's really easy to find it. For example, for your glmark2 issue, I simply did: http://autobuild.buildroot.net/?reason=glmark2-fa71af2dfab711fac87b9504b6fc9862f44bf72a And looked at the last few errors, and they were the ones your patch was fixing. Best regards, Thomas
diff --git a/package/glmark2/glmark2.hash b/package/glmark2/glmark2.hash index 7868b37d9..92c53e541 100644 --- a/package/glmark2/glmark2.hash +++ b/package/glmark2/glmark2.hash @@ -1,2 +1,2 @@ # Locally computed -sha256 421bdb87ed8c04a25f60816c7754d45e91a45136f5489df59d74001c159882b8 glmark2-fa71af2dfab711fac87b9504b6fc9862f44bf72a.tar.gz +sha256 ea59bd267a88e2c773423eec43f7cb90b0ca1c369762e836dec575ebdcdcc012 glmark2-7215c0f337dae0b232535549c37fca441747a891.tar.gz diff --git a/package/glmark2/glmark2.mk b/package/glmark2/glmark2.mk index e35e36a4e..f9631a0c3 100644 --- a/package/glmark2/glmark2.mk +++ b/package/glmark2/glmark2.mk @@ -4,7 +4,7 @@ # ################################################################################ -GLMARK2_VERSION = fa71af2dfab711fac87b9504b6fc9862f44bf72a +GLMARK2_VERSION = 7215c0f337dae0b232535549c37fca441747a891 GLMARK2_SITE = $(call github,glmark2,glmark2,$(GLMARK2_VERSION)) GLMARK2_LICENSE = GPLv3+ SGIv1 GLMARK2_LICENSE_FILES = COPYING COPYING.SGI
The package otherwise fails to build with a recent toolchain with GCC6 (tested with Linaro ARM 2016.11). It used to fail at sqrt check during package configuration: Checking for function sqrt : not found The configuration failed Bumping version to latest HEAD fixes the issue as explained in the following discussion: https://github.com/glmark2/glmark2/issues/15 Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com> --- package/glmark2/glmark2.hash | 2 +- package/glmark2/glmark2.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)