MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013386CMakeCPackpublic2012-07-09 08:222016-06-10 14:31
ReporterJohannes Wienke 
Assigned ToRaffi Enficiaud 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformallOSLinux/UbuntuOS Versionall
Product VersionCMake-2-8 
Target VersionCMake 2.8.12Fixed in Version 
Summary0013386: CPack-generated Debian packages do not comply to Debian policy (discovered via lintian)
DescriptionRunning lintian on a CPack-generated Debian package produces the following output (some warnings not related to CPack bugs have been removed; our package name is "rsb0.7", the library is called "librsbcore.so"):

E: rsb0.7: control-file-has-bad-permissions md5sums 0640 != 0644
E: rsb0.7: no-copyright-file [1]
W: rsb0.7: non-standard-dir-perm usr/ 0700 != 0755 [2]
W: rsb0.7: non-standard-dir-perm usr/bin/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/include/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/lib/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/share/ 0700 != 0755
E: rsb0.7: md5sums-lists-nonexisting-file usr/lib/librsbcore.so [3]
E: rsb0.7: no-shlibs-control-file usr/lib/librsbcore.so.0.7.0
E: rsb0.7: postinst-must-call-ldconfig usr/lib/librsbcore.so.0.7.0

Notes:
[1] We use SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/COPYING.txt"), therefore CPack should use the specified file as package license file
[2] The exact permissions and therefore error message depend on the current umask. CPack should set a fixed, compliant umask independently of what the user happens to use.
[3] This is caused by symlinking usr/lib/librsbcore.so to usr/lib/librsbcore.so.0.7.0 which happens when sonames and -versions are used in CMake.
Steps To ReproduceOur CMake and CPack files are a bit length to include here (viewable at https://code.cor-lab.org/projects/rsb/repository/entry/trunk/cpp/core/CMakeLists.txt [^]).

We called cpack (or make package) with fakeroot to achieve correct user- and group-ids.

Packaging any CMake based library project should produce identical warnings.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-07-09 08:22Johannes WienkeNew Issue
2012-08-14 17:21Eric NOULARDAssigned To => Eric NOULARD
2012-08-14 17:21Eric NOULARDStatusnew => assigned
2012-08-14 17:21Eric NOULARDTarget Version => CMake 2.8.10
2012-10-14 13:11Eric NOULARDTarget VersionCMake 2.8.10 => CMake 2.8.11
2012-10-14 13:31Eric NOULARDNote Added: 0031230
2013-05-17 09:33Robert MaynardTarget VersionCMake 2.8.11 => CMake 2.8.12
2014-10-14 13:07Jason TurnerNote Added: 0037031
2014-10-14 13:07Jason TurnerNote Edited: 0037031bug_revision_view_page.php?bugnote_id=37031#r1591
2014-10-15 01:42Eric NOULARDAssigned ToEric NOULARD => Micha Hergarden
2014-10-15 01:56Eric NOULARDNote Added: 0037033
2014-10-15 01:58Eric NOULARDNote Added: 0037034
2015-03-11 10:33zjesNote Added: 0038201
2015-05-18 03:35Raffi EnficiaudNote Added: 0038756
2015-05-18 11:42Domen VrankarNote Added: 0038768
2015-09-14 02:34Eran IfrahNote Added: 0039409
2015-09-14 17:23Domen VrankarNote Added: 0039424
2015-09-20 10:17Raffi EnficiaudAssigned ToMicha Hergarden => Raffi Enficiaud
2015-09-20 17:34Domen VrankarNote Added: 0039453
2015-09-20 17:37Domen VrankarNote Edited: 0039453bug_revision_view_page.php?bugnote_id=39453#r1907
2016-06-10 14:28Kitware RobotNote Added: 0042085
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0031230)
Eric NOULARD   
2012-10-14 13:31   
Hi there,

I won't be able to handle this for 2.8.10.
I'll try for 2.8.11.
(0037031)
Jason Turner   
2014-10-14 13:07   
FYI, this has become a real problem now, with packages installed via the Ubuntu Software Center (default handler for .deb files on Ubuntu now) seeing the packages as inferior and warning the user that it might do horrible things to their systems.

See the note here: http://stackoverflow.com/questions/17796670/cpack-deb-generator-control-file-has-bad-permissions-mdsums-0644-0644 [^]
(0037033)
Eric NOULARD   
2014-10-15 01:56   
Hi Jason,

I'm in the process of a take over on my CPack activities, see:
see:http://public.kitware.com/pipermail/cmake-developers/2014-October/011606.html [^]

Sorry for the delay.

Micha has volunteered to try to tackle this bug.
(0037034)
Eric NOULARD   
2014-10-15 01:58   
Note for Micha:

The good way to check whether if a deb package is "good" is to call
the debian "lintian" tool on the generated package:
https://lintian.debian.org/ [^]
(0038201)
zjes   
2015-03-11 10:33   
Hi, this issue still active?

Anyway, this patch fixes [3] "md5sums" file for symlinks (just ignores symlinks... in dh_md5sums used "find . -type f", only regular files)

-------------------

diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx
index 0a64bd5..f941301 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -498,6 +498,8 @@ int cmCPackDebGenerator::createDeb()
       for ( fileIt = packageFiles.begin();
             fileIt != packageFiles.end(); ++ fileIt )
       {
+ if (cmsys::SystemTools::FileIsSymlink(*fileIt))
+ continue;
       cmd = "\"";
       cmd += cmakeExecutable;
       cmd += "\" -E md5sum \"";
(0038756)
Raffi Enficiaud   
2015-05-18 03:35   
The latests changes in CPackDEB fix the permission issue of the control file.
(0038768)
Domen Vrankar   
2015-05-18 11:42   
This is the patch that fixes control file permissions issue:
www.cmake.org/gitweb?p=cmake.git;a=commit;h=fdfe458
(0039409)
Eran Ifrah   
2015-09-14 02:34   
Any reason why the patch that fixes the symlink could not be applied?
Atm, deb packages generated by CPack are generating errors when running lintian on the deb file. This happens because CPack's deb generator adds the symblinks into the md5sums file and the lintian report this as an error of type: "md5sums-lists-nonexistent-file"
(0039424)
Domen Vrankar   
2015-09-14 17:23   
I've just missed it... Sorry about that.
Raffi already sent a new patch to mailing list that fixes this issue:
http://www.cmake.org/pipermail/cmake-developers/2015-September/026365.html [^]

I'll apply it as soon as other CPackDEB patches are merged to master.
(0039453)
Domen Vrankar   
2015-09-20 17:34   
(edited on: 2015-09-20 17:37)
Applied patch for symlink exclusion from checksum calculation:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7c7874c8 [^]

This fixes [3].

For [1] copyright file can be added to package like this:
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/license.txt
        DESTINATION share/doc/mylib-applications
        COMPONENT applications
        RENAME copyright)
where mylib-applications is package name and license.txt is copyright file containing at least "Copyright 2015 Firstname Lastname <address@example.com>" otherwise lintian test fails (must be installed on /usr/share/doc/<package_name> location and contain above text somewhere in the copyright file).
Since this is a bit inconvenient CPACK_DEBIAN_FILE_COPYRIGHT could be introduced as a an alternative to above install command. I think that CPACK_RESOURCE_FILE_LICENSE variable is not appropriate for this since its description states that license file will not be installed and also debian copyright requires a certain format.

For [2] this is a issue only with automatically generated directories and those can be created with install command and whichever permissions we require.
As a convenience variable similar to what CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION (and it's component alternative) does for control files could be introduced that would force certain permissions on directories/files the way lintian enforces them.
(0042085)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.