[cmake-developers] [CPack] CPackDeb and fakeroot

Tue Aug 25 10:48:33 EDT 2015

Hi guys,

Some of my thoughts about this one.

2015-08-25 15:42 GMT+02:00 Raffi Enficiaud <raffi.enficiaud at mines-paris.org>
:

> Hi Domen, Brad and CMake developers,
>
> I am trying to create my packages in Launchpad, which uses a pbuilder
> environment for building the packages, directly using CMake>=3.3 (which
> contains the nice recent fixes).
>
> I got the following error when I execute the build of a source package
> from pbuilder:
>
> ------------
> CPack Error:
> /build/cmake-AHTLnO/cmake-3.3travisci1/Source/CPack/cmCPackDebGenerator.cxx:483
> Problem running tar command: /usr/bin/fakeroot "/usr/bin/cmake" -E tar czf
> data.tar.gz
> Please check /«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log for
> errors
> ------------
>
> The full logs for the curious ppl may be found here:
>
> https://launchpadlibrarian.net/215456337/buildlog_ubuntu-trusty-amd64.yayi_0.8.8.1_BUILDING.txt.gz

Yes but the may be interesting part should be in:
/«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log

which is not displayed in the previous file.

>
> Basically in my case, the debian/rule file calls cmake and cpack to
> generate the deb packages.
> pbuilder mimics a clean build environment that is used on Launchpad for
> isolating the build, and I believe (not sure) it calls fakeroot under the
> hood.
>

pbuilder calls fakeroot for sure:
In your log one can see:

make[1]: Leaving directory `/«BUILDDIR»/build_dir'
 fakeroot debian/rules binary-arch
touch debian/files
cpack --version
cpack version 3.3.20150824

And Yes CPackDeb is calling fakeroot iff fakeroot is detected and present
on the system.
It is detected in CPackDeb.cmake and push up in parent scope to
cmCPackGenerator.cxx
as "GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE"

>
> To my understanding fakeroot is a "workaround" to have the proper
> credentials in the tar of the .deb packages since the libarchive used in
> cmake was not allowing that at that time:
>
> - http://public.kitware.com/Bug/view.php?id=11766
> - http://public.kitware.com/Bug/view.php?id=13118
> - http://public.kitware.com/Bug/view.php?id=12901

The introduction of fakeroot usage for CPackDeb was made for that issue:
http://public.kitware.com/Bug/view.php?id=10325
with the small follow-up you cited:
http://public.kitware.com/Bug/view.php?id=13118

>
> I am wondering if, instead of always using fakeroot:
> - there is now the possibility to set the user in libarchive (even if it
> is the case, this would mean that cmake -E tar is able to understand those
> options)
> - if we can get rid of the fakeroot in some circumstances? eg. a variable
> that would avoid using the fakeroot or detecting that the user is already
> root
>

fakeroot is not used unless it is detected as installed on the system.
The question in your case is, why is fakeroot installed AND not working
when used in pbuilder.

My guess is that pbuilder is ALREADY calling fakeroot and that fakeroot
cannot be called from within fakerootED environnement (nested fakeroot is
unsupported).

I would suggest checking (in CPackDeb generator code) whether if CPack has
been called in a fakerootED environment. This can be done by checking
whether if "FAKEROOTKEY" env var is defined or not.
If fakeroot is already in action then one should not call fakeroot again
(whatever the fakerootED user is).

The #13700 bugs referred hereafter confirms this kind of issue:
http://public.kitware.com/Bug/view.php?id=13700

> - unifying the tool used for creating the tar: from the code in
> cmCPackDebGenerator.cxx, some compression schemes use the native tar while
> some others use the cmake tar.
>

This is explained in Source/CPack/cmCPackDebGenerator.cxx
// NOTE:
// A debian package .deb is simply an 'ar' archive. The only subtle
difference
// is that debian uses the BSD ar style archive whereas most Linux distro
have
// a GNU ar.
// See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 for more info
// Therefore we provide our own implementation of a BSD-ar:
static int ar_append(const char*archive,const std::vector<std::string>&
files);

I don't really known whether if this argument still apply nowadays
and I let you read the discussion on bugs.debian.org.

> What would be the best option for you?
>

I let Domen answer for that, I was just jumping in to let you all know the
bits of the story I remember.

> I believe it would address this issues already in the backlog (and help
> ppl deploy things on Launchpad with cmake):
> - http://public.kitware.com/Bug/view.php?id=13700
> - http://public.kitware.com/Bug/view.php?id=11766

Like I said 13700 should be easy to fix by avoiding nested fakeroot call.

11766 is another story.
I think that adding ownership option to cmake -E tar may be useful but not
that urgent considering
that most of these issues can be fixed in another easy mean.

That said libarchive now seems to support "BSD tar"
https://github.com/libarchive/libarchive/tree/master/tar
and ownership using "set_ownership(struct archive_write_disk *)" API.

so may be it's possible to get rid of the BSD tar implementation embedded in
cmCPackDebGenerator.cxx and add appropriate calls to libarchive.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150825/f8c08ad8/attachment.html>