From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Thu, 4 Mar 2021 23:26:34 +0100 Subject: [Buildroot] Analysis of build results for 2021-03-03 In-Reply-To: <20210304224926.45aa4056@windsurf.home> References: <20210304081519.C821B4B530@smtp4.osuosl.org> <20210304224926.45aa4056@windsurf.home> Message-ID: <20210304222634.GP2275@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Thomas, All, On 2021-03-04 22:49 +0100, Thomas Petazzoni spake thusly: > > riscv64 | fuse-overlayfs-1.4.0 | NOK | http://autobuild.buildroot.net/results/cfef18f3adf51edaedbbd193efbff19aebdfe508 | > > This is a bug in uClibc: it implements renameat() only if the > SYS_renameat system call exists. If only the SYS_renameat2 system call > exists, the renameat() function is not implemented. Musl does this > correctly: > > int renameat(int oldfd, const char *old, int newfd, const char *new) > { > #ifdef SYS_renameat > return syscall(SYS_renameat, oldfd, old, newfd, new); > #else > return syscall(SYS_renameat2, oldfd, old, newfd, new, 0); > #endif > } > > uclibc needs to be patched here. But what about external toolchains? We can't know whether they would carry such a patch or not... > > aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 | > > microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 | > > i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 | > > arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda | > What do we do with this? The only way to solve that is to have the > Cargo vendoring support, which we won't have for 2021.02. Should we > drop this package ? I am all in favour of dropping sentry-cli. It is a host-only package with no in-tree users. When it was submitted, no rationale was given to justify for having it upstream (although I suspect it may be helpfull with traces generated with sentry-native). In any case, this package is not playing nice with our infra, and our infra is not ready to accomodate such a package yet. Let's drop it for now... Since you have it in your vendoring branch, you can still keep uisng it to validate your code. > > nios2 | libgeos-3.9.0 | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH > Some more nios2 toolchain issue. > Should we get rid of nios2 support entirely ? How prevalent is nios2? What's the support in the kernel? Some time ago, quite a few old architectures were dropped; IIR, a few others were put on trial to see if they were really still alive (but apart an LWN article https://lwn.net/Articles/748074/ I can't find that list...) > > arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH > > arm | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH > toolchain is gone ? I can get it from here; wget 'https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz' --2021-03-04 23:03:07-- https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz Resolving releases.linaro.org (releases.linaro.org)... 52.215.200.125 Connecting to releases.linaro.org (releases.linaro.org)|52.215.200.125|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A [following] --2021-03-04 23:03:09-- https://publishing-ie-linaro-org.s3.amazonaws.com/releases/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz?Signature=qIOVqoIXcsiFVTalQoTG%2FdNwu9A%3D&Expires=1614895479&AWSAccessKeyId=AKIAIELXV2RYNAHFUP7A Resolving publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)... 52.218.41.226 Connecting to publishing-ie-linaro-org.s3.amazonaws.com (publishing-ie-linaro-org.s3.amazonaws.com)|52.218.41.226|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 107031352 (102M) [application/octet-stream] Saving to: ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz? gcc-linaro-7.3.1-2018.05-x 100%[=====================================>] 102.07M 17.0MB/s in 5.8s 2021-03-04 23:03:15 (17.5 MB/s) - ?gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz? saved [107031352/107031352] Temporary glitch in the network? Goblins? ;-) Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'