Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-17 Thread Domen Vrankar 
> Please find attached the "feature" based onto 68dba7f. I added the variable
> CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart
> for controlling strict behaviour on the files added to control.tar.gz .

Thanks, applied and squashed patches with some changes to
cmArchiveWrite as it was causing compiler warnings regarding signed
unsigned conversions:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3b099fd

> PS.: what about the other patches?

I'll apply them as soon as this feature is merged to master.

Thanks,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-17 Thread Raffi Enficiaud 

Le 17/09/15 21:21, Domen Vrankar a écrit :

Please find attached the "feature" based onto 68dba7f. I added the variable
CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart
for controlling strict behaviour on the files added to control.tar.gz .


Thanks, applied and squashed patches with some changes to
cmArchiveWrite as it was causing compiler warnings regarding signed
unsigned conversions:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3b099fd


PS.: what about the other patches?


I'll apply them as soon as this feature is merged to master.


Super, thanks!

Raffi


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-15 Thread Raffi Enficiaud 

Le 15/09/15 08:43, Domen Vrankar a écrit :

2015-09-14 23:49 GMT+02:00 Raffi Enficiaud :

Le 14/09/15 23:34, Domen Vrankar a écrit :


Thank you. However those two test are not mutually exclusive. I think
having
them on lintian is also a good thing.



I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?



That's very good that it fails :)

I tested on Ubuntu 14.04, maybe Debian distributions are even more strict.
Apparently the files that "file(WRITE ...)" created on your system are with
775. I believe the problem lies in the "file(" commands rather than on a
different version of lintian.

OTOH, I can see from this:

https://lintian.debian.org/tags/control-file-has-bad-permissions.html

that all files should have at least a permission mask set to ~S_IWGRP &
~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so
that the executable bit is left unchanged and the write bit is cleared for
group and others (755 and 644).

What do you think?


You are correct. I've reinstalled my virtual machine and retested with
"control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would
seem that there was an issue in my testing environment - before this
did not work as expected on my machine. Same goes for default
permissions being 664/775 instead of 644/755.

I would keep md5 checksum file permissions on 644 with SetPermissions
and add SetPermissionsMask from above for the rest of control files.
Would you agree?


From this (thanks to lintian now I have the proper link :) )

https://lintian.debian.org/tags/control-file-has-bad-permissions.html
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

all control files:
- should be owned by root:root (+ I would say uid/gid 0/0, because root 
may be mapped) which is the case now

- should be 755 or 644, depending if they are executable or not

The number of files that should be 755 are limited to (according to 
linitian) config, postinst, postrm, preinst, and prerm. All others 
should be 644.


So I would say without loss of generality, we can set the permission to 
644 except for those config, postinst... files . I can send you a patch 
based on 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the 
doc accordingly).


Is that good for you?
Raffi

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-15 Thread Domen Vrankar 
2015-09-14 23:49 GMT+02:00 Raffi Enficiaud :
> Le 14/09/15 23:34, Domen Vrankar a écrit :
>>>
>>> Thank you. However those two test are not mutually exclusive. I think
>>> having
>>> them on lintian is also a good thing.
>>
>>
>> I've tried your test change before but lintian test complained that
>> 775 are invalid permissions (should be 755). Is this caused by a
>> different version of lintian or should I just modify your test to use
>> 755 permissions and apply that?
>>
>
> That's very good that it fails :)
>
> I tested on Ubuntu 14.04, maybe Debian distributions are even more strict.
> Apparently the files that "file(WRITE ...)" created on your system are with
> 775. I believe the problem lies in the "file(" commands rather than on a
> different version of lintian.
>
> OTOH, I can see from this:
>
> https://lintian.debian.org/tags/control-file-has-bad-permissions.html
>
> that all files should have at least a permission mask set to ~S_IWGRP &
> ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so
> that the executable bit is left unchanged and the write bit is cleared for
> group and others (755 and 644).
>
> What do you think?

You are correct. I've reinstalled my virtual machine and retested with
"control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would
seem that there was an issue in my testing environment - before this
did not work as expected on my machine. Same goes for default
permissions being 664/775 instead of 644/755.

I would keep md5 checksum file permissions on 644 with SetPermissions
and add SetPermissionsMask from above for the rest of control files.
Would you agree?

Thanks,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-15 Thread Domen Vrankar 
> From this (thanks to lintian now I have the proper link :) )
>
> https://lintian.debian.org/tags/control-file-has-bad-permissions.html
> https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
>
> all control files:
> - should be owned by root:root (+ I would say uid/gid 0/0, because root may
> be mapped) which is the case now
> - should be 755 or 644, depending if they are executable or not
>
> The number of files that should be 755 are limited to (according to
> linitian) config, postinst, postrm, preinst, and prerm. All others should be
> 644.
>
> So I would say without loss of generality, we can set the permission to 644
> except for those config, postinst... files . I can send you a patch based on
> 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc
> accordingly).
>
> Is that good for you?

Sounds good.
Those rules are written as guidelines and I'm not certain how often
they are broken so could you also add a single variable for toggling
between defaults described above and using file permissions as
provided?

Thanks,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-15 Thread Raffi Enficiaud 

Le 15/09/15 11:00, Domen Vrankar a écrit :


Sounds good.
Those rules are written as guidelines and I'm not certain how often
they are broken so could you also add a single variable for toggling
between defaults described above and using file permissions as
provided?



I think those are not really just "guidelines" if you want ever your 
source package be published with a cmake toolchain (severity "serious").


Please find attached the "feature" based onto 68dba7f. I added the 
variable CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its 
component counterpart for controlling strict behaviour on the files 
added to control.tar.gz .


I added a test over lintian again, as I think lintian is the official 
tool for checking those things.


Please note that I was not able to check the produced documentation 
(although I updated it). I would be happy if you can do it, otherwise I 
will do tonight.


Thanks!
Raffi

PS.: what about the other patches?
>From 36f273c1e07651060deaea3b576150151ed65818 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Tue, 15 Sep 2015 11:26:53 +0200
Subject: [PATCH] fixUp! permissions on control files and strict Debian rules
 variable

---
 Modules/CPackDeb.cmake  | 30 ++---
 Source/CPack/cmCPackDebGenerator.cxx| 39 ++---
 Tests/CPackComponentsDEB/CMakeLists.txt | 19 
 3 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 754df91..43b49f8 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -330,9 +330,30 @@
 #  .. note::
 #
 #The original permissions of the files will be used in the final
-#package. In particular, the scripts should have the proper executable
+#package unless the variable
+#:variable:`CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION` is set.
+#In particular, the scripts should have the proper executable
 #flag prior to the generation of the package.
-
+#
+# .. variable:: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
+#   CPACK_DEBIAN__PACKAGE_CONTROL_STRICT_PERMISSION
+#
+#  This variable indicates if the Debian policy on control files should be
+#  strictly followed.
+#
+#  * Mandatory : NO
+#  * Default   : FALSE
+#
+#  Usage::
+#
+#   set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)
+#
+#  .. note::
+#
+#This overrides the permissions on the original files, following the rules
+#set by Debian policy
+#
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
+#
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
@@ -636,7 +657,7 @@ function(cpack_deb_prepare_package_vars)
   # Are we packaging components ?
   if(CPACK_DEB_PACKAGE_COMPONENT)
 # override values with per component version if set
-foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA")
+foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA" 
"PACKAGE_CONTROL_STRICT_PERMISSION")
   if(CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_})
 set(CPACK_DEBIAN_${VAR_NAME_} 
"${CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}}")
   endif()
@@ -658,6 +679,7 @@ function(cpack_deb_prepare_package_vars)
  message("CPackDeb:Debug: CPACK_PACKAGE_FILE_NAME   = 
${CPACK_PACKAGE_FILE_NAME}")
  message("CPackDeb:Debug: CPACK_PACKAGE_INSTALL_DIRECTORY   = 
${CPACK_PACKAGE_INSTALL_DIRECTORY}")
  message("CPackDeb:Debug: CPACK_TEMPORARY_PACKAGE_FILE_NAME = 
${CPACK_TEMPORARY_PACKAGE_FILE_NAME}")
+ message("CPackDeb:Debug: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION = 
${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}")
   endif()
 
   # For debian source packages:
@@ -694,6 +716,8 @@ function(cpack_deb_prepare_package_vars)
   set(GEN_CPACK_DEBIAN_PACKAGE_PROVIDES "${CPACK_DEBIAN_PACKAGE_PROVIDES}" 
PARENT_SCOPE)
   set(GEN_CPACK_DEBIAN_PACKAGE_REPLACES "${CPACK_DEBIAN_PACKAGE_REPLACES}" 
PARENT_SCOPE)
   set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA 
"${CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA}" PARENT_SCOPE)
+  set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
+  "${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}" PARENT_SCOPE)
   set(GEN_WDIR "${WDIR}" PARENT_SCOPE)
 endfunction()
 
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 981d86d..b497b65 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -576,9 +576,18 @@ int cmCPackDebGenerator::createDeb()
 control_tar.SetUNAME("root");
 control_tar.SetGNAME("root");
 
-// set md5sum file permissions to RW-R--R-- so that deb lintian
-// doesn't warn about it
-control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+// permissions are set according to
+// https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
+// and
+//

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-14 Thread Raffi Enficiaud 

Le 14/09/15 11:51, Raffi Enficiaud a écrit :

Hi Brad and Domen and others,

I just realized that the permissions for the extra control files should
be set in a different way than for the md5sum checksum file.

Please find attached the patch correcting this and the corresponding
test that fires the problem.

Best,
Raffi



It's better with the attachment, sorry.

Raffi

>From 45fa572012ae2140a8b81d56c8d4b0b10e30c19f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Mon, 14 Sep 2015 11:42:33 +0200
Subject: [PATCH] cpackdeb: reset extra file permissions to their original

Adding a note about the file permissions on the extra files.
---
 Modules/CPackDeb.cmake  |  7 ++-
 Source/CPack/cmCPackDebGenerator.cxx|  4 +++-
 Tests/CPackComponentsDEB/CMakeLists.txt | 14 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 970a7d0..0ccfee4 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -326,7 +326,12 @@
 #
 #   set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
 #   "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
-
+#
+#  .. note::
+#
+#The original permissions of the files will be used in the final
+#package. In particular, the scripts should have the proper executable
+#flag prior to the generation of the package.
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index dc9fca3..981d86d 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -576,7 +576,7 @@ int cmCPackDebGenerator::createDeb()
 control_tar.SetUNAME("root");
 control_tar.SetGNAME("root");
 
-// set md5sum file permissins to RW-R--R-- so that deb lintian
+// set md5sum file permissions to RW-R--R-- so that deb lintian
 // doesn't warn about it
 control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
@@ -597,6 +597,8 @@ int cmCPackDebGenerator::createDeb()
   this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA");
 if( controlExtra )
   {
+  // permissions are now controlled by the original file permissions
+  control_tar.SetPermissions(-1);
   std::vector controlExtraList;
   cmSystemTools::ExpandListArgument(controlExtra, controlExtraList);
   for(std::vector::iterator i = controlExtraList.begin();
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index 5c4eeab..c25e33a 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -80,6 +80,20 @@ set(CPACK_COMPONENT_HEADERS_DESCRIPTION
 # depend on the libraries component.
 set(CPACK_COMPONENT_HEADERS_DEPENDS libraries)
 
+# creates preinst/prerm scripts with specific permissions. Those permissions
+# (especially executable) should be in the final archive
+find_program(CHMOD_PROG chmod)
+if(CHMOD_PROG)
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst")
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm")
+  execute_process(COMMAND ${CHMOD_PROG} a+x 
${CMAKE_CURRENT_BINARY_DIR}/preinst)
+  execute_process(COMMAND ${CHMOD_PROG} a+x ${CMAKE_CURRENT_BINARY_DIR}/prerm)
+
+  set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_EXTRA
+  "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
+endif()
+
+
 # We may use the CPack specific config file in order
 # to tailor CPack behavior on a CPack generator specific way
 # (Behavior would be different for RPM or TGZ or DEB ...)
-- 
1.9.1

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-14 Thread Raffi Enficiaud 

Le 14/09/15 23:34, Domen Vrankar a écrit :

Thank you. However those two test are not mutually exclusive. I think having
them on lintian is also a good thing.


I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?



That's very good that it fails :)

I tested on Ubuntu 14.04, maybe Debian distributions are even more 
strict. Apparently the files that "file(WRITE ...)" created on your 
system are with 775. I believe the problem lies in the "file(" commands 
rather than on a different version of lintian.


OTOH, I can see from this:

https://lintian.debian.org/tags/control-file-has-bad-permissions.html

that all files should have at least a permission mask set to ~S_IWGRP & 
~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), 
so that the executable bit is left unchanged and the write bit is 
cleared for group and others (755 and 644).


What do you think?

Raffi



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-14 Thread Raffi Enficiaud 

Hi Domen,

Thank you. However those two test are not mutually exclusive. I think 
having them on lintian is also a good thing.


Best and thanks,
Raffi

Le 14/09/15 23:19, Domen Vrankar a écrit :

I just realized that the permissions for the extra control files should
be set in a different way than for the md5sum checksum file.

Please find attached the patch correcting this and the corresponding
test that fires the problem.


Thanks, applied the fix:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f

I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your
test as I am trying to put new tests there.

Thanks,
Domen




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-14 Thread Domen Vrankar 
>> I just realized that the permissions for the extra control files should
>> be set in a different way than for the md5sum checksum file.
>>
>> Please find attached the patch correcting this and the corresponding
>> test that fires the problem.

Thanks, applied the fix:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f

I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your
test as I am trying to put new tests there.

Thanks,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-14 Thread Domen Vrankar 
> Thank you. However those two test are not mutually exclusive. I think having
> them on lintian is also a good thing.

I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?

Regards,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-11 Thread Domen Vrankar 
> I have made the following changes in order to:
> - support the UID/GID/UNAME/GNAME and permission on tar files at creation
> time
> - using directly libarchive in CPackDeb
> - removing completely the need of fakeroot

Applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45

I've fixed permission mask code in patch 2 and 3. Please confirm that
it works OK in your environment.

I've also removed permission mask setting for directories and files as
I am not certain that it belongs there - it wasn't there before and
user can always change permissions with install command. Issue with
default permissions being 775 is system default related and occurs
only with directories that are automatically created - directories
created with install command get permission 755 which is acceptable
for deb packages.
I believe that this inconsistency should be fixed elsewhere by adding
possibility to set global default directory permissions.

> Is it on time for 3.4 freeze?

Feature freeze was announced for Oct, 1 so it should make it in 3.4

Regards,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

2015-09-11 Thread Raffi Enficiaud 

Le 11/09/15 21:34, Domen Vrankar a écrit :

I have made the following changes in order to:
- support the UID/GID/UNAME/GNAME and permission on tar files at creation
time
- using directly libarchive in CPackDeb
- removing completely the need of fakeroot


Applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45


Many thanks, Domen!



I've fixed permission mask code in patch 2 and 3. Please confirm that
it works OK in your environment.


Should do, I will monitor the test this week end.



I've also removed permission mask setting for directories and files as
I am not certain that it belongs there - it wasn't there before and
user can always change permissions with install command. Issue with
default permissions being 775 is system default related and occurs
only with directories that are automatically created - directories
created with install command get permission 755 which is acceptable
for deb packages.
I believe that this inconsistency should be fixed elsewhere by adding
possibility to set global default directory permissions.



You're right, files in data.tar.xx should not have their permission 
changed from the install command, and having uid/gid root/root should 
not be any different from the behaviour we have now with fakeroot. So I 
am perfectly fine with your changes, thank you!



Is it on time for 3.4 freeze?


Feature freeze was announced for Oct, 1 so it should make it in 3.4


Good!

Cheers,
Raffi

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers