Bug#1065167: google-perftools: FTBFS on armhf/armel: static_assert(sizeof(int32_t) == sizeof(off_t), "")
Hi again. So last time I failed to check _TIME_BITS=64. I only tested _FILE_OFFSET_BITS. And 32-bit arm bits continue failing. https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-2&stamp=1709539473&file=log Please also cherry-pick https://github.com/gperftools/gperftools/commit/02adc8ceab39bbeac1f65e10bde577e1753094fa . On Fri, Mar 1, 2024 at 4:32 PM Aliaksey Kandratsenka < alkondrate...@gmail.com> wrote: > Hi. Upstream maintainer here. Please cherry-pick: > https://github.com/gperftools/gperftools/commit/198b3dd2d0b4d83c873b2ce480837edacc0f35ab > > > On Fri, Mar 1, 2024 at 6:15 AM Emanuele Rocca wrote: > >> Source: google-perftools >> Version: 2.15-1.1 >> Severity: serious >> Tags: ftbfs >> User: debian-...@lists.debian.org >> Usertag: time64 >> >> Dear Maintainer, >> >> google-perftools fails to build from source when building with >> -D_TIME_BITS=64 >> on armhf and armel with the following error: >> >> src/mmap_hook.cc:309:31: error: static assertion failed >> 309 | static_assert(sizeof(int32_t) == sizeof(off_t), ""); >> | ^~~~ >> src/mmap_hook.cc:309:31: note: the comparison reduces to ‘(4 == 8)’ >> make[1]: *** [Makefile:5124: src/libtcmalloc_internal_la-mmap_hook.lo] >> Error 1 >> >> The package builds correctly disabling the time64 flags with: >> >> DEB_BUILD_MAINT_OPTIONS=abi=-time64 dpkg-buildpackage >> >>
Bug#1065167: google-perftools: FTBFS on armhf/armel: static_assert(sizeof(int32_t) == sizeof(off_t), "")
Hi. Upstream maintainer here. Please cherry-pick: https://github.com/gperftools/gperftools/commit/198b3dd2d0b4d83c873b2ce480837edacc0f35ab On Fri, Mar 1, 2024 at 6:15 AM Emanuele Rocca wrote: > Source: google-perftools > Version: 2.15-1.1 > Severity: serious > Tags: ftbfs > User: debian-...@lists.debian.org > Usertag: time64 > > Dear Maintainer, > > google-perftools fails to build from source when building with > -D_TIME_BITS=64 > on armhf and armel with the following error: > > src/mmap_hook.cc:309:31: error: static assertion failed > 309 | static_assert(sizeof(int32_t) == sizeof(off_t), ""); > | ^~~~ > src/mmap_hook.cc:309:31: note: the comparison reduces to ‘(4 == 8)’ > make[1]: *** [Makefile:5124: src/libtcmalloc_internal_la-mmap_hook.lo] > Error 1 > > The package builds correctly disabling the time64 flags with: > > DEB_BUILD_MAINT_OPTIONS=abi=-time64 dpkg-buildpackage > >
Bug#1062116: google-perftools: NMU diff for 64-bit time_t transition
Hi. Upstream maintainer here. Thanks for bringing this up. To my knowledge only cpu profiler bits expose time_t. So libtcmalloc-minimal4 is worth keeping as is. On Wed, Jan 31, 2024 at 7:21 AM Graham Inggs wrote: > Source: google-perftools > Version: 2.15-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > google-perftools as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for > google-perftools > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if > information > becomes available that your package should not be included in the > transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect >
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
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
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#777887: google-perftools: diff for NMU version 2.2.1-0.3
Hi all. I'm maintainer of upstream gperftools. Please keep in mind that latest release is gperftools 2.4 and we've moved to github.com/gpeftools/gperftools On Sat, Feb 20, 2016 at 8:49 AM, Julien Cristau wrote: > Control: tags 777887 + patch > Control: tags 777887 + pending > > Dear maintainer, > > I've prepared an NMU for google-perftools (versioned as 2.2.1-0.3) and > am about to upload it. > > Cheers, > Julien
Bug#777887: This is being fixed upstream
Hi. Upstream maintainer here. This is fixed upstream. Albeit not in any released version yet. But notable thing is that only tests are broken on gcc 5, not actual code.