[Buildroot] Buildroot defconfig failures

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

Fabio, Ren: there are some questions for you below.

I took a look at the Buildroot defconfig failures, which have been
built tested by Gitlab CI this morning. I've fixed a number of them,
but there are a few that still need fixing:

 - The CSKY defconfig does not build, with "SSP support not available
   in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP".
   However, I can't reproduce locally. So I'm not sure what happening.

   There is no hash on the toolchain tarball, but the one I downloaded
   locally has the exact same size as the one that was downloaded by
   Gitlab CI. While not an 100% guaranteed proof that it's the same
   toolchain, it would be unlikely to have the toolchain tarball
   changed in the mean time.

   So the only explanation would be that the SSP check for some reason
   fails in the Gitlab CI infrastructure.

   Arnout, what do you think ?

   Ren, do you have an idea ?

   See https://gitlab.com/buildroot.org/buildroot/builds/15762185

 - All Freescale defconfigs that rely on git.freescale.com are failing
   with "Connection timed out". I'm also not able to clone from
   git.freescale.com from my local machine, at least with git://. I'm
   currently trying with http://. If that works, I'll update the
   defconfigs accordingly.

   Fabio, do you have a suggestion?

The ones that have been fixed:

 - armadeus_apf9328_defconfig

   https://gitlab.com/buildroot.org/buildroot/builds/15762159

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=423e1381b426eb63695b1bc36c2d60aaf4001cf0

 - beaglebone_qt5_defconfig

   https://gitlab.com/buildroot.org/buildroot/builds/15762182

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=028eb673c8f2c79fb26dfe7287d43bc237441035

 - check-gitlab-cy.yml

   https://gitlab.com/buildroot.org/buildroot/builds/15762148

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=6520c06e5b0478e2094a4d61a9b621579cadf0df

 - galileo_defconfig

   https://gitlab.com/buildroot.org/buildroot/builds/15762201

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=fcbb098a0c87337752afdd5cb76bd9714a9873eb

 - pc_x86_64_efi_defconfig

   https://gitlab.com/buildroot.org/buildroot/builds/15762234

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=a4b8342bbe4761b5e9e5306ff549f0ca8bc166bb

 - snps_archs38_zebu_defconfig

   https://gitlab.com/buildroot.org/buildroot/builds/15762277

   Fixed by
   https://git.buildroot.org/buildroot/commit/?id=ef1ad1fe66a6f55a7d5e1c45c88f665c9470c363

 - stm32f469_disco_defconfig 

   https://gitlab.com/buildroot.org/buildroot/builds/15762279

   Fixed by:
   https://git.buildroot.org/buildroot/commit/?id=c383e8fc8be95deb16032fecd1de00792e2cddb0

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

On Sun, 7 May 2017 14:55:48 +0200, Thomas Petazzoni wrote:

>  - All Freescale defconfigs that rely on git.freescale.com are failing
>    with "Connection timed out". I'm also not able to clone from
>    git.freescale.com from my local machine, at least with git://. I'm
>    currently trying with http://. If that works, I'll update the
>    defconfigs accordingly.
> 
>    Fabio, do you have a suggestion?

Cloning from http:// also fails:

>>> linux rel_imx_4.1.15_2.0.0_ga Downloading
Doing shallow clone
Cloning into 'linux-rel_imx_4.1.15_2.0.0_ga'...
fatal: dumb http transport does not support --depth
Shallow clone failed, falling back to doing a full clone
Doing full clone
Cloning into 'linux-rel_imx_4.1.15_2.0.0_ga'...
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

Could not fetch special ref 'rel_imx_4.1.15_2.0.0_ga'; assuming it is not special.

While the tag rel_imx_4.1.15_2.0.0_ga clearly exists in
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/.

Peter: as a temporary fix, could you put
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/snapshot/linux-imx-rel_imx_4.1.15_2.0.0_ga.tar.gz
in http://sources.buildroot.net ? Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Buildroot defconfig failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > Cloning from http:// also fails:

 >>>> linux rel_imx_4.1.15_2.0.0_ga Downloading
 > Doing shallow clone
 > Cloning into 'linux-rel_imx_4.1.15_2.0.0_ga'...
 > fatal: dumb http transport does not support --depth
 > Shallow clone failed, falling back to doing a full clone
 > Doing full clone
 > Cloning into 'linux-rel_imx_4.1.15_2.0.0_ga'...
 > Checking connectivity... done.
 > warning: remote HEAD refers to nonexistent ref, unable to checkout.

 > Could not fetch special ref 'rel_imx_4.1.15_2.0.0_ga'; assuming it is not special.

 > While the tag rel_imx_4.1.15_2.0.0_ga clearly exists in
 > http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/.

 > Peter: as a temporary fix, could you put
 > http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/snapshot/linux-imx-rel_imx_4.1.15_2.0.0_ga.tar.gz
 > in http://sources.buildroot.net ? Thanks!

Done! (earlier today).

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot defconfig failures

[Fabio Estevam]

Hi Thomas,

On Sun, May 7, 2017 at 9:55 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:

>  - All Freescale defconfigs that rely on git.freescale.com are failing
>    with "Connection timed out". I'm also not able to clone from
>    git.freescale.com from my local machine, at least with git://. I'm
>    currently trying with http://. If that works, I'll update the
>    defconfigs accordingly.
>
>    Fabio, do you have a suggestion?

Thanks for reporting. I will talk to the people responsible for the
git server at NXP.

Regards,

Fabio Estevam

[Buildroot] Buildroot defconfig failures

[ren_guo]

Hi Thomas,

>   - The CSKY defconfig does not build, with "SSP support not available
>     in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP".
>     However, I can't reproduce locally. So I'm not sure what happening.

Our toolchain support SSP. And I've tried the cmd from toolchain/helper.mk:419

"echo 'void main(){}' | csky-linux-gcc -fstack-protector -x c - -o hello  && echo y"

It's OK on my ubuntu 16.04.

>     There is no hash on the toolchain tarball, but the one I downloaded
>     locally has the exact same size as the one that was downloaded by
>     Gitlab CI. While not an 100% guaranteed proof that it's the same
>     toolchain, it would be unlikely to have the toolchain tarball
>     changed in the mean time.

Ok, I will add hash right now, thx.

>     So the only explanation would be that the SSP check for some reason
>     fails in the Gitlab CI infrastructure.
>
>     Arnout, what do you think ?
>
>     Ren, do you have an idea ?
>
>     See https://gitlab.com/buildroot.org/buildroot/builds/15762185

I think the problem is exec toolchain/helper.mk:419 failed on Gitlab CI.

-- 
Guo Ren, Software Engineer, C-SKY
3 XiDoumen Rd,BldgA,15F,Hangzhou,China
P.C: 310012
http://www.c-sky.com

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

On Mon, 8 May 2017 10:33:02 +0800, ren_guo wrote:

> >   - The CSKY defconfig does not build, with "SSP support not available
> >     in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP".
> >     However, I can't reproduce locally. So I'm not sure what happening.  
> 
> Our toolchain support SSP. And I've tried the cmd from toolchain/helper.mk:419
> 
> "echo 'void main(){}' | csky-linux-gcc -fstack-protector -x c - -o hello  && echo y"
> 
> It's OK on my ubuntu 16.04.

Yes, it's OK here as well. And it seems to work fine on Gitlab CI for
many other toolchains as well. So we have something weird here.

> >     There is no hash on the toolchain tarball, but the one I downloaded
> >     locally has the exact same size as the one that was downloaded by
> >     Gitlab CI. While not an 100% guaranteed proof that it's the same
> >     toolchain, it would be unlikely to have the toolchain tarball
> >     changed in the mean time.  
> 
> Ok, I will add hash right now, thx.

Where will you add the hash? You can't add the hash in Buildroot for
custom external toolchains.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Buildroot defconfig failures

[ren_guo]

hi Thomas,

> Yes, it's OK here as well. And it seems to work fine on Gitlab CI for
> many other toolEchains as well. So we have something weird here.

We will try to make a Gitlab CI environment to determine csky-linux-gcc problem.

> Where will you add the hash? You can't add the hash in Buildroot for
> custom external toolchains.

En... I want to add a toolchain-external-csky, is that ok?

Best Regards

-- 
Guo Ren, Software Engineer, C-SKY
3 XiDoumen Rd,BldgA,15F,Hangzhou,China
P.C: 310012
http://www.c-sky.com

[Buildroot] Buildroot defconfig failures

[Arnout Vandecappelle]

On 08-05-17 15:43, ren_guo wrote:
> hi Thomas,
> 
>> Yes, it's OK here as well. And it seems to work fine on Gitlab CI for
>> many other toolEchains as well. So we have something weird here.
> 
> We will try to make a Gitlab CI environment to determine csky-linux-gcc problem.

 You can just create a gitlab account, fork the official gitlab buildroot
repository, modify .gitlab-ci.yml and push it. The you use the real gitlab
server for you debugging.

 You can do this on a branch that you delete later to "forget" about this
debugging run.

 Regards,
 Arnout

> 
>> Where will you add the hash? You can't add the hash in Buildroot for
>> custom external toolchains.
> 
> En... I want to add a toolchain-external-csky, is that ok?
> 
> Best Regards
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

On Mon, 8 May 2017 21:43:40 +0800, ren_guo wrote:

> > Where will you add the hash? You can't add the hash in Buildroot for
> > custom external toolchains.  
> 
> En... I want to add a toolchain-external-csky, is that ok?

Ah, yes, good point.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Buildroot defconfig failures

[ren_guo]

>   You can just create a gitlab account, fork the official gitlab buildroot
> repository, modify .gitlab-ci.yml and push it. The you use the real gitlab
> server for you debugging.
>
>   You can do this on a branch that you delete later to "forget" about this
> debugging run.
>
>   Regards,
>   Arnout
>
Thx, nice tips!

-- 
Guo Ren, Software Engineer, C-SKY
3 XiDoumen Rd,BldgA,15F,Hangzhou,China
P.C: 310012
http://www.c-sky.com

[Buildroot] Buildroot defconfig failures

[Fabio Estevam]

Hi Thomas,

On Sun, May 7, 2017 at 9:25 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Thomas,
>
> On Sun, May 7, 2017 at 9:55 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>
>>  - All Freescale defconfigs that rely on git.freescale.com are failing
>>    with "Connection timed out". I'm also not able to clone from
>>    git.freescale.com from my local machine, at least with git://. I'm
>>    currently trying with http://. If that works, I'll update the
>>    defconfigs accordingly.
>>
>>    Fabio, do you have a suggestion?
>
> Thanks for reporting. I will talk to the people responsible for the
> git server at NXP.

The git service has been restored, thanks.

[Buildroot] Buildroot defconfig failures

[ren_guo]

Dear Arnout,

>   You can just create a gitlab account, fork the official gitlab buildroot
> repository, modify .gitlab-ci.yml and push it. The you use the real gitlab
> server for you debugging.
>
>   You can do this on a branch that you delete later to "forget" about this
> debugging run.

1. The problem is lose "libelf1" package, csky-linux-gcc will failed like this:

|$ echo 'void main(){}' | ./bin/csky-linux-gcc -fstack-protector -x c - 
-o hello && echo y 
/builds/guoren83/buildroot/bin/../libexec/gcc/csky-linux/4.5.1/cc1: 
error while loading shared libraries: libelf.so.1: cannot open shared 
object file: No such file or directory test failed log: 
https://gitlab.com/guoren83/buildroot/builds/16073656 2. I add libelf1 
in .gitlab-ci.yml, see below 
https://gitlab.com/guoren83/buildroot/commit/8e718d6ac2d49900042861652cac585c2cb063c7 
Test is OK :) https://gitlab.com/guoren83/buildroot/builds/16074189 Best 
Regards |

-- 
Guo Ren, Software Engineer, C-SKY
3 XiDoumen Rd,BldgA,15F,Hangzhou,China
P.C: 310012
http://www.c-sky.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170511/b593779b/attachment.html>

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

On Thu, 11 May 2017 19:33:14 +0800, ren_guo wrote:

> >   You can just create a gitlab account, fork the official gitlab buildroot
> > repository, modify .gitlab-ci.yml and push it. The you use the real gitlab
> > server for you debugging.
> >
> >   You can do this on a branch that you delete later to "forget" about this
> > debugging run.  
> 
> 1. The problem is lose "libelf1" package, csky-linux-gcc will failed like this:
> 
> |$ echo 'void main(){}' | ./bin/csky-linux-gcc -fstack-protector -x c - 
> -o hello && echo y 
> /builds/guoren83/buildroot/bin/../libexec/gcc/csky-linux/4.5.1/cc1: 
> error while loading shared libraries: libelf.so.1: cannot open shared 
> object file: No such file or directory test failed log: 
> https://gitlab.com/guoren83/buildroot/builds/16073656 2. I add libelf1 
> in .gitlab-ci.yml, see below 
> https://gitlab.com/guoren83/buildroot/commit/8e718d6ac2d49900042861652cac585c2cb063c7 
> Test is OK :) https://gitlab.com/guoren83/buildroot/builds/16074189

Ah, good finding. Thanks for this investigation!

However, do we want to add libelf1 ? Shouldn't you tweak your toolchain
build process to link gcc statically with libelf1 ?

It is worth mentioning that gcc no longer depends on libelf since gcc
4.6.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Buildroot defconfig failures

[ren_guo]

Dear Thomas,

>>>    You can just create a gitlab account, fork the official gitlab buildroot
>>> repository, modify .gitlab-ci.yml and push it. The you use the real gitlab
>>> server for you debugging.
>>>
>>>    You can do this on a branch that you delete later to "forget" about this
>>> debugging run.
>> 1. The problem is lose "libelf1" package, csky-linux-gcc will failed like this:
>>
>> |$ echo 'void main(){}' | ./bin/csky-linux-gcc -fstack-protector -x c -
>> -o hello && echo y
>> /builds/guoren83/buildroot/bin/../libexec/gcc/csky-linux/4.5.1/cc1:
>> error while loading shared libraries: libelf.so.1: cannot open shared
>> object file: No such file or directory test failed log:
>> https://gitlab.com/guoren83/buildroot/builds/16073656 2. I add libelf1
>> in .gitlab-ci.yml, see below
>> https://gitlab.com/guoren83/buildroot/commit/8e718d6ac2d49900042861652cac585c2cb063c7
>> Test is OK :) https://gitlab.com/guoren83/buildroot/builds/16074189
> Ah, good finding. Thanks for this investigation!
>
> However, do we want to add libelf1 ? Shouldn't you tweak your toolchain
> build process to link gcc statically with libelf1 ?

We use gcc 4.5.1 currently, and in gcc's configure file it linked with libelf.

So all gcc-4.5.1 will need libelf, not we cause this.

So pls add libelf1, and very very thx.

Best Regards

-- 
Guo Ren, Software Engineer, C-SKY
3 XiDoumen Rd,BldgA,15F,Hangzhou,China
P.C: 310012
http://www.c-sky.com

[Buildroot] Buildroot defconfig failures

[Thomas Petazzoni]

Hello,

On Thu, 11 May 2017 20:05:26 +0800, ren_guo wrote:

> >> |$ echo 'void main(){}' | ./bin/csky-linux-gcc -fstack-protector -x c -
> >> -o hello && echo y
> >> /builds/guoren83/buildroot/bin/../libexec/gcc/csky-linux/4.5.1/cc1:
> >> error while loading shared libraries: libelf.so.1: cannot open shared
> >> object file: No such file or directory test failed log:
> >> https://gitlab.com/guoren83/buildroot/builds/16073656 2. I add libelf1
> >> in .gitlab-ci.yml, see below
> >> https://gitlab.com/guoren83/buildroot/commit/8e718d6ac2d49900042861652cac585c2cb063c7
> >> Test is OK :) https://gitlab.com/guoren83/buildroot/builds/16074189  
> > Ah, good finding. Thanks for this investigation!
> >
> > However, do we want to add libelf1 ? Shouldn't you tweak your toolchain
> > build process to link gcc statically with libelf1 ?  
> 
> We use gcc 4.5.1 currently, and in gcc's configure file it linked with libelf.
> 
> So all gcc-4.5.1 will need libelf, not we cause this.

Yes, all gcc 4.5 will need libelf, but you could link your gcc
statically against libelf so that you don't need to use the
system-provided libelf.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com