Bug#966897: findent: FTBFS: parser.cpp:104:10: fatal error: parser.hpp: No such file or directory
Hi, findent 3.1.7-1 was removed from testing apparently because this bug concerning findent-3.1.1-1 was still open. I closed this bug, is that enough to get findent-3.1.7-1 in testing again? (Btw: the bug is fixed in 3.1.7-1) Regards, Willem On Mon, 3 Aug 2020 10:01:39 +0200 Lucas Nussbaum wrote: Source: findent Version: 3.1.1-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200802 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o myparser.o myparser.cpp > In file included from myparser.cpp:1: > parser.cpp:104:10: fatal error: parser.hpp: No such file or directory > 104 | #include "parser.hpp" > | ^~~~ > compilation terminated. > make[4]: *** [Makefile:488: myparser.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/08/02/findent_3.1.1-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#966897: findent: FTBFS: parser.cpp:104:10: fatal error: parser.hpp: No such file or directory
findent-3.1.7-1 is now available in sid. On Tue, 4 Aug 2020 08:43:50 +0200 Willem Vermin wrote: Hi Lucas, thanks for mentioning the failing rebuild of findent. It is caused by a change in bison-3.7. In this version the generated file parser.hpp is now included in the generated parser.cpp. In previous versions og bison, this was not the case. Originally, I renamed parser.hpp to parser.h which caused the failing rebuild. I corrected this and will upload the new version to mentors and ask my mentor to upload the new version to sid. Willem On 03/08/2020 10.01, Lucas Nussbaum wrote: > Source: findent > Version: 3.1.1-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200802 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): >> g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o myparser.o myparser.cpp >> In file included from myparser.cpp:1: >> parser.cpp:104:10: fatal error: parser.hpp: No such file or directory >>104 | #include "parser.hpp" >>| ^~~~ >> compilation terminated. >> make[4]: *** [Makefile:488: myparser.o] Error 1 > > The full build log is available from: > http://qa-logs.debian.net/2020/08/02/findent_3.1.1-1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. >
Bug#966897: findent: FTBFS: parser.cpp:104:10: fatal error: parser.hpp: No such file or directory
Hi Lucas, thanks for mentioning the failing rebuild of findent. It is caused by a change in bison-3.7. In this version the generated file parser.hpp is now included in the generated parser.cpp. In previous versions og bison, this was not the case. Originally, I renamed parser.hpp to parser.h which caused the failing rebuild. I corrected this and will upload the new version to mentors and ask my mentor to upload the new version to sid. Willem On 03/08/2020 10.01, Lucas Nussbaum wrote: Source: findent Version: 3.1.1-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200802 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o myparser.o myparser.cpp In file included from myparser.cpp:1: parser.cpp:104:10: fatal error: parser.hpp: No such file or directory 104 | #include "parser.hpp" | ^~~~ compilation terminated. make[4]: *** [Makefile:488: myparser.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/08/02/findent_3.1.1-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#966897: findent: FTBFS: parser.cpp:104:10: fatal error: parser.hpp: No such file or directory
Source: findent Version: 3.1.1-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200802 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -c -o myparser.o myparser.cpp > In file included from myparser.cpp:1: > parser.cpp:104:10: fatal error: parser.hpp: No such file or directory > 104 | #include "parser.hpp" > | ^~~~ > compilation terminated. > make[4]: *** [Makefile:488: myparser.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/08/02/findent_3.1.1-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
