Re: [cmake-developers] Tag signature with expired key

2016-12-12 Thread Alan W. Irwin 

Speculation: the key was renewed locally, but those things have not

been uploaded to the keyservers.

Hi Eike:

The explanation was similar to your above speculation but not quite.
:-) I had not refreshed my local keyring from the keyservers recently.
When I did that refresh (inspired by your speculation), the expired
key "problem" was solved.

So sorry for the noise, but nevertheless there is a useful gpg lesson
to be learned here.  After keys expire they can be renewed (which I
didn't realize before) rather than having to generate a whole new key.
So that means I (or anybody else) should always execute "gpg
--refresh-keys" before complaining about expired keys!

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Tag signature with expired key

2016-12-12 Thread Rolf Eike Beer 
Am Montag, 12. Dezember 2016, 17:26:08 schrieb Alan W. Irwin:
> Hi Brad:
> 
> I attempted to verify a recent tag on the release branch with the
> following results:
> 
> software@raven> git tag --verify v3.7.1
> object db3499df5d06ab2cacc61e9f7720a33456aeafe4
> type commit
> tag v3.7.1
> tagger Brad King  1480522722 -0500
> 
> CMake 3.7.1
> gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID
> 34921684 gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "Brad King"
> gpg: aka "Brad King "
> gpg: aka "[jpeg image of size 4005]"
> gpg: Note: This key has expired!
> Primary key fingerprint: CBA2 3971 357C 2E65 90D9  EFD3 EC8F EF3A 7BFB 4EDA
>   Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5  13D0 2D2C EF10 3492 1684
> error: could not verify the tag 'v3.7.1'
> software@raven> echo $?
> 1
> 
> I assume that error in an otherwise good tag signature is due to the
> fact your key has expired, but I thought it was impossible to sign
> with an expired key?  Anyhow, I thought I should bring this signing by
> an expired key to your attention in case there is something going on
> here that you are not aware of.

Speculation: the key was renewed locally, but those things have not been 
uploaded to the keyservers.

Eikek

signature.asc
Description: This is a digitally signed message part.
-- 

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

[cmake-developers] Tag signature with expired key

2016-12-12 Thread Alan W. Irwin 

Hi Brad:

I attempted to verify a recent tag on the release branch with the
following results:

software@raven> git tag --verify v3.7.1
object db3499df5d06ab2cacc61e9f7720a33456aeafe4
type commit
tag v3.7.1
tagger Brad King  1480522722 -0500

CMake 3.7.1
gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID 34921684
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Good signature from "Brad King"
gpg: aka "Brad King "
gpg: aka "[jpeg image of size 4005]"
gpg: Note: This key has expired!
Primary key fingerprint: CBA2 3971 357C 2E65 90D9  EFD3 EC8F EF3A 7BFB 4EDA
 Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5  13D0 2D2C EF10 3492 1684
error: could not verify the tag 'v3.7.1'
software@raven> echo $?
1

I assume that error in an otherwise good tag signature is due to the
fact your key has expired, but I thought it was impossible to sign
with an expired key?  Anyhow, I thought I should bring this signing by
an expired key to your attention in case there is something going on
here that you are not aware of.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Local target aliases

2016-12-12 Thread Egor Pugin 
> If your trees are so huge or import so many other third-party projects that 
> name collisions are a problem

They are. I'm predicting possible collisions, but it's ok for now.

> ... ExternalProject.

Not much suitable.

---

Ok, I'll try to do some workarounds. Thanks for the replies.

On 12 December 2016 at 20:02, Brad King  wrote:
> On 12/12/2016 11:35 AM, Egor Pugin wrote:
>> So, the original proposal is to make ALIAS & OBJECT targets local. And
>> explicit GLOBAL keyword will make them global again.
>
> An OBJECT library is just like any other target as far as the generated
> build system is concerned, so it needs a globally unique name like any
> other.  The purpose of ALIAS targets is this:
>
> ```
> # some/subdir/CMakeLists.txt
> add_library(lib1 lib1.cpp)
> install(TARGETS lib1 EXPORT lib1Export ${dest_args})
> install(EXPORT lib1Export NAMESPACE Upstream:: ${other_args})
> add_library(Upstream::lib1 ALIAS lib1)
> ```
>
> Then other code in the project can use the name `Upstream::lib1` as
> if it had imported that target (e.g. for test trees that may build
> inside the project or externally).  The other code is not necessarily
> in the same directory, so the global visibility of ALIAS targets is
> an intentional design decision.  Since the aliased target has a globally
> unique name, so would the ALIAS if it is only used to prefix a namespace.
>
> If your trees are so huge or import so many other third-party projects
> that name collisions are a problem, then I suggest breaking it down
> using ExternalProject.
>
> -Brad



-- 
Egor Pugin
-- 

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] CPackProductbuild Scripts

2016-12-12 Thread clinton 


- On Dec 12, 2016, at 9:51 AM, Harry Mallon ha...@codexdigital.com wrote:

> Hello,
> 
> I am messing around with the CPackProductbuild stuff to try to port over what 
> we
> had before. Currently it support undocumented options
> "CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT",
> "CPACK_PREFLIGHT__SCRIPT" and 
> "CPACK_POSTFLIGHT__SCRIPT".
> It looks like these are also supported (also undocumented) in
> CPackPackageMaker. Are these options good names? Do they need to be these for
> ease of porting from Package Maker?

Productbuild inherited those variables by factoring out common pkg support 
between PackageMaker and ProductBuild.
I'm not aware of porting concerns, but I can imagine that being useful.
I think there *are* people using the undocumented variables with PackageMaker.

> Should they start with CPACK_PRODUCTBUILD_*
> as they are not generic?

The other CPack generators have their own variable names for this kind of thing.
And they also have separate code to handle it.  In this case, we have 2 pkg 
based generators with a potential of using the same named variables.

With PackageMaker being deprecated, CPACK_PRODUCTBUILD_* sounds good.

Clint

> 
> If the current names are fine I can prepare a pull req with documentation.
> 
> Yours,
> Harry
> 
> Harry Mallon
> CODEX | Software Engineer
> 60 Poland Street | London | England | W1F 7NT
> E ha...@codexdigital.com | T +44 203 7000 989
> --
> 
> 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
-- 

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] Local target aliases

2016-12-12 Thread Brad King 
On 12/12/2016 11:35 AM, Egor Pugin wrote:
> So, the original proposal is to make ALIAS & OBJECT targets local. And
> explicit GLOBAL keyword will make them global again.

An OBJECT library is just like any other target as far as the generated
build system is concerned, so it needs a globally unique name like any
other.  The purpose of ALIAS targets is this:

```
# some/subdir/CMakeLists.txt
add_library(lib1 lib1.cpp)
install(TARGETS lib1 EXPORT lib1Export ${dest_args})
install(EXPORT lib1Export NAMESPACE Upstream:: ${other_args})
add_library(Upstream::lib1 ALIAS lib1)
```

Then other code in the project can use the name `Upstream::lib1` as
if it had imported that target (e.g. for test trees that may build
inside the project or externally).  The other code is not necessarily
in the same directory, so the global visibility of ALIAS targets is
an intentional design decision.  Since the aliased target has a globally
unique name, so would the ALIAS if it is only used to prefix a namespace.

If your trees are so huge or import so many other third-party projects
that name collisions are a problem, then I suggest breaking it down
using ExternalProject.

-Brad
-- 

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

[cmake-developers] CPackProductbuild Scripts

2016-12-12 Thread Harry Mallon 
Hello,

I am messing around with the CPackProductbuild stuff to try to port over what 
we had before. Currently it support undocumented options
"CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT", 
"CPACK_PREFLIGHT__SCRIPT" and "CPACK_POSTFLIGHT__SCRIPT". 
It looks like these are also supported (also undocumented) in 
CPackPackageMaker. Are these options good names? Do they need to be these for 
ease of porting from Package Maker? Should they start with CPACK_PRODUCTBUILD_* 
as they are not generic?

If the current names are fine I can prepare a pull req with documentation.

Yours,
Harry

Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989
-- 

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] Local target aliases

2016-12-12 Thread Egor Pugin 
So, the original proposal is to make ALIAS & OBJECT targets local. And
explicit GLOBAL keyword will make them global again.

On 12 December 2016 at 18:37, Brad King  wrote:
> On 12/10/2016 04:13 PM, Egor Pugin wrote:
>> Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets 
>> (lib/exe)?
>
> The GLOBAL option is only available with an IMPORTED target:
>
>  https://cmake.org/cmake/help/v3.7/command/add_library.html#imported-libraries
>
> Non-imported targets are always globally visible.
>
>> For consistency it's also possible to add GLOBAL for OBJECT libs.
>
> OBJECT libraries are non-imported and therefore already GLOBAL.
>
>> Goal is to not interfere with same alias names in other dirs.
>
> The purpose of ALIAS targets is to allow in-project code to access a
> non-imported target through the same name as external code might access
> that target when it is imported.  Since non-imported targets are always
> globally visible their names are not allowed to conflict anyway.
>
> -Brad
>



-- 
Egor Pugin
-- 

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] Local target aliases

2016-12-12 Thread Brad King 
On 12/10/2016 04:13 PM, Egor Pugin wrote:
> Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets 
> (lib/exe)?

The GLOBAL option is only available with an IMPORTED target:

 https://cmake.org/cmake/help/v3.7/command/add_library.html#imported-libraries

Non-imported targets are always globally visible.

> For consistency it's also possible to add GLOBAL for OBJECT libs.

OBJECT libraries are non-imported and therefore already GLOBAL.

> Goal is to not interfere with same alias names in other dirs.

The purpose of ALIAS targets is to allow in-project code to access a
non-imported target through the same name as external code might access
that target when it is imported.  Since non-imported targets are always
globally visible their names are not allowed to conflict anyway.

-Brad

-- 

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