Hello,
I seem to have begun receiving CI/CD patch notifications from ci_notify@linaro.org. I don't understand them, and they might be premature. I don't want to ignore them, though, if they do matter.
I am supplying a 100,000 line patch, roughly, to add a COBOL front-end to gcc. As of now, there is no libgcobol or gcc/cobol directory in the master branch. The supplied patch came most recently in 14 "easy pieces". To be applied successfully, the patches to the Python scripts that create those directories must be applied first.
The URLs at the end of the mail come up 404. I suppose they are ephemeral. I haven't been able to look at a complete log to understand the basis of the report.
The mail says to ask here, so here I be. Please advise. I'm not subscribed to this list.
Thanks,
--jkl
Begin forwarded message:
Date: Wed, 19 Feb 2025 15:10:38 +0000 (UTC) From: ci_notify@linaro.org To: jklowden@schemamania.org Subject: [Linaro-TCWG-CI] gcc patch #106762: Failure on aarch64
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In gcc_build master-aarch64, after: | gcc patch https://patchwork.sourceware.org/patch/106762 | Author: James K. Lowden jklowden@schemamania.org | Date: Tue Feb 18 18:37:13 2025 -0500 | | [PATCH] COBOL v3: 3/14 80K bld: config and build machinery | | From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST | From: "James K. Lowden" jklowden@symas.com | Date: Tue 18 Feb 2025 04:19:10 PM EST | ... 27 lines of the commit log omitted. | ... applied on top of baseline commit: | 427386042f0 LoongArch: Use normal RTL pattern instead of UNSPEC for {x,}vsr{a,l}ri instructions
Produces Failure: | Results changed to | # reset_artifacts: | -10 | # true: | 0 | # build_abe gcc: | # FAILED | # First few build errors in logs: | # 00:03:17 make[1]: *** [Makefile:4720: all-gcc] Error 2 | # 00:03:17 make: *** [Makefile:1063: all] Error 2 | | From | # reset_artifacts: | -10 | # true: | 0 | # build_abe gcc: | 1
Used configuration : *CI config* tcwg_gcc_build master-aarch64 *configure and test flags:*
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in * https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art... The full lists of regressions and improvements as well as configure and make commands are in * https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art... The list of [ignored] baseline and flaky failures are in * https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art...
Current build : https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art... Reference build : https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-build/3164/artifact...
Warning: we do not enable maintainer-mode nor automatically update generated files, which may lead to failures if the patch modifies the master files.
Hi James,
Thanks for reaching out!
[CC: Christophe], would you please look at replacing [broken] links to testsuite results with links to build logs? See below.
See comments inline.
On Feb 20, 2025, at 13:42, James K. Lowden jklowden@schemamania.org wrote:
Hello,
I seem to have begun receiving CI/CD patch notifications from ci_notify@linaro.org. I don't understand them, and they might be premature. I don't want to ignore them, though, if they do matter.
I am supplying a 100,000 line patch, roughly, to add a COBOL front-end to gcc. As of now, there is no libgcobol or gcc/cobol directory in the master branch. The supplied patch came most recently in 14 "easy pieces". To be applied successfully, the patches to the Python scripts that create those directories must be applied first.
The URLs at the end of the mail come up 404. I suppose they are ephemeral. I haven't been able to look at a complete log to understand the basis of the report.
The mail says to ask here, so here I be. Please advise. I'm not subscribed to this list.
Thanks,
--jkl
Begin forwarded message:
Date: Wed, 19 Feb 2025 15:10:38 +0000 (UTC) From: ci_notify@linaro.org To: jklowden@schemamania.org Subject: [Linaro-TCWG-CI] gcc patch #106762: Failure on aarch64
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In gcc_build master-aarch64, after: | gcc patch https://patchwork.sourceware.org/patch/106762
Looking at the above patchwork entry, I see that your patch "COBOL v3: 3/14 80K bld: config and build machinery" was not detected as part of the series [1], which means it was applied without the prerequisite 1/14 and 2/14 patches. That's the reason for the failure.
[1] https://patchwork.sourceware.org/project/gcc/list/?series=44237
Looking at your whole submission [2], I see that patchwork sees each patch as its own series, so our CI will test them individually. I'm, actually, surprised that only patch 3/14 fails to build -- the rest pass the CI. I would have expected all but 1/14 to fail.
[2] https://patchwork.sourceware.org/project/gcc/list/?submitter=37098
| Author: James K. Lowden jklowden@schemamania.org | Date: Tue Feb 18 18:37:13 2025 -0500 | | [PATCH] COBOL v3: 3/14 80K bld: config and build machinery | | From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST | From: "James K. Lowden" jklowden@symas.com | Date: Tue 18 Feb 2025 04:19:10 PM EST | ... 27 lines of the commit log omitted. | ... applied on top of baseline commit: | 427386042f0 LoongArch: Use normal RTL pattern instead of UNSPEC for {x,}vsr{a,l}ri instructions
Produces Failure: | Results changed to | # reset_artifacts: | -10 | # true: | 0 | # build_abe gcc: | # FAILED | # First few build errors in logs: | # 00:03:17 make[1]: *** [Makefile:4720: all-gcc] Error 2 | # 00:03:17 make: *** [Makefile:1063: all] Error 2
The build log is at [3].
[3] https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art...
Looking at make-gcc-stage2.log.xz I see === make[2]: *** No rule to make target '/home/tcwg-build/workspace/tcwg_gnu_4/abe/snapshots/gcc.git~master/gcc/cobol/cobol1.cc', needed by 's-gtype'. Stop. ===
| | From | # reset_artifacts: | -10 | # true: | 0 | # build_abe gcc: | 1
Used configuration : *CI config* tcwg_gcc_build master-aarch64 *configure and test flags:*
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art...
This is a build failure, but we [mistakenly] include a link to the testsuite results -- we will fix this.
The full lists of regressions and improvements as well as configure and make commands are in
https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art...
This one works.
The list of [ignored] baseline and flaky failures are in
https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art...
Similar to the first, this is where testsuite xfails would have been; need to remove this link.
Current build : https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-precommit/16368/art... Reference build : https://ci.linaro.org/job/tcwg_gcc_build--master-aarch64-build/3164/artifact...
Warning: we do not enable maintainer-mode nor automatically update generated files, which may lead to failures if the patch modifies the master files. _______________________________________________ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
-- Maxim Kuvyrkov https://www.linaro.org
On Thu, 20 Feb 2025 15:05:48 +1300 Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi Maxim,
Thank you kindly for your helpful reply. Despite running my own mailserver for 25 years (reluctantly of late because bureaucracy) it seems I still have things to learn.
In gcc_build master-aarch64, after: | gcc patch https://patchwork.sourceware.org/patch/106762
Looking at the above patchwork entry, I see that your patch "COBOL v3: 3/14 80K bld: config and build machinery" was not detected as part of the series [1], which means it was applied without the prerequisite 1/14 and 2/14 patches. That's the reason for the failure.
[1] https://patchwork.sourceware.org/project/gcc/list/?series=44237
Looking at your whole submission [2], I see that patchwork sees each patch as its own series, so our CI will test them individually. I'm, actually, surprised that only patch 3/14 fails to build -- the rest pass the CI. I would have expected all but 1/14 to fail.
I did receive a few other reports. Pehaps they were applied in parallel, and those that happened to be sequenced after 1/14 succeeded. That would make sense to me.
The problem would seem to be that I don't know what a patch series is.
My patches are produced in the simplest way imaginable for someone who uses git while wearing oven mitts to avoid scorching. I have a script that runs "git diff" for a set of files, and one to convert that into a mail message. Then I use sylpheed to send each one in turn. (I could use nmh but I'm less comfortable with that, for sending. Nothing beats nmh for searching mail.)
I think you are going to tell me that some git magic will link those together as a series. Possibly a gcc git script. I haven't tried to connect git to mail because the git boxes aren't set up to send/receive mail. I've been told that's unnecessary (and/or easy to rememdy) but so far haven't gotten over the hump.
If you would nudge me in the right direction, perhaps I can DTRT.
Many thanks for your time.
Regards,
--jkl
Hi James,
I, personally, use "git format-patch / git send-email" workflow. This is described in [1] and in man pages of these respective commands. Don't mind that it is a checklist for glibc -- gcc uses the same process.
[1] https://sourceware.org/glibc/wiki/Contribution%20checklist
HTH,
-- Maxim Kuvyrkov https://www.linaro.org
On Feb 21, 2025, at 05:36, James K. Lowden jklowden@schemamania.org wrote:
On Thu, 20 Feb 2025 15:05:48 +1300 Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi Maxim,
Thank you kindly for your helpful reply. Despite running my own mailserver for 25 years (reluctantly of late because bureaucracy) it seems I still have things to learn.
In gcc_build master-aarch64, after: | gcc patch https://patchwork.sourceware.org/patch/106762
Looking at the above patchwork entry, I see that your patch "COBOL v3: 3/14 80K bld: config and build machinery" was not detected as part of the series [1], which means it was applied without the prerequisite 1/14 and 2/14 patches. That's the reason for the failure.
[1] https://patchwork.sourceware.org/project/gcc/list/?series=44237
Looking at your whole submission [2], I see that patchwork sees each patch as its own series, so our CI will test them individually. I'm, actually, surprised that only patch 3/14 fails to build -- the rest pass the CI. I would have expected all but 1/14 to fail.
I did receive a few other reports. Pehaps they were applied in parallel, and those that happened to be sequenced after 1/14 succeeded. That would make sense to me.
The problem would seem to be that I don't know what a patch series is.
My patches are produced in the simplest way imaginable for someone who uses git while wearing oven mitts to avoid scorching. I have a script that runs "git diff" for a set of files, and one to convert that into a mail message. Then I use sylpheed to send each one in turn. (I could use nmh but I'm less comfortable with that, for sending. Nothing beats nmh for searching mail.)
I think you are going to tell me that some git magic will link those together as a series. Possibly a gcc git script. I haven't tried to connect git to mail because the git boxes aren't set up to send/receive mail. I've been told that's unnecessary (and/or easy to rememdy) but so far haven't gotten over the hump.
If you would nudge me in the right direction, perhaps I can DTRT.
Many thanks for your time.
Regards,
linaro-toolchain@lists.linaro.org
-
James K. Lowden -
Maxim Kuvyrkov