Re: [Ceph-maintainers] Updated ceph backport
On Thu, Oct 16, 2014 at 1:50 AM, Gaudenz Steinlin <gaudenz@debian.org> wrote:
> Philipp Kern <pkern@debian.org> writes:
>
>> On Wed, Oct 15, 2014 at 09:57:13PM +0200, Gaudenz Steinlin wrote:
>>> Why armhf and powerpc are BD-Uninstallable because of
>>> libgoogle-perftools-dev I don't understand at all. This package is
>>> present in wheezy on all released architectures. So this should not stop
>>> a build attempt. Does anyone have more insight into this and can shed
>>> some light on this?
>>
>> Not sure what you looked at, but:
>>
>> libgoogle-perftools-dev | 2.0-2 | wheezy | amd64, i386
>> libgoogle-perftools-dev | 2.2.1-0.2 | jessie | amd64, arm64, armel, armhf, i386, powerpc, ppc64el
>> libgoogle-perftools-dev | 2.2.1-0.2 | sid | amd64, arm64, armel, armhf, i386, powerpc, ppc64el
>>
>> It's by no means available on all release architectures. ;-)
>
> I clicked through from the buildd status page to:
> https://buildd.debian.org/status/package.php?p=google-perftools&suite=wheezy
>
> This page lead me to belive that the package was available on all
> architectures. But you are right that I did not check the actual archive
> contents. So the question is why this package got removed from the
> release. Or looking at the source package and the build logs, the
> information on this page is misleading. Version 2.0-2 never built on
> anything other than amd64 and i386 and the later version 2.0-3 which
> built on powerpc never made it into wheezy.
>
> As google-perftools are optional for ceph, the best fix for this is
> probably to remove the dependency in the backport for the architectures
> not supported in wheezy. This simple patch would probably do it (not
> tested):
FYI, this is probably not the most desirable solution. The main thing
we use gperftools for is the tcmalloc memory allocator; the default
malloc tends to have serious memory fragmentation problems under our
workload.
Not that it won't work, but virtual memory allocations measured in
tens of gigabytes are not unheard-of (versus application-allocated
memory of a few hundred megabytes). I imagine suboptimal malloc is
preferable to not having the Ceph packages, but having the perftools
packages is even better. :)
-Greg
>
> diff --git a/debian/control b/debian/control
> index 96d98fa..f022982 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -26,7 +26,7 @@ Build-Depends: debhelper (>= 9~),
> libexpat1-dev,
> libfcgi-dev,
> libfuse-dev,
> - libgoogle-perftools-dev [i386 amd64 powerpc armhf ppc64el],
> + libgoogle-perftools-dev [i386 amd64],
> libkeyutils-dev,
> libleveldb-dev,
> libnss3-dev,
> diff --git a/debian/rules b/debian/rules
> index b3b0ccb..9941375 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -26,7 +26,7 @@ ifeq ($(DEB_HOST_ARCH), armel)
> endif
>
> # Only selected architectures support gperftools
> -gperftools_archs = i386 amd64 powerpc armhf ppc64el
> +gperftools_archs = i386 amd64
> ifneq (,$(filter $(DEB_HOST_ARCH), $(gperftools_archs)))
> extraopts += --with-tcmalloc
> else
>
> If there are no objections I can push this patch to the repository.
>
> Gaudenz
> _______________________________________________
> Ceph-maintainers mailing list
> Ceph-maintainers@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
Reply to: