Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
On my machine this is passing reliably. Given that KVM virtual machine image was mentioned, maybe someone can share KVM image where this is failing? I am still eager to debug this. On Sun, Sep 18, 2016 at 4:07 AM, Santiago Vila wrote: > > On Fri, 16 Sep 2016, Lucas Nussbaum wrote: > >> On 15/09/16 at 19:39 +0200, Santiago Vila wrote: > >> > Version 2.2.1-0.3 is the first one that does not *always* fail for me. >> > This is a great achievement indeed. >> > >> > Now it builds sometimes, but 3/11 is not a very good ratio. >> >> I'm not sure, no. It's indeed possible that it's still failing randomly. > > Ok, based on available data, this package still FTBFS randomly, so I'm > raising the severity to serious again. > > Since there is a new upstream release, maybe it does not make much > sense to try to debug this in the current version. > > So I suggest the maintainer to disable the tests (trivial but untested > patch attached) for this release and reenable them for the next > upstream version. > > I don't use this package myself, and it is not my intention or desire > to see it autoremoved for the sake of removing it. > > Everything I ask is that it builds ok, so if anybody reading this > wants to see this package in stretch in its current form please consider > contacting the maintainer and/or disabling the tests in a NMU. > > Upstream is willing to help here, but if the maintainer seems to be MIA, > there is not much else we can do. > > Thanks.
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
severity 831240 serious tags 831240 patch thanks On Fri, 16 Sep 2016, Lucas Nussbaum wrote: > On 15/09/16 at 19:39 +0200, Santiago Vila wrote: > > Version 2.2.1-0.3 is the first one that does not *always* fail for me. > > This is a great achievement indeed. > > > > Now it builds sometimes, but 3/11 is not a very good ratio. > > I'm not sure, no. It's indeed possible that it's still failing randomly. Ok, based on available data, this package still FTBFS randomly, so I'm raising the severity to serious again. Since there is a new upstream release, maybe it does not make much sense to try to debug this in the current version. So I suggest the maintainer to disable the tests (trivial but untested patch attached) for this release and reenable them for the next upstream version. I don't use this package myself, and it is not my intention or desire to see it autoremoved for the sake of removing it. Everything I ask is that it builds ok, so if anybody reading this wants to see this package in stretch in its current form please consider contacting the maintainer and/or disabling the tests in a NMU. Upstream is willing to help here, but if the maintainer seems to be MIA, there is not much else we can do. Thanks.--- a/debian/rules +++ b/debian/rules @@ -22,7 +22,7 @@ DEB_INSTALL_CHANGELOGS_ALL := ChangeLog ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) # List of architectures for which test execution is enabled -TEST_ARCHS=i386 amd64 +TEST_ARCHS= ifneq (,$(findstring $(DEB_HOST_ARCH), $(TEST_ARCHS))) DEB_MAKE_CHECK_TARGET := check endif # TEST_ARCHS
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
Hi, On 15/09/16 at 19:39 +0200, Santiago Vila wrote: > Hello. > > This package is still a headache for my autobuilder. > > On Tue, 19 Jul 2016, Lucas Nussbaum wrote: > > > Indeed it was the equivalent of dpkg-buildpackage -A that > > triggered it. > > Do you mean you could always reproduce with "dpkg-buildpackage -A" > and never with "dpkg-buildpackage"? > > Later you said: > > > [ sysctl tunings ] > > It seems that one of those caused that failure, because, now that I have > > them disabled, it does not fail anymore. > > Are you sure that removing those settings is the real reason it stopped > failing for you? (Would you try a few more times?) > > It still fails for me, randomly, and I'm not using EC2 but KVM on my > own server and KVM on a commercial provider, so my alternate theory is > that it was random before you dropped the settings, and it continues > to be random after dropping the settings. > > This is my historic data: > > Status: failed google-perftools_2.2.1-0.2_amd64-20151025T1748Z > Status: failed google-perftools_2.2.1-0.2_amd64-20151201T1848Z > Status: failed google-perftools_2.2.1-0.2_amd64-20151220T1430Z > Status: failed google-perftools_2.2.1-0.2_amd64-20160101T2221Z > Status: failed google-perftools_2.2.1-0.2_amd64-20160507T1523Z > Status: failed google-perftools_2.2.1-0.2_amd64-20160507T1649Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T055103Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T150752Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151026Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151114Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161241Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151357Z > Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161322Z > Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161612Z > Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161656Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161654Z > Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161043Z > > > Version 2.2.1-0.3 is the first one that does not *always* fail for me. > This is a great achievement indeed. > > Now it builds sometimes, but 3/11 is not a very good ratio. I'm not sure, no. It's indeed possible that it's still failing randomly. Lucas
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
Hello. This package is still a headache for my autobuilder. On Tue, 19 Jul 2016, Lucas Nussbaum wrote: > Indeed it was the equivalent of dpkg-buildpackage -A that > triggered it. Do you mean you could always reproduce with "dpkg-buildpackage -A" and never with "dpkg-buildpackage"? Later you said: > [ sysctl tunings ] > It seems that one of those caused that failure, because, now that I have > them disabled, it does not fail anymore. Are you sure that removing those settings is the real reason it stopped failing for you? (Would you try a few more times?) It still fails for me, randomly, and I'm not using EC2 but KVM on my own server and KVM on a commercial provider, so my alternate theory is that it was random before you dropped the settings, and it continues to be random after dropping the settings. This is my historic data: Status: failed google-perftools_2.2.1-0.2_amd64-20151025T1748Z Status: failed google-perftools_2.2.1-0.2_amd64-20151201T1848Z Status: failed google-perftools_2.2.1-0.2_amd64-20151220T1430Z Status: failed google-perftools_2.2.1-0.2_amd64-20160101T2221Z Status: failed google-perftools_2.2.1-0.2_amd64-20160507T1523Z Status: failed google-perftools_2.2.1-0.2_amd64-20160507T1649Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T055103Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T150752Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151026Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151114Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161241Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T151357Z Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161322Z Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161612Z Status: successful google-perftools_2.2.1-0.3_amd64-20160914T161656Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161654Z Status: failed google-perftools_2.2.1-0.3_amd64-20160914T161043Z Version 2.2.1-0.3 is the first one that does not *always* fail for me. This is a great achievement indeed. Now it builds sometimes, but 3/11 is not a very good ratio. Is the Debian maintainer alive?
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
On 27/08/16 at 12:07 -0700, Aliaksey Kandratsenka wrote: > On Thu, Jul 21, 2016 at 3:18 AM, Santiago Vila wrote: > > severity 831240 important > > reopen 831240 > > > > On Thu, 21 Jul 2016, Lucas Nussbaum wrote: > > > >> I recently discovered that the official Debian images on AWS EC2 include > >> some sysctl tunings (see > >> https://github.com/andsens/bootstrap-vz/pull/256/commits/06da309895f69573996a4c1ff027f999155b876b#diff-43081b58ccf1565f80325d26c36d7c57R18 > >> ) > >> > >> It seems that one of those caused that failure, because, now that I have > >> them disabled, it does not fail anymore. > >> > >> I'm closing this bug, sorry for the noise. > > > > Hmm. Failure to build from source is still a bug. > > Indeed, I would like to debug this some more (against latest > gperftools). Can somebody provide some instructions how to get that > AWS image necessary for reproduction ? Hi, You could try to apply the sysctl settings described in https://github.com/andsens/bootstrap-vz/pull/256/commits/06da309895f69573996a4c1ff027f999155b876b#diff-43081b58ccf1565f80325d26c36d7c57R18 and see if you can reproduce it. I don't think that there's an easy way to get that AWS image without using AWS. Lucas
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
On Thu, Jul 21, 2016 at 3:18 AM, Santiago Vila wrote: > severity 831240 important > reopen 831240 > > On Thu, 21 Jul 2016, Lucas Nussbaum wrote: > >> I recently discovered that the official Debian images on AWS EC2 include >> some sysctl tunings (see >> https://github.com/andsens/bootstrap-vz/pull/256/commits/06da309895f69573996a4c1ff027f999155b876b#diff-43081b58ccf1565f80325d26c36d7c57R18 >> ) >> >> It seems that one of those caused that failure, because, now that I have >> them disabled, it does not fail anymore. >> >> I'm closing this bug, sorry for the noise. > > Hmm. Failure to build from source is still a bug. Indeed, I would like to debug this some more (against latest gperftools). Can somebody provide some instructions how to get that AWS image necessary for reproduction ?
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
severity 831240 important reopen 831240 On Thu, 21 Jul 2016, Lucas Nussbaum wrote: > I recently discovered that the official Debian images on AWS EC2 include > some sysctl tunings (see > https://github.com/andsens/bootstrap-vz/pull/256/commits/06da309895f69573996a4c1ff027f999155b876b#diff-43081b58ccf1565f80325d26c36d7c57R18 > ) > > It seems that one of those caused that failure, because, now that I have > them disabled, it does not fail anymore. > > I'm closing this bug, sorry for the noise. Hmm. Failure to build from source is still a bug. Ok, some people do not consider a FTBFS to be serious if the failure does not happen in the official buildds, but this fact should only make the bug non-RC, not make it a non-bug. OTOH, if there is really a good reason to fail in this non-standard environment, then the bug should be reassigned to whatever package setups the non-standard environment (bootstrap-vz?), not just closed. Thanks.
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
On Tue, Jul 19, 2016 at 1:29 PM, Lucas Nussbaum wrote: > Hi Aliaksey, > > On 16/07/16 at 12:28 +0200, Santiago Vila wrote: >> On Fri, 15 Jul 2016, Aliaksey Kandratsenka wrote: >> >> > Thanks for reporting the issue. I just tried to reproduce the problem >> > on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to >> > hit this issue. This maybe indicates that kernel matters or maybe >> > there is something else in the host that is relevant. >> >> For the record: While checking for "dpkg-buildpackage -A", I was also >> able to reproduce this problem in the past: >> >> Running death test 0...make[2]: *** wait: No child processes. Stop. >> make[2]: *** Waiting for unfinished jobs >> make[2]: *** wait: No child processes. Stop. >> make[1]: *** wait: No child processes. Stop. >> make[1]: *** Waiting for unfinished jobs >> make[1]: *** wait: No child processes. Stop. >> make: *** wait: No child processes. Stop. >> make: *** Waiting for unfinished jobs >> make: *** wait: No child processes. Stop. >> Build killed with signal TERM after 150 minutes of inactivity >> >> I'm also using sbuild, triggered by a cron job. > > Do you still need help to reproduce the issue? Indeed it was the > equivalent of dpkg-buildpackage -A that triggered it. I got sbuild set up on my box (via instructions at https://wiki.debian.org/sbuild) and even under sbuild I am unable to reproduce the problem. So maybe this is something with kernel? Should I try to get, say recent stable installed under KVM? I am running on fairly up-to-date unstable distro.
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
Hi Aliaksey, On 16/07/16 at 12:28 +0200, Santiago Vila wrote: > On Fri, 15 Jul 2016, Aliaksey Kandratsenka wrote: > > > Thanks for reporting the issue. I just tried to reproduce the problem > > on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to > > hit this issue. This maybe indicates that kernel matters or maybe > > there is something else in the host that is relevant. > > For the record: While checking for "dpkg-buildpackage -A", I was also > able to reproduce this problem in the past: > > Running death test 0...make[2]: *** wait: No child processes. Stop. > make[2]: *** Waiting for unfinished jobs > make[2]: *** wait: No child processes. Stop. > make[1]: *** wait: No child processes. Stop. > make[1]: *** Waiting for unfinished jobs > make[1]: *** wait: No child processes. Stop. > make: *** wait: No child processes. Stop. > make: *** Waiting for unfinished jobs > make: *** wait: No child processes. Stop. > Build killed with signal TERM after 150 minutes of inactivity > > I'm also using sbuild, triggered by a cron job. Do you still need help to reproduce the issue? Indeed it was the equivalent of dpkg-buildpackage -A that triggered it. Lucas
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
On Fri, 15 Jul 2016, Aliaksey Kandratsenka wrote: > Thanks for reporting the issue. I just tried to reproduce the problem > on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to > hit this issue. This maybe indicates that kernel matters or maybe > there is something else in the host that is relevant. For the record: While checking for "dpkg-buildpackage -A", I was also able to reproduce this problem in the past: Running death test 0...make[2]: *** wait: No child processes. Stop. make[2]: *** Waiting for unfinished jobs make[2]: *** wait: No child processes. Stop. make[1]: *** wait: No child processes. Stop. make[1]: *** Waiting for unfinished jobs make[1]: *** wait: No child processes. Stop. make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. Build killed with signal TERM after 150 minutes of inactivity I'm also using sbuild, triggered by a cron job. Thanks.
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
Thanks for reporting the issue. I just tried to reproduce the problem on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to hit this issue. This maybe indicates that kernel matters or maybe there is something else in the host that is relevant. Can you please share more details on how I can reproduce this? Also let me note once again that 2.2.1 is much outdated and latest upstream is 2.4, although I don't think we fixed anything related to death tests recently. On Thu, Jul 14, 2016 at 3:06 AM, Lucas Nussbaum wrote: > Source: google-perftools > Version: 2.2.1-0.3 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160714 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): >> PASS: malloc_extension_debug_test >> PASS >> PASS: memalign_debug_unittest >> PASS >> PASS: realloc_debug_unittest >> make[2]: *** wait: No child processes. Stop. >> make[2]: *** Waiting for unfinished jobs >> make[2]: *** wait: No child processes. Stop. >> make[1]: *** wait: No child processes. Stop. >> make[1]: *** Waiting for unfinished jobs >> make[1]: *** wait: No child processes. Stop. >> make: *** wait: No child processes. Stop. >> make: *** Waiting for unfinished jobs >> make: *** wait: No child processes. Stop. >> E: Caught signal ‘Terminated’: terminating immediately >> Running death test 0Build killed with signal TERM after 150 minutes of >> inactivity > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2016/07/14/google-perftools_2.2.1-0.3_unstable_gcc5.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#831240: google-perftools: FTBFS: Running death test 0 hangs
Source: google-perftools Version: 2.2.1-0.3 Severity: serious Tags: stretch sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20160714 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > PASS: malloc_extension_debug_test > PASS > PASS: memalign_debug_unittest > PASS > PASS: realloc_debug_unittest > make[2]: *** wait: No child processes. Stop. > make[2]: *** Waiting for unfinished jobs > make[2]: *** wait: No child processes. Stop. > make[1]: *** wait: No child processes. Stop. > make[1]: *** Waiting for unfinished jobs > make[1]: *** wait: No child processes. Stop. > make: *** wait: No child processes. Stop. > make: *** Waiting for unfinished jobs > make: *** wait: No child processes. Stop. > E: Caught signal ‘Terminated’: terminating immediately > Running death test 0Build killed with signal TERM after 150 minutes of > inactivity The full build log is available from: http://people.debian.org/~lucas/logs/2016/07/14/google-perftools_2.2.1-0.3_unstable_gcc5.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.
