Bug#1065167: google-perftools: FTBFS on armhf/armel: static_assert(sizeof(int32_t) == sizeof(off_t), "")

[Aliaksey Kandratsenka]

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=armel=2.15-2=1709539473=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), "")

[Aliaksey Kandratsenka]

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

[Aliaksey Kandratsenka]

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

[Aliaksey Kandratsenka]

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

[Aliaksey Kandratsenka]

On Tue, Jul 19, 2016 at 1:29 PM, Lucas Nussbaum <lu...@debian.org> 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

[Aliaksey Kandratsenka]

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

[Aliaksey Kandratsenka]

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

[Aliaksey Kandratsenka]

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.